On 12/10/2009 13:46, Rob Stradling wrote:
On Monday 12 October 2009 12:12:22 Ian G wrote:
On 12/10/2009 12:13, Rob Stradling wrote:
<snip>
That CA clearly fell short of this requirement.
It is ... surely a thing of customer<--> CA relationship. If there are
insufficient resources, the customer experience will be crap.
Which "customer" are you referring to?
It's the relying party (i.e. a human using a browser) who are most likely to
suffer when a CA's OCSP Responder isn't working well. And that relying party
will probably either blame their browser or the operator of the website which
is experiencing the problem.
Right, in this case, the customer's customer suffers. No problem, the
customer should learn about the quality of the user experience delivered
to its customer. The market, business as usual.
I think the AMO case is likely to be the exception rather than the rule. The
operator of the website (Mozilla) was technically knowledgeable enough to
spot the source of the problem (GlobalSign's OCSP Responder).
Yeah, I'm simply commenting on the relationship to the EV guidelines.
If the market isn't working here, then there is something wrong with the
market, and creating a requirement in a dry dusty document
I'm not sure how a PDF file can gather dust. ;-)
is pretty close to the worst thing to do.
Ian, what do you think would be the best thing to do?
Well, assuming a context of the EV guidelines, it should be re-written
to strip out all business and competitive stuff. Anything that seems to
be related to the customer experience (whatever that means).
Of course this won't happen :) so there isn't a lot of point in worrying
about it for those guys [0]. But here, we should know the difference
and keep it out.
If an OCSP request takes 10 seconds, that's something the customer's
customer can grumble about, and the customer can go and get another
cert. Plain and simple.
iang
[0] of course, we know *why* it's in there, but we don't want to spoil
someone's party.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
