On Wednesday 24 March 2010 15:52:58 Konrads Smelkovs wrote: > Hi, > > This issue also spurred me to think about a patch :) I don't think OpenSSL > should write a RFC 2560 noncompliant feature, however, an option would be > to provide a warning explaining the issue better than current > "OCSP_basic_verify:root ca not trusted" and then optionally doing the extra > steps to verify up the chain.
Hi Konrads. I'm not sure, but I think I may have confused you. The patch I've written addresses a different (but related) RFC2560-compliant issue to the (non-compliant) issue you raised at the beginning of this thread. Sorry, perhaps I should have changed the "Subject:" when I slightly changed the topic. As far as your issue is concerned, I personally think that the current behaviour of "openssl ocsp" is acceptable. Steve has already mentioned that "you can explicitly trust the responder certificate with the -VAfile option or add explicit OCSP signing trust to the root". My issue is that I'm looking for "openssl ocsp" to *implicitly* trust the certificate's issuer (i.e. the RFC2560-compliant "non-delegated" model). I think I'll post my patch to the Request Tracker now, rather than hijack this thread any longer. ;-) > -- > Konrads Smelkovs > Applied IT sorcery. > > On Wed, Mar 24, 2010 at 2:38 PM, Rob Stradling <rob.stradl...@comodo.com>wrote: > > On Wednesday 24 March 2010 12:01:51 you wrote: > > <snip> > > > > > > > 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". > > > > <snip> > > > > > Yes sorry I should've qualified that statement. I was attempting to > > > keep this simple and that always includes the risk of > > > oversimplification. > > > > Steve, thanks for explaining. > > > > <snip> > > > > > Though of course the delegated trust model can also support > > > pre-produced OCSP responses. > > > > That's true. > > > > By the way Steve, I'd like to propose a small change to "openssl ocsp" to > > support the non-delegated model more seamlessly. I've always been > > surprised > > and slightly confused that you have to specify both "-issuer ca.pem" and > > "- VAfile ca.pem" to verify the signature on a non-delegated OCSP > > Response. Why doesn't "-issuer ca.pem" cause ca.pem to be treated as a > > candidate OCSP Response signer certificate? > > > > When, a couple of weeks ago, a colleague independently made the same > > observation and asked me that same question, it spurred me to write a > > patch. > > > > Would you be happy with this change in behaviour? If so, I'll submit my > > patch > > to the Request Tracker. > > > > > 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 > > Office Tel: +44.(0)1274.730505 > > Office Fax: +44.(0)1274.730909 > > www.comodo.com > > > > Comodo CA Limited, Registered in England No. 04058690 > > Registered Office: > > 3rd Floor, 26 Office Village, Exchange Quay, > > Trafford Road, Salford, Manchester M5 3EQ > > > > This e-mail and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they are > > addressed. If you have received this email in error please notify the > > sender by replying > > to the e-mail containing this attachment. Replies to this email may be > > monitored by Comodo for operational or business reasons. Whilst every > > endeavour is taken to ensure that e-mails are free from viruses, no > > liability > > can be accepted and the recipient is requested to use their own virus > > checking > > software. > > ______________________________________________________________________ > > 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 Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
