Subject: [COSE] CBOR certificate by reference (c5u)

From: John Mattsson <[email-masked]>
Date: Thu, 21 Jan 2021 22:02:45 +0000

Hi,

Good that Laurance brought up the "trust relationship" that the x5u text talks about during the interim, this seem quite unspecified in the draft. Also, forcing the implementation to support pkcs7 in addition to COSE_X509 seems unnecessary.

https://github.com/cose-wg/X509/issues/31

I updated the text for 'c5u'. It does not align with x5u as much anymore. We definitely do not want to force implementation to support pkcs7. The current plan is to let c5u just be a way to do c5bag/c5chain out of band. Should it be bag or chain?

Below is the current updated text in GitHub.

-------------------------------------------------

COSE Header Parameters Registry {#cose}

EDITORS NOTE: Should x5u refer to a bag or a chain? The text should be moved a section and not be in the IANA Section.

This document registers the following entries in the "COSE Header Parameters" registry under the "CBOR Object Signing and Encryption (COSE)" heading. The formatting and processing for c5bag, c5chain, and c5t are the same as the corresponding x5bag, x5chain, and x5t defined in {{I-D.ietf-cose-x509}} except that the certificates are CBOR encoded instead of DER encoded and that c5t MUST refer to an end-entity certificate. c5u provides an alternative way to identify an untrusted certificate bag/chain by reference with a URI. The content is a COSE_X509 item served with the application/cbor content format.

As the contents of c5bag, c5chain, c5t, and c5u are untrusted input, the header parameters can be in either the protected or unprotected header bucket. The trust mechanism MUST process any certificates in the c5bag, c5chain, and c5u parameters as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation.

Note that certificates can also be identified with a 'kid' header parameter by storing 'kid' and the associated bag or chain in a dictionary.

+-----------+-------+----------------+------------------------------+
| Name      | Label | Value Type     | Description                  |
+===========+=======+================+==============================+
| c5bag     |  TBD1 | COSE_X509      | An unordered bag of CBOR     |
|           |       |                | certificates                 |
+-----------+-------+----------------+------------------------------+
| c5chain   |  TBD2 | COSE_X509      | An ordered chain of CBOR     |
|           |       |                | certificates                 |
+-----------+-------+----------------+------------------------------+
| c5t       |  TBD3 | COSE_CertHash  | Hash of a CBOR certificate   |
+-----------+-------+----------------+------------------------------+
| c5u       |  TBD4 | uri            | URI pointing to a bag/chain  |
|           |       |                | of CBOR certificates         |
+-----------+-------+----------------+------------------------------+

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 18:12:44 -0500

If one wanted to include a draft-mattsson-cose-cbor-cert-compress-06 compressed certificate
in a COSE object using draft-ietf-cose-x509, would I use an existing tag?
I can see that with x5u, that there would be a mime type and negotiation that
could determine whether or not to send the compressed certificate.

But for the rest, we need something.
Probably, a new x5bag equivalent?
Or, it could be that each member (or single item) of the x5bag could have a tag.
In that case, I think that maybe x509-08, should define a tag for
uncompressed PKIX certificate?

Should draft-mattsson-cose-cbor-cert-compress-06 extend draft-ietf-cose-x509,
or should draft-ietf-cose-x509 reference cert-compress (probably normative).

On the topic of draft-mattsson-cose-cbor-cert-compress-06, since we've spent
at least two entire virtual interims on it, shouldn't it get adopted already?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [