Re: [pkix] OCSP Signing Certificate Key usage standards
"Dr. Pala" <director@openca.org> Tue, 05 April 2016 17:02 UTC
Return-Path: <director@openca.org>
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 322D812D86E for <pkix@ietfa.amsl.com>; Tue, 5 Apr 2016 10:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 aVi13QVJAP83 for <pkix@ietfa.amsl.com>; Tue, 5 Apr 2016 10:02:01 -0700 (PDT)
Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 473E012D8A1 for <pkix@ietf.org>; Tue, 5 Apr 2016 10:01:59 -0700 (PDT)
Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:fcb8:f7a1:6531:7f0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id AF2E93743B7B for <pkix@ietf.org>; Mon, 4 Apr 2016 15:54:44 -0400 (EDT)
To: pkix@ietf.org
References: <CAJKvcBTk6i2K1QYCm3VaO1jOm9sNTi7R8_oUuRVuuhBnzcZw9w@mail.gmail.com>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <5702C682.1020700@openca.org>
Date: Mon, 04 Apr 2016 16:54:42 -0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAJKvcBTk6i2K1QYCm3VaO1jOm9sNTi7R8_oUuRVuuhBnzcZw9w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070009070903050108000802"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/EpTWT3UMAP5_YbqywcnRkgyh6Y8>
Subject: Re: [pkix] OCSP Signing Certificate Key usage standards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Apr 2016 17:02:03 -0000
Hi Daniel, personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said. However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO. To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options) If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response! Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case). I hope this helps, Cheers, Max On 4/4/16 4:07 PM, daniel bryan wrote: > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on > 20 different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit > all 20 for Signing to each CA. Import the Signed Certificate into my > OCSP service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a > generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN > value during Signing to reference their CA name, Import all 20 Signed > certificates into my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is > lost/compromised, it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it > will increase the signing speed potential of the HSM, being that it > doesn't have to determine which key to use from a pool of 20 keys. > Obviously the bad side is, if we ever loose the key, I would have to > get all 20 CAs to sign another request. This is especially bad when > the certs have the noCheck extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > * > Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use > to support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca
- [pkix] OCSP Signing Certificate Key usage standar… daniel bryan
- Re: [pkix] OCSP Signing Certificate Key usage sta… Liaquat Khan
- Re: [pkix] OCSP Signing Certificate Key usage sta… daniel bryan
- Re: [pkix] OCSP Signing Certificate Key usage sta… Dr. Pala
- Re: [pkix] OCSP Signing Certificate Key usage sta… Dr. Massimiliano Pala
- Re: [pkix] OCSP Signing Certificate Key usage sta… Dr. Pala
- Re: [pkix] OCSP Signing Certificate Key usage sta… Dr. Pala
- Re: [pkix] OCSP Signing Certificate Key usage sta… Dr. Pala
- Re: [pkix] OCSP Signing Certificate Key usage sta… daniel bryan
- Re: [pkix] OCSP Signing Certificate Key usage sta… Dr. Pala