[gnutls-devel] SSL certificate validation bugs in GnuTLS

[Nikos Mavrogiannopoulos]

On 02/13/2014 08:41 PM, Daniel Kahn Gillmor wrote:
> 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 could be. In master I use a hash table so adding more flags wouldn't
hurt.

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

That could be done if we add individual priority string flags for all
work arounds. Unsetting flags is not supported though, and I don't know
if that additional complexity is needed.

regards,
Nikos


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