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
