Subject: [COSE] CBOR Certificates Open Issues

From: John Mattsson <[email-masked]>
Date: Tue, 24 Nov 2020 09:58:26 +0000

Hi,

We have addressed most of the comments that we got during the meeting. Some issues require some more discussion and are listed below. Any comments on the issues below or reviews of the whole -04 draft is very welcome.

CBOR Certificates Open Issues:

- Should a CBOR certificate be a CBOR Sequence or a CBOR array? Making it an array would add 1 byte, but maybe it has benefits with CDDL validation using current tools.

- Is "#6.6(bstr)" the correct way to write CDDL for tags-oid? Assuming the label 6 will be used in the end. Would be good with something more readable like biguint.

- Do any algorithms with parameters need to be supported? Algorithms with parameters are e.g. RSA-PSS with SHA2, id-ecPublicKey with id-ecPublicKey and specifiedCurve are MUST NOT be used in PKIX according to RFC 5480.

- Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit strings are used in public keys and signature values.

- Do any more attributeTypes need to be supported? Do oid-tags need to be supported for attributeType?

- Do any more character string types than printablestring and utf8string need to be supported? E.g. TeletexString, BMPString, or UniversalString, or IA5String? Neither of therse should be used in new certificates.

- Should the draft use unwrapped CBOR tag 1 for validity? That CBOR implementations already support unix time removes one of the problems. RFC 5280 certificates can use leap seconds, is this important to support? Unix time does not. There are examples of certificates using generalized time for dates < 2050 (in violation with RFC 5280). We could decide to not support these.

- Do any more types of subjectAltName need to be supported? E.g. x400Address, ediPartyName, and registeredID?

- Which optimizations are worth having and what kind of certificate should we optimize for. The draft currently optimize encoding of the example certificate. Encoding subject as a byte string provides quite big savings (17 bytes).

- How to encode extensionvalue for non-7925 extensions? Should they stay DER encoded byte strings, should we specify an encoding for each, can we come up with a general DER-CBOR encoding that can be applied to them all?

- There was a suggestion that SHA-1 algorithms should get large values, but sha1WithRSAEncryption is still one of the most common algorithm. It is quite commonly used in self-signed root certificates, where it is fine to do so.

- Do anything else similar to SCT list and id-at-organizationIdentifier that has been specified after RFC 5280 need to be supported?

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Nov 2020 11:39:49 +0100

Hi John,

> - Should a CBOR certificate be a CBOR Sequence or a CBOR array? Making it an array would add 1 byte, but maybe it has benefits with CDDL validation using current tools.

I’d rather fix the tool instead of spending that byte.

I added an option to the verification choice in the CDDL tool that makes it read a sequence as an array.  That should allow directly using the method recommended in RFC 8742.

Usage:

  cddl foo.cddl vs bar.cborseq

(v for validate, s for sequence).

$ cat sequence.cddl
a = [tstr, tstr, tstr]
$ echo aaaaa | cddl sequence.cddl vs -
$ echo aaaaa | cddl sequence.cddl vsp -
/a/ [/tstr/ "a", /tstr/ "a", /tstr/ "\n"]
$

(“a” is 0x61, the head for a text string of length one.)

Use `gem update` to spring forward to cddl tool version 0.8.15 (*).

> - Is "#6.6(bstr)" the correct way to write CDDL for tags-oid? Assuming the label 6 will be used in the end. Would be good with something more readable like biguint.

6 will not be the tag number; that would be a quite old version of the draft.
Please see 

https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-03.html

for a fresh version.

Section 8:

https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-03.html#name-cddl-typenames

also has suggested CDDL that you can add to your spec.

> - Do any algorithms with parameters need to be supported? Algorithms with parameters are e.g. RSA-PSS with SHA2, id-ecPublicKey with id-ecPublicKey and specifiedCurve are MUST NOT be used in PKIX a…

You mean with parameters beyond namedCurve?

> - Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit strings are used in public keys and signature values.

Good question.
I’m not aware of anyone being that foolish.
I would argue that we don’t need to support such foolery even if it does exist.

> - Do any more attributeTypes need to be supported? Do oid-tags need to be supported for attributeType?

(Don’t know.)

> - Do any more character string types than printablestring and utf8string need to be supported? E.g. TeletexString, BMPString, or UniversalString, or IA5String? Neither of therse should be used in n…

Again, even if they exist in the wild we should not support such foolery.

> - Should the draft use unwrapped CBOR tag 1 for validity? That CBOR implementations already support unix time removes one of the problems. RFC 5280 certificates can use leap seconds, is this import…

To have a problem with the UNIX time scale, a certificate would need to put one of its significant points in time on a leap second.  This is hard to do for future times, as we usually don’t know more than half a year into the future whether there will be a leap second at one of the possible instants.  Certifying a key at a leap second would probably generate enough interop problems that any CA would avoid that.

So I don’t think we need to support leap seconds (read: provide a way to express instances of time that are on a leap second, 23:59:60 UTC).

> - Do any more types of subjectAltName need to be supported? E.g. x400Address, ediPartyName, and registeredID?

Good question.

> - Which optimizations are worth having and what kind of certificate should we optimize for. The draft currently optimize encoding of the example certificate. Encoding subject as a byte string provi…

These are the savings we are looking for.
(But, any German should know, “Kleinvieh macht auch Mist”, i.e., “Many pennies make a dollar”.)

> - How to encode extensionvalue for non-7925 extensions? Should they stay DER encoded byte strings, should we specify an encoding for each, can we come up with a general DER-CBOR encoding that can b…

We could.  I haven’t tried, but that would probably not save a lot.
Do we have an example corpus of such extensions?

> - There was a suggestion that SHA-1 algorithms should get large values, but sha1WithRSAEncryption is still one of the most common algorithm. It is quite commonly used in self-signed root certificat…

Agree.

> - Do anything else similar to SCT list and id-at-organizationIdentifier that has been specified after RFC 5280 need to be supported?

Don’t know.

Grüße, Carsten

(*) Yep, that is a weird number to a German.

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Nov 2020 10:31:26 -0500

John:

A few thoughts on some, but not all, of you questions.

> - Do any algorithms with parameters need to be supported? Algorithms with parameters are e.g. RSA-PSS with SHA2, id-ecPublicKey with id-ecPublicKey and specifiedCurve are MUST NOT be used in PKIX a…

The parameters must be supported.  For id-ecPublicKey, the parameter is namedCurve.

> - Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit strings are used in public keys and signature values.

BIT STRING will not need unused bits for public keys or signatures, but BIT STRING is also used for the key usage extension.

> - Do any more character string types than printablestring and utf8string need to be supported? E.g. TeletexString, BMPString, or UniversalString, or IA5String? Neither of therse should be used in n…

Support for TeletexString, BMPString, and UniversalString is OPTIONAL in RFC 5280.  However IA5String is needed for emailAddress because @ is not supported bt PrintableString.

> - Should the draft use unwrapped CBOR tag 1 for validity? That CBOR implementations already support unix time removes one of the problems. RFC 5280 certificates can use leap seconds, is this import…

it only maters that the mapping is one-to-one.

> - Do any more types of subjectAltName need to be supported? E.g. x400Address, ediPartyName, and registeredID?

These are not likely to be used in the IoT environment.

> - There was a suggestion that SHA-1 algorithms should get large values, but sha1WithRSAEncryption is still one of the most common algorithm. It is quite commonly used in self-signed root certificat…

When do you see the transmission of the root certificate?  TLS sends the certification path up to, but not including, the root certificate.

Russ

---

From: John Mattsson <[email-masked]>
Date: Tue, 24 Nov 2020 22:14:50 +0000

Thanks for your comments and German lessons Carsten!

>I’d rather fix the tool instead of spending that byte.

Agree. Thanks for fixing the tool. and I will try version 0.8.15 :)

>6 will not be the tag number; that would be a quite old version of the draft.

Yes, I must have looked at an an old version of the oid tag draft. I made a commit that use "oid" in CDDL. The tag number is not important anymore when there is suggested CDDL

>> - Do any algorithms with parameters need to be supported? Algorithms with >parameters are e.g. RSA-PSS with SHA2, id-ecPublicKey with id-ecPublicKey >and specifiedCurve are MUST NOT be used in PKIX according to RFC 5480.
>

As pointed out also by Russ, this question was not well-formulated. Let me try again :)

The current draft support id-ecPublicKey with namedCurve and RSA algorithms that set parameters to NULL. The question is if CBOR certificates need to support anything beyond this. RSA-PSS with SHA2 signatures are for example not currently supported, but does not seem to be used much.

>> - Should the draft use unwrapped CBOR tag 1 for validity? That CBOR >implementations already support unix time removes one of the problems. RFC >5280 certificates can use leap seconds, is this important to support? Unix >time does not. There are examples of certificates using generalized time >for dates < 2050 (in violation with RFC 5280). We could decide to not >support these.
>
>To have a problem with the UNIX time scale, a certificate would need to put >one of its significant points in time on a leap second.  This is hard to do >for future times, as we usually don’t know more than half a year into the >future whether there will be a leap second at one of the possible >instants.  Certifying a key at a leap second would probably generate enough >interop problems that any CA would avoid that.
>
>So I don’t think we need to support leap seconds (read: provide a way to >express instances of time that are on a leap second, 23:59:60 UTC).

Agree, we do not need to support leap seconds. The question is if compression of certificates from misbehaving CAs using GeneralizedTime for dates before 2050 need to be supported.

>> - How to encode extensionvalue for non-7925 extensions? Should they stay >DER encoded byte strings, should we specify an encoding for each, can we >come up with a general DER-CBOR encoding that can be applied to them all?
>

Probably not, but for natively signed certificates, the extensionvalues would have to be parsed. I would maybe not be so optimal to force devices to also support DER.

>Do we have an example corpus of such extensions?

The Web?

Cheers,
John

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Date: Tuesday, 24 November 2020 at 11:40
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] CBOR Certificates Open Issues

Hi John,

Usage:

$ cat sequence.cddl
a = [tstr, tstr, tstr]

for a fresh version.

Section 8:

Good question.

(Don’t know.)

Good question.

Agree.

Don’t know.

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Tue, 24 Nov 2020 22:15:06 +0000

Thanks Russ,

>The parameters must be supported.  For id-ecPublicKey, the parameter is >namedCurve.

As pointed out also by Carsten, this question was not well-formulated. Let me try again :)

>> - Do ASN.1 bit strings with unused bits != 0 need to be supported? Bit >strings are used in public keys and signature values.
>
>BIT STRING will not need unused bits for public keys or signatures, but BIT >STRING is also used for the key usage extension.

Thanks, good to get confirmation that unused bits != 0 do not need to be supported in public keys and signature values. The question was really just for these two cases. The bit string in the key usage extention is already encoded as an int.

>> - Do any more character string types than printablestring and utf8string >need to be supported? E.g. TeletexString, BMPString, or UniversalString, or >IA5String? Neither of therse should be used in new certificates.
>
>Support for TeletexString, BMPString, and UniversalString is OPTIONAL in >RFC 5280.  However IA5String is needed for emailAddress because @ is not >supported bt PrintableString.

RFC 5280 states that "Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (Section 4.2.1.6) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted."

Given your answer I guess CAs are still putting emailAddress and IA5String in new certificates and that it need to be supported. I made a commit to support emailAddress.

>it only maters that the mapping is one-to-one.

If CAs follow RFC 5280, we could encode both UTCTime and GeneralizedTime to POSIX time without additional information. It would be one-to-one. If CAs use GeneralizedTime for dates earlier than 2050, it would not be one-to-one and we need to do something more.

>> - There was a suggestion that SHA-1 algorithms should get large values, >but sha1WithRSAEncryption is still one of the most common algorithm. It is >quite commonly used in self-signed root certificates, where it is fine to >do so.
>
>When do you see the transmission of the root certificate?  TLS sends the >certification path up to, but not including, the root certificate.

Good point. Not as often as other certificates, but the root certificates need to be transfered to the IoT devices at least once in the factory or when they are deployed. IoT devices may want to store there root certificates as CBOR certificates to save storage and memory. Compressed root certificates would not even have to be decompressed again.

Cheers,
John

-----Original Message-----
From: Russ Housley <[email-masked]>
Date: Tuesday, 24 November 2020 at 16:31
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] CBOR Certificates Open Issues

John:

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Nov 2020 16:11:13 -0500

> On Nov 24, 2020, at 5:15 PM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Thanks Russ,
> 

I see no uptake of RSA-PSS or RSA-OAEP or RSA-KEM, so it seems reasonable to let them fail compression.

> Thanks, good to get confirmation that unused bits != 0 do not need to be supported in public keys and signature values. The question was really just for these two cases. The bit string in the key u…

Okay.

> Given your answer I guess CAs are still putting emailAddress and IA5String in new certificates and that it need to be supported. I made a commit to support emailAddress.

I see email addresses in three places, but I would really encourage people to only use rfc822Name in the subject alternative name extension.  As best I can tell, the other two locations are to support legacy applications, and I hope that IoT does not have too many of those yet.

> If CAs follow RFC 5280, we could encode both UTCTime and GeneralizedTime to POSIX time without additional information. It would be one-to-one. If CAs use GeneralizedTime for dates earlier than 2050…

This convention has been around since 1999.  RFC 2459 says:

   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.

I hope we can count on it.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2020 20:18:26 -0500

John Mattsson <john.mattsson=[email-masked]> wrote:
    > - There was a suggestion that SHA-1 algorithms should get large values,
    > but sha1WithRSAEncryption is still one of the most common algorithm. It
    > is quite commonly used in self-signed root certificates, where it is
    > fine to do so.

Self-signed root certificates tend not to be transmitted.
If you don't have the right anchor, the chain is useless.
I do have counter-examples (BRSKI) where it is either useful for debugging,
or essential to get pinning right.
However, it's a greenfield, and we'd prefer to encourage ECDSA anyway, so I
strongly agree that SHA-1 algorithms can get large values.

I couldn't tell with the replies of "Agree" what other posters actually were
agreeing to.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2020 20:27:09 -0500

John Mattsson <john.mattsson=[email-masked]> wrote:
    >>> - There was a suggestion that SHA-1 algorithms should get large
    >>> values, >but sha1WithRSAEncryption is still one of the most common
    >>> algorithm. It is >quite commonly used in self-signed root certificates,
    >>> where it is fine to >do so.

    >> When do you see the transmission of the root certificate?  TLS sends
    >> the certification path up to, but not including, the root certificate.

    > Good point. Not as often as other certificates, but the root
    > certificates need to be transfered to the IoT devices at least once in
    > the factory or when they are deployed. IoT devices may want to store
    > there root certificates as CBOR certificates to save storage and
    > memory. Compressed root certificates would not even have to be
    > decompressed again.

I disagree.
If deployed at the factory, then they are likely baked into firmware, or
installed via JTAG, or if done over a network, this won't matter.
As for storing, it only needs the public key part, which would be best to
store in whatever the native big-integer format is. (Maybe more bytes, but
no need to convert to another form)

It might need an index in the form of the Issuer DN.

I hope that the compression of DNs will be distinguished such that there is
only one way to do it, and one can compare the compressed forms rather than
having to expand it to be sure.
I don't feel confident that this will be the case because I think that there
will always be an "out" where raw DER bits can be included for things that
the compressor doesn't know how to deal with.  So a stupid compressor might
produce a bigger result than a smarter compressor.

I also wonder about this work in the context of Packed CBOR.
Should we restart our thinking assuming that we are really just building a
static directory for Packed CBOR?  I suspect that this bespoke compression
will do better for bytes-on-the wire, but what is the code size impact,
assuming that Packed CBOR code was already available?

---

From: John Mattsson <[email-masked]>
Date: Thu, 26 Nov 2020 04:18:02 +0000

Hi Russ,

Then I suggest stick with not supporting RSA-PSS+SHA2. RSA-PSS with SHAKE is supported if people would start to use RSA-PSS.

I already made a commit to support email addresses in issuer, subject, and subjectAltName. assume there a three places you see email addresses. Supporting email addresses in issuer and subject was an easy fix. Henk also indicated before that he thought it probably needed to be supported.

Based on your comment on time I made a commit to use POSIX time which is easy given that people follow RFC 5280/2459. I think we should only support things that deviates from RFC 5280 if it happens to be very widespread. With the new commit time is encoded as unwrapped CBOR epoch date/time (label 1). This simplifies things and aligns with CBOR. It saves 1 byte for dates in the range 2050-2106 and adds 4 bytes for dates in the range 2106-9999.

/John

-----Original Message-----
From: Russ Housley <[email-masked]>
Date: Wednesday, 25 November 2020 at 22:11
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] CBOR Certificates Open Issues

Okay.

Russ

---

From: John Mattsson <[email-masked]>
Date: Thu, 26 Nov 2020 05:19:37 +0000

Hi Michael,

>produce a bigger result than a smarter compressor.

A long as DER is Distinguished (which it should be) and the CBOR encoding is one-to-one (which it should be) comparing the CBOR encoded DNs will not be a problem.

It is hard to comment unless you give more details on why you believe the CBOR encoding would not be one-to-one. 

As long as certificates really are DER, I think everything will work. If some certs are BER in disguise, we will get problem. 

>assuming that Packed CBOR code was already available?

I do not see how Packet CBOR would replace anything in this context. What is mainly needed here is a DER -> CBOR  one-to-one function. CBOR packing is CBOR -> CBOR and it is not one-to-one (it is not a function). Packed CBOR seems to work best on very structured data. Packed CBOR with or without a static dictionary could be used to pack a c5chain of CBOR certificates. I guess you could also theoretically combine a different (not yet specified) DER -> CBOR one-to-one function with a (not yet specified) deterministic one-to-one CBOR packing, and a (not yet specified) dictionary, but I think the "compression" would be limited.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Nov 2020 12:21:24 -0500

> A long as DER is Distinguished (which it should be) and the CBOR
    > encoding is one-to-one (which it should be) comparing the CBOR encoded
    > DNs will not be a problem.

Okay, I've re-read the document.
I thought that there were some outs, i.e. if some rarely occuring thing
occured that it could be sent as pieces of DER.  No such things occur.

So, I agree, we can compare CBOR encoded DNs.
My point remains that an IoT device storing a root certificate only needs the
public key and *maybe* the DN, if it has more than one such anchor.

    > I do not see how Packet CBOR would replace anything in this
    > context. What is mainly needed here is a DER -> CBOR  one-to-one
    > function. CBOR packing is CBOR -> CBOR and it is not one-to-one (it is
    > not a function). Packed CBOR seems to work best on very structured
    > data. Packed CBOR with or without a static dictionary could be used to
    > pack a c5chain of CBOR certificates. I guess you could also
    > theoretically combine a different (not yet specified) DER -> CBOR
    > one-to-one function with a (not yet specified) deterministic one-to-one
    > CBOR packing, and a (not yet specified) dictionary, but I think the
    > "compression" would be limited.

I guess you are right.

---

From: John Mattsson <[email-masked]>
Date: Mon, 30 Nov 2020 11:27:36 +0000

>public key and *maybe* the DN, if it has more than one such anchor.

I agree. But you might want to store validity and some extensions as well. Based on your comments I made a commit that moves the two SHA-1 algorithms to -255 and -254. I agree if it is good to indicate that they should not be used in any new certificates (root or not). We can discuss more details of the IANA registrations at some interim meeting.

Cheers,
John

-----Original Message-----
From: Michael Richardson <[email-masked]>
Date: Thursday, 26 November 2020 at 18:21
To: John Mattsson <[email-masked]>, cose <[email-masked]>
Subject: Re: [COSE] CBOR Certificates Open Issues

I guess you are right.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Nov 2020 13:51:39 +0100

On 2020-11-30, at 12:27, John Mattsson <john.mattsson=[email-masked]> wrote:
>  -255 and -254

(Not that this matters here at all, but I might note that the 1+1 byte range of integers in CBOR goes from —256 to 255.)

Grüße, Carsten