Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

[Laurence Lundblade <[e-mail]>]

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 code complexity; both CBOR and DER encoding / decoding needed
- Can transform to/from X.509 mechanically without the private key

1) COSE + Mirroring with CBOR Sequence from Raza draft
- Uses the CBOR sequence that exactly mirrors X.509
- Reduces size of cert and lowers code complexity; no DER encoding / decoding
- Must have private key to generate; must be generated by the CA

2) COSE + Mirroring with CWT Claims
- A set of CWT claims are defined that exactly mirror X.509 fields
- Reduces size of cert and lowers code complexity; no DER encoding / decoding; can re use some CWT code
- Must have private key to generate; must be generated by the CA

3) COSE + Improved CWT Claims
- A set of CWT claims that don’t necessarily mirror X.509 exactly, but give similar semantics
- Reduces size of cert and lowers code complexity; no DER encoding / decoding; can re use some CWT code
- Must have private key to generate; must be generated by the CA

I was definitely talking about 3) in my last email. It is clearly not in the charter.

So maybe the debate is between 1) and 2). Both are in the charter. Some advantages of 2) are:
- Can re use some of the CWT code
- Can move to 3) incrementally when the time comes
- Can drop fields that are not used possibly giving the smallest cert size on the wire of any of the options

LL



> On Apr 28, 2020, at 3:23 AM, Göran Selander <[e-mail]> wrote:
> 
> 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 leave that out for now.
>  
> My comment was about the other part, what we both call “native CBOR certificates” but mean different things. What is called native in
> draft-raza-ace-cbor-certificates is not intended as a certificate format breaking with X.509. While there are many potential improvements to make on X.509, there is a resistance against new certificate architectures as was clear when this was brought up in Secdispatch at IETF 104 a year ago. As mentioned previously, what we mean by “native CBOR” is the lossless compression of the certificate profile of X.509 into a CBOR encoded format, but signing over the CBOR instead of on the uncompressed data. In this way it is possible to define a bijection between native CBOR certificates and profiled X.509 certificates – the payload of the compressed version of the latter would be identical to the former. So the native CBOR certificates are a faithful representation of these profiled X.509 certificates, using the same payload as in the CBOR compression scheme.
>  
> In contrast to the compression scheme, a conversion between native CBOR and X.509 representations requires access to the private signature key.
> Therefore a mix of X.509 and native CBOR would require multiple handlers at the backend (parsing the payload would be the same). Dedicated deployments could of course use native CBOR certificates exclusively.
>  
> In the same way it would be possible to instead define a COSE_Sign1 and/or a CWT representing these profiled X.509 certificates, this is what I thought you were asking about but apparently not. That would be an alternative as long as we can decide on exactly one of these representations.
>  
> There are a lot of fun things to do in this space, my concern is how to get out a standard. Trying to replace X.509 doesn’t seem like a promising way forward I’m afraid . . .
>  
> Göran
>  
>  
> From: Ace <[e-mail]> on behalf of Laurence Lundblade <[e-mail]>
> Date: Monday, 27 April 2020 at 20:13
> To: Göran Selander <goran.selander=[e-mail]>
> Cc: Joel Höglund <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt
> 
>> On Apr 27, 2020, at 5:00 AM, Göran Selander <goran.selander=[e-mail] <mailto:goran.selander=[e-mail]>> 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 minimal changes when moving from compressed to native CBOR certificates.
>>  
>> I agree with you that the overhead of COSE_Sign1 or CWT is not major and these points are open for discussion. The more important question is where this should be standardized. The compression scheme is now included in the new draft charter for COSE:
>> https://github.com/cose-wg/Charter/blob/master/Charter.md <https://protect2.fireeye.com/v1/url?k=dd127709-819bd8c0-dd123792-0cc47ad93e1c-5b6bae84abc5c4a0&q=1&e=5bb412fa-ec1d-44a0-8dba-c66844d1b797&u=https%3A%2F%2Fgithub.com%2Fcose-wg%2FCharter%2Fblob%2Fmaster%2FCharter.md>
>> The charter is currently not explicitly supporting native CBOR certificates. If you think it should, in some variant, then this is a good time to raise your voice.
> 
>  
> To go straight to the issue, I think a designing a native CBOR cert should be approached differently than compressing / re-encoding an X.509 cert:
>  
> Re-encoding
> - Size is important
> - Exact compatibility is required
> - Near zero change to fields and semantics
>  
> Native CBOR Cert
> - Clean up some of the mess in X.509; it is an old standard with a lot of cruft and baggage
> - Re design extensions so they are in CBOR format
> - Make many of the fields optional, for example not before can often be left off, maybe even serial number
> - Avoid DN structure for issuer and subject for most use cases
> - Use modern formats like COSE and CWT and COSE_Key
> - Size is important, but far from the only goal (some size reductions, like optional fields will be possible here that are not possible with re-encoding)
> - Compatibility matters, but not in the same way
>  
> Seems like the right thing to do here is to remove native CBOR certs from this document and just focus on compression and re-encoding. Maybe even call them “Compressed Certs” rather than “CBOR Certs”.. Where that work should go is above my pay grade.
>  
>  
> BUT, my main interest here relates to CWT and EAT. CWT seems like a really good choice on which to base a native CBOR cert. Some of the fields for an X.509 cert are already defined in CWT (subject, issuer, expiration, not-before). It has an extension mechanism built in already in the CWT IANA registry. The crypto and signing are well-handled by CWT’s use of COSE.
>  
> In work to fit EAT <https://tools.ietf.org/html/draft-ietf-rats-eat-03> in as a CWT, a few issues have come up — how fields / claims are managed and registered with IANA, label spaces and other.  All these issues would apply to CWT/COSE/CBOR-based certificate as well. 
>  
> To name just one issue, in CWT the expiration date/time can be a floating-point number, which is burdensome, not useful. Should we change CWT to disallow or should it just be disallowed when a CWT is used as an EAT and when it is used as a Cert?
>  
> I’m also excited at the idea of re using CWT in a simple form so there is re use of code between CWT, EAT and native CBOR certs. I’ve started playing with an implementation like this.
>  
> LL