Subject: Re: [COSE] Some comments on draft-mattsson-cose-cbor-cert-compress

From: John Mattsson <[email-masked]>
Date: Thu, 13 May 2021 11:22:36 +0000

Thanks Ilari!

I will go through your comments next week and include updates for version -01.

Great that you are implementing, there are other people implementing as well. In the future, we should maybe make a list of implementations and maybe make sure that they are interoperable.

Next week I will release the RUST code I wrote to generate the examples in the draft. My code take a DER encoded cert from file, or a DER encoded chain from a TLS server and compress it to C509.

Cheers,
John

-----Original Message-----
From: COSE <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Date: Monday, 22 March 2021 at 18:26
To: cose <[email-masked]>
Subject: [COSE] Some comments on draft-mattsson-cose-cbor-cert-compress

I am trying to write an implementation of draft-mattsson-cose-cbor-cert-compress,
some comments on editor's draft about things that came up:

- Section 3.3. Encoding of Extensions says that:

  "Critical extensions are encoded with a positive sign and non-critical
  extensions are encoded with a negative sign."

  However, section 8.3. C509 Certificate Extensions Registry has:

  0 -> Subject Key Identifier

  0 is neither positive nor negative, so sign-flipping can not be
  used with it. 

  Name kinds do similar name flipping, but there at least is no
  name kind 0.

- Section 3.3. Encoding of Extensions says that:

  "Critical extensions are encoded with a positive sign and non-critical
  extensions are encoded with a negative sign."

  However, section 3.3.1. Example Encoding of Extensions contains a
  number of examples, where seemingly sign is used in exactly the
  opposite way (positive is non-critical, negative is critical).

- Section 8.3. C509 Certificate Extensions Registry has:

  Authority Key Identifier -> bytes

  However, section 3.3. Encoding of Extensions says:

  "authorityKeyIdentifier. extensionValue is encoded as an array where"

  So AKI may be an array.

- Section 3.3. Encoding of Extensions has CDDL, which has derivation:

  ExtValueAKI -> bytes

  However, the prose does not seem to say what having bytes there
  means.

  It would make sense to use bytes to mean AKI that has only the
  keyIdentifier field, as that is seemignly the most common case, and
  it would make AKI match up with SKI. 

- Section 8.3. C509 Certificate Extensions Registry has:

  Extended Key Usage -> int

  However, section 3.3. Encoding of Extensions says:

  "extKeyUsage. extensionValue is encoded as an array of"

  So EKU may be an array.

- Section 3.1. Message Fields says:

  "If the array contains exactly two ints and the absolute value of the
  first int is 2, the array is omitted and"

  Extension 2 is Subject Alternative Name, which does not admit int
  as argument (only array and text).

- Unknown algorithms with no parameters could be encoded as bytes
  instead of current [bytes].

- Unknown non-critical extensions could be encoded as (bytes, bytes)
  instead of current (bytes, false, bytes).

- This may be intentional, but looks bit odd: RSASSA-PKCS1-v1_5 with
  SHA-256 is 23, which is 1 byte int, whereas all the other RSA
  signatures use 2 byte identifiers.

-Ilari

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 13 May 2021 21:05:16 -0700

If I’m thinking right, the one-byte saving from using a sequence rather than array for CBORCertificate only happens when using CBORCertificate in a non-CBOR protocol. When you put CBORCertificate in a CBOR protocol, it has to be an array (or a bstr-wrapped sequence) so it can be distinguished from the surrounding CBOR. In non-CBOR protocols, the surrounding protocol (e.g., the DER, or the TLS records) provides the framing for what is the cert, so the array is not needed.

I’d like to see CBORCertificate an array in the main definition. Then when CBORCertificate is put in a non-CBOR protocol, it can be “unwrapped" to save the byte. The CDDL notation for that would be ~CBORCertificate. (I’ve been reading up on CDDL unwrapping lately, so hopefully I got that right).

This also aligns CBORCertificate with the other CBOR protocols I’ve seen so far. They use an array or map to hold the top-level messages together.

Also, I’m pretty sure the CDDL for COSE_C5 is wrong in the -08 draft. It says:

    COSE_C5 = [ + CBORCertificate ]

With CBORCertificate defined as a CDDL group, no framing structure to distinguish the individual CBORCertificates is generated. The array defined by this is not of individual certs, but of an aggregation of all the certificate data items. It would not be possible to decode correctly. Making CBORCertificate an array solves this problem.

We should expect CBORCertificate to be incorporated into lots and lots of other CBOR-based protocols. If we are making a mistake like this because of CBORCertificate being a sequence and not an array, it seems others may as well. So another reason for the main definition of CBORCertificate to be an array.

LL

---

From: John Mattsson <[email-masked]>
Date: Fri, 14 May 2021 08:22:44 +0000

> This is what is in the draft now, I'm I'm pretty sure it is incorrect CDDL
>

This is not in the current version. It has already been changed in the GitHub version based on the discussions during the previous interim. There seemed to be agreement to use arrays. We did not want to make technical changes is -00 so the change will come in -01. The current version is
COSE_C5 = [ [ + C509Certificate ] ]

It should be discussed if the inner array should be moved to C509Certificate. The idea to unwrap ~C509Certificate when the array is not needed is a good idea.

> I'm I'm pretty sure it is incorrect CDDL

I don't know why you think this was incorrect CDDL. RFC 8610 even has the following example [+(left: uint, right: uint)] (but this does not matter as I think we have already taken the decision to use arrays).
> It would not be possible to decode correctly.

I don’t think that was true. That would only be true if you cannot determine the number of elements from c509CertificateType (but this does not matter as I think we have already taken the decision to use arrays).

Cheers,
John

From: COSE <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Friday, 14 May 2021 at 06:05
To: cose <[email-masked]>
Subject: [COSE] The one-byte saving from use of a sequence

LL

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 May 2021 12:14:48 +0200

I haven’t looked at that part of the draft in a while, but in CDDL we have types and groups.

To model sequences, we can use a group or (if a top level type is required) wrap those groups into an array.

C509Certificate = (…)
Is a group.  You can repeat such a group using

	+C509Certificate

But that means you have to count to eleven.

So you want to wrap that group into an array to then repeat it:

COSE_C5 = [ + [ C509Certificate ] ]

which is what the current editor’s draft says:

https://github.com/cose-wg/CBOR-certificates/blob/master/draft-ietf-cose-cbor-encoded-cert.md

(Can someone please fix the README?  “Editor copy” link from HTML is 404, still says EricssonResearch.)

Grüße, Carsten

> On 14. May 2021, at 10:22, John Mattsson <john.mattsson=[email-masked]> wrote:
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 14 May 2021 11:03:22 -0700

> On May 14, 2021, at 1:22 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 

Yes, you are right, as long as the number of items is fixed, you can count and successfully decode (didn’t think of counting like that).

You’d have to be aware of this every time you designed a CBOR protocol that uses CBORCertificate

For example, you couldn’t count for this protocol, but it works fine if CBORCertificate is an array.

   [ 
       * cert : CBORCertificate
       * vector : int
   ]

I still think everyone’s life will be easier if CBORCertificate defined as an array so it works as expected for CBOR-based protocols and you unwrap the array to save the byte in non-CBOR protocols.

LL