Here are some additional comments inline. > -----Original Message----- > From: Peter Saint-Andre [mailto:[email protected]] > Sent: Monday, September 13, 2010 11:41 AM > To: James Schaad > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [TLS] Review of draft-saintandre-tls-server-id-check > > Thanks for your careful review. Comments inline. > > On 9/6/10 11:14 PM, James Schaad wrote: > > 1. There are those who say that the DNS system is dead for dealing with > > identification of items. That the main way that people find items these > > days is by doing searches. This should perhaps be acknowledged in > > section 1.3 under the DNS domain names section. I.e. we use DNS names > > still for some things (such as SMTP servers), but for many things the > > name that the user knows is obtained in a very indirect manner. (search, > > URL click, address book entry) In a similar manner today people don�t > > remember telephone numbers as they are all indirectly obtained, but they > > do write them down to give to other people. > > Yes, that is a good point. Complicated, but good. We somewhat address it > in this paragraph: > > Finally, we do not discuss attributes unrelated to DNS domain > names, such as those defined in [X.520] and other such > specifications (e.g., organizational attributes, geographical > attributes, company logos, and the like). > > It seems to me that this relates to the expectations of human users more > than our relatively clear-cut discussion of DNS domain names. For > example, supposedly some large percentage of the searches on Yahoo! are > for "Google" (and vice-versa); clearly the folks who are doing such > searches are from our perspective rather unsophisticated users of the > Internet, and they might know that they're on "Google" when they see the > company logo (which changes on special days!) not when they see > "http://www.google.com/"; in the address bar of their browser. The > authors of this I-D have not completed any research into the > expectations of such users (although Jeff has better knowledge of the > literature than I do), so it seems inappropriate for us to say much > about the matter. However, I agree that this would be a good topic for > further research and discussion (e.g., perhaps "petnames" might make > sense here).
I agree that there is an issue. I disagree that this is discussed in any way. I read the paragraph above as addressing the question of additional attributes that might appear in a certificate (such as logotypes) and not as dealing with additional attributes that are displayed on the screen or indirectly inferred by the user. I still think that a (short) discussion to the fact that in some cases where the user did not explicitly enter the reference identifier, there may be cases that even though all of the details match -- the user will be at an unexpected location. (This is after all what a phishing attack is all about.) > > > 2. Do you consider an HTTP redirect to still be a direct name or is > > this now an indirect name? The simplest method would be to go from an > > http: to an https: but other types of redirects are also interesting � > > not the least is just clicking w/o actually looking at where you are going. > > IMHO the name received via an HTTP redirect is an indirect name (e.g., I > typed "exmaple.com" but my browser is redirected to "example.com"). > Naturally that applies only to domain redirects -- a redirect from one > URL to another URL within the same domain would preserve the same DNS > domain name for identity checking purposes. I agree that this is a case of an indirect name. I think therefore that you need to look at the table in section 2.1 and change the URI-ID to be "Either" rather than "Yes" in the Direct column. And yes I agree that if the URL that you are redirected to has the same Domain Name, then it is a moot point. > > > 3. You might want to also give a domain-component (dc=) version of the > > common name for doing identifiers � and then say it is out of scope. > > i.e. �dc=com, dc=example, dc=www� > > Earlier versions of this I-D (up through -06) talked about domain > components as something not to do, but that seems to have caused more > confusion than clarity so we removed the text. I understand. > > > 4. You might want to add to the implementation note on page 15 that > > there is not always agreement about the order that the strings should be > > displayed in. Thus for some the root RDN is displayed first but for > > others it is displayed last. (Thus the CERT_NAME_STR_REVERSE_FLAG for > > the CertStrToName function from Microsoft.) > > Yes, there was much discussion about that topic on the [email protected] list. > > We currently have this sentence: > > However, because > a Relative Distinguished Name (RDN) is an unordered group of > attribute-type-and-value pairs, the string representation of an > RDN can differ from the canonical DER encoding. > > Does adding the parenthetical clause at the end of the following text > address your concern? > > However, because > a Relative Distinguished Name (RDN) is an unordered group of > attribute-type-and-value pairs, the string representation of an > RDN can differ from the canonical DER encoding (and the order of > attribute-type-and-value pairs can differ in the string > representations or display orders provided by various > implementations). Sorry - I did not make myself sufficiently clear. There are cases where the RDNSequence (a SEQUENCE and therefore ordered) is displayed in reverse order. This is what the flag does. Inside of the RDNSequence is a RelativeDistinguishedName which is a SET an therefore does not have order. The order of the RDNSequence is ordered since it is in fact a sequence. What is not ordered is the attribute value pairs that make up a RelativeDistinguishedName. Generally an RDN is the same as the RDNSequence. Going back and re-reading the text. It is clear that there is going to be some confusion about what names are and what the fields of names are. Certificates use the type RDNSequence as the "Name" field of a certificate. This corresponds to the DN that you are talking about in the text. They use the longer RelativeDistinguishedName type as the RDN that you are talking about in the text. Without some clarification someplace, there is bound to be some confusing popping up. > > > 5. In section 3, what about URI-ID and SVN-ID � are multiple of these > > name forms allowed or not? Since 5 is explicit on CN-ID and DNS-ID I > > think that the other two name forms should be covered as well. > > I agree that we need to be clear about that, and I think that it is > acceptable to include multiple instances of those identifier types. I would think that having multiple SVN-IDs make sense - esp since you can get multiple values from the DNS on the indirect. I am not so sure that it makes any more sense to allow for multiple URI-ID values unless they are in the same DNS space - for the same reasons that it does not make sense to allow for multiple DNS-ID records to be presented. > > > 6. I am not really happy with the choice of wording for �and aborting > > the search� � in my mind you abort for bad conditions and not for good > > conditions. Stop the search, exit the search are all reasonable and > > don�t imply an error state. > > In the working copy I've changed "aborting" to "stopping". Yes this addresses my issue. > > > 7. I got confused and started to say that you needed to do wildcards in > > section 4.4.1 because that is not referenced in the text of section > > 4.4. > > Yes, adding a forward pointer from 4.4 to 4.4.3 makes sense. > > > It is not clear how the wildcard label matching should be done > > dependent on the tradition vs. internationalized domain name difference. > > > > The client MUST match the source domain of a reference identifier > > according to the following rules. The rules used depends on whether the > > source domain is a "traditional domain name" or an "internationalized > > domain name" as previously defined, and if wildcard labels are permitted. > > I see your point. In our working copy I've adjusted Section 4.4 to read > as follows (thus pointing to the sections that follow): > > ### > > 4.4. Verifying a Domain Name > > The client MUST match the source domain of a reference identifier > according to the following rules. The rules differ depending on > whether the source domain is a "traditional domain name" or an > "internationalized domain name" (as previously defined). > Furthermore, the source domain (whether a traditional domain name or > an internationalized domain name) might contain the wildcard > character '*' as the left-most label, so we define a supplemental > rule for so-called "wildcard domains". Finally, we specify the > circumstances under which it is acceptable to check the "CN-ID" > identifier type. > > ### Looks good > > > 8. Does the following statement apply in section 4.4.2? What does it > > mean for 4.4.1 if a wildcard is present? > > > > Each label MUST match in order for the names to be considered to > match. > > > > I think that it is confusing and should potentially be > > removed. > > Yes, that applies to both traditional domain names and internationalized > domain names. I have added the sentence to the paragraph in Section 4.4.2. > > However, I have slightly modified the text to address your point about > wildcard labels, as follows: > > ### > > 4.4.1. Checking of Traditional Domain Names > > If the source domain of a reference identifier is a "traditional > domain name", then matching of the reference identifier against the > presented identifier is performed by comparing the set of domain name > components using a case-insensitive ASCII comparison, as clarified by > [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to > "www.example.com" for comparison purposes). Each label MUST match in > order for the names to be considered to match, except as supplemented > by the rule about checking of wildcard labels (Section 4.4.3). > > 4.4.2. Checking of Internationalized Domain Names > > If the source domain of a reference identifier is an > internationalized domain name, then an implementation MUST convert > every label in the domain name to an A-label before checking the > domain name. Each label MUST match in order for the names to be > considered to match, except as supplemented by the rule about > checking of wildcard labels (Section 4.4.3). > > 4.4.3. Checking of Wildcard Labels > > A client employing this specification's rules MAY match the reference > identifier against a presented identifier whose DNS domain name > contains one instance of the wildcard character '*', but only if that > character is the complete left-most label of the domain name, e.g. > *.example.com (following the definition of "label" from [DNS]). > > If the wildcard character '*' is the complete left-most label of a > traditional domain name or internationalized domain name, the > wildcard MUST be used to match only the one position-wise > corresponding label (thus *.example.com matches foo.example.com but > not bar.foo.example.com or example.com). The client MUST fail to > match a presented identifier 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), or in which the wildcard character does not > comprise the left-most label in the presented identifier (e.g., > neither bar.*.example.net nor bar.f*o.example.net are allowed). > > [...] > > ### Looks good > > > 9. In section 4.6.2 � I can understand that a certificate �change� by > > having the certification path change. However if one were to change the > > DNS domain name, identifiers, issuer or expiration date, I don�t > > understand how one would say that it is the same cached certificate? Do > > you expect clients to cache the certificate based one something other > > than the actual bytes of the certificate? i.e. the public key and > > subject name? Or are you trying to address the case where for the > > specific reference identifier there exists a cached certificate and the > > certificate that was presented is a different certificate from the one > > that was cached? (In which case one should potentially say that one > > needs to fall into the 4.6.3 logic after informing the user of the fact.) > > We care about the latter case, which means we can simplify the text in > Section 4.6.2, as follows: > > ### > > 4.6.2. Case #2: No Match Found, Cached Certificate > > If the client finds no presented identifier that matches any of the > reference identifiers but a natural person has permanently accepted > the certificate during a previous connection attempt or via > configured preferences, the certificate is cached. In this case, the > client MUST verify that the presented certificate matches the cached > certificate; if the presented certificate does not match the cached > certificate then the client MUST proceed as described under Case #3 > below. > > > ### Did you mean to lose the case where the certification chain has been modified from the time where the natural person accepted the certificate? I can see this as being one case where a different processing might need to occur. Jim > > Thanks again for the review. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
