Re: [COSE] compressed certificates -- Re: Proposed charter update

[Carsten Bormann <[e-mail]>]

On 2020-09-26, at 00:20, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Jim Schaad <[e-mail]> wrote:
>> I just made a relatively fast read through on the compressed
>> certificate draft.  If we are looking to do "native CBOR" certificates
>> then I think that we need to be very explicit what it is meant by
>> "native CBOR".  When I hear that term I end up with a number of
>> different things that this could end up being:
> 
>> 1.  A CBOR Encoding for ASN.1.
> 
> I'll bet Nico could whip that up from the Heimdal ASN.1 compiler tools.
> It's worth investigating what the resulting benefits would be.

Uh.  What could be an interesting experiment would be defining somewhat mechanical rules for converting ASN.1 to a CBOR data structure (e.g., expressed in CDDL).
But defining “CBOR Encoding Rules” with support for all nooks and crannies of ASN.1 would generate a lot of complexity (e.g., compare the basic YANG-CBOR idea with what it turned into with having to support for YANG’s weird unions).

>> 2.  A CBOR Encoding for an X.509 certificate replacement.  (CWT?)
> 
> Or possibly an EAT, which is really a subset of CWT.
> draft-birkholz-core-coid

Yes, we should do this, but maybe thinking wider.
I hope this is then more than an “X.509 certificate replacement”…
Oe objective behind the CoID work was to look at real-life X.509 certificates and make sure that all their payload content can be expressed in CWTs.

>> 3.  What is being proposed in the document which amounts to CBOR
>> Compressed X.509 certificate signed in the CBOR format.
> 
> No, that's #4 :-)
>  0. is CBOR compressed certificates signed in ASN.1 format, because
>     the CBOR compression was 100% bit-for-bit reversible.

Re-encoding vs. “compression”…

Note that you could have a cert with both forms of signaturen (on reconstructed ASN.1 DER, on original CBOR = native signature) included (not very concise then, but the sender of such a cert could simply elide the form that is not needed).

>> It might be that coining a new term for this might be best because I
>> definitely got a surprise on the definition.
> 
> I think that we have use cases for all these.
> We probably shouldn't do them all.
> It would be very nice if we were able to deploy this incrementally.
> 
> I agree that some terms would be helpful.

Terminology is the basis for communicating efficiently (and often, required for communicating effectively).

Grüße, Carsten