[gnutls-devel] SSL certificate validation bugs in GnuTLS

[Daniel Kahn Gillmor]

On 02/13/2014 11:45 AM, Antoine Delignat-Lavaud wrote:

> 1. check all basic constraints and key usage flags properly

I think this should be split into two pieces: basic constraints and key
usage flags.

Do we have evidence that other TLS stacks are actually checking key
usage flags and acting on the results?  Nikos' concern that users or
devs will think "GnuTLS is broken for site X" is a legitimate concern,
unfortunately.

It looks like key usage violations used to be permitted only when
%COMPAT was specified in the priority string, and then commit id
16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be
tolerated by default.  Perhaps this behavior could be added back in a
way that could be controlled by a more specific priority string (i'm not
sure what the default would be).

In addition to knowing what other TLS libraries do, a survey of sites
that are willing to offer ECDHE or DHE key exchange mechanisms without a
digital signature key usage flag would be helpful in making an argument
about what the default should be.

I could produce this patch if people think that's a good approach.

> 2. (depends on 1) enforce critical extensions. According to our
> measurements, there are only two CA that have issued certificates with
> non-standard critical extensions in the past 2 years, for a total of 629
> certificates.

why does this depend on 1?  enforcing criticality of extensions seems
like it could be done independently.

> 3. enforce extended key usage
> 4. enforce name constraints

it would be great to clarify which particular name constraints are the
goal.  DNS does seem like the right direction to start from, clearly,
though it doesn't make as much sense when thinking about client-side certs.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140213/ea3a9538/attachment.sig>