Adam Roach has entered the following ballot position for draft-ietf-anima-voucher-06: No Objection
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-anima-voucher/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
