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

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

Forwarding from the [e-mail] list to maintain continuity.

-------- Original Message --------
Subject: [apps-discuss] draft-saintandre-tls-server-id-check and user
overrides
Date: Wed, 9 Jun 2010 09:46:41 +0800
From: Thomson, Martin <[e-mail]>
To: [e-mail] <[e-mail]>rg>,	[e-mail]
<[e-mail]>om>,	[e-mail] <[e-mail]>

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.
_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss