Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

2013-10-24 Thread Eddy Nigg

On 10/24/2013 08:01 PM, From Kathleen Wilson:
For EV certs Firefox has always checked the CRL when the OCSP AIA URI 
was not provided. EV treatment would not be given if current 
revocation information was not obtained.




If Firefox really uses the CRLDP, then I suggest to keep that option 
still open  meaning if no stapled OCSP response, use the normal 
pointers and if that fails use CRL. Remove EV (and the secure UI 
indicators if you want from any other certificate) when certificate 
status can't be verified.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

2013-10-24 Thread Michael Ströder
Kathleen Wilson wrote:
 In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI
 is not provided.

Which CRL? Where does it come from?

 Though, I believe the plan is to stop checking CRL in the
 future...
 https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
 Instead of checking explicitly for an OCSP responder URI in the AIA
 extension, let's simply remove the support for downloading CRLs from Firefox's
 EV checking. That will have the effect of enforcing that all certs in the
 chain have an OCSP AIA extension, except possibly for the end-entity
 certificate if the server stapled the end-entity OCSP response. I agree with
 the CA representatives that a missing OCSP AIA URL isn't harmful when a
 stapled OCSP response is provided. So, I am OK with allowing that exception,
 at least for now.

Anyone writing such a non-sense surely is on NSA's payroll.

Ciao, Michael.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

2013-10-24 Thread Ryan Sleevi
On Thu, October 24, 2013 2:47 pm, Michael Ströder wrote:
  Kathleen Wilson wrote:
  In the case of EV certs, Mozilla is still checking the CRL when the OCSP
  URI
  is not provided.

  Which CRL? Where does it come from?

  Though, I believe the plan is to stop checking CRL in the
  future...
  https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
  Instead of checking explicitly for an OCSP responder URI in the AIA
  extension, let's simply remove the support for downloading CRLs from
  Firefox's
  EV checking. That will have the effect of enforcing that all certs in
  the
  chain have an OCSP AIA extension, except possibly for the end-entity
  certificate if the server stapled the end-entity OCSP response. I agree
  with
  the CA representatives that a missing OCSP AIA URL isn't harmful when a
  stapled OCSP response is provided. So, I am OK with allowing that
  exception,
  at least for now.

  Anyone writing such a non-sense surely is on NSA's payroll.

  Ciao, Michael.


Yes, surely only someone insidious and evil and who hates Freedom would
ever support such an security-hostile idea as a 1-4KB OCSP response,
rather than a 50MB CRL. It's likely that the Legion of Cryptographic Doom
have compromised OCSP, likely using the World Bank to infiltrate the IETF
with members of the Secret Illuminati (which even the regular Illuminati
don't know about), and only CRLs can save us from the impending saucer
people who will break our crypto and control our minds with houseplants.

Please keep it civil, Michael, and please provide technical discussions,
rather than emotional pleas or accusations.

OCSP and CRLs both represent ways to obtain revocation information. Thus,
for EV, it's should always be possible to obtain fresh information.

CRLs and OCSP offer no security advantage unless enabled for 'hard fail',
which cannot be enabled by default, and which few users (if any) have ever
enabled. The security gains absent hard fail are illusions (... not
tricks), and so Firefox, which was not implemented hard-fail by default
and will not implement hard fail by default, it's a perfectly practical
decision.

If you would like to discuss the technical concerns behind such a thing,
might I encourage you to discuss on mozilla.dev.tech.crypto - or with the
Firefox developers - focusing on technical arguments rather than accusing
people of having some hidden agenda to harm the Internet?

Or I suppose I'm also on the NSA payroll for suggesting at this point,
you're sounding like a troll, rather than an informed user?

Cheers,
Ryan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy