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

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>>>>      [e-mail]             www.ihtfp.com
>>>>      Computer and Internet Security Consultant
>>>> 
>>>> _______________________________________________
>>>> COSE mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cose
>>> 
>>> 
>> 
>> 
>> --
>>       Derek Atkins                 617-623-3745
>>       [e-mail]             www.ihtfp.com
>>       Computer and Internet Security Consultant
>> 
>> 
> 
> 
> -- 
>       Derek Atkins                 617-623-3745
>       [e-mail]             www.ihtfp.com
>       Computer and Internet Security Consultant
> 
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose