I don't know if there is any hope you may reconsider your decision of
not fixing this bug (from my point of view it make sense since it breaks
20% of the certification authorities and introduces a significative
change in application behaviour), but in case you do, here are my
suggestions:
- maintain the ability to refuse v3 certs as AC if they do not have the
"AC=TRUE" attribute, as the current fix does;
- but tolerate v1 certs as root ACs (which the current fix doesn't);
- 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...
- 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.
And let the API and clients change go for a further Debian release.
Regards,
Benoit Branciard
--
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
