Closed johngray-dev closed 1 week ago
June 5th - We will keep this one here, revisit after the final standards are released.
From Piotr:
Hi All
I strongly support this change and point out that it is consistent with the current wording of Section 5.3, which indicates that CompositeSignaturePrivateKey is a component of the OneAsymmetricKey structure, not the OneAsymmetricKey structure itself. See:
When a CompositeSignaturePrivateKey is conveyed inside a
OneAsymmetricKey structure (version 1 of which is also known as
PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set
to the corresponding composite algorithm identifier defined according
to Section 7, the privateKey field SHALL contain the
CompositeSignaturePrivateKey, and the publicKey field MUST NOT be
present.
Also discussed this related issue for libOQS: https://github.com/open-quantum-safe/oqs-provider/issues/466
August 14th, 2024: The authors group has agreed to do this work:
Dan sent an e-mail about this:
From: Daniel Van Geest daniel.vangeest@cryptonext-security.com Sent: Wednesday, September 25, 2024 1:12 PM To: Mike Ounsworth Mike.Ounsworth@entrust.com; Klaußner, Jan Jan.Klaussner@bdr.de; draft-ietf-lamps-pq-composite-sigs.authors@ietf.org draft-ietf-lamps-pq-composite-sigs.authors@ietf.org Subject: [EXTERNAL] Re: Composite signatures and EDDSA encodings
Somewhat related, do you have plans to rework the CompositeSignaturePrivateKey encoding? (I think so, though I don't have time to read the whole issue right now: https://github.com/lamps-wg/draft-composite-sigs/issues/6) If you're leaving it as a SEQUENCE of OneAsymmetricKey, then there's a bug in the OQS composite signatures implementation which I'll have to report (they don't do the double wrapping of the private key as specified in RFC 8410), but if it's changing then there's no need to report it as the implementation will likely change as the format changes. Daniel Van Geest
I replied to Dan with this:
Hi Dan,
Yes, on August 14th our group agreed to make this change... It will align better with what we did for public keys and remove redundant information. It hasn't been updated in the document, but we are diligently working through the outstanding issues, trying to get them all resolved before the October 21st cutoff date.
Cheers,
John Gray
Dan vG further voted to keep it as SEQUENCE OF OneAsymmetricKey:
Regarding the composite private key being a SEQUENCE of OneAsymmetricKey, from an implementation perspective that's actually really convenient because there will already be PKCS#8 or RFC 5958 APIs for the component private keys, so you only need to stick those in a SEQUENCE. Making it a SEQUENCE of PrivateKey complicates the implementation somewhat because, if you mean the same PrivateKey in the OneAsymmetricKey, there's often not an API to get that directly so you may have to dissect the OneAsymmetricKey ASN.1 to get at it. But of course it's a trade-off to reduce the complexity in the composite private key format, and probably a good trade-off. I'm actually in the middle of making such a dissecting change myself, so I'll see how bad it is!
That comment wasn't a vote in either direction, it was just a point for consideration :) It would be really nice to get rid of the redundancy of the OneAsymmetricKeys, and that's the way I would lean. I just think the text has to be extra clear about what the PrivateKey OCTET STRING contains, i.e. the structure of the public key is in PUBLIC-KEY.&PrivateKey from the public key identifier of the component keys.
Dan vG further voted to keep it as SEQUENCE OF OneAsymmetricKey:
Regarding the composite private key being a SEQUENCE of OneAsymmetricKey, from an implementation perspective that's actually really convenient because there will already be PKCS#8 or RFC 5958 APIs for the component private keys, so you only need to stick those in a SEQUENCE. Making it a SEQUENCE of PrivateKey complicates the implementation somewhat because, if you mean the same PrivateKey in the OneAsymmetricKey, there's often not an API to get that directly so you may have to dissect the OneAsymmetricKey ASN.1 to get at it. But of course it's a trade-off to reduce the complexity in the composite private key format, and probably a good trade-off. I'm actually in the middle of making such a dissecting change myself, so I'll see how bad it is!
Group is agreeing to change it to:
CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING
Resolved in Pull #68
From: https://github.com/EntrustCorporation/draft-ounsworth-composite-sigs/issues/121
We simplified the composite signature public key format from:
CompositeSignaturePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo to CompositeSignaturePublicKey ::= SEQUENCE SIZE (2) OF BIT STRING
We haven't changed the CompositePrivateKeyFormat: CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey
OneAsymmetric Key from RFC 5958 is this:
OneAsymmetricKey ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] Attributes OPTIONAL, ..., [[2: publicKey [1] PublicKey OPTIONAL ]], ... }
PrivateKey ::= OCTET STRING -- Content varies based on type of key. The -- algorithm identifier dictates the format of -- the key.
OneAsymmetricKey can carry the public key and has the algorithmIdentifier and version fields which are really redundant information. I think we could simply do this:
CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF PrivateKey
which is effectively: CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING
It would allow sending composite private keys in PKCS12, or in raw encrypted blobs, to be smaller.
As of May 8th, 2024 - We are leaning in making this compact change - after getting the v14 update published on the lamp-wg github.
It also has the benefit of making key consistency better defined as a static mapping of the algorithm details needs to be used to reonstruct the private key.