Subject: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Jun 2010 09:46:41 +0800

In draft-saintandre-tls-server-id-check-05, Sections 3.6.2 and 3.6.3.1 talk about user choice in interactively trusting a certificate.  

What is missing is discussion on "why" users might need to (or want to) override the default behaviour.  Usage practices aren't obvious, so this seems like a good place to expand on this.

It would be good if this described what are acceptable types of certificate validation failure and what aren't.  Common reasons that are potentially valid are:
 - not trusted (no CA)
 - expired certificate
 - wrong name
 - revoked certificate

Obviously, you aren't going to accept a certificate if the entity providing it could not prove that they possess the corresponding private key.

It might help to explain the significance of such an action - the user is trusting the entity that is able to proof possession of the private key that corresponds to the private key in the certificate.  All other data in the certificate becomes irrelevant.

--Martin

p.s. I don't know what happens in practice if a certificate is pinned before expiry and then subsequently expires.  Same goes for revocation.  I'd be interested in learning what people do.  Logic suggests that if a certificate is accepted despite violating one criterion, it does not imply continued acceptance when another criteria are subsequently violated.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 20:23:26 -0600

On 6/8/10 7:46 PM, Thomson, Martin wrote:

> In draft-saintandre-tls-server-id-check-05...

The preferred (and quite active) venue for discussion of this I-D is the
[email-masked] list:

https://www.ietf.org/mailman/listinfo/certid

I'm going to forward your message to that list and reply there.

Peter

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