https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-keys/
https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/ These were discussed at IETF 114, and some updates are in the works. There will be a call for adoption in the LAMPS WG after the next version gets posted. Russ > On Sep 26, 2022, at 1:01 PM, Derek Atkins <[email protected]> wrote: > > 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
