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. On Mon, Jul 29, 2013 at 11:19 AM, Jeremy Rowley <[email protected]>wrote: > 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 protected] [mailto:[email protected]] On Behalf > Of > websec issue tracker > Sent: Monday, July 29, 2013 9:10 AM > To: [email protected]; [email protected] > Cc: [email protected] > Subject: [websec] #58: Should we pin only SPKI, or also names > > #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 protected] | [email protected] > 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/> > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
