Then another problem is that the LAMPS draft uses ASN.1 for RSA and ECDSA, which greatly increases the complexity of encoding (I did implement that stuff for a test, and the difference against custom formats was just wild). I am ignoring private keys (since that can never be baked in), this is about public keys and signatures (which do not seem to get baked in). The LAMPS draft uses existing encodings of RSA and ECDSA. Why would we need or want to invent a new encoding of RSA and ECDSA when every cryptographic library already supports them. Then people would complain that they had to re-encode the keys into existing encodings so they would be acceptable to their cryptographic libraries.
I think that the current state of post-quantum signatures is so bad that very few are going to use those without either some compliance requirements or an imminent CRQC. And I do not think any compliance regime is going to require hybrids (and hybrids will not improve matters against imminent CRQC). We already need to use them and have customers asking us for them. Cheers, John Gray ________________________________ From: Ilari Liusvaara <[email protected]> Sent: Friday, October 17, 2025 1:03 PM To: [email protected] <[email protected]>; cose <[email protected]> Subject: [EXTERNAL] [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 On Thu, Oct 02, 2025 at 08: 10: 31AM -0500, Orie wrote: > Hi, > > Adding COSE because of the draft title. > > I think composite signatures for JOSE & COSE do not make a lot of sense for > the common cases of short lived access On Thu, Oct 02, 2025 at 08:10:31AM -0500, Orie wrote: > Hi, > > Adding COSE because of the draft title. > > I think composite signatures for JOSE & COSE do not make a lot of sense for > the common cases of short lived access tokens. > For longer lived identity credentials they might make sense, especially if > you are shipping hardware with no ability to upgrade that is going to speak > COSE, perhaps in long lived smart building IoT scenarios? > I would tend to wait for TLS / LAMPs (to successfully adopt documents) and > align with them. I think that the current state of post-quantum signatures is so bad that very few are going to use those without either some compliance requirements or an imminent CRQC. And I do not think any compliance regime is going to require hybrids (and hybrids will not improve matters against imminent CRQC). Then another problem is that the LAMPS draft uses ASN.1 for RSA and ECDSA, which greatly increases the complexity of encoding (I did implement that stuff for a test, and the difference against custom formats was just wild). I am ignoring private keys (since that can never be baked in), this is about public keys and signatures (which do not seem to get baked in). And on SUF security (already a topic in some messages in this thread), one way to end up needing it is to hash compact JWS signature and then use the hash as a replay key (instead of hashing just the protected and payload fields). Hoever, ECDSA already allows two different signatures for the same message (unless one does non-standard canonicalization). -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected] Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
