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. > 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. > 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 > Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
