Subject: [COSE] Conditional call for adoption: draft-mattsson-cose-cbor-cert-compress

From: Ivaylo Petrov <[email-masked]>
Date: Tue, 2 Mar 2021 22:46:48 +0100

Dear all,

This message starts the conditional *call for adoption* of the following
draft :

* *draft-mattsson-cose-cbor-cert-compress-08*
  - https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress-08

In previous meetings and email discussions, we have already discussed this
draft on multiple occasions. It appears to us that there is significant
support for the adoption of this document. If you have *read the draft*,
please indicate whether you support its adoption as a working group item or
not. As it appears that there is sufficient support for adopting it, *we
are especially interested in knowing if there are any objections.*

Please note that the adoption of this work is *dependent on the result of
the COSE WG rechartering*. If the new charter is accepted in a form that
allows this work to be taken in COSE, the result of this adoption call will
be taken into account.

We would like to remind you that adoption *does not mean they are finished*,
only that they are an *acceptable starting point*.

This call will run slightly less than two weeks, *ending on March 12*. Please
try to respond before that date.

Best regards,

- Matthew and Ivaylo
COSE Working Group Chairs

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Mar 2021 16:56:47 -0500

I support adoption of this draft.

Russ

> On Mar 2, 2021, at 4:46 PM, Ivaylo Petrov <[email-masked]> wrote:
> 
> Dear all,
> 
> This message starts the conditional call for adoption of the following draft :
> 
> * draft-mattsson-cose-cbor-cert-compress-08
>  <https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress-08>
> In previous meetings and email discussions, we have already discussed this draft on multiple occasions. It appears to us that there is significant support for the adoption of this document. If you have read the draft, please indicate whether you support its adoption as a working group item or not. As it appears that there is sufficient support for adopting it, we are especially interested in knowing if there are any objections.
> 
> Please note that the adoption of this work is dependent on the result of the COSE WG rechartering. If the new charter is accepted in a form that allows this work to be taken in COSE, the result of this adoption call will be taken into account.
> 
> We would like to remind you that adoption does not mean they are finished, only that they are an acceptable starting point.
> 
> This call will run slightly less than two weeks, ending on March 12. Please try to respond before that date.
> 
> Best regards,
> 
> - Matthew and Ivaylo
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Mar 2021 18:09:29 -0500

> This message starts the conditional *call for adoption* of the
    > following draft :

    > * *draft-mattsson-cose-cbor-cert-compress-08* -
    > https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress-08

    > In previous meetings and email discussions, we have already discussed
    > this draft on multiple occasions. It appears to us that there is
    > significant support for the adoption of this document. If you have
    > *read the draft*, please indicate whether you support its adoption as a
    > working group item or not. As it appears that there is sufficient
    > support for adopting it, *we are especially interested in knowing if
    > there are any objections.*

I have read the document, and I have an implementation underway.
I agree with adoption.

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

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 11 Mar 2021 18:13:12 +0100

+1 for adopting this document.

Best,
/Marco

On 2021-03-02 22:46, Ivaylo Petrov wrote:
>   - 
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mattsson-cose-cbor-cert-compress-08&data=04%7C01%7Cmarco.tiloca%40ri.se%7C9f1b4d21d5aa49090ee608d8ddc4c52c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637503184863773646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MQpM1oKrhIpBZ%2BB0cJaWxxEeZLMuJrbnR9oSxPD4Uys%3D&reserved=0>
> *read the draft*, please indicate whether you support its adoption as 
> a working group item or not. As it appears that there is sufficient 
> Please note that the adoption of this work is *dependent on the result 
> of the COSE WG rechartering*. If the new charter is accepted in a form 
> that allows this work to be taken in COSE, the result of this adoption 
> call will be taken into account.
>
> We would like to remind you that adoption *does not mean they are 
> finished*, only that they are an *acceptable starting point*.
>
> This call will run slightly less than two weeks, *ending on March 
> 12*. Please try to respond before that date.
>
> Best regards,
>
> - Matthew and Ivaylo

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Rene Struik <[email-masked]>
Date: Thu, 11 Mar 2021 17:54:27 -0500

Dear colleagues:

I think considering ways to represent certificates more efficiently may 
be useful, where this draft could be a possible starting point to work from.

I have not yet read the entire draft, but am wondering about some of the 
underlying philosophies, where, e.g.,
(a) in Fig. 4 (CBOR Cert Public Key Algorithms), NIST curve P-256 is not 
supported, whereas curves isomorphic to Curve25519 are, which seems to 
be inconsistent;
(b) in Fig. 3 (CBOR Cert Signature Algorithms), EdDSA is supported, 
whereas this deterministic scheme is known to be susceptible to 
single-fault attacks, which seems to be contrary to best current practice.

The above comments should not prevent using this draft as a starting 
point, though.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: John Mattsson <[email-masked]>
Date: Thu, 11 Mar 2021 23:06:34 +0000

- secp256r1 is supported and included in Figure 9. Fig 4? Are you maybe reading some old version?

- C509 is CBOR encoding of X509. It follows X.509 and does should not really go into security aspects of the algs. Also note that the signature would be made by a CA, not an IoT device.

John

From: COSE <[email-masked]> on behalf of Rene Struik <[email-masked]>
Date: Thursday, 11 March 2021 at 23:54
To: Ivaylo Petrov <[email-masked]>, cose <[email-masked]>
Cc: Cose Chairs Wg <[email-masked]>
Subject: Re: [COSE] Conditional call for adoption: draft-mattsson-cose-cbor-cert-compress

Dear colleagues:

I think considering ways to represent certificates more efficiently may be useful, where this draft could be a possible starting point to work from.

I have not yet read the entire draft, but am wondering about some of the underlying philosophies, where, e.g.,
(a) in Fig. 4 (CBOR Cert Public Key Algorithms), NIST curve P-256 is not supported, whereas curves isomorphic to Curve25519 are, which seems to be inconsistent;
(b) in Fig. 3 (CBOR Cert Signature Algorithms), EdDSA is supported, whereas this deterministic scheme is known to be susceptible to single-fault attacks, which seems to be contrary to best current practice.

The above comments should not prevent using this draft as a starting point, though.

Best regards, Rene

Best regards,

- Matthew and Ivaylo

COSE mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Thu, 11 Mar 2021 18:34:26 -0500

Hi John:

My web browser indeed served up an older version - my apologies.

If a device has to implement signature verification logic for a 
signature scheme, it is highly likely that that device also uses this 
algorithm for signing (if only to amortize some of the BOM and 
engineering cost). Hence, eco-system impacts should be considered, at 
least in my thinking. {Where a signature scheme has known weaknesses on 
the signing side, one should try and steer way from inadvertently 
enticing moral hazards.}

I hope this helps, Rene

On 2021-03-11 6:06 p.m., John Mattsson wrote:
> - secp256r1is supported and included in Figure 9. Fig 4? Are you maybe reading some old version?
> - C509 is CBOR encoding of X509. It follows X.509 and does should not 
> really go into security aspects of the algs. Also note that the 
> signature would be made by a CA, not an IoT device.
>
> John
>
> *From: *COSE <[email-masked]> on behalf of Rene Struik 
> <[email-masked]>
> *Date: *Thursday, 11 March 2021 at 23:54
> *To: *Ivaylo Petrov <[email-masked]>, cose <[email-masked]>
> *Cc: *Cose Chairs Wg <[email-masked]>
> *Subject: *Re: [COSE] Conditional call for adoption: 
> draft-mattsson-cose-cbor-cert-compress
>
> Dear colleagues:
>
> I think considering ways to represent certificates more efficiently 
> may be useful, where this draft could be a possible starting point to 
> work from.
>
> I have not yet read the entire draft, but am wondering about some of 
> the underlying philosophies, where, e.g.,
>
> (a) in Fig. 4 (CBOR Cert Public Key Algorithms), NIST curve P-256 is 
> not supported, whereas curves isomorphic to Curve25519 are, which 
> seems to be inconsistent;
>
>     In previous meetings and email discussions, we have already
>     discussed this draft on multiple occasions. It appears to us that
>     there is significant support for the adoption of this document. If
>     you have *read the draft*, please indicate whether you support its
>     adoption as a working group item or not. As it appears that there
>     is sufficient support for adopting it, *we are especially
>     interested in knowing if there are any objections.*
>
>     Please note that the adoption of this work is *dependent on
>     the result of the COSE WG rechartering*. If the new charter is
>     accepted in a form that allows this work to be taken in COSE,
>     the result of this adoption call will be taken into account.
>
>     [email-masked]  <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/cose  <https://www.ietf.org/mailman/listinfo/cose>
>
> -- 
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 22 Mar 2021 19:26:03 +0200

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