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

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

On 6/9/10 8:24 PM, Peter Saint-Andre wrote:
> 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.

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/