On 02/18/2009 01:50 PM, Benoit Branciard wrote: > - maintain the ability to refuse v3 certs as AC if they do not have the > "AC=TRUE" attribute, as the current fix does;
I'm assuming you mean "CA" where you have "AC" here, right? This is an
abbreviation for "Certificate Authority"
> - but tolerate v1 certs as root ACs (which the current fix doesn't);
This seems to be the only proposed change in functionality; basically
you're suggesting that GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set by
default. This has the side effect that storing an out-of-band-verified
V1 peer (end-entity) certificate in the list of trusted certificates
would grant that end entity the ability to act as a CA.
> - refuse v1 certs as intermediate AC chains elements, since this appears
> to be the most dangerous threat: if an attacker gains access to an
> AC-validated v1 server cert, he could generate any AC-validated forged
> certs he wants using the robbed cert as an AC intermediate, and dupe
> many clients...
Agreed!
> - put somewhere in the doc (maybe a debconf popup ?) that trusting (and
> using) v1 server certs is dangerous because they could be hijacked for
> use as ACs.
I think this would be an abuse of debconf, particularly because the
warning would make more sense coming from the programs which are relying
on undocumented behavior of GnuTLS.
That is, programs which believe they are only storing trusted *CA*
certificates (and no peer certificates) in the list of trusted certs
should already be setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT in order to
indicate that preference to the library. If they expect users to store
end entity certificates in the trusted list as well, then it would be
wise to alert those users, but this is a group that gnutls (as a
library) would have a hard time targetting.
I'm still torn about how to resolve this, fwiw, because i understand the
arguments from both sides.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
