Subject: [wpkops] Some lessons of the Turktrust incident

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Jan 2013 17:00:06 -0500

Don't want to go too deep here, but issues uncovered in the TURKTRUST
incident demonstrate an urgent need for specifying the WebPKI.

Not every certificate that is a valid PKIX certificate is a valid WebPKI
certificate (and vice versa). In particular WebPKI allows for self signed
certs which are not PKIX certs and self signed certs typically lack
features that PKIX mandates like key usage, revocation distribution points
etc.

Self-signed certs are accepted in the WebPKI because they have a specific
purpose which is OK. But accepting a certificate chained to an embedded
trust anchor that lacks mandated PKIX features is not.

This particular incident appears to be the result of an administrative
error. But that error might have been caught if the offline/online
separation had included a requirement that an online certificate issuer
MUST NOT be capable of issuing CA certs and clients MUST be able to reject
CA certs issued by such an issuer.

This is something that is easily implemented using a path length constraint
but you have to know that there is a potential problem to avoid it.

Another feature of the generated certs is that they lacked CRL or OCSP
distribution points so the cert status could not be checked. This is not
permitted in WebPKI to an embedded trust anchor.

-- 
Website: http://hallambaker.com/

---

From: Leif Johansson <[email-masked]>
Date: Wed, 09 Jan 2013 08:40:18 +0100

> This is something that is easily implemented using a path length
> constraint but you have to know that there is a potential problem to
> avoid it.
>
Has anyone done interop testing in the wild for path length and name
constraints, eg
for commonly deployed TLS stacks and browsers?

            Cheers Leif

---

From: Yoav Nir <[email-masked]>
Date: Wed, 9 Jan 2013 07:49:25 +0000

I don't know about a wide study, but if you look at the PKIX mailing list archives around last May, there was a lively discussion with some anecdotal evidence.

Turns out quite a few browsers don't enforce name constraints. When present, they ignore it even if the Critical bit is set (which RFC 5280 says is a MUST). The trigger for that discussion was that iOS changed its behavior so that it started failing on critical name constraints.

Of course, it's been 8 months, so things may have changed.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Wednesday, January 09, 2013 9:40 AM
To: [email-masked]
Subject: Re: [wpkops] Some lessons of the Turktrust incident

> constraint but you have to know that there is a potential problem to 
Has anyone done interop testing in the wild for path length and name constraints, eg for commonly deployed TLS stacks and browsers?

            Cheers Leif
_______________________________________________
wpkops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/wpkops

Email secured by Check Point

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 9 Jan 2013 10:10:31 +0100

Major browsers seem to deal correctly with basicConstraints. iOS and MacOSX
don't handle NameConstraints, Mozilla used to apply them to SAN only.

For software stacks, OpenSSL handles BC well, I haven't checked about NC
but it should be OK.
GNUtls correctly handles BC since version 3.1.3, don't know if the patch
has been backported to 3.0 and 2.6; it can't handle NC at all. GNUtls is
widely used on Debian/Ubuntu.
Java needs some testing.
NSS is fine.

Lesser used stacks. PolarSSL doesn't check NC, and based on my readings of
the source code, BC support is incomplete. Don't know about other stacks.

---

From: Erwann ABALEA <[email-masked]>
Date: Wed, 9 Jan 2013 10:33:01 +0100

[Repost with my correct sender address]

2013/1/9 Leif Johansson <[email-masked]>

-- 
Erwann.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Jan 2013 07:02:31 -0500

My main concern is to detect anomalies. Blocking in the browser protects
one user. Detecting that there is a problem and reporting it protects
millions.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 09 Jan 2013 14:13:47 +0100

On 01/09/2013 10:10 AM, Erwann Abalea wrote:
>
> Major browsers seem to deal correctly with basicConstraints. iOS and
> MacOSX don't handle NameConstraints, Mozilla used to apply them to SAN
> only.
>
Your definition of "major" differ a bit from mine :-)
>
> For software stacks, OpenSSL handles BC well, I haven't checked about
> NC but it should be OK.
> GNUtls correctly handles BC since version 3.1.3, don't know if the
> patch has been backported to 3.0 and 2.6; it can't handle NC at all.
> GNUtls is widely used on Debian/Ubuntu.
> Java needs some testing.
> NSS is fine.
>

thx
>
> Lesser used stacks. PolarSSL doesn't check NC, and based on my
> readings of the source code, BC support is incomplete. Don't know
> about other stacks.
>
> Le 9 janv. 2013 08:40, "Leif Johansson" <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 09 Jan 2013 14:23:27 +0100

On 01/09/2013 01:02 PM, Phillip Hallam-Baker wrote:
> My main concern is to detect anomalies. Blocking in the browser
> protects one user. Detecting that there is a problem and reporting it
> protects millions.
So give the SSL observatory access to your customer db. Done.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Jan 2013 09:33:47 -0500

> So give the SSL observatory access to your customer db. Done.

That is not the roadblock, they already have far more certs than are
necessary to have a pretty good statistical idea of what is going on. The
problem is the lack of a definitive specification of normal.

Comodo is not necessarily adverse to release of the database. The question
would be reciprocity. If everyone does it then the release becomes a wash
as far as commercial advantage goes.

---

From: Sean Mullan <[email-masked]>
Date: Wed, 09 Jan 2013 11:45:24 -0500

On 01/09/2013 04:33 AM, Erwann ABALEA wrote:
> MacOSX don't handle NameConstraints, Mozilla used to apply them to SAN only.
>

Java supports both the Name Constraints extension and Basic Constraints 
extension path length constraints, in TLS, or in other usages. Let me 
know if you need more information.

--Sean

> NSS is fine.
>
> Lesser used stacks. PolarSSL doesn't check NC, and based on my readings
> of the source code, BC support is incomplete. Don't know about other stacks.
>
>
> 2013/1/9 Leif Johansson <[email-masked] <mailto:[email-masked]>>
>
>