Simon Josefsson wrote:
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
0) Leave the library as it is; tools must use GnuTLS in the documented
way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
trust V1 certificates as certificate authorities.
This appears to be the Right Thing in general, and happens to also be
the simplest for me as GnuTLS maintainer, so it is what the upstream
GnuTLS package will use. Or rather, it is what upstream will continue
to use, nothing in the documentation or intended behaviour has changed
in the last few years here.
This seems like a reasonable approach for upstream. For etch I believe
it's too disruptive a change. For lenny... well I'm not sure. It may be
possible to patch all the relevant apps for the first point release but:
a) I don't know if this is an acceptable "fix" now that lenny is stable.
b) A number of systems will break on upgrade until the fixes get out.
c) This should probably be added to the release notes, is that still
possible?
1) same as 0, but we special-case the limited set of publically-known
V1 CA certificates shipped in the ca-certificates package: if any of
those exact certificates are included in the trusted certificates list,
they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
is not set.
Sounds pragmatic to me, although somewhat complex and I suspect we'll
see increasing requests to add to that list of exceptions. I won't
produce a patch for this, it seems somewhat messy.
Too messy to get into etch certainly. Probably too messy for lenny too.
2) same as 1, but rather than test exact matches against the specific
V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
if they meet the following requirements:
Sounds reasonable, but I'm suspicious that these special case rules
won't turn out to match the exact set of certs that we'd wish. It also
sounds less messy than 1) but still adding a big chunk of new code.
3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
This is essentially the (untested) patch I proposed earlier.
I have tested it. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=144;bug=514807
I've had no issues in my (limited) testing. I'm going to deploy it to a
more heavily used system and see if anything crops up.
Also: maybe we want to use one approach for etch, and a different one
for lenny. With a well-thought out transition strategy, we could
minimize some of the potential pain.
Yes, I am beginning to think that possibly 3) may be appropriate for
etch, although I'm not sure how large of a problem this actually is. If
it is not a large problem, maybe the answer should just be that they
need to renew their certificates with a better CA (or set up their own
CA).
I think my views for etch are clear. I should add that this is not
simply an issue with checking my own organization's certificates. Some
libgnutls-linked apps need to verify 3rd-party certificates which I (and
other Debian users) have no control over. I think mail.google.com was
mentioned as an example.
For lenny I'm far more flexible. So long as the issue gets resolved
(soon) I don't particularly mind how. Whether 0) or 3) or some
compromise is chosen will depend more on what changes are acceptable now
that lenny is stable.
PS i really don't like the monopolistic/money-grubbing/unethical
behavior of most of the dominant commercial CAs; i feel like their
general motives are at odds with my personal goals of having end-to-end
secure connections available for any netizen. So explicitly
grandfathering these groups into gnutls X.509 verification (option 1)
irks me not a little bit. However, newer CAs can (and do) use V3 root
certs, so i don't feel that we would be further entrenching the
800-pound gorillas.
I don't disagree with your views of the big players, however I think
this is a red herring. There does seem to be an ongoing transition away
from v1 certs but it appears to be rather a slow process. I don't think
GnuTLS is really in a position to strong-arm the big players into
hurrying things along.
--
Edward Allcutt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
