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

[Derek Atkins <[e-mail]>]

Hi,

On Mon, September 26, 2022 12:27 pm, Michael Richardson wrote:
>
> Derek Atkins <[e-mail]> wrote:
>     > We are happily using the (currently draft) CBOR Certificates object
> in
>     > our code, but we're getting closer to having a requirement where a
>
> To be clear, you are talking about certificates encoded in CBOR, and for
> which the signature is calculated over the CBOR. i.e. _Natively signed
> C509 certificates_

Yes, I am specifically talking about NATIVE CBOR certificates, where the
signature is calculated over the CBOR.

>
>     > 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.
>
> So, this might be backwards compatible to the draft, it would not be 1:1
> with
> X509 format certificates.  I guess that you are alright with this, but I
> think for the community, that might be a big step.

We don't use X509 in any capacity (except our cloud service that uses HTTPS).

>
>     > 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.
>
> Agreed.
>
>     > 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.
>
> If we were further along with cose-cbor-encoded-cert, then I'd want to see
> it
> as a new document.  It does not seem that we are in that place yet.
> Still, it might be kinder to the reviewers of the current document if it
> were
> a new draft.

I am fine with that, although my draft would start with "take all the
definitions from [xxx] and make these minor changes"

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant