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

This topic is being discussed on the LAMPS mail list.  The C509 certificate has a one-to-one alignment with the X.509 certificate (see RFC 5280 for the syntax).  The answer here needs to keep that alignment, so I hope we can have the discussion on one mail list.

Russ

> On Sep 26, 2022, at 10:19 AM, Derek Atkins <derek@ihtfp.com> wrote:
> 
> 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
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose