Re: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt

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

On 10/30/10 11:53 AM, Jim Schaad wrote:
> Peter,
> 
> 1.  I had an email problem so probably missed the discussion, however
> I do not understand the current text for the example of a delegated
> domain.  I would suggest text, but as I am running on I don't
> understand that is not possible.  Is this supposed to be some type of
> mapping that says the domain X is really the domain Y?

One example might be that [e-mail] configures her email client
to connect to mailhost.example.com instead of just example.com. Another
example might be connecting to isp.example.net for example.com. Again,
these would be explicitly configured in an email client.

> 2.   In the definition of reference identifier
> s/optionally/optionally/

Fixed.

> 3.   In section 2.1 you have the sentence "This dimension matters
> most for certificate verification."  Would this be more appropriate
> as s/verification/consumption/ ?  The process of certificate
> verification does not really care, but the name matching does.

Done.

> 4.  In the definitions you might want to add one for "automated
> client" to match "interactive client"

I think we already have that in version -10:

   automated client:  A software agent or device that is not directly
      controlled by a human user.

> 5.  On page 20, the following text exists: For an interactive client,
> it is strongly encouraged that each reference identifier SHOULD be
> based on the source domain provided by the user and SHOULD NOT be
> based on a derived domain (e.g., a host name or domain name
> discovered through DNS resolution of the source domain).
> 
> I am not clear why this is important for interactive clients and not
> for automated clients.

Good point. Changed in my working copy to:

   It is strongly encouraged that each reference identifier
   in the list SHOULD...

> 6.  In section 4.6.2 - I am disappointed that the concept of checking
> that the context is either the same or similar is not also included
> in this check.  I think this is an important concept.

Agreed. I propose adding the clause "including the context as described
under Section 5.1", as follows:

   If the client does not find a presented identifier matching any of
   the reference identifiers but the client has previously pinned the
   application service's certificate to one of the reference identifiers
   in the list it constructed for this connection attempt (as "pinning"
   is explained under Section 1.5), and the presented certificate
   matches the pinned certificate (including the context as described
   under Section 5.1), then the service identity check succeeds.

Thanks for your feedback.

Peter

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