Ben and all, Very good questions all IMO. Thanks for asking them! >:)
-----Original Message----- >From: Ben Campbell <[email protected]> >Sent: Dec 6, 2010 11:19 AM >To: [email protected] >Subject: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 > >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." >_______________________________________________ >certid mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/certid Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 Network Eng. SR. Eng. Network data security ABA member in good standing member ID 01257402 E-Mail [email protected] Phone: 214-244-4827 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
