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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
