Florian Weimer <f...@deneb.enyo.de> writes: > * Simon Josefsson: > >> What are the possible channels to communicate to etch users that they >> will get (intentional) errors from gnutls if they have 1) a V1 >> certificate in their certificate chains, or 2) have a RSA-MD2/MD5 >> signature in non-trusted certificates in their chain? Perhaps a wiki >> page will help to explain the issue better than this bug report e-mail >> thread can do. > > 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: (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). 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. > Furthermore, arguments based on the age of those certificates and the > resulting deficiencies are not that convincing because most root > certificates share one or more of those flaws. The whole system is a > mess and has little to do with security (whatever it is). The lack of > accountability and transparency (who owns which root certificates?) > and the disregard for cryptographic best practices (on key sizes and > rollovers) is quite stunning. I completely agree. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org