Skip to main content

A Voucher Artifact for Bootstrapping Protocols
RFC 8366

Yes

(Terry Manderson)

No Objection

Alvaro Retana
(Alia Atlas)
(Alissa Cooper)
(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana No Objection

(Terry Manderson; former steering group member) Yes

Yes (for -06)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2017-12-13 for -06)
Thanks to the authors and working group participants for their work on this document. I have a somewhat major and handful of minor suggestions for improvement.

The larger comment is: section 5 talks about a variety of potential alternate formats and mentions a couple of techniques that might be used to differentiate among them. I'll note that these techniques relate to MIME types and related data (filename extensions). The fact that *this* document doesn't define a MIME type for the CMS-signed-JSON variant will make it difficult and/or awkward for these future formats to employ these techniques. For example, if I were to define a COSE-signed-CBOR format and say "use HTTP Content-Type header fields to tell this apart from CMS-signed-JSON", I would be in the somewhat odd position of having to define the MIME-type for CMS-signed-JSON in *that* document, or of coming up with a very short update to the anima-voucher document that does nothing other than define its MIME type.

It seems that adding a single sentence to section 5 ("To facilitate these techniques, this document registers a MIME type for CMS-signed JSON in section 8.4") plus a registration of a new MIME type along with its filename extension (e.g., "application/voucher-cms+json" and ".vcj") in that new section 8.4 would make life much easier for anyone who wants to define the alternate formats envisioned by section 5.


Section 2:
      Securely imprinting is a primary focus of this document [imprinting].

This is a pretty awkward citation. Suggest maybe changing it to:
      Securely imprinting is a primary focus of [imprinting].

(It's also not entirely clear that the cited article covers *securely* imprinting, so you may consider rephrasing the sentence entirely)

Section 2:
   Authentication of Join Registrar:  Indicates how the Pledge can
      authenticate the Join Registrar.  This might include an indication
      of the private PKIX (Public Key Infrastructure using X.509) trust
      anchor used by the Registrar, or an indication of a public PKIX
      trust anchor and additional CN-ID or DNS-ID information to
      complete authentication.

I think a citation here to RFC6125 would be helpful to the user in understanding the meaning of CN-ID and DNS-ID.


Section 7.1: I think it would be useful to explicitly point out that a device that might have a MITM registrar could also have an MITM attack against any attempts to use an unauthenticated network protocol (such as NTP) to retrieve a time; and that such network-retreived times cannot be trusted for voucher verification purposes.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2017-12-12 for -06)
The document is generally fine, but first references to CN-ID and DNS-ID need a reference to RFC 6125, as these terms are not defined anywhere in the document. X.690 also needs a reference.

Nit In 7.1, first sentence:

has no understand ==> has no understanding

(Alia Atlas; former steering group member) No Objection

No Objection (for -06)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2017-12-13 for -06)
Just some editorial comments:

- Abstract: I suspect readers will not understand the meaning of "pledge". The abstract should be understandable without referencing the terminology section.

-4, definition of Assertion Basis" : is "secure root of trust of measurement" a term of art, or a typo?

-7.1, first paragraph: s/understand/understanding

(Benoît Claise; former steering group member) No Objection

No Objection (2017-12-14 for -06)
Some nits, coming from Joe Clarke as OPS DIR reviewer.

Section 2:

Old Text:

The MAS concept is explained in more detail in...

New Text:

The MASA concept is explained in more detail in...

(Note: MAS => MASA)

Old Text:

Registrar  See Join Registrar

New Text:

Registrar:  See Join Registrar

(Note: colon added)

(Deborah Brungard; former steering group member) No Objection

No Objection (for -06)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (2017-12-14 for -06)
We are discussing some comments in email, but they seem to be about writing, not technology.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-12-13 for -06)
Thank you for addressing Russ' Gen Art comments.  With that, I'm wondering if a recommended signature algorithm should be specified.  This change had the work go from just supporting RSA to including other (and better) choices.  

Thanks,
Kathleen

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -06)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -06)