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

[Laurence Lundblade <[e-mail]>]

> On Apr 27, 2020, at 5:00 AM, Göran Selander <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://github.com/cose-wg/Charter/blob/master/Charter.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