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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 20:24:03 -0600

Forwarding from the [email-masked] 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-masked]>
To: [email-masked] <[email-masked]>,	[email-masked]
<[email-masked]>,	[email-masked] <[email-masked]>

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-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 20:43:55 -0600

> 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.

> certificate validation failure and what aren't.  Common reasons that are

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.

> 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/

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 10 Jun 2010 13:45:08 +0800

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-masked]]
> 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)
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Jun 2010 15:12:05 -0600

> Let's just drop anything about the "why".  The rathole that opens is

/me pulls back from the edge of the abyss...

> 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; 

That sounds too broad. I don't think we want to let a "pinned"
certificate off the hook regarding all aspects of PKIX-validity. All
we're saying is that the user has explicitly approved this certificate
as acceptable for this application server, despite an identity mismatch.

> and c) your
> readership isn't being told any of this, most are working it out for
> themselves.

Yes, and that's not good, so we need to clarify things.

> 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.

Again, I think that's probably too lenient.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 15 Jun 2010 07:41:04 +0800

> > What concerns me

I might be convinced that you are limiting scope to "server identity" and so you want to enumerate the faults that "pinning" can be used for.  

If you do so, you run the risk of becoming irrelevant.  I can pin a cert in my browser for a number of reasons.   Why is an identity mismatch any more forgivable than an unknown CA?

> Again, I think that's probably too lenient.

Yes, very.  But the alternative (enumeration) seems both hard and counterproductive.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 15 Jun 2010 07:51:57 +0200

Thomson, Martin wrote:
> Why is an identity mismatch any more forgivable than an unknown CA?

The user might have knowledge about DNS aliases but not about the public key
of the unknown CA.

Not sure whether that should all be part of this BCP document though...

Ciao, Michael.