Re: [certid] [TLS] Review of draft-saintandre-tls-server-id-check

[Peter Saint-Andre <[e-mail]>]

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).

> 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.

> 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.

> 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 [e-mail] 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).

> 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.

> 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".

> 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.

###

> 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).

   [...]

###

> 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.


###

Thanks again for the review.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/