Subject: [websec] HPKP: Cross-signing with a self-signed certificate and pinning that cert?

From: jxtps435 <[email-masked]>
Date: Mon, 21 Sep 2015 16:18:52 -0700

I'm interested in implementing HPKP on my sites, but it is a bit tricky to
do:

- We add / remove websites from a single SAN certificate on a semi-regular
basis.

- Our CA recently switched out at least their intermediate, if not their
root cert in response to the SHA1 -> SHA256 transition.

- We'd like to be able to switch root CA for business reasons.

So pinning any of these certs seems like a recipe for disaster (maybe
things won't change in the future, but when they have demonstrably changed
in the past I would / should get fired if I don't take that into account).

So basically, I need to be able to switch out our certificates at any time,
for any reason, to any CA, without bricking our sites, to be able to use
HPKP.

Sounds impossible, right?

But wait. What if I could cross-sign my certificates with a self-signed
certificate and pin that certificate?

So the browser would trust the regular root CA's authority, but it would do
the pinning to my not-at-all-trusted self-signed certificate, enabling me
to update my certs whenever I want, and as long as I can keep my
self-signed cert safe no-one else can tamper with our sites.

Would that work in theory? Would that work with current implementations?
Thoughts?

(I don't know the details of cross-signing, but apparently Google does it:
http://googleonlinesecurity.blogspot.com/2015/09/disabling-sslv3-and-rc4.html
)

---

From: Joseph Bonneau <[email-masked]>
Date: Mon, 21 Sep 2015 22:31:30 -0700

You might want to check out TACK (http://tack.io/) which is the closes
proposal I know of to this.

Reasons this hasn't caught on:
1) Requires site owners to create and reason about a second private
key/certificate
2) Requires more changes to TLS stack.

On Mon, Sep 21, 2015 at 4:18 PM, jxtps435 <[email-masked]> wrote:

> So basically, I need to be able to switch out our certificates at any
> time, for any reason, to any CA, without bricking our sites, to be able to
> use HPKP.
>
> So the browser would trust the regular root CA's authority, but it would
> do the pinning to my not-at-all-trusted self-signed certificate, enabling
> me to update my certs whenever I want, and as long as I can keep my
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 22 Sep 2015 02:01:48 -0400

> - We add / remove websites from a single SAN certificate on a semi-regular

You should re-certify the same public key. Or maybe that's too much
like bike shedding and I should ask: do you re-certify the same pubic
key?

What we've found is key continuity is more important security property
than many previously used rituals, like key rotation.

> root cert in response to the SHA1 -> SHA256 transition.

When they do this, they often re-certify the same public key, and even
use the same Distinguished Name. That should not break public key
pinning (but will break certificate pinning).

> - We'd like to be able to switch root CA for business reasons.

OK, this means you can't pin to a CA or subordinate.

> for any reason, to any CA, without bricking our sites, to be able to use

Yes, its possible. Re-certify the same public key, and don't change
the Distinguished Name. Essentially, the only thing that changes is
the certificate's serial number and the resulting digest.

Its perfectly legal according to the IETF. I don't know where the CA/B
stands on the issue. But it is inconvenient to troubleshoot because
the Subject and Issue DN remain the same, but the SN changes.

> certificate and pin that certificate?

Oh no, the IETF and CA/B won't have any part of that.

> the pinning to my not-at-all-trusted self-signed certificate, enabling me to
> update my certs whenever I want, and as long as I can keep my self-signed
> cert safe no-one else can tamper with our sites.
>

I had the same desire/use case - certify a site using an internal CA
for internal software, and a public CA for external software. The cert
would essentially have two Issuers and two signatures.

There's no format to present a certificate with multiple
Issuers/signatures, and there's only room for one Authority Key
Identifier, not two or more.

Jeff