Subject: [COSE] "CBOR Certificates"

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Feb 2021 16:39:24 -0500

So, draft-mattsson-cose-cbor-cert-compress has in it's title:

        CBOR Encoding of X.509 Certificates (CBOR Certificates)

Section 7 is: _Natively Signed CBOR Certificates_

and I strongly believe that we should remove this section, and the title.
This is going to very confusing.  And section 7 is not sufficient to really
have native CBOR Certificates.  It even says that it's an intermediate step.

   CBOR encoded X.509 certificates provides an intermediate step between
   [RFC7925] or [IEEE-802.1AR] profiled X.509 certificates and natively
   signed CBOR certificates: An implementation of CBOR encoded X.509
   certificates contains both the CBOR encoding of the X.509 certificate
   and the signature operations sufficient for natively signed CBOR
   certificates.

So if this document confuses people into thinking that this intermediate step
are "CBOR Certificates", then when we actually do that (as LGL and others
want to do with EAT), then there will be mass confusion.

So, if that term could be struck from this otherwise excellent document on
compressing PKIX certificates, that would be nice.

(ps: I have some IDevID examples which I can share.  I've been trying to
compress them, but haven't done the OID compression that I need yet)

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 12 Feb 2021 07:36:47 +0000

Hi Michael,

We have struggled with naming. And as names have been updated, not all text has followed. 
The draft is defining a CBOR encoding of PKIX certificates and two different ways of signing them. One which requires re-encoding as ASN.1/DER and one which does not, each having advantages and disadvantages. It seems to me that both variants have support in the working group. 

We can revisit the naming, and discuss whether it is relevant to describe one as an intermediate step between the PKIX and the other. But removing the specification of one of them because of confusion with the current naming is throwing the baby out with the bath water.

What you point to is that in -06 the term "CBOR certificate" is overloaded to mean either both variants, or the variant which is signed over ASN.1/DER.

I think it makes sense to use the term "CBOR certificate"  (shorthand for "CBOR encoded X.509 certificate") as a common term for both (i.e. keep the title of the document), and use other qualifying words to describe the difference in how the signature is generated. 

These terms are probably too long:
1. CBOR certificate signed over the ASN.1/DER encoding
2. CBOR certificate signed over the CBOR encoding

We have already discussed and agreed on "natively signed CBOR certificate" for no. 2 and I don't have a better proposal. How about "PKIX signed CBOR certificate" for no. 1? Other proposal?

For comparison, with this terminology the quoted text (with minor editorial) becomes:

       PKIX signed CBOR certificates provides an intermediate step between
       PKIX certificates and natively signed CBOR certificates: An implementation
       of PKIX signed CBOR certificates contains both the CBOR encoding of the X.509 certificate
       and the signature operation, which are sufficient for processing natively signed CBOR certificates.

(If we still don't link this paragraph and can't fix it then we can skip it.) 

Thanks for providing IDevID examples! Please share, you don't need to do the compression.

Göran

On 2021-02-11, 22:39, "COSE on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: John Mattsson <[email-masked]>
Date: Fri, 12 Feb 2021 08:06:03 +0000

Hi,

I don't think it makes sense to primarily use the term "PKIX". I understand Michaels wish to use "PKIX", but I think is bad for marketing purposes. Everybody knows what "X.509" is and very few knew what "PKIX" is, especially outside of the IETF.

Even in RFC 5280, X.509 is used in the title and five times in the abstract. PKIX is not mentioned before Section 3 and then mainly used in the term "PKIX specifications" mostly referring to the PKIX WG.

John

-----Original Message-----
From: COSE <[email-masked]> on behalf of Göran Selander <goran.selander=[email-masked]>
Date: Friday, 12 February 2021 at 08:37
To: Michael Richardson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [COSE] "CBOR Certificates"

Hi Michael,

Göran

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Feb 2021 09:39:11 +0100

On 12. Feb 2021, at 08:36, Göran Selander <goran.selander=[email-masked]> wrote:
> 
>  "CBOR certificate"  (shorthand for "CBOR encoded X.509 certificate”)

I’m still hoping that we will, at some point, have “CBOR encoded modern certificates” as well, so I’m not sure I like this shorthand.
We will have a hard time controlling what people will call these things, so being upfront about the naming will be really useful.

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Fri, 12 Feb 2021 10:44:29 +0000

CBOR + X.509 = C.509 (CBOR encoded X.509) ?

---

From: Göran Selander <[email-masked]>
Date: Fri, 12 Feb 2021 10:48:35 +0000

Fine by me. I don't think there is an ITU-T C-series to confuse with.

On 2021-02-12, 11:44, "COSE on behalf of John Mattsson" <[email-masked] on behalf of john.mattsson=[email-masked]> wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Feb 2021 13:22:08 +0100

> On 2021-02-12, at 11:48, Göran Selander <[email-masked]> wrote:
> 

https://www.itu.int/itudoc/itu-t/86097.pdf

SERIES C 
General telecommunication statistics 

C.1 (03/93) Withdrawn (10/00) ITU statistical yearbook 
Deleted after the transfer of telecommunication statistics activity to ITU-D 
10pp E 5555 F 5554 S 5556 11 CHF 

C.3 (03/93) Withdrawn (09/02) Instructions for international telecommunication services 
Given that the text of Rec. C.3 consists of an index to a number of Recommendations which are now of little or no practical use, it was decided to delete it. 
Electronic access to ITU-T Recommendations would appear to provide a better index and reference mechanisms 
1pp E 3702 F 3701 S 3703 8 CHF

Not really :-)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Feb 2021 13:59:03 -0500

Göran Selander <[email-masked]> wrote:
    > We have struggled with naming. And as names have been updated, not all
    > text has followed.  The draft is defining a CBOR encoding of PKIX
    > certificates and two different ways of signing them. One which requires
    > re-encoding as ASN.1/DER and one which does not, each having advantages
    > and disadvantages. It seems to me that both variants have support in
    > the working group.

CBOR compressed (X509) Certificates
would be fine with me.

I believe that the second way of signing (CBOR artifacts) belongs in another document.

    > I think it makes sense to use the term "CBOR certificate" (shorthand
    > for "CBOR encoded X.509 certificate") as a common term for both

It is a hard no for me to call them CBOR certificates.
For the reason that Carsten gave: I want something completely divorced from
the X.509 legacy.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Feb 2021 20:00:20 +0100

On 12. Feb 2021, at 19:59, Michael Richardson <[email-masked]> wrote:
> compressed

But they aren’t compressed.

They are just more reasonably encoded…

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Feb 2021 22:42:18 -0500

> But they aren’t compressed.

abridged then.

---

From: John Mattsson <[email-masked]>
Date: Sat, 13 Feb 2021 17:00:51 +0000

Hi,

I think it is good to have a discussion regarding the name and terminology.

I think “CBOR encoded X.509 Certificates” with some suitable abbreviation would fit both type 0 and 1. Both use CBOR for encoding and both follow RFC 5280 (X.509) except when it comes to DER encoding. As long as the DER<->CBOR encoding is one-to-one it is easy to see that the security of type 0 and type 1 are equal.

I am not against changing the term “CBOR certificate” and saving that for something else that has nothing with RFC 5280 to do, but I do not understand the previous comment to move type 0 to another document. Given a specification of type 1, type 0 follows trivially.

/John

-----Original Message-----
From: COSE <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Saturday, 13 February 2021 at 04:42
To: Carsten Bormann <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Göran Selander <[email-masked]>
Subject: Re: [COSE] "CBOR Certificates"

abridged then.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Feb 2021 14:48:18 -0500

> I think “CBOR encoded X.509 Certificates” with some suitable
    > abbreviation would fit both type 0 and 1. Both use CBOR for encoding
    > and both follow RFC 5280 (X.509) except when it comes to DER
    > encoding. As long as the DER<->CBOR encoding is one-to-one it is easy
    > to see that the security of type 0 and type 1 are equal.

I can totally live with this.
(I still think we give the ITU X-cmte way too much credit)

    > I am not against changing the term “CBOR certificate” and saving that
    > for something else that has nothing with RFC 5280 to do, but I do not
    > understand the previous comment to move type 0 to another
    > document. Given a specification of type 1, type 0 follows trivially.

Good... "make it so"

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 13 Feb 2021 20:50:16 +0100

In 2021-02-13, at 20:48, Michael Richardson <[email-masked]> wrote:
> ITU X-cmte

-v, please?

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 13 Feb 2021 15:30:07 -0700

CBOR.X.509 pronounced “CBOR X 509”?  X.509.CBOR could work too.

Then when we have real CBOR certs they get called “CBOR Certificates” of “CBOR Certs”.

LL

> On Feb 12, 2021, at 3:44 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>