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 <[email protected]> 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 > [email protected] www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
