Hi Henk, Thanks for the input. Great to also see your note about usefulness of native CBOR certificates! This adds to Laurence previous comments on the list.
For your information, we are now working on a merge of the following drafts: draft-raza-ace-cbor-certificates draft-mattsson-tls-cbor-cert-compress draft-mattsson-cose-cbor-cert-compress The union of the contents will become a new version of draft-mattsson-cose-cbor-cert-compress (being the draft having the right WG designation). We will not be able to take your comments into account before the cutoff on the 13th, but this is excellent input for discussion before and at the !ETF 108 WG meeting. Thanks Göran From: Joel Höglund <[email protected]> Date: Thursday, 9 July 2020 at 22:02 To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [COSE] Structure of CBOR certificates Resent from: <[email protected]> Resent to: <[email protected]>, <[email protected]>, <[email protected]>, John Mattsson <[email protected]>, <[email protected]> Resent date: Thursday, 9 July 2020 at 22:02 Hi Henk and all! Thank you for your comments and update proposals! In brief, there is definitely a need to clarify the assumptions about existing x509 data structures we want to encode, and probably in some cases make the proposal more general to allow more valid rfc7925 certificates. Some further comments to the highlighted issues follows. 1. About Issuer-field encodings: We would like to have more discussions on if for instance your directoryString proposal is necessary, or if the string types can be assumed -- hopefully with input from others with experience of how Issuer-fields normally are encoded. 2. About algorithm parameters: Our current assumption is that for our target certificates, all needed algorithm info can be represented using only the subjectPublicKeyInfo_algorithm field. 3. About a general extension oid-mapping: We believe the four extensions mandated by rfc7925 should suffice, but are open for hearing about IoT requirements that go beyond those four. Looking forward to further discussions, and Best Regards Joel Höglund On Thu, 9 Jul 2020 at 12:26, Henk Birkholz <[email protected]<mailto:[email protected]>> wrote: Hi all, TL;DR moving the CBOR X.509 Profile forward + comments on native CBOR certificates After some dialog with the authors, I created a PR on a few topics we think should be discussed on-list. > https://github.com/EricssonResearch/CBOR-certificates/pull/24<https://protect2.fireeye.com/v1/url?k=55948e46-0b346ed8-5594cedd-86ee86bd5107-faf6e602f8a174dd&q=1&e=4b292bae-4962-4a86-9de0-0c0127e741fe&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FCBOR-certificates%2Fpull%2F24> Some context: The CBOR profile for X.509 certs is based on requirements coming from the (D)TLS profiles for IoT as defined in RFC7925. Section 4.4 in RFC7925 is about certificates and the most relevant part of that RFC for this work. Most of the requirements defined help to reduce the complexity of how to use X.509 pub-key identity documents. This helps with the complexity of a corresponding canonical de-composition and re-composition of "CBOR certificates" - and ultimately to safe bytes during conveyance. It is also important to highlight here that not only saving bytes is important, but also the applicability of the solution. The more certificates can be processed/compressed via the defined approach, the more it will be useful in the field. The PR highlighted above includes a proposal how a full CDDL specification can looks like. It also adds some complexity to the CBOR structure that we may or may not want. And that is what we would like to find out with the help of the list. As a result that PR is intended to be a basis for discussion. In order to kick-off the discussion, I would like to highlight a few topics we started to discuss via the PR here on the list. 1.) While the use of Subject is significantly simplified in RFC7925, the same is not true for Issuer. The PR provides an example of how to present "not-RFC7925-optimized" hierarchical names. And you can see the increased complexity quite well. String types like the options from directoryString or AI5 have to be retained in order to allow for canonical re-construction of Issuer. But maybe - effectively - strings type are used in a very deterministic manner. Would that be naive assumption? Or might it be feasible to reuse the Subject constraints from RFC7925 for Issuer? 2.) In order to steer the use algorithms, algorithm parameters can be included next to the algorithm identifiers. If they are included in a certificate, these have to be represented in this profile, too. Or can assumption be made that they are not used or somehow deterministic? If in doubt, the small amount of complexity as found in the CDDL might be warranted. In the end, it would be unfortunate to exclude a subset of certs, because they include alg parameters. 3.) How relevant is the inclusion of generic extensions via oid for the application of the CBOR profile for X.509? The PR includes a relative straight forward approach how to map oid, but is that necessary? Is it safe to assume that there will be a core set of extensions that warrants a mapping to a set of integers that would significantly reduce the size of a CBOR cert? These are three prominent topics today and there will be other. I hope to get feedback on the topics elaborated on here and of course the PR. The diff for the PR to see the changes side by side can be found here: > https://github.com/EricssonResearch/CBOR-certificates/pull/24/files<https://protect2.fireeye.com/v1/url?k=10493808-4ee9d896-10497893-86ee86bd5107-d50a06dc675c460c&q=1&e=4b292bae-4962-4a86-9de0-0c0127e741fe&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FCBOR-certificates%2Fpull%2F24%2Ffiles> Looking at the current and proposed CDDL structure, I'd like to note as a separate topic that with only a few minimal tweaks to the current specification it already resembles a solution viable for native CBOR certificates, too. The only effective difference is the scope of the signature, which would not require a dual stack implementation on constrained devices (that sometimes might want to check a signature). In general, native CBOR certificates would be quite useful in applications, such as SUIT Workflow Models, trustworthy time synchronization in swarms of things, lightweight remote-attestation, Concise Software Identities or the emerging SBOM efforts of NTIA/CICP. If you think of the IoT as an initial scope, there is also no pressing need for public CAs to embrace a native format ad-hoc. Viele Grüße, Henk _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
