Subject: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 19:58:06 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-cose-x509-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-x509/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 2.  Where is the uri (CCDL) syntax/format/data type (used by x5u and
x5u-sender) defined?  Is this covered by CBOR tag=32?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would like to recognize Jim Schaad’s tremendous contribution to the IETF as
author, implementer, mentor and leader.

Thank you to the Charlie Kaufman for the SECDIR review.  This review proposes
and poses a few places where clarifying text would be helpful.  Please respond
to it.

** Section 1.  Per the github pointer with examples:
-- please add this url as a reference, not an inline url
-- which exact set of references are relevant to this draft?  It isn’t clear
how this collection of examples applies.

** Section 2.  Recommend precision on the string vs. integer algorithm
identifier.

OLD
The first element is an algorithm identifier which is
      an integer or a string containing the hash algorithm identifier.
      The algorithm is registered in the "COSE Algorithms" registry

NEW
The first element is an algorithm identifier which is an integer or a string
containing the hash algorithm identifier corresponding to either the Value
(integer) or Name (string) column of the algorithm registered in the "COSE
Algorithms" registry.

** Table 1.  To line up with the column names of COSE Headers Parameters
registry with this table, s/Type/Value Type/

** Section 5.  Recommend pointing to Section 7 of RFC3986 to cover security
considerations of URI.

** Section 5.  Per “On the other hand, an oracle can potentially be built based
on detecting the network resources which is only done if the signature
validation passes.”, I didn’t follow what this means.

** Editorial Nits

-- Section 1.  Editorial.  Multiple typos.
OLD
In the process of writing [RFC8152] the working group discussed X.509
   certificates [RFC5280] ad decided that no use cases wher prestented
   that showed a need to support certificates

NEW
In the process of writing [RFC8152], the working group discussed X.509
certificates [RFC5280] and found that that no use cases were presented that
showed a need to support certificates

-- Section 1.  Editorial.
OLD
for example, in the 6TiSCH
   environment [I-D.richardson-enrollment-roadmap], describes a device
   enrollment solution that relies on the presence in the device of a
   factory-installed certificate.

NEW
for example, in the 6TiSCH environment, [I-D.richardson-enrollment-roadmap]
describes a device enrollment solution that relies on the presence of a
factory-installed certificate on the device.

-- Section 2.  Editorial.  s/be configured use a/be configured to us a/

-- Section 2.  There appears to be a missing transition from describing x5u and
Table 1 which applies to all the preceding text.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Oct 2020 09:06:06 +0200

On 2020-10-21, at 04:58, Roman Danyliw via Datatracker <[email-masked]> wrote:
> x5u-sender) defined?  

The draft references RFC 3986.

It could be more explicit in saying that the URI as defined in RFC 3986 is represented as a CBOR text string; it is indeed unfortunate that the tables use the term “uri” which is the name given by RFC 8610 Appendix D to the CDDL prelude type for Tag 32 (uri = #6.32(tstr)).

> Is this covered by CBOR tag=32?

Tag 32 would be a way to mark the text string as a URI at the CBOR level (the definitions of Tag 32 in RFC 7049 as well as draft-ietf-cbor-7049bis both also reference RFC 3986).
However, the addition of the tag is not needed here, as the labeled parameter (x5u/x5u-sender) already provides the URI semantics.
(One convention to signify the use of an unadorned text string with URI semantics in CDDL would be “~uri”.)

Grüße, Carsten

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 21 Oct 2020 12:14:00 +0000

Hi Carsten!

> -----Original Message-----
> From: Carsten Bormann <[email-masked]>
> Sent: Wednesday, October 21, 2020 3:06 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]; [email-masked]
> Subject: Re: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with
> DISCUSS and COMMENT)
> 
> It could be more explicit in saying that the URI as defined in RFC 3986 is
> represented as a CBOR text string; it is indeed unfortunate that the tables use
> the term “uri” which is the name given by RFC 8610 Appendix D to the CDDL
> prelude type for Tag 32 (uri = #6.32(tstr)).

Exactly.  The drafts cites the syntax of the URL with RFC3986, but it does not state the CBOR data type -- this was the simple clarification I was looking for.

The name collision is definitely unfortunate.

Regards,
Roman

> Tag 32 would be a way to mark the text string as a URI at the CBOR level (the
> definitions of Tag 32 in RFC 7049 as well as draft-ietf-cbor-7049bis both also
> reference RFC 3986).
> However, the addition of the tag is not needed here, as the labeled parameter
> (x5u/x5u-sender) already provides the URI semantics.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2020 08:27:49 -0700

> validation passes.”, I didn’t follow what this means.

The scenario is an attacker sending probably-bogus signatures to the node
that behaves in this way.  The (lack of) outbound network requests is an
oracle as to whether the signature is valid.  This is generally not useful
in its own right, but is a fairly common building block to assemble with
other weaknesses into a consolidated attack, which is why I assumed it was
mentioned.

-Ben