I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-saintandre-tls-server-id-check-11 Reviewer: Ben Campbell Review Date: 2010-12-03 IETF LC End Date: 2010-12-16 Summary: This draft is almost ready for publication as a BCP. I have a few questions and comments that I think should be considered first, as well as a few editorial comments. *** Major issues: -- [ Not so much a "major issue" as a "slightly less minor" one] I'd like to see more discussion around URI-IDs. These seem to me to be the most complex ID type to get right, but there are no examples and limited discussion. Picking on SIP, purely as an example for which I have a passing familiarity: Would a SIP reference identity match a SIPS URI-ID in a certificate? Do I put both a URI-ID and an SRV-ID in my reference set and/or certificate? How do I handle the fact that I sometimes need to do a NAPTR query, before the SRV query depending on whether I know the transport protocol? (I realize SIP already defines cert ID matching, but what would I do for a new application protocol URI with similar properties?) I wonder if the answer is that such things are scheme specific, and that its hard to say much about the generic handling of URI-IDs. If so, it might be worth mentioning that, and maybe discuss what things the designer of a new scheme should keep in mind. *** Minor issues: -- 1.2, last paragraph: Nothing normative here? Do we think that protocol designers SHOULD reference document instead of rolling their own? For example, would you expect additional IESG or SECDIR scrutiny for a new spec that rolls its own rather than referenda this? As stated, this paragraph makes it sound like this is something designers could use, rather than something designers should use. It seems like a BCP might take a stronger position. -- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related technologies such as [S-NAPTR], since such identifiers cannot be validated in a trusted manner in the absence of [DNSSEC]." Does that mean validation of a source domain that will be used to construct a NAPTR request is out of scope, or just validation against the result of a NAPTR query? (I note SIP may require the first). -- 2.3, paragraph 1: A DN example might be helpful. -- 2.3, paragraph 3: "application service is identified by a name or names carried in the subject field and/or in one of the following identifier types" May be identified, right? Since, as you mentioned earlier, it is common to identify a service with a name plus service designator, and only the SRV-ID and URI-ID intrinsically do this. -- 3.1, rule 3: What happens when you have multiple schemes that are defined to refer to the same resource. For example, SIP and SIPS? Does a SIP URI-ID match an otherwise identical SIPS URI-ID? (Maybe this should be left to the URI definitions themselves, but it might be worth mentioning the complication somewhere.) -- 3.1, rule 5: "... unless a profile of this specification... " This pattern recurs throughout the document. Can you elaborate on what you mean by "profile"? Normally I think of a "profile" as defining a subset of choices for some particular application. But if a profile relaxes a requirement (i.e. encouraging something that is a SHOULD NOT here), that's not really a subset. Are you referring to an application protocol spec that refers to this document? Updates to this document? (I'm not sure if this should count as a minor issue or an editorial comment. It depends on whether its just a confusion around the word choice, or whether you have something specific in mind that I did not grok). -- 3.1, rule 6: Can you motivate why this is not a MUST NOT? -- section 3.2: I'd like to see a (non-trivial) URL-ID example. -- 3.2, first example: Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in examples? The example does seem to make sense, but it makes me wonder if the SHOULD NOT would be better placed on the client verification process not the cert generation process. --4.2.1, paragraph 3: It's probably out of scope, but it might be useful to offer some guidance on how ensuring the extraction is "not subject to subversion" is not always trivial. For example, if you got your input URI by clicking on a link in a phishing email, that can be almost isomorphic to using a delegation from a non-trusted source. -- 4.2.2: Can we have a URI-ID example? (and maybe an explanation why the HTTP example doesn't use one?) -- 4.3, 4th bullet item: An example would be helpful here. -- 4.4, rule 1: Why not MUST NOT? -- 5.1: Should this doc mention anything about the ability to unpin? *** Nits/editorial comments: -- 1.1, paragraph 1: "...visible face of the Internet consists of services that employ a client-server architecture..." This seems a little overstated. Client-server applications are certainly common, but they don't represent all common uses of the Internet. (Or do I misinterpret what you mean by "visible face"?) "references some conception... of... identity" I'm not sure what that means. Can you state this more plainly? Maybe "concept of identity" or "idea of identity"? (I realize "conception" can mean "concept", but it sounds strained to my mental ear.) -- 1.2, Paragraph 1: "document does not supersede the rules for certificate issuance or validation provided in [PKIX]" If this document does not supercede PKIX, then that also means that PKIX is authoritative on any point for which is draft may be in conflict with it, right? "Specifically, in order to ensure proper authentication, application clients need to verify the entire certification path, because this document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate." Sentence hard to parse. Can it be broken up or simplified? -- 1.2, Paragraph 2: "existing application protocols" Probably worth tying that to a point in time, as in "application protocols that were specified prior to the publication of this BCP" -- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a space." I don't see any $'s -- 1.5, definition of "delegated domain": "connecting to the source domain" Is connecting to really the term you want here? Maybe "associated with"? In the context of this draft, I'm afraid people will think of connection in terms of tcp connections, etc. -- 1.5, definition of "subject name" Is there a definition or reference for "composite name"? -- 1.6: I don't know if it matters, but I usually see contributors and acknowledgments sections near the end. It seems sort of abrupt to find them imbedded between technical content sections. -- 3.1, 1st paragraph: It's probably worth emphasizing that the rules are often cumulative. I think someone thinking about these for the first time might not grasp that until they see examples later in the doc. -- 4.3, implementation note: "although such behavior is not forbidden by this document" The "SHOULD stop the search" language in previous paragraph implies that you SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's strongly discouraged. The implementation note makes it sound more like it is merely out of scope. -- 4.3, 4th bullet item does the ABNF or URI reference define "reg-name" as well as "scheme"? That seems ambiguous. If not, then it might be helpful to have an expansion, definition, or reference for "reg-name". -- 4.4: "Furthermore, if the client supports presented identifiers that contain the wildcard character ’*’, we define a supplemental rule for so-called "wildcard certificates". I think the definition will stay there regardless of the intent of the client :-) Perhaps something to the effect of "... We define a supplemental rule...which may be used by clients that support wildcards." _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf