Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
When referencing RFC 6125 you need to provide more details. In particular, you need to pretty much answer every question in section 3 of RFC 6125: <https://tools.ietf.org/html/rfc6125#section-3> One example of how this might look like is in Section 9.2 of <https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/?include_text=1>. For your convenience the relevant text is pasted below: Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". rpki-rtr implementations which use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125]. The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.)
In 5.2: a document defining HTTPS URI needs to be a normative reference. In 5.2.3: can you show an example of response (with relevant HTTP Header Fields)? Or update example in 5.2 to include HTTP Header Fields.
- 4, "Since it is a JWT, JSON strings MUST be represented in UTF-8. ": Is that a new requirement, or a statement of fact about an existing JWT requirement? - 5.2: I'm not sure all readers will understand the meaning of "feature phone". Also, WAP and 2G don't seem all that relevant in 2017. - 5.2.1, first sentence, "The URL MUST be HTTPS URL.": Is that redundant to the similar requirement in the previous section? That instance had an "unless" clause, but this one does not. --2nd paragraph: "... MUST have appropriate entropy for its lifetime." Can you offer discussion (or a reference) for what constitutes "appropriate entropy"? -- 3rd paragraph: Is it reasonable that one would know if TLS would offer adequate authentication at the time of the signing decision? - 5.2.3, 2nd paragraph: "SHOULD use a unique URI": Why not MUST? Would it ever be reasonable to not do this? - 6.1, 2nd paragraph: What if validation fails? - 13: Do you want this in the final RFC? If not, it would be wise to add a note to the RFC editor to that effect.
- intro: "attacks... have been identified." yells out for a reference - it'd be a good bit better if implementers could easily find details of some such attacks, so I hope you add some refs here. - section 3; WAP? Really? I'm surprised any WAP technology would still be in use, even on feature-phones. Do you really need this? - section 4: I think it will turn out to be an error to allow for mixing query parameters and protected parameters (in a Request Object) in a single request. Do you really need that level of flexibility? It'd be simpler and less likely to be attackable to insist that all parameters be in the Request Object if one is used. (See also section 11.2.1 below.) - section 10: Is there nothing to be said about the new indirection caused by the request_uri? I'd have thought there were some corner cases that'd warrant a mention, e.g. if some kind of deadlock or looping could happen, or if one client (in OAuth terms) could use a request_uri value as a way to attempt attacks (to be assisted by an innocent browser) against some resource owner. - section 11: thanks for that, it's good. - section 11: Saying that an ISO thing is "good to follow" is quite weak IMO. (And is that ISO spec accessible? Hmm... it seems that one needs to accept cookies to get it which is wonderfully ironic;-) If the authors have the energy, I'd suggest trying to find better guidance that's more publically available in a privacy-friendly manner. (Or just drop the ISO reference if 6973 is good enough.)
Should this document maybe update rfc6749?