On 13/10/2009 18:23, Johnathan Nightingale wrote:
On 13-Oct-09, at 2:04 AM, Rob Stradling wrote:
An alternate approach I'd like to lobby our front-end guys on would be
to put up a scary red bar when we can't validate OCSP.
I think that your suggestion strikes a good balance between security and
useability.
Sorry I missed this thread - Canadian thanksgiving wreaks havoc on an
inbox.
This piece of this conversation sounds an awful lot like:
https://bugzilla.mozilla.org/show_bug.cgi?id=496661, and in comment 8, I
outline my own thinking on the constraints under which that kind of UI
would need to operate. I'm not sure I agree with Nelson in comment 11,
characterizing my reply as a de facto WONTFIX, but I do feel like it's a
hard line to walk. The temptation to attach UI to this problem sets off
"blame the user" alarms for me - do we think that uses will make better
decisions with this information? Like I say, I don't think we're at
WONTFIX on this question, but I don't think it's an easy problem to
solve correctly, either.
I think I agree with Nelson's comments there. If there is no revocation
info in the cert, it is a CA problem, not a browser problem. It would
be nice if the browser could invent a resolution here, but
unfortunately, the CA made a statement, and once we start
re-interpreting those statements because they upset our worldview ...
then we're likely confusing the situation.
Also, while I don't see the "blame the user" aspect quite here ... it
does seem as though a big scary warning for a failure of determining
accurate revocation info (as opposed to an actual revocation) is likely
to just lead to more click-thru syndrome.
So it still seems to point to ... patience. Not a particularly notable
skill it seems :)
As for ipsCA, I find myself agreeing with Eddy's point: that the null
bytes are a regrettable validation error that we should work with ipsCA
to ensure they fix; but NXDOMAIN on an OCSP server that appears in
issued certs is a bigger problem. I'm talking with Frank and Kathleen
about options there. I think contacting the CA and understanding their
situation is certain to be part of it. I think suspension of their trust
bits is a possible outcome, but it's premature to talk about that before
giving ipsCA a full chance to explain things. We break 6k cert holders
if we do that, which I'll support if we don't have better options, but I
don't see that we're there yet.
Do others really feel like we've exhausted other options or that
attempts to communicate with the CA are fruitless?
The question of how to deal with apparent failures with CAs / issuances
has been brought up many times, but without a conclusion or enough
forward movement. As far as I can see, it lands in your lap (where here
I mean the mozilla foundation CA desk, so Frank & Kathleen, including
you if you're close enough).
So more patience demanded of us, I'm afraid.
But to be honest, I'm not following the ipsCA issue in detail, and
probably won't until some policy question is raised.
iang
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
