On 2020-09-26, at 00:20, Michael Richardson <[email protected]> wrote: > > Signed PGP part > > Jim Schaad <[email protected]> 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
