I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Please forgive the lateness of this review; I really meant to have it done sooner. First, I found the document to be a tough read, and I can't really pin down why. I started reviewing it several times, and restarted, before I finally got through it. I can't give any advice with this comment, so just take it as it is. Second, there's a mixture of "natural person" and "human user" in the document, and my sense is that you mean the same thing by both. If you do, you should switch to one term (I prefer the latter; "natural person" sounds odd). If they're meant to be different, you should make it clear what the difference is. Third, I'll note the earlier discussion of issues with IDN comparisons. I have nothing to add to that discussion, and it may be that the best thing is to leave things as they are. Comments are in order of appearance, not significance: -- Page 16, bullet 6: The certificate MAY contain more than one DNS-ID, but SHOULD NOT contain more than one CN-ID. Why "SHOULD NOT", and not "MUST NOT" ? I'm not challenging this; it's a question. -- Page 17, sec 4.2, first graf: Before connecting to the server, the client MUST construct a list of acceptable reference identifiers. Why MUST it be done "before"? Can anyone detect, or does it hurt interoperability, if it's done, say, in parallel with connection, or while the client is waiting for the server to return the certificate? -- Page 18, sec 4.2, last bullet: o The list SHOULD NOT include a CN-ID; however, the CN-ID (if included) MUST be constructed only from the source domain and never from a target domain. I find this oddly put. How about "The list SHOULD NOT include a CN-ID. If a CN-ID is used despite this advice, it MUST be..." ? I'd also like to take the security note from section 4.3 and echo it here. So maybe this?: << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite this advice, it MUST be constructed only from the source domain and never from a target domain. Further, it MUST NOT be used unless there are no other supported identifiers present in the certificate. >> -- Page 18, sec 4.3, first graf: by seeking a match and aborting the search if any presented identifier matches one of its reference identifiers. "Aborting" has the connotation of premature termination, before completion, and that's not the case here; you're saying that the match completes the process. How about, simply, "stopping", or "ending" ? -- Page 19, sec 4.4.3: I think implementers might think that you're simply allowing any leading wildcard character, so we should explicitly dissuade them. So, in the first graf: the wildcard character '*', but only as the left-most label of the domain name, make it "only as the complete value of the left-most label". And in the second graf: in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) change to: baz1.example.net and baz2.example.net; also, *bozz.example.net is not allowed and MUST NOT be taken to match frobozz.example.net) -- Page 19, sec 4.4.3, last graf: A specification that references the rules defined in this document can specify that the wildcard character is not allowed in certificates used by the relevant application protocol or community of interest. How about “...can strengthen this section by ruling out wildcard matching altogether for the relevant...” ? -- Page 20, sec 4.4.4, second graf: entry types supported by the client), the client MAY as a fallback check for a string whose form matches that of a fully-qualified DNS domain name in the CN-ID. Back in section 4.2, you say that the client SHOULD NOT include CN-ID in the list, and here you're saying that it MAY make such a comparison. That seems oddly contradictory to me, though one can certainly argue that SHOULD NOT implies MAY. I'd prefer to see this worded differently. -- Page 21, sec 4.6.2: client MUST verify that the presented certificate matches the cached certificate and (if it is an interactive client) MUST notify the user if the certificate has changed since the last time a secure connection was successfully negotiated (where causes of change include but are not limited to changes in the DNS domain name, identifiers, issuer, certification path, and expiration date). I worry about this kind of advice. It violates my rule that says, "Don't ask the user a question that he's not qualified to answer." Of course, "notify the user" can mean a lot of things, but too many clients will implement something like this with a popup that will be meaningless to 99% of the people who use it. -- Page 21, sec 4.6.3, last graf: Instead, the client MUST proceed as follows. I like a colon there, instead of the full stop. -- Page 21, sec 4.6.3.1, security note: caution, for example by first encouraging the user to terminate the connection, forcing the user to view the entire certification path, and allowing the user to accept the certificate only on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session). Same comment as for 4.6.2. Most users will not understand certificate problems, and will have no idea what they should do about them. Always remember the "Barry's mother problem". My mother will *never* want to see an "entire certification path", let alone appreciate being "forced" to. -- Page 22, sec 5.1: When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user (e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host or URI as in [SIP-LOC]) and MUST NOT be derived from the user inputs in an automated fashion (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs (in the form of a reference identifier) and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the connection. Does this mean that a client specifically designed for the "gumbo" service can't automatically use the service type "gumbo", without the user's involvement? Or that a client put out by example.net can't assume a host name of services.example.net in the absence of user input that says otherwise? Further, it's entirely reasonable for a program to have a user enter something like "gmail", and have the client turn that into something like "mail.google.com", deriving it from the user's input in an automated fashion. Do we really want to forbid that sort of thing? -- Barry Leiba