Re: [COSE] Structure of CBOR certificates

[Göran Selander <[e-mail]>]

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 <[e-mail]>
Date: Thursday, 9 July 2020 at 22:02
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [COSE] Structure of CBOR certificates
Resent from: <[e-mail]>
Resent to: <[e-mail]>, <[e-mail]>, <[e-mail]>, John Mattsson <[e-mail]>, <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose