Hi,
On Mon, September 26, 2022 12:27 pm, Michael Richardson wrote:
>
> 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_
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
[email protected] www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
