Yes, it would be counter-productive to increase scope arbitrarily. Let's just drop anything about the "why". The rathole that opens is scary deep.
I'm not looking for anything on validation either. What concerns me is that a) the implications of the override are not articulated; and b) this "pinning" or override function applies to certificates regardless of their RFC5280-determined validity; and c) your readership isn't being told any of this, most are working it out for themselves. Perhaps I can offer text for 3.6.3.1: A cached or "pinned" certificate need not be valid according to [PKIX]. A server that presents a pinned certificate is found to match based solely on its ability to prove that it possesses the private key that corresponds to the public key in the certificate. --Martin > -----Original Message----- > From: Peter Saint-Andre [mailto:[email protected]] > Sent: Thursday, 10 June 2010 12:44 PM > To: IETF cert-based identity > Cc: Thomson, Martin > Subject: user overrides (was: Re: [certid] Fwd: [apps-discuss] draft- > saintandre-tls-server-id-check and user overrides) > > 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/ > > _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
