Algorithm support

[asitplus-pteufl]

As in the discussion with @dirkx, we fully agree that some recommendation on secure cryptographic algorithms (and min. key lengths) needs to be taken (SOGIS; BSI, NIST etc. whatever fits best in the European context). However, I strongly believe that this is not enough. If we just go for the min. recommendations and allow to exceed them, we will have compatibility issues since all readers will not support all algorithms (e.g. EDDSA is not supported everywhere). Also, certain key-sizes/algorithms will not work due to QR-code size (RSA, but maybe even 512 bit hashes with ECC). COSE already limits the algorithms to practically: https://www.iana.org/assignments/cose/cose.xhtml#algorithms, reading the spec, I extract:

• various RSA variants (not an option)
• ECDSA with NIST curves (not sure if anything larger than 256 bits can be really used), no other curves
• EDDSA (not really sure how wide the support here already is) (for JWS this is not supported by all libs)

So practically, not much else than ES256 remains feasible (maybe ES384 or even ES512 if the size permits it).

What are your thoughts about this?

[dirkx]

So lets recommend ECDSA for the first version of this spec; with at least 256 bits (as per SOG-IS) - and limit this to NIST P256 or brainpool ?

[jschlyter]

Using only ES256 for the first version of this spec makes sense at this point. Do we want test vectors for RSA to better understand the sizes even though we never plan to use it?

[dirkx]

So ES256 is ECDSA with NIST P256 (SecP256k1). The US curve set.

And yes - think that is very wise to have RSA examples - as it documents the size issue in plain sight (including the indirect issues for RSA 4096 CSCA whose DSC signed cert cannot be included in the barcode).

[asitplus-pteufl]

agree on the samples, I think we also should to ES384 and ES512 and document the qr-size as soon as the complete chain is solid, so that we have a clear reference for future aspects. On NIST vs. Brainpool, from our cash register project we had chosen ES256 only, since we had crypto implementations for that on every platform, brainpool was not widely distributed then. Not sure how much that has changed (we did this in 2016). Main issue would be on the validation side. If we need the brainpool curves (or other curves, algorithms), I guess it would be helpful to have a clear view on the platforms (JS, Kotlin, Swift etc.) and evaluate the different combinations to get a clear matrix on the support side.

[jschlyter]

So ES256 is ECDSA with NIST P256 (SecP256k1). The US curve set.

Yes, ES256 per RFC 8152 (value -7) using the NIST curves. This document also defines ES384 and ES512.

[asitplus-pteufl]

we are currently checking the availability of all algorithms in our kotlin chain, we can provide the demo sizes as soon as we have the stable chain. Could be documented on a page for further reference

[dirkx]

FWIIW they all should be 2x256bits (is 64 bytes) and 8 bytes KID 'raw'.

[asitplus-pteufl]

regarding RSA size, we adapted our testset: https://dev.a-sit.at/certservice/testsuite (which includes faulty codes also) RSA 2048 QR size for our demo vacc. cert is already 1052 vs. 717, which is still doable, but we need to assume that from 2023 on keys >3000 need to be used.

[asitplus-pteufl]

adding the text from the mail discussion from today, to have it one place: RSA: still not happy with the possible implications: In 2023, we will have recommendations for >3000 bit keys. So, we need to clarify that the QR-code sizes are doable with RSA 3072. Otherwise RSA would not work and placing it in the specification would create problems in 2023. To answer that we would need to have the clarification on the type of documents that can be stored in the QR-code. Is it allowed to have only one HCERT in the qr-code or also more than one, and what is the typical size to-be-expected.

If the size turns out to be ok: Fine let’s use RSA, but we should have something in there which allows us to switch the specification to 3072 bits in 2023 without changing the HC1 ID

If the size is not ok:

• Drop RSA

• Or if we cannot get rid of RSA (due to policies etc.), we would need to state very clearly (more clearly than now) that RSA can only be used for certain scenarios (e.g. only one cert if multiple are allowed). Otherwise there will be creation chains that pose problems.

[asitplus-pteufl]

I think we can close this, this has been discussed in detail and is being covered in the document by tsystems: https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md