[COSE] Proposal for multiple keys / signatures in CBOR Certificates

[Derek Atkins <[e-mail]>]

Hi all,

We are happily using the (currently draft) CBOR Certificates object in our
code, but we're getting closer to having a requirement where a device
needs to support multiple PK Methods (think PQC).  To that end, we are
looking at a way to extend CBOR Certificates to allow for multiple
subjectPublicKey and multiple signature entries.

As a reminder, the current C509 structure is:

    C509Certificate = [
       TBSCertificate,
       issuerSignatureValue : any,
    ]

    TBSCertificate = (
       c509CertificateType: int,
       certificateSerialNumber: CertificateSerialNumber,
       issuer: Name,
       validityNotBefore: Time,
       validityNotAfter: Time,
       subject: Name,
       subjectPublicKeyAlgorithm: AlgorithmIdentifier,
       subjectPublicKey: any,
       extensions: Extensions,
       issuerSignatureAlgorithm: AlgorithmIdentifier,
    )

My straightforward proposal, which keeps some amount of backwards
compatibility (in the sense that the TBSCertificate still has the same
number of top-level entries), would be to modify this to allow either a
singleton or an array for subjectPublicKeyAlgorithm, subjectPublicKey,
issuerSignatureAlgorithm, and issuerSignatureValue.   At a higher level,
the restriction that both subjectPublicKeyAlgoritihm and subjectPublicKey
must contain the same number of items and in the same order, and both
issuerSignatureAlgorithm and issuerSignatureValue must contain the same
number of items and in the same order.

In CDDL this would boil down to:

    C509Certificate = [
       TBSCertificate,
       issuerSignatureValue : any / [ any, +any ],
    ]

    TBSCertificate = (
       c509CertificateType: int,
       certificateSerialNumber: CertificateSerialNumber,
       issuer: Name,
       validityNotBefore: Time,
       validityNotAfter: Time,
       subject: Name,
       subjectPublicKeyAlgorithm: AlgorithmIdentifier / [
AlgorithmIdentier, +AlgorithmIdentifier ],
       subjectPublicKey: any / [ any, +any ],
       extensions: Extensions,
       issuerSignatureAlgorithm: AlgorithmIdentifier / [
AlgorithmIdentier, +AlgorithmIdentifier ],
    )

I'm not a CDDL expert, so I do acknowledge that this specification does
not restrict the validation requirements of equivalent array lengths.  But
I'm not sure how one would actually encode that into CDDL.

The benefit of this approach is that all signatures cover all keys and all
SignatureAlgorithm identifiers, so you cannot go back and add a new
signature method (downgrade attack).

Another benefit of this approach is that it requires only minimal updates
to existing parsers.  While it is true that a parser that expects a single
entry would fail with the array with multiple Ids/Keys/Signatures, I don't
see this as a bad thing because, most likely, the recipient would want to
be able to validate both signatures.

The only alternate approach would be an extension, but I'm not sure how
you could have multiple signatures using that approach.

Any comments/suggestions?

Oh... Having thrown this out there, I am offering to write it up if there
is interest, either as a modification to the existing CBOR-Certs draft, or
a companion draft.

Thanks,

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant