Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

["Ryan Sleevi" <[e-mail]>]

On Wed, October 17, 2012 7:23 am, Tom Ritter wrote:
>  Section 2.4: "Validating Pinned Connections":
>
>     For the purposes of Pin Validation, the UA MUST ignore
>     certificates who SPKI cannot be taken in isolation and superfluous
>     certificates in the chain that do not form part of the validating
>     chain.
>
>  I know I just modified this, but the second phrase just hit me.
>  Because path construction is non-standard, could a client wind up in a
>  situation where the site pinned to CA_Alice, with the intended path
>  CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was
>  trusted, the ultimate validating chain was simply CA_Bob ->
>  Intermediate -> Leaf?  I'm not sure what the right way to counteract
>  that would be...

Yes. This is one of the troubling areas of the current draft, and that has
been particularly challenging when implementing within Chromium.

It's not clear whether your case was demonstrative of the
inter-organizational cross-signing relationships (a new CA getting
cross-certified by an existing, established CA) or whether it was an
intra-organizational relationship, such as a SHA-1 root cross-signing the
SHA-2 root, until such a time as the SHA-2 root is included in the trust
stores.

In the case of inter-organizational, where CA_Alice and CA_Bob are two
distinct entities, it's generally seen as unlikely that the "site" would
pin to CA_Alice, since their business relationship is almost certainly
with CA_Bob (by virtue of CA_Bob having certified Intermediate). So if the
site were to pin to CA_Bob, their issue would be mitigated.

However, for the intra-organizational scenario, where intermediates and
roots are changed or re-issued more commonly than site operators may
realized or be re-configuring, I agree that this is a very real problem.

The mitigation for this has been to make the pins an appropriate
cross-section of both root and intermediates - intermediates in the event
of new roots being issued, and roots in the event of the CA issuing new
intermediates (and serving them up via AIA, as the common case is)

This leaves the broader question of "How does the site operator know about
CA_Alice and CA_Bob to begin with". One possible solution for this is a
report-but-unenforced mode, where user agents could describe their
observed chains to the site. As unseemly as this is, it's very likely that
many site operators - even Very Large, High Value sites - may not have a
full understanding of the PKI that they're a participant in.

Another solution is to rely on policy changes in root stores, such as
Mozilla's recent proposed CA Certificate Store requirements change, which
would encourage (by requiring, with only one acceptable alternative) the
public disclosure of such CA hierarchies. As a result of such changes,
there would be knowledge of the relationship between CA_Alice and CA_Bob,
which under today's model, is actually quite hard for site operators to
discover.

Because pinning permits multiple entries, and is considered satisfied so
long as at least one SPKI appears in the client validated chain, the issue
here is largely not a technical challenge, but an operational one, and
that's why this issue is not critical, but remains very important.