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

[Derek Atkins <[e-mail]>]

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