Derek Atkins <[email protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
