Subject: [COSE] Proposed charter update

From: Göran Selander <[email-masked]>
Date: Fri, 25 Sep 2020 13:31:02 +0000

Hi,

We got an action last meeting to propose new text for the charter. Please find a proposal below.

OLD is the charter *after* incorporating the changes proposed by John (as discussed in the meeting):
https://mailarchive.ietf.org/arch/msg/cose/bUSlA5k5k855lVEq6ZnP1KPO0Cg/

NEW is the proposal. The first and last paragraph of OLD are unchanged, and the middle paragraph is replaced with two new ones.

OLD
---
A CBOR encoding of the compressed certificate profile defined in RFC 7925. It is expected that the compression works with a large subset of RFC 7925 and takes into consideration any updates in draft-ietf-uta-tls13-iot-profile-00. The compression may also include other important IoT certificate profiles like IEEE 802.1AR.

It should be noted that this is not a new certificate architecture, rather it is a method of compressing current X.509 certificates that meet a specific profile into a smaller format. The compression algorithm is loss-less so they can be expanded and normal X.509 certificate processing used.

This work will be based on draft-mattsson-cose-cbor-cert-compress. The working group will collaborate and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and validate the requirements and solution.
---

NEW
---
A CBOR encoding of the compressed certificate profile defined in RFC 7925. It is expected that the compression works with a large subset of RFC 7925 and takes into consideration any updates in draft-ietf-uta-tls13-iot-profile-00. The compression may also include other important IoT certificate profiles like IEEE 802.1AR.

The main objective is to define a method of compressing current X.509 certificates that meet a specific profile into a smaller format. This compression algorithm is loss-less so they can be expanded and normal X.509 certificate processing used.

Another objective is to explore the possibility to parse and verify the compressed X.509 encoding directly on the target device. This removes the need for compression, decompression, and DER parsing, with associated overhead and code, which is relevant for embedded implementations.

This work will be based on draft-mattsson-cose-cbor-cert-compress. The working group will collaborate and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and validate the requirements and solution.
---

Göran

On 2020-09-23, 18:35, "COSE on behalf of John Mattsson" <[email-masked] on behalf of john.mattsson=[email-masked]> wrote:

     Three suggestion regarding certificate compression in the charter.

    OLD
    "A CBOR encoding of the compressed certificate profile defined in RFC 7925."

    NEW
    "A CBOR encoding of the compressed certificate profile defined in RFC 7925. It is expected that the compression works with a large subset of RFC 7925 and takes into consideration any updates in draft-ietf-uta-tls13-iot-profile-00. The compression may also include other important IoT certificate profiles like IEEE 802.11AR."

    OLD:
    "This work will be based on draft-mattsson-cose-cbor-cert-compress and draft-raza-ace-cbor-certificates. It is expected these documents are to be combined into a single document."

    NEW
    "This work will be based on draft-mattsson-cose-cbor-cert-compress"

    ADD
    "The working group will collaborate and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and validate the
    requirements and solution."

    _______________________________________________
    COSE mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/cose

---

From: Jim Schaad <[email-masked]>
Date: Fri, 25 Sep 2020 10:01:30 -0700

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.
2.  A CBOR Encoding for an X.509 certificate replacement.  (CWT?)
3.  What is being proposed in the document which amounts to CBOR Compressed X.509 certificate signed in the CBOR format.

It might be that coining a new term for this might be best because I definitely got a surprise on the definition.

Jim

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Göran Selander
Sent: Friday, September 25, 2020 6:31 AM
To: [email-masked]
Subject: [COSE] Proposed charter update

Hi,

OLD
---

NEW
---

Göran

    OLD

    NEW

    OLD:

    NEW

    ADD

---

From: Göran Selander <[email-masked]>
Date: Fri, 25 Sep 2020 18:18:38 +0000

Hi Jim,

Thanks for commenting. 

On the term "native CBOR certificate" in draft-mattsson-cose-cbor-cert-compress.

We are not specially attached to this term. Happy to replace it with some other adjective or just use "CBOR certificate type 1",  "CBOR certificate type 2", if that is less confusing. 

We did not intend to define "native CBOR" (like in 1. below), the intended parenthesis is like this: native (CBOR certificate). Not like this: (native CBOR) certificate.

The rationale (perhaps twisted, but anyway) is like this: Assume there is a device which speaks CBOR (i.e. "is native in CBOR"), then it should be able to parse and verify a "native" CBOR certificate without knowing of other encodings.

We are not targeting an X.509 certificate replacement as in 2. below. The only difference between the compressed X.509 format and the native format is in what is being signed. In the former the signature is on the uncompressed ASN.1/DER encoding, in the latter the signature is on the CBOR encoding, like in 3. below.

Hope that helps.

Göran

On 2020-09-25, 19:02, "COSE on behalf of Jim Schaad" <[email-masked] on behalf of [email-masked]> wrote:

    Jim

    -----Original Message-----
    From: COSE <[email-masked]> On Behalf Of Göran Selander
    Sent: Friday, September 25, 2020 6:31 AM
    To: [email-masked]
    Subject: [COSE] Proposed charter update

    Hi,

    OLD
    ---

    NEW
    ---

    Göran

        OLD

        NEW

        OLD:

        NEW

        ADD

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Sep 2020 20:29:51 +0200

On 2020-09-25, at 20:18, Göran Selander <goran.selander=[email-masked]> wrote:
> 
> The only difference between the compressed X.509 format and the native format is in what is being signed.

So “natively signed” might be a term that we can use.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 25 Sep 2020 14:05:07 -0700

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Carsten Bormann
Sent: Friday, September 25, 2020 11:30 AM
To: Göran Selander <goran.selander=[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] Proposed charter update

[JLS] This seems to be a much cleaner term.  So maybe we are looking at "CBOR Compressed X.509 certificate" and "natively signed CBOR Compressed X.509 certificate"
Jim

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Sep 2020 18:20:53 -0400

Jim Schaad <[email-masked]> 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.

    > 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

    > 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.

    > 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.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Sep 2020 18:22:52 -0400

> So “natively signed” might be a term that we can use.

But, it's a relative term.

It's native for members of the CBOR sect.
The ASN.1/DER sect also performs native signatures.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Sep 2020 08:11:55 +0200

On 2020-09-26, at 00:20, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

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).

> Or possibly an EAT, which is really a subset of CWT.

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.

>     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).

> I agree that some terms would be helpful.

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

Grüße, Carsten