From jxtps435@gmail.com Mon Sep 21 16:18:56 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAC91ACF02 for ; Mon, 21 Sep 2015 16:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMHFmMZSoMDY for ; Mon, 21 Sep 2015 16:18:54 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D4A1ACEED for ; Mon, 21 Sep 2015 16:18:54 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so59255316lbc.3 for ; Mon, 21 Sep 2015 16:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/nQcLBVnSYYdXkF19D8vCL4pmtK3EFwrpEl6Omm0UNM=; b=MKlWlpXrDf9vvVnF0kJbbGzNScHD/dAPF/0CB3l5SBvdm5QddevouZwz6lwqa5fBQH ocuxFsOtEJIADq+yiv9orddHyjvKVGhau1XI10QoKlEdnvE1YAhTSt8pNrd6gDgjAKEv LbozqXGpLOEr1hDrveybWenNqurrCO0HaHrZ2ZNZI4DCZIjKY8OaU51t35PegoF/Axye +SjZ5jG8Q57k+Nr2XH4O1bFsRc46pe8Ftyd0rEt5HRQCWzXiVAQPKf8pS06TAhfiXqzW JsM2ySvYthq+jZGSLJ40VtZY0xpqjA0bH2Mmcyz4dXbWkV240XOrFhA8xdwZ1wyzIKyD NEtw== MIME-Version: 1.0 X-Received: by 10.152.1.104 with SMTP id 8mr8592748lal.24.1442877532209; Mon, 21 Sep 2015 16:18:52 -0700 (PDT) Received: by 10.112.210.134 with HTTP; Mon, 21 Sep 2015 16:18:52 -0700 (PDT) Date: Mon, 21 Sep 2015 16:18:52 -0700 Message-ID: From: jxtps435 To: websec@ietf.org Content-Type: multipart/alternative; boundary=089e013c64d4c30a2505204a1ab1 Archived-At: Subject: [websec] HPKP: Cross-signing with a self-signed certificate and pinning that cert? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 23:19:57 -0000 --089e013c64d4c30a2505204a1ab1 Content-Type: text/plain; charset=UTF-8 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 ) --089e013c64d4c30a2505204a1ab1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm interested in implementing HPKP on my sites, but i= t is a bit tricky to do:=C2=A0

- We add / remove website= s from a single SAN certificate on a semi-regular basis.=C2=A0

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

- We'd like to be able to switch root C= A for business reasons.=C2=A0

So pinning any of th= ese certs seems like a recipe for disaster (maybe things won't change i= n 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 a= ny time, for any reason, to any CA, without bricking our sites, to be able = to use HPKP.=C2=A0

Sounds impossible, right?=C2=A0=

But wait. What if I could cross-sign my certifica= tes with a self-signed certificate and pin that certificate?=C2=A0

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

Would that work in theory? Would that work wit= h current implementations? Thoughts?=C2=A0

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


<= /div>
--089e013c64d4c30a2505204a1ab1-- From nobody Mon Sep 21 22:31:53 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E191A8AE3 for ; Mon, 21 Sep 2015 22:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5-m5TBAxWAE for ; Mon, 21 Sep 2015 22:31:50 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199281A8ADE for ; Mon, 21 Sep 2015 22:31:50 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so74815900igb.0 for ; Mon, 21 Sep 2015 22:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4vraCIWH9X+orFDNV7bcijkh+llotNCW6dd0BinT1a0=; b=i0jHe6mEweumUAF13gQWWB+HRDlwp3qMmE+gS0fHmkcXCVuazwIqWlCRuhTpPlIJ15 jgiJRidmLLQz0QchIU2tZyaKNjhDMhuZtsK7f851iyoltOGrqAY4/ujBcb3FjWTeUjWK PWIEjCPVJKekpfNQMX2AKlTuUg+AJR75efOz6RhdxA6kclSFISv8zehn4HmIDHNws7u+ CB4DcvpI9IivqNru3NDLLfdYS/gFZdwV9LP6hExir74DFzlCP8T026K4bLQBLwQQH8bN RAcvuobnr7QAa+R1xsTfbpr565GMI6MqxVfGPlaN9eRbhXIEewxr9lb3yNUww9gxkeqf ZyIg== X-Received: by 10.50.79.167 with SMTP id k7mr14179339igx.67.1442899909425; Mon, 21 Sep 2015 22:31:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.1.75 with HTTP; Mon, 21 Sep 2015 22:31:30 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Mon, 21 Sep 2015 22:31:30 -0700 Message-ID: To: jxtps435 Content-Type: multipart/alternative; boundary=089e013a1a388c445405204f50de Archived-At: Cc: "" Subject: Re: [websec] HPKP: Cross-signing with a self-signed certificate and pinning that cert? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 05:31:53 -0000 --089e013a1a388c445405204f50de Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 > ) > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > --089e013a1a388c445405204f50de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 s= ite 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 <jxtps435@gmail.com> wrote:
I'm interested in implementing= HPKP on my sites, but it is a bit tricky to do:=C2=A0

-= We add / remove websites from a single SAN certificate on a semi-regular b= asis.=C2=A0

- Our CA recently switched out at = least their intermediate, if not their root cert in response to the SHA1 -&= gt; SHA256 transition.=C2=A0

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

So pinning any of these certs seems like a recipe for disaster (maybe thi= ngs 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 accou= nt).

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.=C2=A0

Sounds im= possible, right?=C2=A0

But wait. What if I could c= ross-sign my certificates with a self-signed certificate and pin that certi= ficate?=C2=A0

So the browser would trust the regul= ar root CA's authority, but it would do the pinning to my not-at-all-tr= usted self-signed certificate, enabling me to update my certs whenever I wa= nt, and as long as I can keep my self-signed cert safe no-one else can tamp= er with our sites.=C2=A0

Would that work in theory= ? Would that work with current implementations? Thoughts?=C2=A0


(I don't know the details of cross-sig= ning, but apparently Google does it:=C2=A0= http://googleonlinesecurity.blogspot.com/2015/09/disabling-sslv3-and-rc4.ht= ml )



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


--089e013a1a388c445405204f50de-- From nobody Mon Sep 21 23:01:51 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348391A9004 for ; Mon, 21 Sep 2015 23:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VftToHUWrUse for ; Mon, 21 Sep 2015 23:01:48 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1DD1A8FD5 for ; Mon, 21 Sep 2015 23:01:48 -0700 (PDT) Received: by igxx6 with SMTP id x6so4045580igx.1 for ; Mon, 21 Sep 2015 23:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jyEorh5/qC7MPsaNdvRz2yGtR3tjieDJCrL9rNPm51c=; b=BoKHjicTqYoZK4qpu4hHiZR/ywSwYcTYz8ihjCaqY2fDrrAuw9+usYpx8WEY6ls0xn Ut0lh00ADhGYnj7LZVa3kg4U2eGAqMv0EV57xOrCftFXQd53zWtNpBiDS8LQN5iNe4Nv hwogTZ3+0czfzSkCB9MK6AMODmLm9unyRxZZVfnLsXzNQyEPpAq5wSR69vi+wiTWcfVD ygl7pUBFA4MSJRzOFTKW2ufDAZWCTAljqcwjM5y82b4/ETb8lpGYXdz0CYAjWGaa3Xhw bu3WmmbE0qqwqp7CWGD7gU/hokBwukKClhzkUgLKNbA4Xvn/C5kntFYbsXFzulGBZK0u oJDQ== MIME-Version: 1.0 X-Received: by 10.50.20.8 with SMTP id j8mr14202591ige.36.1442901708110; Mon, 21 Sep 2015 23:01:48 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Mon, 21 Sep 2015 23:01:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Sep 2015 02:01:48 -0400 Message-ID: From: Jeffrey Walton To: jxtps435 Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP: Cross-signing with a self-signed certificate and pinning that cert? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 06:01:50 -0000 > - We add / remove websites from a single SAN certificate on a semi-regular > basis. 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. > - Our CA recently switched out at least their intermediate, if not their > 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. > 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. 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. > But wait. What if I could cross-sign my certificates with a self-signed > certificate and pin that certificate? Oh no, the IETF and CA/B won't have any part of that. > 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 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