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-boun...@ietf.org on behalf of mcr+i...@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+i...@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
