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

[Derek Atkins <[e-mail]>]

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