On 10/15/2009 04:38 PM, Anders Rundgren:
But I don't *insist* that OCSP validation is a bad thing I just think that
using plain-vanilla HTTP or rolling your own cer seem to be an easier
way than faking an identity for a CA.
Agreed, but this is obviously an entire different issue.
--
Regard
Eddy Nigg wrote:
>Which is obviously not correct. Most revocations happen due to loss and
>compromise of private keys, retirements, software bugs, misuse, but
>seldom due to validation failures.
I would be surprised if a single public-TTP-issued server-certificate has ever
been revoked due to lo
On 10/15/2009 03:57 PM, Ian G:
On 15/10/2009 15:21, Gervase Markham wrote:
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. Th
On 15/10/2009 15:21, Gervase Markham wrote:
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often en
On 13/10/09 22:37, Robert Relyea wrote:
It turns out that of all cases 2, 3, and 4, case 4 is the easiest
(simply overload the requested OCSP server). Also, if you can do 2, and
3, you can always do 4 (You just drop the packet on the ground). So
while an attacker may have lots of things he can do
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often enough to motivate the building of new infrast
Apropos Gerv's strawman question about trying to make OCSP soft fail
better, here is a fairly eloquent article from Bruce Schneier that might
help. I don't always agree with him, but on this article, I am in full
agreement. First and last paras only.
http://threatpost.com/blogs/difficulty-
>>
>> In summary, we have to be careful about 'doing something because it just
>> seems right'. We need to truly understand the risks, and what we are
>> getting for those risks.
>>
>
> Bob, a way to mitigate attacks on OCSP responders (DOS) can be
> mitigated to by also supporting CRLs at mul
> IMO putting OCSP or CRLs in public SSL certificates was never a
> particularly good idea because the only likely case for a revocation
> is when a CA fails to validate a customer. That has happened
> but not often enough to motivate the building of new infrastructure.
Dont forget the sale of t
On 10/13/2009 11:37 PM, Robert Relyea:
On 10/13/2009 06:54 AM, Gervase Markham wrote:
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response oth
On 10/13/2009 07:31 AM, Rob Stradling wrote:
> Gerv, have you read the current "security.OCSP.require in Firefox" thread on
> mozilla.dev.security?
>
> Daniel Veditz said yesterday...
> "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
On 10/13/2009 06:54 AM, Gervase Markham wrote:
> Firefox uses OCSP but, by default, any response other than a definite
> "is revoked" response is treated as "is not revoked". There is a user
> pref that allows the user to change that, so that any response other
> than "is not revoked" is treated as
On 10/13/2009 04:47 PM, Ian G:
My view: I would defer any "smarter" things that reduce customer
usability until (a) everyone has OCSP really well worked throughout,
end-to-end ... and (b) we see some actual evidence that suggests that
the risk of an OCSP interference is something worth worryin
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often enough to motivate the building of new infrastructure.
It seems like an easier way to jus
Not OK:
300 OCSP blocked by AV software, vendor fined $1 for each occurrence
Wes Kussmaul
Gervase Markham wrote:
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change tha
On 13/10/2009 15:54, Gervase Markham wrote:
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response other
than "is not revoked" is treated as "is revo
On 13/10/09 15:31, Rob Stradling wrote:
Gerv, have you read the current "security.OCSP.require in Firefox" thread on
mozilla.dev.security?
Er. Yes. This discussion is happening in multiple places at the moment,
and I lost track :-) Let's carry on with Dan's thread.
Gerv
--
dev-tech-crypto ma
Gerv, have you read the current "security.OCSP.require in Firefox" thread on
mozilla.dev.security?
Daniel Veditz said yesterday...
"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. Users can still
get to their sites so
On 10/13/2009 03:54 PM, Gervase Markham:
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response other
than "is not revoked" is treated as "is revok
19 matches
Mail list logo
