Anders: The LAMPS WG will be talking about certificates and CMS support for PQC algorithms next week during IETF 113.
Also, BouncyCastle has supported HSS/LMS signatures, which are quantum-safe, for at least two years. In addition, the specifications are done for using HSS/LMS with COSE and CMS. The state that needs to be tracked for HSS/LMS does not need to be tracked for other quantum-safe signature algorithms. So, other quantum-safe signature algoritms should be more straightforward. Russ > On Mar 15, 2022, at 12:03 AM, Anders Rundgren <[email protected]> > wrote: > > Hi Orie, > > To me PQK represents overloading since the anticipated crypto systems seem to > be more or less unrelated. Overloaded identifiers make the introduction of > new algorithms more difficult and is at odds with pluggability. > > To avoid overloading kty:CRYD3 could be a possible choice. For DH keys (if > applicable), I would consider kty:CRYD3-DH which would give you basic > algorithm separation. > > BouncyCastle which has been the leading crypto provider for Java (until > Java17), have indeed defined a unique key type for the single PQC algorithm > they currently support: > https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/SPHINCSPlusParameterSpec.java > > It would be valuable knowing what the PKIX folks are planning here since they > have basically the same problem. Russ? > > Thanx, > Anders > > On 2022-03-14 21:19, Orie Steele wrote: >> > I believe there’s insufficient reason to make things different for this >> > new class of algorithms. >> If that's the case, we will need to register a new "crv" like property for >> post quantum keys, let's call it "pset" for now, as we had originally >> intended to register this property, and it's still present in the current >> draft. >> And then define a mapping between that new property and every supported alg. >> For example: >> - kty:EC, crv:P-256 -> alg:ES256 / alg:ECDH-ES+A256KW >> - kty:EC, crv:secp256k1 -> alg:ES256K >> - kty:OKP, crv:Ed25519 -> alg:EdDSA >> ... >> - kty:RSA, n / e -> alg:PS256 / RS256 ? >> - kty:EC, crv:secp256k1... ? -> alg:ES256K / alg:SS256K? >> ... >> - kty:PQK, pset: CRYD3 -> alg: CRYD3 >> - kty:PQK, pset: CRYD5 -> alg: CRYD5 >> - kty:PQK, pset: xmss.public_key.SHA2_10_256 -> alg: xmss.SHA2_10_256 ? >> We have learned a lot since JOSE was first created. >> In particular we have learned that handling optional parameters is a source >> of security issues, especially related to "alg". >> New registrations should not make this problem worse. >> If we can't make "alg" required for "kty:PQK" we will need to define a new >> "pset" or similar, and it will have to have a mapping for every registered >> `alg`. >> So for a dilithium example: >> kty: PQK (required) >> pset: CRYD3 (required) >> x: ... (required) >> alg: CRYD3 (optional) >> Obviously JWK thumbprint will need to be aware of all required fields, and >> will need to drop all optional fields in order to be useful. >> If we don't define something like "pset" and we don't make "alg" required >> for "kty:PQK"... the only optional will be to explode based on mismatched >> keys / signatures... unless I am missing something... we have the same >> problem with P-256 keys today... when "alg" is not present, you can't tell >> if the key is for "signing" or "key agreement"... which means that any JWE / >> JWS can target that key, and the key representation won't catch what the key >> was intended for... unless "alg" and "use" are present... which nobody can >> rely on, because they are marked optional. >> Take a look at: >> https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties >> >> <https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties> >> Notice that they include "alg" and "use"... if both are optional, why >> include them in such an example? >> FWIW I think making "alg" required is the best thing to do for new key types >> moving forward (it addresses future ambiguity / explicit over implicit makes >> me feel safer). >> Extra language regarding thumbprint computation seems "worth it" for >> removing parameter kty type to alg type ambiguity. >> Keep in mind we will have this same issue for the families of lattice, hash, >> and isogeny... So if we set a precedent of registering an alternative for >> 'crv' for lattices say. "pset", we will need to follow through with the >> others as well, either reusing that new parameter or creating a new one for >> each family. >> @Mike Jones >> Should there be 1 new "crv' like property or 1 per family (3 in total). >> What would you suggest for the new "crv" like parameter name? "pset" ? >> Do you have an alternative proposal? >> OS >> On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <[email protected] >> <mailto:[email protected]>> wrote: >> Requiring “alg” in a JWK for one class of algorithms and/or key type >> values would be non-parallel to other algorithms and/or key type values. >> This matters not just for aesthetic reasons but also because it would make >> the JWK Thumbprint calculations [RFC 7638] have to special-case these >> algorithms and/or key type.____ >> __ __ >> Yes, you always need to know the “alg” when using a key – but in JOSE and >> COSE you already authoritatively get that from the JOSE or COSE header >> parameters. I believe there’s insufficient reason to make things different >> for this new class of algorithms.____ >> __ __ >> -- Mike____ >> __ __ >> *From:* COSE <[email protected] <mailto:[email protected]>> *On >> Behalf Of * Orie Steele >> *Sent:* Monday, March 14, 2022 8:20 AM >> *To:* Russ Housley <[email protected] <mailto:[email protected]>> >> *Cc:* Ilari Liusvaara <[email protected] >> <mailto:[email protected]>>; [email protected] <mailto:[email protected]> >> *Subject:* Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: >> Re: Call for COSE Agenda Items for IETF 113 in Vienna]____ >> __ __ >> Refocusing on the "kty" : "OKP" vs "PQK" issue. >> As I understand it, "alg" is optional even when "kty": "OKP"... so a main >> reason to choose "kty": "PQK" would be to say that "alg" is now required... >> If we think overloading "OKP" would cause harm, we should make the new "kty" >> bring more to the table, such as mandating the presence of "alg". >> I expect we will be marking "alg" values as forbidden (when the become >> unadvisable), and not marking whole "kty" families as forbidden in the >> future... having the "alg" be required in "kty" "PQK" seems like it >> provides a better security posture in that context, but eager to hear from >> others. >> Regards, >> OS____ >> __ __ >> On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <[email protected] >> <mailto:[email protected]>> wrote:____ >> > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara >> <[email protected] <mailto:[email protected]>> wrote: >> > >> > On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote: >> >> >> >> >> >>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >> >>> NISTPQC signatures would fit into signature keys "subtype", but >> NISTPQC >> >>> KEMs will not fit into the key agreement keys "subtype", so that >> would >> >>> be a third "subtype" (all NISTPQC algorithms have OKP-style key >> format, >> >>> as this was required by NIST). >> >> >> >> Right. It makes sense to add support for KEM. We can figure >> that out >> >> without waiting for NIST to announce Round 3 winners. We can do >> the >> >> work based on RFC 5990. >> > >> > One idea how (modelled on ECDH-ES, as operation of KEMs is very >> similar >> > to ECDH-ES): >> > >> > - Add new alg values KEM+{A{128,192,256}KW,HKDF-{256,512}}, >> mirroring >> > the ECDH-ES ones. >> > - Add new new header algorithm parameter "encapsulated ciphertext" >> > (bstr) that carries the KEM ciphertext. >> > - Sender procedure: >> > - Select the public key to encrypt to. >> > - Apply the KEM encapsulate operation to the public key. >> > - Use the encapsulate secret output as input for key derivation, >> just >> > like in ECDH-ES. >> > - Write the encapsulate ciphertext output into the "encapsulated >> > ciphertext" header algorithm parameter. >> > - Receiver procedure: >> > - Retretive the private key to use. >> > - Read the ciphertext input from the "encapsulated ciphertext" >> header >> > algorithm parameter. >> > - Apply the KEM decapsulate operation to the private key and the >> > ciphertext. If decapsulate fails, fail. >> > - Use the decapsulate secret output as input for key derivation, >> just >> > like in ECDH-ES. >> > >> > >> > A word of cauntion: Altough it might seem that the "encapsulated >> > ciphertext" header can be reused for HPKE, there is a subtle issue: >> > This mechanism can not trivially support compressing the >> ciphertext. So >> > reusing it would require HPKE to define compact NIST curves, so >> COSE >> > could just forget about key compression. >> If you are talking about ECC Point Compression, I agree that COSE >> should ignore it. For a very long time, the patent kept many >> implementations from supporting it. Now that patent has expired, but the >> engineering effort to add support for ECC Point Compression is significant, >> and everyone will have to be prepared to encounter implementations that are >> not yet prepared to handle compression. The savings of 32 bytes does not >> seem worth the transition pain. >> Russ >> _______________________________________________ >> COSE mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/cose >> <https://www.ietf.org/mailman/listinfo/cose>____ >> ____ >> __ __ >> -- ____ >> *ORIE STEELE*____ >> Chief Technical Officer____ >> www.transmute.industries <http://www.transmute.industries>____ >> __ __ >> <https://www.transmute.industries/>____ >> -- >> *ORIE STEELE* >> Chief Technical Officer >> www.transmute.industries >> <https://www.transmute.industries> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
