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

[johngray-dev]

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.

[johngray-dev]

Authors group discussed this two weeks ago and decided to keep the format the same for now (at least in version -13). However, we will keep this issue open and maybe bring it to the mailing list (assuming the document gets adopted).

[johngray-dev]

May 8th, 2024 - We are leaning in making this compact change - after getting the v14 update published on the lamp-wp github