Forwarding from the [email protected] 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 <[email protected]> To: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>
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 [email protected] https://www.ietf.org/mailman/listinfo/apps-discuss
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
