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

[Michael Richardson <[e-mail]>]

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_

    > 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.

    > 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.

-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-