[gnutls-devel] SSL certificate validation bugs in GnuTLS

[Daniel Kahn Gillmor]

On 02/13/2014 02:20 PM, Nikos Mavrogiannopoulos wrote:
> On 02/13/2014 06:19 PM, Daniel Kahn Gillmor wrote:
> 
>> 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.
> 
> Maybe we can add back the check for 3.3.x when %COMPAT is not specified?

is there a reason to only lump this in with %COMPAT and not have it be a
distinct %PERMISSIVE_KEY_USAGE flag? %COMPAT could imply
%PERMISSIVE_KEY_USAGE.

It occurs to me: is there a way to *unset* a priority string flag?  I'm
thinking about a scenario where an administrator anticipates a change in
the defaults for some setting, and wants to ensure that their preferred
configuration setting works and is stable using the same priority string
across versions.  (another way to look at this is: how can someone write
a HOWTO for a particular use case that has a single priority string that
will work regardless of what the defaults are of the particular version
the reader has deployed)

	--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/d1bbdc84/attachment-0001.sig>