<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap:break-word">
Rick,
<div><br>
</div>
<div>I shared this info with some other parties in the forum, but perhaps it may be helpful to a broader audience.</div>
<div><br>
</div>
<div>
<div>I know that software infrastructure can be difficult to change or upgrade, but maybe it would be helpful for you (and others) to review our open source OCSP responder and CA, named r509?</div>
<div><br>
</div>
<div>We open sourced the CA and OCSP responders that we built for ourselves and you can see info about them here:</div>
<div><a href="http://r509.org/">http://r509.org</a></div>
<div><a href="http://langui.sh/2012/11/02/building-a-ca-r509-howto/">http://langui.sh/2012/11/02/building-a-ca-r509-howto/</a></div>
<div><a href="https://github.com/reaperhulk/r509">https://github.com/reaperhulk/r509</a></div>
<div><br>
</div>
<div>Let me know if you have any questions, and again, I hope that maybe this helps a bit.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Brian Trzupek</div>
<div>VP Managed Identity and SSL</div>
<div>Trustwave</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>On May 1, 2013, at 8:16 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Symantec has been using CoreStreet, and although we're moving off of it (so we can comply with the BR) I asked them the question, in case other CAs are relying on them. Here's their answer:<br>
<br>
'The problem here is that in traditional PKI environments, CRLs only list revoked certs, and it's up to OCSP vendors to infer which certificates are good. To that end, the Validation Authority (the server backend component of our OCSP solution), can be configured
to return "good" OCSP responses to varying degrees for these inferred certificates. In the extreme case, the VA can be configured to only return "revoked" responses for certificates matching CRL entries, and "unknown" or "unauthorized" for any other certificate.
We have some customers with different preferences to help with performance and what not. The VA documentation covers these configuration settings. Please see sections 1.6.4 and 1.6.5 of the attached Admin guide.<br>
<br>
'We also have an alternative solution using a component called the Smart Data Bridge. Here, the CA explicitly notifies our OCSP solution whenever a certificate is issued, and responses for this certificate can then be explicitly generated (thus there's no
need to infer anything).'<br>
<br>
-Rick<br>
<br>
<blockquote type="cite">-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:public-<a href="mailto:bounces@cabforum.org">bounces@cabforum.org</a>]<br>
On Behalf Of <a href="mailto:Joseph.R.Kaluzny@wellsfargo.com">Joseph.R.Kaluzny@wellsfargo.com</a><br>
Sent: Wednesday, May 01, 2013 8:07 AM<br>
To: <a href="mailto:yngve@spec-work.net">yngve@spec-work.net</a>; <a href="mailto:public@cabforum.org">
public@cabforum.org</a><br>
Subject: Re: [cabfpub] Thursday's Agenda<br>
<br>
Yngve, I do agree with the idea behind the ballot so I wanted to add<br>
that we understand the reasoning and our suggestion to take another<br>
look at this is merely for compliance. In answer to your question, our<br>
vendor has no plans on their roadmap to update their product to meet<br>
this requirement at all so we would be out of compliance for the<br>
foreseeable future. Switching vendors is a possibility but will take<br>
some time and effort for a company our size. I guess I'm a bit<br>
surprised that no other members of the forum is coming across this<br>
problem.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:public-<a href="mailto:bounces@cabforum.org">bounces@cabforum.org</a>]<br>
On Behalf Of Yngve N. Pettersen<br>
Sent: Tuesday, April 30, 2013 7:17 PM<br>
To: <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] Thursday's Agenda<br>
<br>
On Tue, 30 Apr 2013 18:33:47 +0200, <<a href="mailto:Joseph.R.Kaluzny@wellsfargo.com">Joseph.R.Kaluzny@wellsfargo.com</a>><br>
wrote:<br>
<br>
<blockquote type="cite">We discussed ballot 80 in the last call regarding OCSP responders<br>
answering with "good" for non-issued certificates. I would suggest<br>
adding this to the agenda on the next call to discuss further. I<br>
contacted our vendor regarding this and they have no plans to put<br>
</blockquote>
this<br>
<blockquote type="cite">on their roadmap so we would not be able to meet this requirement by<br>
Aug. 1st, 2013.<br>
</blockquote>
<br>
Does this mean "no plans within X months", or "no plans, ever"?<br>
<br>
If it is the first, then what is X?<br>
<br>
Unfortunately, assuming the vendor is paraphrased correctly, the<br>
impression I get is that their meaning is "never". If so, there is no<br>
way that CAs using responders from this vendor (or others like it) will<br>
ever be able to get into compliance with the BR, unless they change<br>
vendors.<br>
<br>
While the 'no "good" response for non-issued' policy won't handle all<br>
types of CA compromises, it was intended to counter a very specific<br>
kind of compromise, one where the attacker deletes the log and other<br>
information about issued certificates in order to avoid detection of<br>
his activities. Exactly what happened during the DigiNotar breach (For<br>
reference, according to available information DigiNotar was apparently<br>
revoking the attackers certificates almost as soon as he got them<br>
issued, which is probably why he deleted the logs).<br>
<br>
What an extension of the August deadline means for Well Fargo (or any<br>
CA in a similar situation) is that if, hypothetically, you were<br>
compromised in the same fashion as DigiNotar, you would not even be<br>
able to take the step DigiNotar took when they finally realized how bad<br>
the situation was:<br>
Return revoked for any serial number you did not know anything about.<br>
<br>
In this situation the only option available to Wells Fargo (or any<br>
other such CA) would be to revoke the intermediate CA certificate(s)<br>
used to issue the certificate(s) and move all known issued certificates<br>
to a new CA, with all the chaos that would entail. Worst case, the<br>
entire affected Root CA would have to be revoked by the browsers (and<br>
the CA may literally have only days to avoid that fate).<br>
<br>
IMO the Vendor should treat this change at least as an important must-<br>
fix security policy modification, if not an outright security<br>
problem/vulnerability with their responder. By not acting they are<br>
disqualifying their product from a large segment of their market, the<br>
SSL/TLS certificate CA market.<br>
<br>
The questions that I think needs to be answered are:<br>
<br>
1) Does the vendor mean X months, and if so, what is X?<br>
2) Regardless of what the vendor meant, what is Wells Fargo's plans<br>
to get into compliance with the BR on this point, and how many months Y<br>
will it take.<br>
3) Is X much larger than Y?<br>
4) Is Min(X,Y) >6 months (from today)?<br>
<br>
Without any definite answer to these questions, any discussion about<br>
extending the MUST deadline for "no good response" is almost worthless,<br>
since any talk about an extension would be about how to pick a date<br>
(Keep in mind that I really wanted a much more accelerated schedule in<br>
the 3-6 month range; August was chosen to give more time for vendors to<br>
adapt and patches applied, or to change vendors, if necessary).<br>
<br>
<br>
BTW and FYI: While still a month or two off, I am planning to add<br>
functionality to my next generation TLS Prober that will check<br>
random/modified serial numbers and record the OCSP responses.<br>
<br>
--<br>
Sincerely,<br>
Yngve N. Pettersen<br>
<br>
Using Opera's mail client: <a href="http://www.opera.com/mail/">http://www.opera.com/mail/</a><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
https://cabforum.org/mailman/listinfo/public<br>
_______________________________________________<br>
Public mailing list<br>
Public@cabforum.org<br>
https://cabforum.org/mailman/listinfo/public<br>
</blockquote>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
https://cabforum.org/mailman/listinfo/public<br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
</font>
</body>
</HTML>