Hi Laurence, and all,
Thanks for providing a taxonomy. As mentioned, type 0 is clearly in the current
draft COSE charter, and we see also the need for a representation of the X.509
profile in RFC 7925 which relieves constrained devices from implementing
DER/ASN.1 encoding as well as
Hi Göran,
I understand your two types of native CBOR certs, and raise you by one. I’ve
assumed COSE because it seems a clear choice to me (no size issue, code re use).
0) Compressed/re-encoded
- Uses CBOR Sequence that exactly mirrors X.509 from Raza draft
- Reduces size of cert, but increased
Hi Laurence,
Thanks for sharing your thoughts. It seems we are working on slightly different
paths.
The part you called “Compressed Certs” is already in the draft COSE charter
where it is referred to as “A CBOR encoding of the compressed certificate
profile defined in RFC 7925” so we can
> On Apr 27, 2020, at 5:00 AM, Göran Selander
> wrote:
>
> [GS] The rationale for native CBOR certificates is to reuse the same encoding
> as in the compression scheme defined for RFC 7925, but signing the CBOR
> instead of signing the uncompressed data. This provides a roadmap with
>
Hi Laurence,
(Copying both ACE and COSE pending further notice about right mail list.)
Comments inline.
From: COSE on behalf of Laurence Lundblade
Date: Friday, 24 April 2020 at 20:58
To: Joel Höglund
Cc: "cose@ietf.org"
Subject: Re: [COSE] [Ace] draft-raza-ace-cbor-certifica
> On Apr 24, 2020, at 5:01 AM, Joel Höglund wrote:
>
> > But of most interest to me is whether the COSE was considered as the
> > signing format for native CBOR certs. If COSE is used, then this looks
> > almost identical to CWT and may be a native CBOR cert is a variant of
> > a CWT? … …
>
>
Hi!
First a meta comment, sorry for spamming: I’m now answering to both the ACE
and the COSE mailing list. If the working group chairs have
recommendations on where to keep the continued discussion I’m eager to hear.
Thank you for your review! Some answers to the questions are inline below.
>
