On 2009-02-24 Florian Weimer f...@deneb.enyo.de wrote:
* Simon Josefsson:
Florian Weimer f...@deneb.enyo.de writes:
Simon, could we make the harmless variant (X.509v1 certificate set as
trusted is accepted as a root CA, but intermediate X.509v1
certificates aren't accepted) the default in
* Andreas Metzler:
I have been watching this play out since other people participating in
this thread are more knowledgable than me. From what I have read I
also think this might the right thing to do. Do you intend to push
this through security or proposed updates?
I've uploaded changed
* Simon Josefsson:
Florian Weimer f...@deneb.enyo.de writes:
Simon, could we make the harmless variant (X.509v1 certificate set as
trusted is accepted as a root CA, but intermediate X.509v1
certificates aren't accepted) the default in etch?
It may be that the practical problems are more
Florian Weimer f...@deneb.enyo.de writes:
* Simon Josefsson:
Florian Weimer f...@deneb.enyo.de writes:
Simon, could we make the harmless variant (X.509v1 certificate set as
trusted is accepted as a root CA, but intermediate X.509v1
certificates aren't accepted) the default in etch?
It
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:
-
On 02/18/2009 01:50 PM, Benoit Branciard wrote:
- maintain the ability to refuse v3 certs as AC if they do not have the
AC=TRUE attribute, as the current fix does;
I'm assuming you mean CA where you have AC here, right? This is an
abbreviation for Certificate Authority
- but tolerate v1
Simon Josefsson wrote:
Florian Weimer f...@deneb.enyo.de 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
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
GTE CyberTrust Global Root, which we happen to use widely in our
institution, also is a version *1* x509 certificate.
So the libgnutls13 update broke several of our apps.
A quick search among the files in ca-certificates package shows up to
20 version-1 certificates over a total of 102.
* 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
Florian Weimer f...@deneb.enyo.de writes:
* Simon Josefsson:
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 think it is somewhat
Daniel Kahn Gillmor d...@fifthhorseman.net writes:
One option, of course, is to change the interface of GnuTLS to cleanly
separate out trusted peer certificates from trusted CA certificates in
the API. This would permit users to specify how they intend to use a
given V1 cert. Of course,
Edward Allcutt emall...@gleim.com writes:
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
Florian Weimer f...@deneb.enyo.de writes:
Simon, could we make the harmless variant (X.509v1 certificate set as
trusted is accepted as a root CA, but intermediate X.509v1
certificates aren't accepted) the default in etch?
It is possible to allow V1 certs to be used as roots when validating
* Simon Josefsson:
and the DN doesn't really matter, either.
The SubjectDN of the CA needs to match the IssuerDN of the next cert in
the chain.
I meant it in the sense that no root certificates are revoked after
the DN has become invalid because the denoted legal entity has ceased
to exist,
Florian Weimer wrote:
* Edward Allcutt:
I believe this is a significant regression in stable because at least
one widely used CA (godaddy) still issues certificates with a chain
ending in a v1 root (ValiCert Class 2).
Are we talking about this certificate?
Subject: L=ValiCert
Dear team,
The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at
least in my opinion) this also subtly changed the semantics of trusted
certificate lists. Version 1 X509 certificates in the list are no longer
trusted as CAs unless an extra flag is set.
Several users of
Edward Allcutt emall...@gleim.com writes:
Dear team,
The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at
least in my opinion) this also subtly changed the semantics of trusted
certificate lists. Version 1 X509 certificates in the list are no longer
trusted as CAs
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
* Edward Allcutt:
I believe this is a significant regression in stable because at least
one widely used CA (godaddy) still issues certificates with a chain
ending in a v1 root (ValiCert Class 2).
Are we talking about this certificate?
Certificate:
Data:
Version: 1 (0x0)
* Simon Josefsson:
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 think it is somewhat debatable if this also applies to the root CA
On 02/11/2009 06:05 PM, Florian Weimer wrote:
I think it is somewhat debatable if this also applies to the root CA
container, where the X.509 structure is just use as a transport for
key material. The RSA-MD5 signature does not hurt there, and the DN
doesn't really matter, either. The risk I
22 matches
Mail list logo
