Simon Josefsson wrote:
Simon Josefsson <si...@josefsson.org> writes:
The reason gnutls-cli doesn't complain is because it contains this code:
/* there are some CAs that have a v1 certificate *%&@#*%&
*/
gnutls_certificate_set_verify_flags (xcred,
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
I don't recommend doing the same in other applications, and we should
probably remove it from gnutls-cli too. It may be useful to create a
parameter in other tools to enable the flag on a per-case basis, though.
FWIW, I've worked on this in the gnutls 2.7.x branch. gnutls-cli no
longer accepts V1 CAs by default, and there is a new --priority token
%VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it. The
priority string approach is what we recommend applications expose to
their users for configuring GnuTLS internal details.
That's all very well, but it's a rather big change in functionality for
stable. I doubt it would be acceptable to patch all the relevant apps
which assume that their list of trusted CAs will actually be used as such.
I can see the same change has been made in libgnutls26 in lenny. Should
I file several RC bugs against the various modules affected? Bear in
mind that their documented semantics are "a list of trusted CAs" so I
think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be entirely appropriate
in those cases.
Are there any apps which provide a list of trusted certs which should
not all be considered trusted CAs? If not then perhaps
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default.
--
Edward Allcutt
Network Operations
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
