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

[John Mattsson <[e-mail]>]

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 <[e-mail]> on behalf of Ilari Liusvaara <[e-mail]>
Date: Monday, 22 March 2021 at 18:26
To: cose <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/cose