Hello Ilari, Thank you very much for your feedback and suggestions. I have added two issues to the draft's Github repository to address your comments: https://github.com/lucasprabel/draft-jose-pq-composite-sigs/issues
1) I agree that it would make sense to use the same domain separators as in the LAMPS composite draft. In this draft v1, I used specific domain separators for JOSE and COSE because the LAMPS draft defines their domain separators as the DER encoding of the composite algorithm OID, which JOSE and COSE tend not to use. Besides, using the same domain separators as in the LAMPS composite draft would mean there would be no protocol context binding. Would this be an issue? 2) If we use the AKP Key Type, we would only have the Public Key and Private Key Parameters available, and we would not be able to specify, for example, the crv parameter for the ECDSA traditional component. Would this be a problem? Or would tying this information to the composite algorithm name be sufficient? Thank you, Regards, Lucas > -----Original Message----- > From: [email protected] <[email protected]> > Sent: mardi 17 juin 2025 12:44 > To: [email protected] > Subject: [jose] Re: FW: New Version Notification for draft-prabel-jose-pq- > composite-sigs-01.txt > > On Tue, Jun 17, 2025 at 08:28:48AM +0000, Lucas Prabel wrote: > > Hello all, > > > > We have published a new version of > > https://datatracker.ietf.org/doc/draft-prabel-jose-pq-composite-sigs/0 > > 1/ which describes how to use PQ/T composite keys and signatures for > > JOSE and COSE. We are pleased to welcome John Gray as a co-author of > > the draft, who will in particular help us align with the LAMPS > > composite draft when necessary. > > > > The draft was presented at IETF 121, and numerous changes have been > made since. > > > > In particular: > > - as with draft-ietf-cose-dilithium-07, we now only support the seed > > representation for the private key; > > - we changed the composite signature combiner to align with the > > upcoming version of the LAMPS composite draft; > > - test vectors for JOSE have been added. > > > > We welcome all comments, feedback and suggestions, and we plan to > > present the updated draft at IETF 123 in Madrid. > > 1) The domain separators being different makes this incompatible with the > LAMPS combiners. > > This is a problem, because JOSE/COSE and X.509 would require separate > implementations of two algorithms that are different for no apparent reason. > And worse, that is crypto-grade code, which is not cheap. > > > 2) The key type is very badly named, and would not work with things like ML- > DSA+EdDSA (which are included in LAMPS draft for a reason). > > > What I think should be done is having this draft specify how to map the > signature construction in draft-ietf-lamps-pq-composite-sigs to JOSE and > COSE in the simplest way possible (in style of how section 6 of that draft > defines how to map the construct to X.509) and then define some signature > algorithms. > > - SerializeSignatureValue gives byte string signature value, which is > exactly what JOSE and COSE needs. > > - The keys are algorithm-fixed, and SerializePublicKey and > SerializePrivateKey gives byte string representations of public and > private keys, which is exactly what AKP was designed for. > > This way, one could use the same (higher-quality) implementation for > JOSE/COSE and X.509 with minimal differences. > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
