<br><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 4:40 AM, Peter Gutmann <span dir="ltr"><<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Phillip Hallam-Baker <<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>> writes:<br>
<br>
>2) Technical defects in OCSP: the cert is referenced by the serial number,<br>
>not the hash of the cert.<br>
<br>
</div>This won't help.  Remember how I said earlier that OCSP is multiple-redundant<br>
broken by design?  If you change the ID from the serial number to a hash then<br>
that fact that it's blacklist-based will allow attackers to evade the<br>
blacklist just as easily as with the serial-number as ID.</blockquote><div><br></div><div><br></div><div>The issue you were complaining about in that respect was due to Valicert's insistence on enabling their business model. Valicert only had CRLs to work on and did not know the database of issued certs.</div>
<div><br></div><div>The CAs I have worked with have always known the set of issued certs. It was not an issue.</div><div><br></div><div><br></div><div>What is the error response that a CA is meant to give when it receives a status request for a cert it knows was never issued?</div>
<div><br></div><div>If there isn't one we should fix OCSP in PKIX. I believe that was planned in any case. </div></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>