Subject: [COSE] Iotdir telechat review of draft-ietf-cose-x509-07

From: Carsten Bormann via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 15:04:20 -0700

Reviewer: Carsten Bormann
Review result: Ready with Issues

First, I would like to express my gratitude to Jim Schaad for having
done this work (and all the work that led up to making this work
possible).

The draft fills a gap where COSE is being used in conjunction with
infrastructure employing X.509-based validation of keys.  JOSE defined
the necessary parameters right away, while the use case for COSE was
less clear initially.

One criticism might be that the draft does not speculate on how
constrained devices could share tasks that need to be performed in
this use case with trusted less-constrained devices -- there are
probably infinite ways of doing so, and the ones actually to be used
should rather be discussed in the protocols that govern the
constrained--less-constrained communication.

The draft is ready with issues.

## Major

Section 1:

The draft points to examples to be found in the github repository
https://github.com/cose-wg/Examples -- these are not in there.
Either these examples need to be added or this sentence deleted.

## Minor

Section 2:

I'm not sure what "certificates of a chain length of..." actually
means -- the chain length is not an intrinsic property of a
certificate, but a function of what the application's roots are.
Maybe rephrase:

   These rules apply when the validation succeeds in a single step as
   well as when certificate chains need to be built.

The draft uses the term "bag" for what is meant to be a set.
Maybe stick with the "x5bag" parameter name and the prose "certificate
bag", but when saying what it is, say that it is a set.

## Nits

https://github.com/cose-wg/X509/pull/28

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Oct 2020 21:15:21 -0400

Thank you for the timely review!

    > bag", but when saying what it is, say that it is a set.

I believe we use the term bag because it is permissible for a certificate
artifact to appear more than once. Stupid maybe, but permissible.

I think that some systems/libaries considered the Issuer/Subject to be the
key for indexing the set, and then they got confused if there was more than
one certificate in the bag.  The additional object used a different signature
and/or hash.  At least, I have some dim memory of some situation being
described to me.  I think that the names of the guilty parties were withheld.

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 20 Oct 2020 10:25:12 +0000

Thank you Carsten for this review of indeed a very special I-D.

I have used your IoT directorate review to enter my ballot.

Regards

-éric

-----Original Message-----
From: last-call <[email-masked]> on behalf of Carsten Bormann via Datatracker <[email-masked]>
Reply-To: Carsten Bormann <[email-masked]>
Date: Tuesday, 20 October 2020 at 00:05
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Last-Call] Iotdir telechat review of draft-ietf-cose-x509-07

    ## Major

    Section 1:

    ## Minor

    Section 2:

    ## Nits

    -- 
    last-call mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/last-call

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Oct 2020 13:42:53 +0200

> described to me.  I think that the names of the guilty parties were withheld.

I think we have a different perception of what “is” means.
In my shopping bag, there *is* a difference between having one or two yoghurts in there.
In the x5bag, having the same certificate twice is exactly equivalent to having it once.
So it “is” a (non-empty) set, not a bag, even if the *representation* (as an array, with a special case for the singleton) can actually have duplicates.

Given the semantics, the question how one “finds” things in that set is more of an implementation question.  I don’t think offering this as a multimap(*) with some arbitrarily chosen map key is flexible enough.  Normally, a simple iterator (so you get to see any and all of the elements) will be the best solution, because the implementation cannot know what the application-specific validation process is looking for, and we are talking about a very small set.

Grüße, Carsten

(*) Cannot be a map, as there is no guarantee of uniqueness of any key.