Russ, I just perused the LAMPS archives for the last 6 weeks (back to August 12) and do not see anything related to multiple keys and/or multiple signatures in a certificate. Or at least none of the conversations or document titles are obviously on that topic.
Could you please point me to the discussion thread? Thank you, -derek PS: I will say up front that I do not care about X509 here, I only care about native C509 certs. But I do agree that the semantics should carry over if at all possible. On Mon, September 26, 2022 12:41 pm, Derek Atkins wrote: > 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 > > -- 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
