Re: [COSE] "CBOR Certificates"

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 <cose-bounces@ietf.org> on behalf of Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
Date: Friday, 12 February 2021 at 08:37
To: Michael Richardson <mcr+ietf@sandelman.ca>, "cose@ietf.org" <cose@ietf.org>
Subject: Re: [COSE] "CBOR Certificates"

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" <cose-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:

    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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
               Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose