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]> 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 > > 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 > > > 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] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
