Thanks, Russ. I am happy to move conversation over there..
-derek On Mon, September 26, 2022 12:34 pm, Russ Housley wrote: > 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 > > -- 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
