[No idea if these will show up on the lists since I'm not subscribed]
On Fri, Sep 11, 2015 at 9:30 PM, Martin Thomson <
m...@mozilla.com> wrote:
> I have some questions, to which I was unable to find answers for in
> the (numerous and long) threads on this subject.
>
> 1. When we download and install a client cert, what checking do we do?
> Do we insist upon it meeting the same algorithm requirements we have
> for servers with respect to use of things like short RSA keys and weak
> hashes (MD5/SHA-1)?
>
No. These are client certs (generally for internal systems), for which
there are no imposed policies on (CA/B Forum or otherwise).
The only checking re: algorithms are those which NSS itself has not
disabled globally (MD5, minimum keysizes, etc), but only if they present as
parse errors - not as signature validation errors.
If it comes in as application/x-x509-user-cert (vs, say,
application/x-x509-ca-cert, which can be used to quickly add a root
certificate),
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#849
is what first parses/interprets the byte stream.
The validation requires:
1) That the user has an existing private key (from any source, <keygen> or
otherwise - so you can use this as an existence proof of whether or not a
user has a matching key). That's line 886
2) That it's syntactically valid for one of the forms Mozilla accepts - or
one of the ones it can munge into something it accepts (a liberal decoder)
- that's line 875
If so, it'll toast the user (via
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#810
) to let them know a certificate was installed (after the fact)
It'll then parse the rest of the bundle, and if they are certificates that
chain to a CA the user trusts, they'll also be imported (that's line 924)
This behaviour, however, is different than Chrome's in several ways
(primarily related to the parsing of the bundle and handling the additional
certificates). Chrome also explored a number of strict checks (is it a
valid client certificate from a known CA), but those had to be relaxed for
compatability with Firefox and the existing use cases.
We also explored not committing the generated key to the persistent
keystore until it'd been "confirmed" (via installation of a certificate),
except that broke nearly every <keygen> use case outside of WebID. In
particular, if you closed Chrome, we'd destroy the key - so that didn't
work for situations where you'd do a <keygen> enrollment, close Chrome, a
day later getting an email with a link from your CA w/ the certificate. So
you'd need some form of semi-persistent, origin-scoped storage if you went
that way.
>
> 2. What is the potential scope of use for a client certificate?
> Global? The origin that provided it? Something in-between like
> domain or domain plus subdomains?
>
Global - all domains, all applications. A common pattern, as seen on the
CA/Browser Forum list, is to use this method to configure S/MIME
certificates for Thunderbird, which uses the same NSS database.
Any other domain could do an existence test to see if a user has such a
certificate, by using <keygen> to create a key (which may or may not
involve prompting; various criteria there), using
application/x-x509-user-cert to deliver the user's cert that matches a
chosen ("attacker") issuer string, and then doing a TLS handshake that
requests a client certificate with the ca_names set to the attacker's
unique fingerprint.
The timing difference between the handshakes - whether or not the user has
a matching certificate and private key - can reveal to any domain who knows
the ca_names whether or not the user matches, at the cost of potentially
prompting the user (if they do match).