On Wed, Mar 24, 2010, Rob Stradling wrote: > On Tuesday 23 March 2010 18:40:58 Dr. Stephen Henson wrote: > > On Tue, Mar 23, 2010, Eisenacher, Patrick wrote: > > > Hi Steve, > > > > > > > -----Original Message----- > > > > From: Dr. Stephen Henson > > > > > > > > There are two automatic trust models for OCSP responder > > > > certificates. One is the CA key that signed the > > > > certificate also signs responses: that isn't > > > > recommended for security reasons. > > > > > > can you please elaborate on this? > > > > Well it would typically require giving a public responder access to a CA > > key: increasing the risk of compromise especially if the private key > > itself is placed on the server. > > Steve, I think it's entirely unfair to label the non-delegated model as "not > recommended for security reasons" just because *some implementations* might > give "a public responder access to a CA key". > > Non-delegated OCSP Responses can be pre-produced (RFC 2560 section 2.5) by > the > CA without increasing the risk of compromise of the CA's private key. > Although RFC 2560 recognises that pre-produced and/or nonce-less OCSP > Responses are vulnerable to replay attacks, RFC 5019 recognises that the > "scalability issues inherent when using OCSP in large scale (high volume) > Public Key Infrastructure (PKI) environments" can mean that pre-produced > and/or nonce-less OCSP Responses are sensible and sometimes necessary. >
Yes sorry I should've qualified that statement. I was attempting to keep this simple and that always includes the risk of oversimplification. > > In the delegated model only a dedicate OCSP signing key is needed on the > > responder. > > Whilst this is obviously preferable to placing a CA private key on the > responder, I'm tempted to suggest that it's "not recommended for security > reasons". Why? Because *some implementations* use OCSP Signing certificates > that include the "id-pkix-ocsp-nocheck" extension, and RFC 2560 points out > that "CAs issuing such a certificate should realized (sic) that a compromise > of the responder's key, is as serious as the compromise of a CA key used to > sign CRLs, at least for the validity period of this certificate." > > In contrast, non-delegated pre-produced OCSP Responses require *zero* keys to > be placed on the responder, so there is never a need to worry about the > potential compromise of keys housed on the responder. > Though of course the delegated trust model can also support pre-produced OCSP responses. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
