Subject: [websec] Certificate Pinning via HSTS

From: Chris Palmer <[email-masked]>
Date: Mon, 12 Sep 2011 14:56:56 -0700

Hi all,

Chris Evans and I work at Google on the Chrome security team. We have
devised this specification for a new extension to Strict Transport
Security to allow site operators to "pin" certificates: UAs will
require that TLS connections be validated with at least one of the
public keys identified in the new "pins" directive in the HSTS header.
(Sites can pin to one or more public keys in end entity, subordinate
CA, and/or root CA certificates, for flexibility and disaster
recovery.)

We hope that this mechanism opens up the benefits of certificate
pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior
and certificate pins for sites, but the mechanism for doing this
(email us!) does not scale.

We eagerly anticipate your comments, questions, concerns, et c. As you
can see from the Ideas section, there are some unanswered questions
about the behavior of UAs and hosts, and possible extensions to the
policy.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 20:54:13 -0400

Hey Chris & Chris,

This seems like a useful near-term approach, but also probably something that might want to migrate to DANE over time.

Is there any particular reason you're using key fingerprints instead of cert fingerprints?  It seems like the latter might be slightly easier to implement, since you don't have to parse the cert.

--Richard

On Sep 12, 2011, at 5:56 PM, Chris Palmer wrote:

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

---

From: SM <[email-masked]>
Date: Mon, 12 Sep 2011 17:51:17 -0700

Hi Chris,
>devised this specification for a new extension to Strict Transport

[snip]

>We eagerly anticipate your comments, questions, concerns, et c. As you

Would it be possible for you to post the specification as an Internet-Draft?

Thanks,
-sm

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 Sep 2011 21:05:49 -0500

> about the behavior of UAs and hosts, and possible extensions to the

I see it used commonly in the context of SSH, but what's the definition 
of a "key fingerprint" for x509?

Would it be something like KeyID from here: ?
http://tools.ietf.org/html/draft-ietf-pkix-certid-keyid

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Sep 2011 08:53:29 +0300

> Is there any particular reason you're using key fingerprints instead of cert fingerprints?  It seems like the latter might be slightly easier to implement, since you don't have to parse the cert.

I can think of two reasons. 

1. Sometimes certificates are renewed periodically with the same public key. This is very common for sub-CAs and less so for EE certificates, but unless it has been compromised, or NIST recommends that you double your bit-length again, there's no reason not to use the same old public key and the new certificate

2. The spec talks about having a backup key pair kept offline. Although the spec says that you should have that key pair signed by a different CA, you can save money by not having it signed unless your "live" certificate has been lost or otherwise compromised. With the full automation you get with today's CAs, you can get a DV certificate in a matter of minutes. EV certificates take longer, but if you're the kind of organization that buys EV certificates, you might want a backup plan that includes a signed certificate.

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Sep 2011 04:59:12 -0400

> I can think of two reasons.

You're basically right. Quoting from my
http://www.imperialviolet.org/2011/05/04/pinning.html

"In general, hashing certificates is the obvious solution, but the
wrong one. The problem is that CA certificates are often reissued:
there are multiple certificates with the same public key, subject name
etc but different extensions or expiry dates. Browsers build
certificates chains from a pool of certificates, bottom up, and an
alternative version of a certificate might be substituted for the one
that you expect.

For example, StartSSL has two root certificates: one signed with SHA1
and the other with SHA256. If you wished to pin to StartSSL as your
CA, which certificate hash would you use? You would have to use both,
but how would you know about the other root if I hadn't just told you?

Conversely, public key hashes must be correct:

Browsers assume that the leaf certificate is fixed: it's always the
starting point of the chain. The leaf certificate contains a signature
which must be a valid signature, from its parent, for that
certificate. That implies that the public key of the parent is fixed
by the leaf certificate. So, inductively, the chain of public keys is
fixed, modulo truncation.

The only sharp edge is that you mustn't pin to a cross-certifying
root. For example, GoDaddy's root is signed by Valicert so that older
clients, which don't recognise GoDaddy as a root, still trust those
certificates. However, you wouldn't want to pin to Valicert because
newer clients will stop their chain at GoDaddy."

Public key hashes are hashes of the SubjectPublicKeyInfo, which should
be nailed down in any spec.

There is the possibility of a cert getting reissued with a difference
SPKI, but the same effective public key. (i.e. omitting a NULL
AlgorithmIdentifier.Parameters). However, I'm not aware of any
instances of this actually happening.

Cheers

AGL

---

From: James Nicoll <[email-masked]>
Date: Tue, 13 Sep 2011 10:41:54 +0000

I was under the impression that this wasn't a good idea, as periodic
replacement of the keys was done incase of an undetected compromise?

Ross

On 13/09/2011 06:53, "Yoav Nir" <[email-masked]> wrote:

>1. Sometimes certificates are renewed periodically with the same public
>key. This is very common for sub-CAs and less so for EE certificates, but
>unless it has been compromised, or NIST recommends that you double your
>bit-length again, there's no reason not to use the same old public key
>and the new certificate

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Sep 2011 07:13:16 -0400

> replacement of the keys was done incase of an undetected compromise?

One typically pins, at least, to a CA which allows a site to rotate
its keys without issue so long as they use the same CA.

Cheers

AGL

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 13 Sep 2011 12:26:48 +0100

Hi Chris and Chris,

<speaking as individual>
I like the idea, too. And would very much second the thought of putting 
this down in the form of an Internet-Draft. Especially with the CA 
problems we have seen in the last few months, this is important and 
could be a great addition to HSTS in the websec WG.

<speaking as chair>
If you consider putting this in as an Internet-Draft and need any help 
in doing so, please feel free to drop a note to the mailing-list, or you 
can also always ask me, Alexey or Yoav (WG chairs and secretary) for 
advice/help on how to put this in I-D form the easiest way. Will always 
be happy to make things easy and smooth for authors and editors.

Kind regards, Tobias

On 13/09/11 01:51, SM wrote:
> _______________________________________________
> websec mailing list
> [email-masked]

---

From: Tom Ritter <[email-masked]>
Date: Tue, 13 Sep 2011 08:10:39 -0400

I echo Marsh's question.  Does a x509 Key Fingerprint include
basicConstraints?  I couldn't imagine a scenario where an attacker could get
his own cert signed by a leaf cert of a website - but I also couldn't
imagine New York getting hit by an earthquake ;)

Other observations:

I find the Revocation section very confusingly written.

> "In the event of a mismatch, clients must check whatever revocation
mechanism is available and attempt to discover whether the certificate with
the mismatching fingerprint has been revoked."

What is the definition of mismatch?  I interpreted it as no cert in the
chain contains a fingerprint which matches one of the fingerprints in the
pin list (supplied via prior pinned directive, or preloaded list).
Therefore all certificates in the chain supplied by the site are
mismatching.  But seeing if they are revoked is useless, I want to check the
pinned list to see if any in the pin list is revoked, so I can reevaluate
the pinned list and possibly downgrade the site to 'Known HSTS Host'.  But
the pin list only contains fingerprints - how do I check if a cert is
revoked by fingerprint?

The "Interactions With Built-in HSTS Lists" section is does not cover UA
updates.  Should a UA update with new pin information overwrite pin
information previously validly supplied by a site?

Finally, I'm of the opinion that all SSL Certificate information should be
exposed as javascript properties by browser.  That's a bit out of scope, so
I'll dial it back and say while we're working on HSTS, HSTS information
should be exposed as a read-only javascript property.  It doesn't need to be
structured, the entire contents of the header is sufficient, similar to
document.cookie.  This would allow at least two more (optional) defensive
practices:

1) Plugin/Extension/Greasemonkey authors could produce something like
HTTPSEverywhere or NoScript that could preload pins in a method similar to
preloaded pins in a UA.  If a site sent a pin list that didn't match the
preloaded pin list, the extension could show a warning, error, or some
alert.  Although similar to preloaded pins, this would not require a UA to
do work, nor would it require a UA to supply a user interface to bulk-load
pins.

2) Site authors could include checks in javascript to check their pinned
list.  While this *is* an arms race, and any javascript that is already
being middled by an attacker *could* be rewritten - in practice, javascript
can be sufficently obfuscated to raise the barrier to exploitation (see
gmail's javascript for example).

-tom

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 13 Sep 2011 08:45:10 -0400

Thanks for publishing this spec, Chrises!

> CA, and/or root CA certificates, for flexibility and disaster

I think more discussion about the relative consequences of pinning EE
vs. intermediate CA vs. root CA certs would be useful.

From my perspective, i see no advantage to pinning any of the CAs -- if
your EE is compromised, you're sunk.  And since the mechanism provides a
mechanism (and nice instructions, thanks) for transition to an emergency
offline backup EE key+cert, that is all handled well.

What advantage would a site gain from pinning to an intermediate or root
CA?  It seems that all this would do is expose the site operators to
(limited, thankfully) extortion from the CA in question.

The only situation where i can see it being useful is to ease deployment
in a situation where the operating organization operates their own CA.
If this is the only circumstance where it is advisable to pin a CA cert
instead of an EE cert, that should probably be added to the
documentation explicitly.

Or is there some other circumstance that it would be actually useful
that  i'm missing?

	--dkg

---

From: Philip Gladstone <[email-masked]>
Date: Tue, 13 Sep 2011 10:04:30 -0400

On 9/13/2011 8:10 AM, Tom Ritter wrote:
> mechanism is available and attempt to discover whether the certificate
> with the mismatching fingerprint has been revoked."
>
> What is the definition of mismatch?  I interpreted it as no cert in
> the chain contains a fingerprint which matches one of the fingerprints
> in the pin list (supplied via prior pinned directive, or preloaded
> list).  Therefore all certificates in the chain supplied by the site
> are mismatching.  But seeing if they are revoked is useless, I want to
> check the pinned list to see if any in the pin list is revoked, so I
> can reevaluate the pinned list and possibly downgrade the site to
> 'Known HSTS Host'.  But the pin list only contains fingerprints - how
> do I check if a cert is revoked by fingerprint?
>
>
I don't understand this either. I thought that if a subsequent HTTPS 
connection was established and none of the certificates in the chain 
matched any of the fingerprints, then the connection was closed (with no 
way for the user to override this).

Is it the case that the model is for the UA to store the actual 
certificates associated with each fingerprint? This is the only way that 
I can see for the UA to determine which certificates have been revoked.

Does this proposal also support self-signed certificates? I.e. if you 
connect to a site, accept the self-signed certificate, can that site 
then pin itself using that self-signed cert? I.e. can the validation of 
the cert chain stop as soon as there is a pin match?

Philip

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 11:11:54 -0700

Hi everybody,

Thanks for your comments and questions — good ones! I'll try to
address them in the XMLified draft that I'm working on now, and which
I'll send out today.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 17:40:23 -0400

I think we have a potential convergence here between four sets of security
policy data and four delivery mechanisms:

A) Revocation information for certs/roots
B) Security protocol policy 'MUST USE TLS'
C) Security Trust Policy 'use only this CA'
D) Reporting

1) Data baked into the browser
2) Data pushed out to the browser in a signed format out of band
3) Data acquired by the browser from HTTP headers
4) Data acquired by the browser via DNS/DNSSEC

The first clearly does not scale but has huge leverage since ten domains
represent the biggest targets on the net for certain typs of criminal
behavior.

The second does not scale either but provides us with a vital tool to use
when responding to an actual in-progress attack.

The third scales but only gives secure after first contact. It is difficult
to see how far hardfail will be practical.

The fourth scales but is dependent on deployment of infrastructure and
access to that infrastructure which means that it is going to be some time
before clients can hardfail if the data is not available.

Having the three mechanisms using a common data format allows for an agile
approach to response.

For example let us imagine that paymentgate.com is attacked and a bogus cert
is issued.

paymentgate.com has decided that it is a likely target for attack and has
implemented and published a security policy through DNS records and
published it with DNSSEC.

paymentgate.com is not however sufficiently prominent to be amongst 10 or so
security policies that are baked into browsers.

A client that has _reliable_ access to DNSSEC data will detect the bogus
cert and reject it. But that is only going to be effective if the browser
can hardfail if the DNSSEC data is not present. If Iran is performing a
network level MITM attack you can be certain that they will strip all DNSSEC
data the minute that any deployed clients start relying on it.

So perversely DNSSEC only provides direct security for the people who are
not likely being attacked. :-(

We can however get some DNSSEC data through using other channels and so it
is quite reasonable to expect that we can get a notification that the attack
is in in progress by those clients reading the security policy data in the
DNS and then making use of whatever reporting infrastructure we build into
those clients.

However we have the option of using the Langley/Kaminsky hack of pickling a
chain of DNS data and putting it into another signed object. For example a
certificate or an OCSP token.

So when a report is received, the browser provider looks at the taget(s) of
the attack and can attempt to retrieve security policy from the DNS. If
there is a published policy they can decide to add paymentgate.com to the
list of data driven security policy they push out.

So in summary, I would like to address all four delivery mechanisms as if
they are merely different delivery mechanisms for the same data types.

Despite that, I would like all three mechanisms to employ the

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

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 14:55:32 -0700

> offline backup EE key+cert, that is all handled well.

In the case of normal EE certificate expiration — as opposed to
compromise — if you are pinned to (say) an intermediary signer, you
can just get a fresh certificate from the same signer, deploy it, and
change nothing else.

Conversely, if you had pinned to an EE, you'd need to follow a
procedure something like this near expiration time:

0. Generate the new cert.
1. Change your pins directive to include the new and the old public
key fingerprints.
2. Wait long enough for "most, surely?" of your users to have received
the new pins, or for their pins to expire by the normal maxAge means.
3. Decommission the old EE cert and deploy the new.

Maybe that sounds reasonably easy to you, and you just never want to
pin to a signer's public key. That's ok. Our goal with the "you can
pin to any public key(s) in your cert chain" idea was to maximize
flexibility and enable a range of policies and practices, knowing that
one size does not fit all but that all achieve the goal.

You could, of course, also just re-use your old key pair and get it
re-signed, and no need to migrate keys as well as certs. In that case,
no problem. Again, that's fine and one size does not fit all.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 15:02:16 -0700

On Tue, Sep 13, 2011 at 7:04 AM, Philip Gladstone <[email-masked]> wrote:

[ snip questions about revocation — I'm trying to think about and
clarify that stuff next ]

> connect to a site, accept the self-signed certificate, can that site then
> pin itself using that self-signed cert? I.e. can the validation of the cert
> chain stop as soon as there is a pin match?

This specification is agnostic on that issue. If your client lets you
accept self-signed certificates, then there's no reason it can't also
note it as a Known Pinned HSTS Host pinned to your self--signed public
key.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 14 Sep 2011 09:15:36 -0400

> 3. Decommission the old EE cert and deploy the new.

Actually, if your certificate policy requires key rotation at
certificate expiry, you can generate key N+1 at any time (preferably
early in the life of the cert corresponding to key N), and introduce the
secondary pin at that point, without having gotten certificate N+1 yet.

Then, as certificate N approaches expiration, get a certificate made
from key N+1 -- your pin is already well-known.  Generate key N+2
(stored safely offline someplace?), deploy key N+1, and update your pin
list to be (N+1,N+2).  There's no waiting required.  And this approach
dovetails nicely with your recommendations for backup resiliency as well.

It still looks to me like pinning a CA does nothing more than give them
the chance to hold you hostage at certificate renewal time, and to
expose you to vulnerability should the CA itself be compromised.

> no problem.

Yep; the only reason you'd need the more-complex approach above is if
you require key rotation at certificate expiry.  If all you care about
is convenience and simplicity of operation, just get the existing key
re-certified by any CA.  In this case, there's still no need or
advantage (and significant disadvantages) to pin to a CA instead of
pinning to your EE.

> Again, that's fine and one size does not fit all.

Sure, one size does not fit all, but it looks like the document is
(reasonably) trying to outline some common patterns of reasonable
behavior to encourage best practices.  I still don't see any best
practice that involves pinning to a CA unless that CA is itself under
the control of your own organization.

I recommend that the draft make this explicit, to avoid encouraging
system operators binding themselves even more tightly to a CA by
misapplication of this mechanism.

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 09:26:59 -0400

Or maybe DANE should consider migrating to the WEBSEC approach.

I was pushing for DANE to consider the pinning and 'must be SSL' approach
from the start. The consensus of the group has been that they don't want to
consider those use cases at all. Furthermore the response I have got from
the key contributors has been 'we don't want to consider those issues
because we can't understand the issues and have no interest in attempting to
do so'.

The reason that I was pushing hard to get the use of prefixes fixed was
because I have been looking at these use cases for two years now and I don't
see the naive prefix approach that has been insisted on will allow for
effective security policy.

If you want DANE to be compatible with the WebSec approach I suggest that
DANE make the accommodations to the deployed HTTP and TLS infrastructure
rather than propose a completely new infrastructure and then demand that
everyone work around the legacy you have just created.

There is 20 years of Web legacy. It is big, ugly and complex. There is 0
years of DANE legacy.

PKI is really hard for reasons that go beyond the syntax and structure of
X.509v3. The complexity of PKIX comes mostly from the fact that the original
design did not have enough flexibility to meet real world needs and so a
heck of a lot that should have been in the core ended up as ad-hoc
extensions and patches. In particular X.509 was originally designed round a
PEM style monolithic hierarchy.

On Mon, Sep 12, 2011 at 8:54 PM, Richard L. Barnes <[email-masked]> wrote:

> Hey Chris & Chris,
>
> This seems like a useful near-term approach, but also probably something
> that might want to migrate to DANE over time.
>
> Is there any particular reason you're using key fingerprints instead of
> cert fingerprints?  It seems like the latter might be slightly easier to
> implement, since you don't have to parse the cert.
>
> --Richard
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 09:46:04 -0400

> secondary pin at that point, without having gotten certificate N+1 yet.

Yep.

> expose you to vulnerability should the CA itself be compromised.

It gives you scaling and administrative convenience.

If you have 10,000 hosts in your enterprise network you really do not want
to have to be managing trust on a per host level. Now consider the case
where you are renting your compute power in the cloud and so the machine
instances are existing for a few hours at a time.

Any scheme that insists on only tying to the EE cert or key is going to
create a major operational headache for those sites. It is really easy to
design a scheme that is easy to administer.

It is also going to cause huge amounts of state that the client has to
manage. If you have 10,000 front end web servers you are going to need
10,000 different client keys to do the job right.

So what most of the large enterprises would likely do if they introduced any
form of security policy would be to have a private CA run up that is an
intermediate in a larger hierarchy. This is why the bogus EFF study came up
with the absurd number of 600 CAs. What they have never come clean on is the
fact that 150 of those 'CAs' are in fact merely intermediate roots tied to a
single customer that are managed in the same infrastructure as the root CA
operations.

What pinning to a CA does raise is the absolute need to have the ability to
pin more than one CA at a time.

> misapplication of this mechanism.

There is certainly a difference in the risk factor here between pinning in
the browser and CAA as currently specd (i.e. without the client enforcement
capability). [I originally wrote big, but thinking it through, maybe not so
much]

CA issue of certs is never a 100% automated process. There are some cases
where automated issue is possible but there are inevitably exceptions.

CAA does not prevent a CA issuing a cert, it merely triggers an exception.
So the CA that received the failed application is going to circle back to
the customer and ask what is up. If the CAA record was inserted maliciously
or without informed consent then the customer is going to be mighty peeved
with their old CA and likely contact slashdot with a nasty story.

If there is client enforcement of the records then there is a potential to
use them maliciously.

But even so, I can't see this being much of a practical concern. The main
value add CAs bring in practice is teaching people how to configure crypto
and install certs properly without making a mess of it. Every customer call
center I have been in the conversations you hear are salespeople walking a
customer through install for Apache or ISS.

So provided there is an escape hole from the pinning mechanism, the CAs are
going to be more than capable of talking the customer through how to untie
themselves from the attempted customer capture.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 10:00:08 -0400

One technical point, have you considered the ODI mechanism that we developed
for CAA up to the -01 version when the client enforcement bit got kiboshed?

The name is confuising, but lets say we call it the DIGEST URI type and the
digest data consists of

DIGEST: < Base64 ( <Object-type> + <Digest-alg> + <Digest-value>)

The idea was that this is something we could write code into various crypto
libs to generate as a fixed ASCII blob that the user can then cut and paste.

It is thus easier for the admin to manage than having the digest alg being a
separate parameter that they have to get right.

A practical benefit here is that it makes it easy to have multiple digests
in the same header without the need for bracketing:

Pin: DIGEST:w2eoiuweoifuweoi==  DIGEST:weowoeifwoeifj==

Is easier to parse than:

Pin: [alg=sha1 fingerprint=odoiweoifjio==]  [alg=sha256
fingerprint=wejwekhjw==]

This makes it easy to provide two versions of the digest so that old and new
browsers can make use of the same data.

This is the type of capability that I think will be essential in emergency
response if we ever have a SHA2 breach to cope with.

It also means that the digest format is intrinsically proof against content
type substitution attacks. If the code expects a cert or a key, it can check
that it is not being fed a cunningly crafted object of another type.

One minor point, the draft mentions SHA1. Could we just dump that? I can't
see a good reason to use SHA1 in new code at this point. I would like all
new code to be SHA3 capable from the start.

Which is why the ODI scheme used ASN.1. Any code that is going to touch
certs is going to have to have an ASN.1 algorithm type mechanism. But
knowing what the IANA situation is takes an additional bit of data.

[As a matter of policy I would prefer that the IETF get out of the business
of giving code points that recognize vanity crypto and only ever issue code
points for algorithms that the IETF endorses as MUSTs for IETF protocols.]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 14 Sep 2011 11:13:47 -0400

On 09/14/2011 09:46 AM, Phillip Hallam-Baker wrote:
> to have to be managing trust on a per host level.

You're not "managing trust on a per host level" -- you're managing
*identity* on a per-host level, which is exactly what it should be.  If
you have 10K hosts, you need to think clearly about the identity
presented by each of those hosts.

> Now consider the case

is it more of an operational headache to get an external CA to sign a
new key for each host each time it comes up "for a few hours"?  or to
just push the relevant pre-existing keys+certificates onto the hosts in
question?

> 10,000 different client keys to do the job right.

eh?  why?  if these are front-end web servers hosting the same service,
wouldn't they just share a key (and a certificate)?  The only large
organization i know of that uses one key per server is citibank, and
many people are making decent arguments that this is problematic for
other methods of identity verification (e.g. Perspectives and
Convergence plugins)

> intermediate in a larger hierarchy.

Sure, as i pointed out, the only reason you'd want to pin a CA is if the
CA is under your own organization's direct control.

> This is why the bogus EFF study came up

if those intermediate authorities are not explicitly domain-restricted
*in their own certificate*, then yes -- the risk is larger.  i don't

> pin more than one CA at a time.

i think for rollover purposes, you already need to be able to pin
multiple certs if you're pinning an EE.

Still unconvinced,

	--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 14 Sep 2011 11:31:46 -0400

> *in their own certificate*, then yes -- the risk is larger.  i don't

sorry -- this got cut off somehow.

... i don't think EFFs study is bogus in its analysis.  "the same
infrastructure" doesn't mean "using the same access controls" --
certainly customers in control of an intermediate root have more access
to that root than other people, so there are additional risks to relying
parties from them if they're not explicitly domain-restricted.

Were these 150 intermediate certs explicitly domain-restricted in the
certificates themselves?

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 12:44:29 -0400

On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor <[email-masked]
> wrote:

> presented by each of those hosts.

Identity is a property of the site, the host is merely an implementation
detail.

> just push the relevant pre-existing keys+certificates onto the hosts in

I really hate having private keys move off a host.

If people are going to be doing that pattern of hosting I would prefer to
have keys tied to the virtual hosts such that they are generated in place
and never ever move from the host. Then have certs generated with short
lived expiry (36 hours), that way the attack surface is kept to a bare
minimum.

> other methods of identity verification (e.g. Perspectives and

Keys should be unique to the host and never move from the host.

It is certainly not just citibank that has that scheme.

> *in their own certificate*, then yes -- the risk is larger.  i don't

Not if the signing keys are in the same hardware module as the intermediate
they are signed under.

The problem is that PKIX policy constraints don't really have the leverage
they should in the real world. And even if they did they don't necessarily
map to real world organizational divisions. A large organization will
typically own many DNS names.

The issue is where validation is performed and if the RA has independent
issue authority or not.

At this point the government of Iran has solved that particular problem.

> multiple certs if you're pinning an EE.

It is an operational issue. There is practically no difference in the code
between only checking the EE cert or key and checking intermediate
certs/keys.

Designs should be as simple as possible BUT NO SIMPLER.

The 'I don't see the need, therefore I will obstruct feature X' approach is
the reason that PKIX has become what it is. We could have had policy
constraints and cross certificate mechanisms that really worked the way we
wanted if they had been baked in on day one. Instead they have become a
black art which can be practiced by a very small circle of people and even
they will tell you how broken the system is.

Give operators the tools to do their job, do not presume to tell them how to
secure their systems.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 12:46:52 -0400

They claimed 600 CAs on the Internet.

Their claim was disproved, the intermediate roots are not under direct
control of the customers.

They did not retract or clarify

That is not how reputable academics do their work. They were making a
political statement using Fox News type tactics.

On Wed, Sep 14, 2011 at 11:31 AM, Daniel Kahn Gillmor <[email-masked]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 14 Sep 2011 13:38:02 -0400

> lived expiry (36 hours), that way the attack surface is kept to a bare

I personally like this approach and i use multiple keys for different
hosts serving the same domain for at least one domain i administer
myself.  i also note that it is diametrically opposed to your earlier
stated goal of avoiding "major operational headache", particularly when
using an external CA.  I was trying to offer a way to avoid major
operational headache in my proposal.

Of course, the other way to avoid the headache in this is to use an
in-house CA, but of course that gets back to my "the only reasonable CA
to pin is an in-house CA".

> It is certainly not just citibank that has that scheme.

Are these other organizations public?  I'm looking to compile a list of
groups that do this to raise this concern with the
Convergence/Perpsectives folks, since these always show up as bad under
their model of analysis.  Feel free to mail the the list privately if
you don't want to publish it, or if you feel it is off-topic for this list.

> Not if the signing keys are in the same hardware module as the intermediate

You're asking me to assume a whole stack of things about operational
integrity, access control, system maintenance, and coding practice at
various CAs.  I have no idea whether any of these things are true for
any CA in particular.  All i know is that there is a CA that is
nominally under the control of a separate organization.

I'd happy if someone could prove that these intermediate CAs are
actually all locked down under very high security and properly limited
in what kinds of certificates they can issue; but i'm not convinced such
a proof is possible.

And given the recent events, i'd have no confidence in an unproved
assertion of secure operations of these subordinate CAs.

> Give operators the tools to do their job, do not presume to tell them how to

The draft as initially proposed included both explicit mechanism and
several "best practice" recommendations (e.g. pin rollover and backup).
 I think these recommendations were good ones, and contribute a lot
toward making the draft clear and useful to the people who will have to
deploy the mechanism.

If this becomes an RFC, i'd hope these recommendations would persist in
a "SECURITY CONSIDERATIONS" section or the equivalent.

I'm proposing an additional recommendation: unless you control and
operate your own CA, you probably only want to pin EEs.

Regards,

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 14:50:46 -0400

> operational headache in my proposal.

Not really. Operating infrastructure on a large scale, the issue is not the
number of operations required but the number of interdependencies between
systems.

Having keys that never leave the machine eliminates a lot of the management
issues to do with equipment that is lost, stolen etc with the keys loaded.
If you have 10 machines it is pretty obvious that you have lost one. On a
large installation racks of equipment can be appearing/disappearing on a
bewildering basis. And it is not uncommon for theft to be an insider who is
selling off machinery that is being booked as destroyed.

The way I would ideally lock a key to a host is to have a permanent host key
that is unique to that device and only used for authenticating cert
requests. To instantiate an instance of some server the data center pushes
out the server image and a one time use authentication key that is used to
authenticate a cert request for that specific machine. The host generates a
new key per cert request.

That approach allows a system where all the data flows are unidirectional,
no three way synchronization etc.

> to pin is an in-house CA".

We can get to agreement on a 'house specific CA'.

Running it in-house is a pain and is going to get worse over time as the
criteria for public CAs are raised by the browser providers.

Where I think we might want to shoot for with this would be to look for dual
control points and a key splitting type approach.

> you don't want to publish it, or if you feel it is off-topic for this list

I would think that would be proprietary and customer confidential and I
would have to ask a former employer.

It is easier to measure than make the request. Just look for companies that
have multiple A records and then see if they have the same cert or not.

> nominally under the control of a separate organization.

No, it is not a CA, according to the defined terms, the CA performs the
validation and signature function. If there are 150 keys in one HSM they are
under control of one CA, not 150.

The fact that a CA issues some certs for a given customer off a different
intermediate to their other customers does not increase the number of
signing parties.

Such a customer might well have had a local RA capability, but that should
have been locked down so they could only issue for their roots. At this
point I very much doubt that there are any such RAs being operated as a true
RA without the CA performing full validation of the requests. Thank the
Iranian government for that change in practice.

There is a slight difference in the trust model in that such an intermediate
root can be and is frequently used to provide authorization data. This is
mostly used for client certs. But if the proposal being discussed here went
through there would be a real value to the key splitting approach outlined
above for servers.

> in what kinds of certificates they can issue; but i'm not convinced such

It is the job of the certificate policy requirements to make those demands
explicit and of the auditors to ensure that they are enforced.

One of the reasons that Comodo has been pushing to introduce baseline
requirements for all public CA issued certs is to get some controls into the
system that can be checked by auditors.

We have these requirements for EV certs, until recently we did not have the
requirements for DV certs.

> assertion of secure operations of these subordinate CAs.

It definitely needs to be audited. But we definitely need to have additional
controls that can be used when the auditors don't do their job.

The fact that the Diginotar root was revoked has woken up anyone who still
needed it.

> a "SECURITY CONSIDERATIONS" section or the equivalent.

That is fine.

I think we can write a set of security considerations that are pretty much
the advice you give and direct them at the smaller to medium sites that turn
SCs into operational policy.

> operate your own CA, you probably only want to pin EEs.

How about we split the difference? We can leave in control. Just take out
'operate'.

My preference for the larger enterprise would be a split key approach. That
reduces my liability and risk.

By the time this is all through I think the number of people still willing
to operate CAs is going to be a much smaller set than in the past.

Regards,