FWIW I'm not a big believer in trying to communicate finely graduated
tiers of risk to end users either. Its already a battle trying to get
users to understand the difference between a clearly valid vs invalid
certificate. I use the "grandmother rule" for security dialogs... if
you can't create a user experience that would result in your
grandmother making the right decision, you're doing it wrong.
For the small percentage of (power) users that can really understand
the implications of a question like "the OCSP URL provided by this
certificate does not appear to be valid at this moment, would you like
to continue", I think they are better served by flipping the
Encryption->Validation setting to require a valid OCSP response for
certs that provide a URL. The reason here is I think this is a choice
the user should make once and its not really relevant on a per-request
basis. In the end, it seems like either you are ok with the lack of
an OCSP response or you are not?
That said, the way we now handle mixed content might be an option...
we don't provide the blue/green domain/org info bar, so the user just
gets a plain white bar (like HTTP). Maybe we could do the same thing
for a broken OCSP link?
Lucas.
On Oct 13, 2009, at 11:04 AM, Ian G wrote:
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
