This email addresses the Adoption Call comments from Toerless Eckert <t...@cs.fau.de> on the JOSE-voucher document that were made 2021-07-01. EXEC SUM: I will rename it draft-ietf-anima-jws-voucher-00 when I post it in ten days.
in the meantime, the diff from draft-richardson-anima-jose-voucher-01 to draft-richardson-anima-jose-voucher-02 is at: https://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-anima-jose-voucher-01&url2=3Dhttps://raw.githubusercontent.com/anima-wg/anima-jws-voucher/main/anima-jose-voucher-02.txt } 13 This document describes a serialiation of the RFC8366 voucher format } 14 to a JSON format is then signed using the JSON Object Signing and } 15 Encryption mechanism described in RFC7515. tte> Welcome to the club of people too lazy to use spell checkers. Yeah. How many times do I need to tell it that "TCP" is a word? Spell-checking the XML is impossible, but the markdown ought to be easier. I also found in spell checking that I was not consistent in the MIME type allocation. tte> (2) Up to the point where an AD or other higher power might have objections, tte> i really would like to see this document marked as an Update to RFC8366 so tte> that we have a breadcrump trail from RFC8366 to this document (personally tte> i am never quite sure what the strict requirements are for such a marking). I have added text; This document should be considered an Update to [RFC8366] in the category of "See Also" as per [I-D.kuehlewind-update-tag]. tte> (3) I like to avoid playing "can you remember that RFC number", by prefacing newly tte> introduced RFC numbers with their title or otherwise better known abbreviations. I have taken your advice, and expanded the document names in the intro, and I've changed the citation to [BRSKI] and [SZTP] rather than [RFC8995] and [RFC8572]. (I kinda wish we could do both, because that would help people recognize important RFC numbers...) tte> Likewise full titles would be better for following instances, like CBOR, but i'l tte> not comment on all places, you get the idea. Since the CBOR and COSE references are rather informative, I could leave them that way. } 88 This document provides an equivalent mapping of JSON format with the } 89 signature format in JOSE format [RFC7515]. tte> (5) Here a quick reason why this document exist should be. Something like: tte> The encoding specified in this document is required for [I-D.ietf-anima-brski-async-enroll] tte> and may be required and/or preferred in other use-cases, for example when tte> JOSE is already used in other parts of the use-case, but CMS is not. I've taken your text as: This document provides an equivalent mapping of JSON format with the signature format in JOSE format [RFC7515]. The encoding specified in this document is required for [I-D.ietf-anima-brski-async-enroll] and may be required and/or preferred in other use-cases, for example when JOSE is already used in other parts of the use-case, but CMS is not. tte> I think this document might be the first one that warrants this warning given tte> how this seems like the first new voucher format defined by itself without tte> being tied to a use-case - like constrained-voucher is really constrained-brski, tte> although the same note would make sense there too. Or we also split that tte> up... well, brski-async-enroll is the use case, and it can say that. } 109 [RFC7515] defines two serializations: the JWS Compact Serialization } 110 and the JWS JSON Serialization. This document restricts itself to } 111 the JWS Compact Serialization (JWT) format. tte> (8) ...because ... ?! explained. tte> (10) It is actually called the JWS payload if i read rfc7515 correctly, and i tte> wonder if this whole draft would also not more correctly be called draft-richardson-anima-jws-voucher That's fair enough, and I'll rename it when I upload it. } 151 If PKIX [RFC5280] format certificates are used then the [RFC7515] } 152 section 4.1.6 "x5c" certificate chain SHOULD be used to contain the } 153 certificate and chain. Vouchers will often need all certificates in } 154 the chain, including what would be considered the trust anchor } 155 certificate because intermediate devices (such as the Registrar) may } 156 need to audit the artifact, or end systems may need to pin a trust } 157 anchor for future operations. This is consistent with [RFC8995] } 158 section 5.5.2. tte> I'll have to hink about this more once its WG draft ;-) CMS provides a bag to put certificates. Because it's ASN.1, they just seem to disappear into the CMS object in a way rather like Hermione's Bag of Holding. The JWS way is "x5c", and it feels a lot less like magic. tte> (13) There should be a section "Updates to rfc8366" which just two sentences: tte> This document adds the new JOSE (JWS ?) signature option to vouchers. tte> This document adds privacy considerations for transporting vouchers. Maybe the note in the Introduction is enough? } 170 5. Security Considerations >> } 172 The issues of how [RFC8366] vouchers are used in a [RFC8995] system } 173 is addressed in tte> EOUTOFCOFFEE ? yes. Oops. } 388 A.2. Example Parboiled Voucher Request (from Registrar to MASA) tte> (15) If you want to keep "parboiled", please add a reference to where an tte> explanation is what it means. I've added an explanation in the example. Maybe it belongs in section 2. Not everyone liked my term, but I didn't get a better one. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
