Simon Josefsson wrote:
Florian Weimer <[email protected]> writes:
There doesn't seem to be industry consensus that X.509v1 root
certificates are a bad idea. This means that users have little
leverage against CAs and server operators when confronted with
problematic certificates.
Doesn't the same hold for RSA-MD5 signatures? I'm not sure industry
consensus is a good measure here. What we are relying on here is this
part of RFC 5280:
Considering that gnutls is aiming to interoperate with software and
certificates produced by this "industry" (including OpenSSL and yaSSL)
I'd say consensus is of the utmost importance. Despite what we may wish
about conformance with published standards, the de facto standards don't
exclude v1 certs or RSA-MD5, although the latter is certainly on the way
out.
(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
certificates.)
GnuTLS doesn't have any API to provide this out-of-band information, so
we simply reject version 1 certificates (unless a flag is set).
That seems like a good enough API to me. If the application is providing
a list of CA certs then it should set the flag. That is, however
unintentionally, an API change that shouldn't get pushed out silently as
a stable security update.
Hm. It is interesting that it says 'intermediate certificates' in the
last sentence. I think this is mistaken, the part of the algorithm
applies to root certificates as well as end-entity certificates too.
I think it is not mistaken. To me it looks precise: Intermediate
certificates MAY be rejected but out-of-band-verified root certificates
MAY NOT be.
I've tested the previously posted patch which adds
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT to verify_flags. This restores the
previous behavior of trusting v1 certs on the trusted list. I tested for
the versions in etch (1.4.4-3+etch3) and lenny (2.6.4-1). Both nss_ldap
and apache mod_ldap began working again with the patched libgnutls
installed.
Is there anything else I can do to get this regression fixed at least in
etch? I'd rather not maintain my own patched version of gnutls.
--
Edward Allcutt
Network Operations
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
