Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
mrex@sap.com (Martin Rex) Mon, 29 October 2012 23:23 UTC
Return-Path: <mrex@sap.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0873221F869F for <pkix@ietfa.amsl.com>; Mon, 29 Oct 2012 16:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Level:
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALbKxd6OsfAq for <pkix@ietfa.amsl.com>; Mon, 29 Oct 2012 16:23:37 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79621F8674 for <pkix@ietf.org>; Mon, 29 Oct 2012 16:23:36 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9TNNTcx015087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Oct 2012 00:23:29 +0100 (MET)
In-Reply-To: <001201cdb402$98ab4d70$ca01e850$@ditenity.com>
To: Piyush Jain <piyush@ditenity.com>
Date: Tue, 30 Oct 2012 00:23:28 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: pkix@ietf.org, 'Stefan Santesson' <stefan@aaa-sec.com>
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2012 23:23:39 -0000
Piyush Jain wrote: > > Martin Rex wrote: >> >> These recommendations are the longer version of >> >> "CA compromise can not possibly happen. If it happens anyhow, nuke the >> PKI" >> >> >> There are two things to do here: >> >> (1) do like NIST, openly admit that existing X.509/PKIX is defective >> describe the consequences for the installed base in case you're using >> X.509/PKIX. > > I think that the conclusion is unfair - X.509/PKIX is defective > because a few CAs get compromised. X.509/PKIX is defective because it breaks badly already on fraudulent cert issuance (a weaker form of CA compromise) and can not cope at all with CA key compromise. > >> (2) fix the architecture of X.509 so that the CA key is no longer >> an unavoidable single-point-of-failure, and that the authentication >> can be restored to secure operation after the breach is detected >> for existing/deployed PKI credentials for use with RPs that use >> (modified) OCSP for revocation checking, _even_ when the CA signing >> key plus the OCSP signing key were captured by the attacker. > > May be there is a silver bullet out there. But I have not seen one yet. I don't think silver bullets exist (I wrote that previously), but one can hardly do worse that rfc2560 for online status checking of certs. OCSP was artificially limited to "as bad as CRL checking." > > None of the proposals here satisfy what you are asking. The closest one > was from Phil some time ago where he informally proposed OCSP responder key > should not be bound to the CA that issues EE certificate. And that one did > not get any support here. > > BTW authentication can be restored by revoking the CA and reissuing the end > entity certificates with a new key. Not saying that it is easy but it is > doable, and unfortunately the only way to patch the vulnerabilities > introduced by a CA compromise. If you imply revoking the compromised CA key by revoking the CA cert, then this isn't restoring authentication at all. It is nuking the old PKI and re-creating a new PKI. In case that this procedure assumes that using an audited log of issued certs can be used to automatically re-signed the public keys with the new CA cert and distribute only that cert (omitting the RA step), then this is conceptually on the right track. We do not even need to issue new certs -- if we extend OCSP to provide an independent confirmation to _others_ (RPs) right away, then we do not have to unconditionally force each PKI credential through a cert replacement _before_ it can be used again. Instead, the CA may keep the existing credential working and have PKI credentials gradually updated. Yes, Phil is right that the rfc2560 approach that the same CA key can sign valid OCSP signer keys is one of the design flaws of OCSP. > > [Piyush] I'm all for improvement, the idea of overloading OCSP as it stands > today is just a hack. I have not seen a single attack scenario where > responding for so called un-issued certificates helps. People have been > splitting hair by saying that even CA compromise can have different > severance level. Unless you can document those and provide guidance on how > this change would help, you are just adding to the confusion. rfc2560 OCSP currently delivers a poor ROI, and by extending the protocol, we could significantly improve its value. The TLS renegotiation issue was based on a completely flawed assumption (by primarily the renegotiating servers), infering from the renegotiation happening inside TLS that the remote peer will still be the same after renegotiation completes. It would have been obvious, for anyone who cared to really check, that there was *NO* cryptographic binding between the two TLS connection states. The flaw with CRLs and OCSP is that it tries to infer, from a lack of a revocation, that a certificate has been properly issued and is valid. Evidently, this turned out to be a logical fallacy with respect to real world usage scenarios. The design of CRLs is pretty much fubar, but OCSP gets at least the basic request-response semantics right, in that it is about a positive confirmation for the status of cert, rather than a flawed inference on the lack of a published revocation. In order to get rid of the CA-key-is-single-point-of-failure, a secondary trust path is necessary, one which can not be forged even when the CA cert signing key is compromised, two independent CA keys, that can be seperated and seperately protected, i.e. (1) CA-key-1 to sign EE certs (2) independent CA-key-2 to sign short-lived OCSP signer certs To issue (=sign) EE-Certs, only CA-key-1 needs to be accessible by the OnlineCA. One of the problems create by compromise of the CA-key-1 is that we can no longer trust any information in certs signed with CA-key-1 _unless_ we can obtain an independent confirmation of the certificate hash signed by an independent key. So in order to convey the necessary information in a fashion that is not affected by a CA-key-1 compromise, but still locally available to the certificate path validation function, we could convey (a) the location of the OCSP responder and (b) the CA-key-2 that is solely authorized to sign OCSP responder keys through new attributes of the CA cert that carries CA-key-1. An approach to make this mostly backwards-interoperable with rfc2560 would be to create a self-issued CA cert with CA-key-2 signed by CA-key-1, adding the certificate hash of this self-issued cert into the CA cert that carries CA-key-1, and create all OCSP responses with two path certs, the OCSP signer cert and the self-issued CA-key-2 signed by CA-key-1 cert. Vanilla rfc2560 RPs will remain unprotected from a CA key compromise, since they will continue to happily accept OCSP signer certs signed by CA-key-1. That is to be expected with a protocol design flaw. The important thing here is that you do not need two different kind of OCSP responses, but can still process value-added OCSP responses with rfc2560 RPs. (Similarly, TLS server implementations without rfc5746 will remain susceptible to the TLS renegotiation problem, but that should not stop anyone from adopting new protocol features). -Martin
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter Rybar
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- [pkix] Straw-poll on OCSP responses for non-revok… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yngve Nysaeter Pettersen
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yoav Nir
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Miller, Timothy J.
- Re: [pkix] Straw-poll on OCSP responses for non-r… David Chadwick
- Re: [pkix] Straw-poll on OCSP responses for non-r… Art Allison
- Re: [pkix] Straw-poll on OCSP responses for non-r… Miller, Timothy J.
- Re: [pkix] Straw-poll on OCSP responses for non-r… Santosh Chokhani
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yoav Nir
- Re: [pkix] Straw-poll on OCSP responses for non-r… Peter Rybar
- Re: [pkix] Straw-poll on OCSP responses for non-r… Paul Hoffman
- Re: [pkix] Straw-poll on OCSP responses for non-r… Juan Gonzalez
- Re: [pkix] Straw-poll on OCSP responses for non-r… Max Pritikin (pritikin)
- Re: [pkix] Straw-poll on OCSP responses for non-r… Simon Tardell
- Re: [pkix] Straw-poll on OCSP responses for non-r… Carl Wallace
- Re: [pkix] Straw-poll on OCSP responses for non-r… Paul Hoffman
- Re: [pkix] Straw-poll on OCSP responses for non-r… Rick Robinson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Jeremy Rowley
- Re: [pkix] Straw-poll on OCSP responses for non-r… Melinda Shore
- Re: [pkix] Straw-poll on OCSP responses for non-r… Martin Rex
- Re: [pkix] Straw-poll on OCSP responses for non-r… Russ Housley
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Ritter
- Re: [pkix] Straw-poll on OCSP responses for non-r… Dr Stephen Henson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ryan Sleevi
- Re: [pkix] Straw-poll on OCSP responses for non-r… Johannes Merkle
- Re: [pkix] Straw-poll on OCSP responses for non-r… Denis Pinkas
- Re: [pkix] Straw-poll on OCSP responses for non-r… Art Allison
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ryan Hurst
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ben Wilson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] Straw-poll on OCSP responses fornon-re… Art Allison
- [pkix] Proposed resolution to non-issued certific… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Ritter
- Re: [pkix] Proposed resolution to non-issued cert… Tom Ritter
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter Gutmann
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Phillip Hallam-Baker
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Peter Rybar
- Re: [pkix] Proposed resolution to non-issued cert… Simon Tardell
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Peter Rybar
- Re: [pkix] Proposed resolution to non-issued cert… Simon Tardell
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Gindin
- Re: [pkix] Straw-poll on OCSP responses for non-r… Phillip Hallam-Baker