Should we consider compacting the CompositeSignaturePrivateKey Format like we did with the public key format?

[johngray-dev]

From: EntrustCorporation/draft-ounsworth-composite-sigs#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.

[johngray-dev]

June 5th - We will keep this one here, revisit after the final standards are released.

[johngray-dev]

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: open-quantum-safe/oqs-provider#466

[johngray-dev]

August 14th, 2024: The authors group has agreed to do this work:

[johngray-dev]

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

[johngray-dev]

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

[ounsworth]

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!

[danvangeest]

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!

[johngray-dev]

Group is agreeing to change it to:

CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING

[johngray-dev]

Resolved in Pull #68