Re: [websec] #58: Should we pin only SPKI, or also names

[Trevor Perrin <[e-mail]>]

On Wed, Aug 14, 2013 at 4:44 PM, Gervase Markham <[e-mail]> wrote:
> On 14/08/13 18:20, Trevor Perrin wrote:
>> My point is that changes like CAs issuing new intermediates or
>> deprecating old roots MUST get incorporated into website pins somehow.
>
> Perhaps this is the point of disagreement.
>
> I would expect CAs to offer appropriate pinning advice with
> certificates, probably in the form of "paste this into your HPKP
> header". Once a cert is in use and pinned, no further changes to those
> pins need to be made.

So you're expecting sites to edit their HPKP header on every cert
change?  In that case I'd expect them to pin their end-entity key (see
reasons below).  I believe they'd have to edit the HPKP header twice:
 * Add their next end-entity key to the HPKP header
 * Wait for time T (where T is sufficient for all older pins to expire)
 * Switch to certificates with the new key
 * Once the switch is complete, delete the old key from the HPKP header

Sound right?


> No matter what happens to the CA's business, as
> long as the root and intermediate you are using are still valid (and,
> absent a CA breach, they will be - no CA sells certs which use roots and
> intermediates which expire before the cert finishes its lifetime), you
> don't have to worry. When you get a new cert (renewal), you'll get
> updated pinning advice.

In a strict sense I don't think this is true.  You're assuming every
end-entity cert "uses" a single root, which is constant for the
lifetime of the cert absent a CA breach.

But HPKP pins are checked against the browser-constructed cert path,
which might contain intermediates and roots different from what the
website sent, or thinks its "using".

Example:  You pin what you think is the root cert of your current
certificate.  3 months later the intermediate is upgraded to a root in
the browser's trust store, or becomes cross-certified by a different
root.  Your pin fails, as the browser no longer constructs paths that
use the pinned root.

See Ryan's explanation of AIA chasing for more on this [1].

While pinning the end-entity's immediate-parent intermediate doesn't
have this problem, I don't see that it has any advantage over pinning
the end-entity key directly.


> If you have pinned a backup provider, you will no doubt have sought
> similar pinning advice from them. There is more of a risk that this
> advice will need to change at a different time from you changing your
> cert, but that's OK, because you can change this stuff as much as you
> like and all you have to do is wait for caches to empty (30 days?).

Well, you *can* change your HPKP header as much as you like, but do
you want to?  If you pin several CAs, and find yourself having to edit
the HPKP header multiple times a year, isn't that kind of a hassle?

My point was not that it's impossible for websites to track CA key
lists, just that it would be more user-friendly if they didn't have
to.


Trevor


[1] http://www.ietf.org/mail-archive/web/websec/current/msg01425.html