Well my idea of running a CA involved lots of layers of physical protection, biometrics, uniformed guards and armies of auditors.<div><br></div><div>If I had had my way that would have been the bar that the browsers would have insisted the new entrants meet as well. Instead they decided that it would be sufficient to have an audit regardless of what the security policy was. So if your security policy was that the CEO would fly round the world with the root HSM in his handluggage, that would be OK.</div>
<div><br></div><div><br></div><div>Anyway, this is something that we need to fix regardless of what the mechanism that is in place to authenticate the keys. </div><div><div><br></div><div>An essential starting point is to partition off the issue and validation tier from the external facing Web site and then put in place controls that ensure that all messages between the two are strictly controlled and audited.</div>
<div><br></div><div><br></div><div>This is something that would be good as a general purpose device to prevent application layer compromise in other circumstances as well.</div><div><br></div><div>I am a little wary of application layer firewalls as being too big and complex for my taste. Also there is the risk that they are compromised in the supply chain.</div>
<div><br></div><div>I am looking at a smaller and cheaper solution.</div><div><br></div><div><br></div><div>What would be ideal is to have a 'default deny cable' between the external tier and the internal tier that:</div>
<div><br></div><div>1) Had measures to prevent control/data conflation attacks (i.e. code injection)</div><div><br></div><div>2) Logged every message that passed across it</div><div><br></div><div>3) Enforced one way communication of the messages (no communication in the reverse direction)</div>
<div><br></div><div>4) Enforced rate limiting controls</div><div><br></div><div>5) Had tamper evident packaging equivalent to the tamper evident requirements of FIPS 140-3 level 3 or 4.</div><div><br></div><div>6) Could be produced for less than $500 each</div>
<div><br></div><div>7) Had protection against timing attacks and power analysis should it be necessary to put a private key in the device (I suspect that this is not the case).</div><div><br></div><div>8) Had code signing/verification built into the platform.</div>
<div><br></div><div>9) Was open source for both hardware and software</div><div><br></div><div>10) Was compact enough for a code audit to be practicable</div><div><br></div><div><br></div><div>Currently something based on the Netduino looks like the best bet.</div>
<div><br></div><div>Most application layer attacks come from code/data conflation and those attacks are in turn mostly due to code injection or buffer-overrun.</div><div><br></div><div>So the role of the default deny cable is to check messages to ensure that they have the correct syntax, that none of the data fields exceeds the permitted size and that each and every command is properly guarded with a prefix and postfix nonce value and that the values match.</div>
<div><br></div><div>If the message is conformant it is logged and passed across the cable.</div><div><br></div><div>For the data volumes we are considering it would take a very long time to fill up a 2Gb log file. The log file would be emptied from time to time.</div>
<div><br></div><div>It is easy enough to set up a mechanism that ensures that the log file can only be cleared once confirmation has been received from the offsite storage location. </div><div><br></div><div><br><div class="gmail_quote">
On Thu, Sep 22, 2011 at 10:22 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>
</div><div class="im">>The CAs I have worked with have always known the set of issued certs.<br>
<br>
</div>The CAs *thought* they knew the set of issued certs. As did DigiNotar.<br>
<div class="im"><br>
>It was not an issue.<br>
<br>
</div>It wasn't an issue with DigiNotar either, until suddenly it was.<br>
<div class="im"><br>
>What is the error response that a CA is meant to give when it receives a<br>
>status request for a cert it knows was never issued?<br>
<br>
</div>According to OCSP either "not revoked" (confusingly labelled "good" in the<br>
spec) or "unknown", depending on how the implementer feels at the time.<br>
Relying parties can interpret this in any way they want, frequently as "the<br>
cert is valid" since it's not "revoked".<br>
<br>
(People were arguing over what the status values in OCSP meant long before it<br>
became an RFC, so this isn't a new issue).<br>
<div class="im"><br>
>If there isn't one we should fix OCSP in PKIX. I believe that was planned in<br>
>any case.<br>
<br>
</div>PKIX have stated on several occasions, quite definitely, that they don't want<br>
this changed and won't change it. Thus my earlier comment about finally being<br>
able to see what happens when hard reality collides with PKIX fantasy.<br>
<br>
I think your comment:<br>
<div class="im"><br>
If there isn't one we should fix OCSP in PKIX.<br>
<br>
</div>should really be phrased:<br>
<br>
If there isn't one we should fix PKIX.<br>
<br>
A reformat and reinstall would be a good start [0].<br>
<br>
Peter.<br>
<br>
[0] Actully that's probably not the best approach. At the moment PKIX serves<br>
as a convenient tarpit for a bunch of people who would be causing a<br>
tremendous amount of damage if they suddenly decided to stick their oars<br>
into other standards groups. So it does serve a useful purpose, and<br>
disbanding it would probably be a bad idea.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>