On 6/9/10 8:24 PM, Peter Saint-Andre wrote: > 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.
I'm not sure if this is the spec in which to describe why a user might need or want to override the default server identity checking behavior. One example of a spec that provides some guidance in this area is http://www.w3.org/TR/2010/WD-wsc-ui-20100309/ but that doesn't cover non-browser or non-web applications, and in any case this is a matter of providing guidance to client developers regarding user interaction, which is not exactly a matter of expertise in the IETF. However, I'm open to accepting suggested text on this point. > 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 So far, with regard to client behavior this spec has been limited to the narrow topic of checking server identity, not the broader topic of certificate validation. > 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. Again, those are interesting and important issues, but somewhat outside the very limited scope that we have set for ourselves. As with other requests for broadening the scope of this spec, I'd like to point out that we might very well write more specs on related topics in the future, and perhaps eventually put them all together into a more general BCP. However, given how contentious these issues can be, I think we'd prefer to do this work in a piecemeal fashion to start with instead of defining a grand unified theory from the beginning (because it's unlikely that we would ever finish that task). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
