[cabfpub] Thursday's Agenda

Wed May 1 16:54:11 UTC 2013

Maybe there are work-arounds.  Can you re-direct the AIA URI for your OCSP
server in your certificates to pre-generated responses?  Then, if your
system has the ability to intercept OCSP requests and respond "unknown" if
the certificate was never issued?  That way you're not relying on your
incompatible backend PKI infrastructure to provide real-time OCSP.  Also,
does your architecture only have one OCSP responder URI?  Remember, the
Baseline Requirements only apply to publicly trusted SSL.  In other words,
assuming you've built your system for two kinds of certificates (bank
customers and bank servers), then the SSL OCSP responses would be delivered
differently than your client certificate OCSP responses anyway.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Joseph.R.Kaluzny at wellsfargo.com
Sent: Wednesday, May 01, 2013 9:07 AM
To: yngve at spec-work.net; public at cabforum.org
Subject: Re: [cabfpub] Thursday's Agenda

Yngve, I do agree with the idea behind the ballot so I wanted to add that we
understand the reasoning and our suggestion to take another look at this is
merely for compliance. In answer to your question, our vendor has no plans
on their roadmap to update their product to meet this requirement at all so
we would be out of compliance for the foreseeable future. Switching vendors
is a possibility but will take some time and effort for a company our size.
I guess I'm a bit surprised that no other members of the forum is coming
across this problem.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Yngve N. Pettersen
Sent: Tuesday, April 30, 2013 7:17 PM
To: public at cabforum.org
Subject: Re: [cabfpub] Thursday's Agenda

On Tue, 30 Apr 2013 18:33:47 +0200, <Joseph.R.Kaluzny at wellsfargo.com>
wrote:

> We discussed ballot 80 in the last call regarding OCSP responders 
> answering with "good" for non-issued certificates. I would suggest 
> adding this to the agenda on the next call to discuss further. I 
> contacted our vendor regarding this and they have no plans to put this 
> on their roadmap so we would not be able to meet this requirement by 
> Aug. 1st, 2013.

Does this mean "no plans within X months", or "no plans, ever"?

If it is the first, then what is X?

Unfortunately, assuming the vendor is paraphrased correctly, the impression
I get is that their meaning is "never". If so, there is no way that CAs
using responders from this vendor (or others like it) will ever be able to
get into compliance with the BR, unless they change vendors.

While the 'no "good" response for non-issued' policy won't handle all types
of CA compromises, it was intended to counter a very specific kind of
compromise, one where the attacker deletes the log and other information
about issued certificates in order to avoid detection of his activities.
Exactly what happened during the DigiNotar breach (For reference, according
to available information DigiNotar was apparently revoking the attackers
certificates almost as soon as he got them issued, which is probably why he
deleted the logs).

What an extension of the August deadline means for Well Fargo (or any CA in
a similar situation) is that if, hypothetically, you were compromised in the
same fashion as DigiNotar, you would not even be able to take the step
DigiNotar took when they finally realized how bad the situation was:  
Return revoked for any serial number you did not know anything about.

In this situation the only option available to Wells Fargo (or any other
such CA) would be to revoke the intermediate CA certificate(s) used to issue
the certificate(s) and move all known issued certificates to a new CA, with
all the chaos that would entail. Worst case, the entire affected Root CA
would have to be revoked by the browsers (and the CA may literally have only
days to avoid that fate).

IMO the Vendor should treat this change at least as an important must-fix
security policy modification, if not an outright security
problem/vulnerability with their responder. By not acting they are
disqualifying their product from a large segment of their market, the
SSL/TLS certificate CA market.

The questions that I think needs to be answered are:

  1) Does the vendor mean X months, and if so, what is X?
  2) Regardless of what the vendor meant, what is Wells Fargo's plans to get
into compliance with the BR on this point, and how many months Y will it
take.
  3) Is X much larger than Y?
  4) Is Min(X,Y) >6 months (from today)?

Without any definite answer to these questions, any discussion about
extending the MUST deadline for "no good response" is almost worthless,
since any talk about an extension would be about how to pick a date (Keep in
mind that I really wanted a much more accelerated schedule in the 3-6 month
range; August was chosen to give more time for vendors to adapt and patches
applied, or to change vendors, if necessary).

BTW and FYI: While still a month or two off, I am planning to add
functionality to my next generation TLS Prober that will check
random/modified serial numbers and record the OCSP responses.

--
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public