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

From: "websec issue tracker" <[email-masked]>
Date: Mon, 29 Jul 2013 15:09:52 -0000

#58: Should we pin only SPKI, or also names

 It has been suggested that instead or in addition to pinning to a has of
 the SPKI, we should also be able to pin to a certificate vendor. So in
 addition to the current pins, like

    Public-Key-Pins: max-age=2592000;
        pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
        pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="

 We will also be able to specify something like this:

    Public-Key-Pins: max-age=2592000;
        pin-name="comodo"

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-websec-key-
  [email-masked]    |  [email-masked]
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:
Component:  key-pinning  |    Version:
 Severity:  In WG Last   |   Keywords:  HPKP
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/58>
websec <http://tools.ietf.org/websec/>

---

From: "Jeremy Rowley" <[email-masked]>
Date: Mon, 29 Jul 2013 09:19:03 -0600

The primary reason for this suggestion is that some CAs switch which
intermediates and roots are used to issue certs on a periodic basis to help
minimize the impact of revocation and ensure small CRLs.  Pinning a single
intermediate to a domain may screw up certificates issued later on for the
domain.  Pinning a set CA will permit the CA to change intermediates/roots
when necessary without impacting the end user.  The effect is primarily
noticeable when intermediates are pinned over roots since a CA may limit its
issuance from a single intermediate to <500 cert whereas roots are rarely
rotated.

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
websec issue tracker
Sent: Monday, July 29, 2013 9:10 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [websec] #58: Should we pin only SPKI, or also names

-- 
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |      Owner:  draft-ietf-websec-key-
  [email-masked]    |  [email-masked]
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:
Component:  key-pinning  |    Version:
 Severity:  In WG Last   |   Keywords:  HPKP
  Call                   |
-------------------------+----------------------------------------------
-------------------------+---

_______________________________________________
websec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/websec

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 29 Jul 2013 12:13:18 -0400

The fact that an online intermediate has a 4-5 year expiry date is likely
deceptive. The intermediate has to have validity for all the issued life of
a cert so it will typically be 6-12 months + the longest expected certlife
+ margin.

Been a while since I looked at the system in that detail but my guess would
be that a cert will never be renewed off the same intermediate.

Tying the pins to the CAs seems like a much better approach to me. The
browsers have to understand the CAs as root cert entries in any case.

If we have a diginotar type situation again (FSM forefend), we want the
pins to a root to be broken at the same time the root is unloaded, yes?

The trust anchor data structures are outside the PKIX model but they
browser providers do need to track them regardless. I would rather tie pins
to the actual entity we want to pin to (the CA) rather than attempt pinning
to some sort of proxy.

There are CAs that are not represented in CABForum but CABForum is a place
where we can get a requirement of the form 'every CA must pick a DNS name
as a unique identifier for their service and report it to the browser
providers'. And that requirement will quickly become universal.

While we could choose a different string, Paul H.'s argument for using DNS
names in CAA was a good one and I can't see any advantage to inconsistency.
It also makes it much easier to make any scheme work with a private CA.

-- 
Website: http://hallambaker.com/