[cabfpub] Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28 June 2012

Chris Palmer palmer at google.com
Wed Jul 11 00:23:13 UTC 2012


"""Gerv said that CNNIC has applied to have its root included.  He
said that it is already included in Windows and Opera.  Rick asked
whether it would make sense to (for instance) remove Chinese CAs from
the list of CAs trusted by default by US users.  Gerv said that the
idea of localized trust-stores has been consider.  But, problems
exist.  He thought that CA-pinning would provide a better solution.
Jens mentioned problems with pinning, such as the "initial trust"
problem, key roll-over and multiple certificates per domain.  Gerv
said that "large-scale surveillance" helps with the initial trust
problem."""

1. I continue to be baffled as to why people keep bringing up this
initial trust problem in pinning, as if we don't already suffer a far
worse form of it without pinning.

The current system is vulnerable to the initial trust problem *on
every TLS session negotiation*. Each time you connect to a server, the
server's identity could be verified by *any* CA, whether intended by
the true site operator or not.

Recall that, in my draft, pin assertions are invalid unless received
over a validly-authenticated TLS connection, and that at least one of
the asserted pins is for the same key as used to make the current,
valid connection. Thus pinning is strictly better than the status quo,
as regards the initial trust problem.

2. Key roll-over: In my draft, you can pin as many keys as you want,
and clients will accept any of them when performing pin validation.
(In fact, you currently *have to* assert a "back-up" pin, but I am
probably going to remove that requirement.)

3. Multiple certificates per domain: We pin keys, not certificates.
But yes, go ahead and pin as many keys as you want per domain. This
is, in a sense, same thing as key roll-over.

For reference, here is my current I-D:

http://tools.ietf.org/html/draft-ietf-websec-key-pinning-02

Finally, CNNIC: At least one CNNIC certificate is already a validate
subordinate issuer in Mozilla (chains up to a trusted root), so adding
them as a root does not actually expose Mozilla users to any *new*
risk from that organization. See
https://www.eff.org/files/DefconSSLiverse.pdf. If anything, making
CNNIC a known public root increases their visibility and allows the
world to at least begin the process of evaluating their
trustworthiness. That can only be a good thing. People should be
worried about the "dark matter" of unknown-but-publicly-trusted
intermediate CAs, rather than one particular CA that is actually
choosing to make themselves visible.



More information about the Public mailing list