Subject: [Fwd: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check]

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 27 Aug 2009 20:21:48 -0600

Oops, mistakenly sent to Paul only...

- -------- Original Message --------
Subject: Re: Deprecating DNS names in the subjectName in
draft-saintandre-tls-server-id-check
Date: Thu, 27 Aug 2009 20:20:54 -0600
From: Peter Saint-Andre <[email-masked]>
To: Paul Hoffman <[email-masked]>
References: <[email-masked]>
<p06240832c64d88af4ed4@[10.1.3.183]> <[email-masked]>
<p06240802c6503138a9f0@[10.20.30.249]> <[email-masked]>
<p0624080dc6bcd6240625@[10.20.30.158]>

On 8/27/09 6:34 PM, Paul Hoffman wrote:
> At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>> Paul, I agree that this document needs to codify secure
>> authentication practices. However, that raises a more general
>> issue: shall this document specify rules only for certificate
>> validation or also for certificate generation?
>
> Validation only.

Works for me.

>> My understanding of the scope that Kurt and I inherited from JeffH
>> and RL Bob is that the document specifies rules only for
>> validation, and even there only for a particular subset of
>> validation, namely matching of the server's presented identities
>> against the client's expected "reference identity" (e.g., not
>> necessarily mentioning anything about the fact that the certificate
>> needs to be certified by a chain of certificates terminating in a
>> trust anchor).
>
> Correct. You might toss in a paragraph saying "of course, you need to
> do full PKIX checking as well, details are in 5280", but I don't
> think you even need that.

Sure thing.

>> Personally I think that it would be helpful to specify rules about
>> both generation and validation (and about how the client should
>> proceed if validation in the broadest sense fails), but before
>> expanding the scope of the document I'd like to make sure that
>> people here are comfortable with doing so.
>
> It would be useful to say what to do when validation fails; you
> simply don't have to list all the PKIXy ways it can fail.

Shamelessly borrowing from draft-ietf-xmpp-3920bis, the text describing
"what to do when validation fails" might be as detailed as this...

***

   The outcome of the checking procedure is one of the following:

   Case #1:  The client finds at least one presented identity that
      matches the reference identity; the entity MUST use this as the
      validated identity of the server.

   Case #2:  The client finds no subjectAltName that matches the
      reference identity but a human user has permanently accepted the
      certificate during a previous connection attempt; the client MUST
      verify that the cached certificate was presented and MUST notify
      the user if the certificate has changed since the last time that a
      secure connection was successfully negotiated.

   Case #3:  The client finds no subjectAltName that matches the
      reference identity and a human user has not permanently accepted
      the certificate during a previous connection attempt; the client
      MUST NOT use the presented identity (if any) as the validated
      identity of the server and instead MUST proceed as described in
      the next section.  Instead, if the client is a user-oriented
      application, then it MUST either (1) automatically terminate the
      connection with a bad certificate error or (2) show the
      certificate (including the entire certificate chain) to the user
      and give the user the choice of terminating the connecting or
      accepting the certificate temporarily (i.e., for this connection
      attempt only) or permanently (i.e., for all future connection
      attempts) and then continuing with the connection; if a user
      permanently accepts a certificate in this way, the client MUST
      cache the certificate (or some non-forgeable representation such
      as a hash value) and in future connection attempts behave as in
      Case #2.  (It is the resposibility of the human user to verify the
      hash value or fingerprint of the certificate with the peer over a
      trusted communication layer.)  If the client is an automated
      application, then it SHOULD terminate the connection with a bad
      certificate error and log the error to an appropriate audit log;
      an automated application MAY provide a configuration setting that
      disables this check, but MUST provide a setting that enables the
      check.

***

However, it's not clear to me if we really need to go into that level of
detail.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 19:29:57 -0700

>However, it's not clear to me if we really need to go into that level of

We don't really need to go to that level, but I think it is quite appropriate, given that the desired result is guidance for developers who often get it wrong.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 27 Aug 2009 20:31:09 -0600

On 8/27/09 8:29 PM, Paul Hoffman wrote:
>> However, it's not clear to me if we really need to go into that
>> level of detail.
> 
> We don't really need to go to that level, but I think it is quite
> appropriate, given that the desired result is guidance for developers
> who often get it wrong.

That's my feeling.

Peter

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