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

On 15/08/13 16:19, Yoav Nir wrote:
> On Aug 15, 2013, at 12:08 PM, Trevor Perrin <trevp@trevp.net> wrote:
>
>> On Thu, Aug 15, 2013 at 1:30 AM, Gervase Markham <gerv@mozilla.org> wrote:
>>> On 15/08/13 09:20, Trevor Perrin wrote:
>>>> So you're expecting sites to edit their HPKP header on every cert
>>>> change?
>>> No; it's quite possible that the advice on renew would be "keep the same
>>> pins".
>> OK.  So you're expecting sites to request a new cert at least T days
>> prior to their existing cert expiring (where T is the length of time
>> needed for extant pins to expire).
> That would require either the sites to buy more certs than they need (and have overlapping certs) or the CAs to issue future certs (notBefore date T days in the future) and commit to the pinning data being valid for (validity_period + T). Not rocket science, but somewhat error prone.
>
> OTOH if the site administrator pins the EE public key, they don't need to involve the CA at all. They just need to generate the key pair (or the certificate request) T days in advance, and add the new pin to the HPKP header/resource.
>
> If someone were to ask me what a good pinning policy would be, I would say that they need three pins most of the time:
>  1. for the EE certificate
>  2. for the current root CA
>  3. for some other root CA (that you trust)
>
> If the EE certificate is compromised, you issue a new one from the current root CA, and update the pin.
> If the CA gets compromised, you issue a new cert from the backup root CA and update the pin (also with a new backup)
> T days before expiry, you generate a certreq, and add the new public key as a fourth pin until you change the certificate. 
>
> The pinning idea became cool because static pinning caught the Diginotar breach. A policy like this would detect fake certificates (as long as Diginotar was not your primary or backup CA).
>
> If CAs publish pin data on their website and guarantee that they will put any change on their website at least x days before the change takes place (90 days?) this kind of policy would work, but it would require administrators to check monthly both their primary and backup pins, otherwise the recovery plan above won't work.
Actually the CA could also use an email push service instead of or in
addition to the website publication.

> Yoav
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec