ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

[Adam Williamson]

On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> > Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> > popular sites because of that change. It should not be assumed that the
> > users of ca-certificates are only programs using nss.
> 
> [1] is an interesting read. I get the impression that certificates are
> being removed as long as there is a compatible replacement that NSS can
> validate, based on NSS's custom strategies for certificate validation.
> Is this claim accurate?

"Custom strategies" is an interesting concept. AFAICS, the TLS standard:

http://tools.ietf.org/html/rfc5246

does not exactly define 'standard' certificate verification strategies,
so in a sense, they're *all* "custom". In other words, we're in good old
Standard Ambiguity Land here. What that doc has to say about chains,
AFAICS, is:

7.4.2.  Server Certificate
...
certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

Note: this doesn't say anything about how the client should *validate*
the server's certificate list. It defines properties of the list, but
not its interpretation by the client.

7.4.5.  Server Hello Done
...
      Upon receipt of the ServerHelloDone message, the client SHOULD
      verify that the server provided a valid certificate, if required,
      and check that the server hello parameters are acceptable.

Again, this doesn't specify precisely how the client should interpret
the requirement for "a valid certificate".

F.1.1.  Authentication and Key Exchange
...
If the server is authenticated,
   its certificate message must provide a valid certificate chain
   leading to an acceptable certificate authority.  Similarly,
   authenticated clients must supply an acceptable certificate to the
   server.  Each party is responsible for verifying that the other's
   certificate is valid and has not expired or been revoked.

Note: this doesn't define exactly *how* the client should verify that
the server provides "a valid certificate chain leading to an acceptable
certificate authority". It doesn't seem to me that the NSS
implementation falls outside of this requirement, for instance.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net