Simon Josefsson wrote:
The CVE-2008-4989 problem was that parts of the chain validation
algorithm was not executed properly. Rejecting V1 CA's is one of those
parts, so I believe this is the intended consequence of the
CVE-2008-4989 fix.
I understood the primary problem to be that if the last (root) cert was
self-signed then its signature of the next-to-last cert would not be
checked. The other checks on the last cert would also not occur but
these were relatively minor.
This change actually brings gnutls in line with its documentation,
however it is still a change in behavior that I think is unsuitable for
a stable security update.
This is my main emphasis. Whatever happens with lenny, changing this
behavior in etch breaks existing setups.
This also affects the same set of packages in lenny. I suppose the
"right" way to solve it in lenny would be to patch all the libgnutls
users which assume v1 CAs should be trusted. However I'm not sure of the
reaction to filing several possibly RC bugs at this point.
This would leave users exposed to the security problems inherent with V1
CAs, which seems like a bad thing. The proper fix is for users to move
away from all V1 CAs.
What are the other significant problems with v1 CAs? Trusting a CA in a
list of certs which is provided with the understanding that they are to
be trusted doesn't seem a huge problem. (That being my interpretation of
the semantics of the configuration of nss_ldap etc.)
What can be done here is to produce better documentation, perhaps in
release notes. People must be aware that trusting X.509 certificate
chains containing RSA-MD5 signatures or V1 CAs is insecure.
I don't disagree, but breaking working configurations, not all of which
are as insecure as you fear, doesn't seem like the best plan, especially
since there was no advance warning.
--
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
