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

["James Schaad" <[e-mail]>]

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.

 

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.

 

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"

 

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

 

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.

 

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.

 

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

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.

 

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

 

 

From: Joe Salowey [mailto:[e-mail]] 
Sent: Wednesday, September 01, 2010 8:14 PM
To: [e-mail]; Sean Turner; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Review of draft-saintandre-tls-server-id-check

 

At IETF-78 you accepted the task of reviewing
draft-saintandre-tls-server-id-check.   We'd like to get this draft moving
and we think it needs wide review.  Please let me know when you think you
will be able to complete a review of the draft. 

Thanks,

Joe