Subject: [COSE] Structure of CBOR certificates

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Jul 2020 12:26:10 +0200

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

---

From: Joel Höglund <[email-masked]>
Date: Thu, 9 Jul 2020 22:02:15 +0200

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-masked]>
wrote:

> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: Göran Selander <[email-masked]>
Date: Fri, 10 Jul 2020 10:08:06 +0000

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-masked]>
Date: Thursday, 9 July 2020 at 22:02
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [COSE] Structure of CBOR certificates
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, John Mattsson <[email-masked]>, <[email-masked]>
Resent date: Thursday, 9 July 2020 at 22:02

Hi Henk and all!

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.

Best Regards

Joel Höglund

On Thu, 9 Jul 2020 at 12:26, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

> 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>

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>

Viele Grüße,

Henk

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Jul 2020 15:58:43 +0300

> experience of how Issuer-fields normally are encoded.

I would say that the encoding of the issuer (and subject) fields is the
most difficult part.

Looking at the definition of issuer/subject, it is essentially:
List<Set<(Oid, Any)>>

Which is bit unfortunate in two ways:

- Set of pairs is not the same as dictionary.
- The right hand side type is Any, and not DirectoryString.
- The outer list is usually of size 1.

If one really wanted to eke bytes, one could have either 1 or 2
lists, since the the first element of inner list can not possibly be
a list itself. If one goes for implementation complexity at cost of
wire size, then one would always have 2 lists.

And then one could have the Oid be encoded as integer for common
ones and bstr for not-common ones.

And the value could be str, which tries to autoguess the correct type,
or bstr containing asn1tag+value as escape.

The type autoguess would guess PrintableString if every character is
valid for PrintableString, else it would guess Utf8String. In practice,
I do not think anybody uses any other ones (and wrong guess would be
just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte
penalty).

Then there is the special case where subject is empty. That could be
encoded as empty list.

> only the subjectPublicKeyInfo_algorithm field.

Note that in practice, there are very few different SubjectPublicKeyInfo
field types in any sort of wide use. Anything else is extremely rare.

Thus, one could compress the field by having integer for type, and bstr
for contents. And perhaps bstr type and bstr contents as escape hatch
(maybe even with the bit stripping octet retained), should that be ever
needed (that would not increase size in common case).

For instance, types could be:

0 => X25519/X448
1 => Ed25519/Ed448
2 => ECDSA P-256/P-384/P-521.

The type overloads are resolvable.

For instance, this encoding could encode Ed25519 or X25519 key to 35
bytes (3 bytes overhead).

And with regards to signature algorithm (which is actually encoded twic
in X.509!), the common case is a few actually used algorithms. E.g.:

0 => Ed25519
1 => Ed448
2 => ECDSA SHA-256
3 => ECDSA SHA-384
4 => ECDSA SHA-512
5 => ECDSA SHAKE-128
6 => ECDSA SHAKE-256

That goes to 1 byte (and of course one could have bstr escape without
affecting common case).

> requirements that go beyond those four.

Extensions could be encoded as array of pairs (one would not want map
here due to order-sensitivity).

One could have generic encoding by having integers encode known
extensions (negative integers encoding critiality) and bstrs encode
escapes (the value of escape would be optional critical flag and then
the raw extension value, which is an octet string). Known extensions
would have more specialzed encodings.

Examples of what could be more specialized encodings:

KeyUsage: Integer value + (1 << bits). 

This would not allow KeyUsage bits above 63th, but I do not think
the number of defined bits is anywhere close to that (RFC5280 defines
9 bits).

And things could turn real annoying if KeyUsage ever needs to set any
bit above 63rd. Sure, one could escape the thing, but relying parties
might puke on that. None of the other three extensions ever needs
escaping for any reasonable value.

ExtendedKeyUsage: List of integer / bstr

Integers would encode some common key usages, bstrs would be escapes
(with just values).

BasicConstraints: null/true/uint

Null encodes empty extension, true encodes just true, and int would
encode true followed by max path length.

SubjectAlternativeName: array of bstr

The bstrs are asn1tag+value. Thus e.g. "foo.example" is encoded as:
4C 82 "foo.example". Encoding IPv4 address would take 6 bytes, IPv6
address would take 18 (2 bytes overhead in both cases).

The difficulty of adding extension beyond these four would depend on
the extension. There would be slots for 24 compact extensions (20 more
than here), 232 bit less compact ones, etc...

Looking at the extension list from RFC5280, the only ones that do not
look like unsuitable for IoT are subject/authority key ID extensions.
Besides the incompatible encodings, if PKI is not crazy, one can use
issuer/subject fields as key identifiers (however, comparing the above
subject/issuer encoding could be annoying). So these do not look
important.

Looking at the other fields, how those could be encoded:

- version: Implicit from presence of optional fields.
- serial_number: bstr (with initial 00 if any stripped).
- validity: pair of integers (unix timestamps). The time format would
  depend on range (-631152000 to 2524607999 is UtcTime). Maybe bstr
  with asn1tag+value as escape in case of misencoded certificate.
- issuerUniqueID/subjectUniqueID absent, null or bstr (including the
  strip bits byte). If subjectUniqueID is present, issuerUniqueID
  has to be as well.

Looking at these rules, this could encode a lot more than just rfc7925
certificates, as there is an escape for nearly everything. The only
obvious thing with no escape is the serial_number, but any violation
there would be fatal ASN.1 error anyway. These should even give valid
compression/decompression for webpki certificates, even if bad one,
due to the junk present.

I have not written any proof-of-concept code for this. So no performance
numbers to give.

-Ilari

---

From: Joel Höglund <[email-masked]>
Date: Thu, 16 Jul 2020 11:38:06 +0200

Hi!

Ilari Liusvaara, we are grateful for your detailed comments, and
constructive proposals. With an extra thank you for sharing your insights
on which field types that are actually in common use. Your comments
highlight the need to further discuss trade-offs between compactness,
generality and ease of implementation.

As you might have seen, we have merged and updated the old cbor certificate
related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) where
we have added some more details regarding encoding and optimizations. We
will look closer to the implications of your proposals as input for
upcoming revisions.

Best Regards

Joel Höglund

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2020 14:50:09 +0300

> generality and ease of implementation.

The principles I followed were mostly:

- Try to do something simple, yet compact in common cases. The solution
  may or may not be pareto-optimal. And even if it is pareto-optimal, it
  may or may not be the best.
- Offer escape hatches, unless fundamential PKIX limitation.
- Minimize the impact of escape hatches on common case (mostly no
  impact).
- Check RFC7925 for the most important extensions, then check RFC5280 to
  see if there are more extensions that could be considered important
  (turns out there are none that are not iffy).

There are some simple optimizations left. For example, one could encode
CN-only names as just tstr/bstr, like is done in
draft-mattsson-cose-cbor-cert-compress-01. This would save 2 bytes for
such name (by eliminating array and integer type tag).

> will look closer to the implications of your proposals as input for

The approach in draft-mattsson-cose-cbor-cert-compress-01 seems much
more specialized. It will probably be at least a few bytes more compact
than what I came up with, but can encode much fewer certificates (which
still may be plenty).

Some issues I noted in draft-mattsson-cose-cbor-cert-compress-01:

1) The encoded certificates may be CA certificates, which would
   presumably indicate that issuer certificate can be explicitly
   encoded.

   There are at least two issues with encoding such certificates:

   a) because subject of issuer must equal issuer of subject (preferably
      bitwise), and subject is CN-only the name of any such CA is
      restricted to be CN-only. Which is not really sufficient for CAs,
      as I would also at least expect unique identifier of the
      organization.

   b) The issuing certificates commonly have Pathlen=0, which is not
      RFC7925-compliant, and is not possible to encode.

   If it is not intended to have explicit issuers, one could remove
   the CA flag entierely, and assume that BasicConstraints is always
   empty.

2) ExtendedKeyUsage is not fixed-order:

   ExtendedKeyUsage is SEQUENCE of OBJECT IDENTIFIER. Neither RFC5280
   nor RFC7925 define order. So presumably the order used is CA-
   dependent, and does affect the signature.

   4 bits is not sufficient to represent non-empty ordered subsets
   of 4 elements. One needs at least 6 bits for that.

   However, one could fit the thing in 4 bits by noting that combining
   id-kp-OCSPSigning with anything else is Bad Idea. And non-empty
   ordered subset of mutually exclusive sets of 3+1 elements does
   fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA,
   CAB, CBA, Z).

3) id-kp-serverAuth/id-kp-clientAuth are TLS-only (the "WWW" in the
   description should read "TLS"). This does also encompass DTLS (and
   future cTLS). But it does not encompass EDHOC.

   EDHOC uses signatures in way incompatible with TLS, and using the
   same key in multiple incompatible ways is not a good idea. Altough
   none of COSE, JWS, X.509 and TLS 1.3 interact harmfully (for pretty
   obvious reasons), e.g., analyzing if TLS 1.2 and COSE would interact
   harmfully is not trivial.

   EDHOC would need its own ExtendedKeyUsage values. And those can
   not be encoded within RFC7925 profile (encoding non-empty ordered
   subset of mutually exclusive sets of 5+1 elements would need 9 bits
   to encode (as there are 326 possibilities)).

4) The draft uses TLS certificate compression instead of TLS certificate
   types. These two have different semantics:

   - TLS certificate types are about encoding of a single certificate
     (it is assumed that all the certificates in chain are of the same
     type).

     This seems to match with what this draft is doing.

   - TLS certificate compression compresses the entiere TLS certificate
     messages in one go. With potentially many certificates, and
     extension blocks for each (which are used, e.g., for OCSP).

     It is only meant to be used with possibly specialized general-
     purpose lossless data compressors (meaning can produce valid, but
     possibly not well-compressed, bytestream for any input). Even the
     much more general compressor I outlined is not even close to
     general-purpose (as there are plenty of inputs where it can not
     produce a valid bytestream).

     And TLS certificate compression and TLS certificate types can both
     be used at once. In this case the decompression is expected to
     produce certificate(s) of correct type. If it does not, the
     certificates(s) very likely get parsed wrong (hopefully running
     into fatal parse error).

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Jul 2020 11:58:19 -0400

A few thoughts inline ...

> On Jul 21, 2020, at 7:50 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

   BasicConstraints ::= SEQUENCE {
        cA                      BOOLEAN DEFAULT FALSE,
        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

You need a way to be clear the difference between no BasicConstraints at all and a BasicConstraints with cA=False and pathLen absent.

>   fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA,

Yes, a SET OF would have defined an order, but it does not help the relying party, who only cares about whether a particular OID is in the SEQUENCE or not.

Putting them in the same order as SET OF would work for new certificates, but it will not help with existing ones.

>   to encode (as there are 326 possibilities)).

Agree that new EKU values are needed for this context.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 20:19:30 -0400

> Looking at the definition of issuer/subject, it is essentially:

Yes, you are right.
To decode for others, the point is that one can have a DN like:
   DC=tuna,DC=sandelman,DC=ca

this is rather uncommon, as most would use CN=tuna.sandelman.ca,
or SAN dnsName=tuna.sandelman.ca with an empty CN if it's the Subject.

I think that the question is perhaps:
   * can we write a reasonable subset (BCP) profile of PKIX for constrained environments?

    > just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte

Who did the CSR, and did the CA molest the type at all?
Otherwise, we could just do Utf8String.

    > The type overloads are resolvable.

We'll have to have RSA in the list too.  We may never want to use it, but I
think it will hav eto be there :-)

What I think we need to do is have someone implement the
compressor/decompressor and then do a survey of certificates out there via
TLS/HTTPS.   That won't be definitive: we'll probably have some failures, and
we may declare them out-of-scope.

I think that the biggest problem will be what goes in the Issuer, which can
be empty, so it has all sorts of kinda throw-away stuff, then a simple CN=
would be enough.
See ^^^ about BCP.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 20:20:46 -0400

> will look closer to the implications of your proposals as input for

Am I correct that the -01 version didn't get posted in time?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Joel Höglund <[email-masked]>
Date: Wed, 22 Jul 2020 09:38:29 +0200

Thank you all for your comments and observations! We will further
investigate the ambiguity of the encoding, and how the scope should be
clarified.

Michael, to quickly reply to your explicit question: the new draft was
posted before the IETF 108 deadline on 2020-07-13, which is also before the
expiry dates of the three different drafts that are now combined. (
https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ )

Another observation is that while our starting point has been to encode
rfc7925 compliant certificates, we hope to make the proposal more future
proof by allowing new algorithms also deemed suitable for constrained
environments. With that target, we think it is possible to exclude RSA on
the list of supported algorithms.

Best Regards

Joel Höglund

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2020 13:12:50 +0200

Hi Joel,

> Michael, to quickly reply to your explicit question: the new draft was posted before the IETF 108 deadline on 2020-07-13, which is also before the expiry dates of the three different drafts that are now combined. (https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ )

That draft says in https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ that it Replaces		draft-raza-ace-cbor-certificates, draft-mattsson-tls-cbor-cert-compress

What is the third draft?

> Another observation is that while our starting point has been to encode rfc7925 compliant certificates, we hope to make the proposal more future proof by allowing new algorithms also deemed suitable for constrained environments. With that target, we think it is possible to exclude RSA on the list of supported algorithms.

Supported for what…

The chain may still have RSA certificates in it.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jul 2020 12:17:08 -0400

Carsten Bormann <[email-masked]> wrote:
    joel> Another observation is that while our starting point has been to
    joel> encode rfc7925 compliant certificates, we hope to make the proposal
    joel> more future proof by allowing new algorithms also deemed suitable
    joel> for constrained environments. With that target, we think it is
    joel> possible to exclude RSA on the list of supported algorithms.

    > The chain may still have RSA certificates in it.

exactly!
I think that the cost is just a single code point.
We are optimizing for network bandwidth, not CPU cycles.
Constrained "environments" isn't specific enough.

In particular, device IDevID or device LDevID, while maybe ECDSA on the
device, may have a chain that anchors up to some pre-existing CA
which can not for legacy reasons be ECDSA (yet).

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Jul 2020 15:16:26 -0400

Micheal:

I suspect that many IoT devices will need to be able to connect to existing infrastructure, and if the requirements get too tight, then people will put proxies in place to avoid changing the certificates on existing infrastructure.  That thinking leads me to a view that we can get great compression when the reasonable subset is followed, but we need to accommodate things outside the subset, even if it means less compression.

Russ

> On Jul 21, 2020, at 8:19 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 22 Jul 2020 21:31:50 +0200

+1 for pointing exactly that out, Russ.

Identifying an appropriate/reasonable subset that allows for streamlined 
value types or condensed keys (or fixed indices in arrays, analogously) 
is an
  important step that needs critical mass for discussion.

"less common" cases, or simply cases that will not find consensus in 
this discussion we will have to represent in a more thorough/verbose manner.

My assumption is that this to be identified subset could also possibly 
help more native representations using COSE.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jul 2020 17:35:17 -0400

Russ Housley <[email-masked]> wrote:
    > I suspect that many IoT devices will need to be able to connect to
    > existing infrastructure, and if the requirements get too tight, then
    > people will put proxies in place to avoid changing the certificates on
    > existing infrastructure.  That thinking leads me to a view that we can
    > get great compression when the reasonable subset is followed, but we
    > need to accommodate things outside the subset, even if it means less
    > compression.

I agree, and I would say this differently:

Devices connecting over challenged networks will need to be part of larger
security infrastructure, not all of which will be trivially upgradable.
(often for non-technical reasons involving regulation)

So, while it might be reasonable to not try to optimize SubjectDN containing
DC=tuna,DC=sandelman,DC=ca, I think that including RSA is easy enough.

{It's not the devices necessarily that are constrained,  it's the networks}

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 26 Jul 2020 20:56:51 +0300

> or SAN dnsName=tuna.sandelman.ca with an empty CN if it's the Subject.

I think most end-entity stuff just has one of the SANs duplicated as
CN and nothing else. Omitting subject is fairly rare due to some
software puking on that.

> Otherwise, we could just do Utf8String.

I think names are usually PrintableString. Utf8String is just used for
the cases where PrintableString just won't do (PrintableString is
proper subset of ASCII, most notably @ and & are not in it).

> think it will hav eto be there :-)

Well, codepoints are pretty cheap here. There are 24 one-byte uints, and
the above just uses 3 of those.

And even if it was not, it would be maybe a two dozen or so more bytes.

> we may declare them out-of-scope.

Well, on TLS/HTTPS, there is mostly WebPKI, which mandates all sorts of
effectively uncompressable junk.

Looking at one 1169 byte certificate, removing all the junk would make
it shrink to ~650 bytes. And using more efficient crypto would shrink
it to ~405 bytes. And fair bit of thet ~405 bytes could be compressed.

-Ilari

---

From: Joel Höglund <[email-masked]>
Date: Mon, 27 Jul 2020 18:09:20 +0200

A follow-up question below:

> Yes, a SET OF would have defined an order, but it does not help the
> relying party, who only cares about whether a particular OID is in the
> SEQUENCE or not.
>
We read Ilari's proposal as a way to uniquely order the relevant EKU
combinations, in which case the encoding would work with both existing and
new certificates. Can you please clarify which situation you are referring
to?

Best Regards

Joel Höglund

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---

From: Joel Höglund <[email-masked]>
Date: Mon, 27 Jul 2020 18:24:25 +0200

Hi!

A reply and a comment below:

On Wed, 22 Jul 2020 at 13:12, Carsten Bormann <[email-masked]> wrote:

> That draft says in
> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> that it Replaces            draft-raza-ace-cbor-certificates,

The current draft, draft-mattsson-cose-cbor-cert-compress-01 is the result
of updating and combining:
draft-raza-ace-cbor-certificates-04,
draft-mattsson-tls-cbor-cert-compress-00 and
draft-mattsson-cose-cbor-cert-compress-00.

> The chain may still have RSA certificates in it.

Supported for being possible to parse and validate by an IoT device: if a
chain has RSA certificates in it, the end device would need to implement
RSA algorithms too. Which is what we have considered out of scope. From
rfc7925, the following explicit constraint is stated:

There are various cryptographic algorithms available to sign digital
certificates; those algorithms include RSA, the Digital Signature Algorithm
(DSA), and ECDSA.  ... [C]ertificates are signed using ECDSA in this
profile. This is not only true for the end-entity certificates but also for
all other certificates in the chain, including CA certificates.This
profiling reduces the amount of flash memory needed on an IoT device to
store the code of several algorithm implementations due to the smaller
number of options."

Best Regards

Joel Höglund

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Jul 2020 13:04:15 -0400

> On Jul 27, 2020, at 12:09 PM, Joel Höglund <[email-masked]> wrote:
> 
> We read Ilari's proposal as a way to uniquely order the relevant EKU combinations, in which case the encoding would work with both existing and new certificates. Can you please clarify which situation you are referring to?

The ASN.1 DER encoding of SET OF specifies the order.  The encoding of SEQUENCE OF allows the sender to pick the order.  I suggest we not pick another ordering.

Russ