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

[Patrick Tate]

Netcraft published a blog post a few days ago, highlighting some of the issues with various CAs meeting the standards set (for themselves!) by the CABF Baseline Requirements:

http://news.netcraft.com/archives/2013/09/23/certificate-authorities-struggle-to-comply-with-baseline-requirements.html

Are Mozilla planning to take any action against the CAs comitting the violations?
The Symantec cert without OCSP that was issued recently *seems* corrected, but the fact that it was issued so recently shows they clearly aren't adhering.

It seems like the Cybertrust/Verizon Business roots should clearly be removed from trust stores as soon as possible - it's clear they aren't even remotely trying to adhere to the guidelines. The EV with no OCSP seems particularly egregious.
I imagine they aren't pulled from the MS root store because MS use them, but Mozilla should have no concerns here.

Are there likely to be repercussions from Mozilla?


Pat

[Kathleen Wilson]

My expectation is that CAs are complying as much as possible with the
BRs now, and are working towards full BR compliance that will be
confirmed soon via an audit statement.

When I specified my expectations regarding BR audits, I acknowledged
that some CAs may need to be granted temporary exceptions as they work
to become compliant.
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements

CAs who needed temporary extensions to the BR dates should have called
them out here:
https://wiki.mozilla.org/CA:Communications#January_2013_Responses

Many CAs stated the need for an extension regarding OCSP, so (for now) I
am OK with the OCSP issues that were noted in the Netcraft report.

According to the report, the short RSA key and missing SAN issues were
found in certificates issued by subordinate CAs. CAs are responsible for
their subordinate CAs, and need to make sure they are updating their
systems to be compliant with the BRs. Additionally, CAs need to be
working with their subCAs to either technically constrain them or have
them audited according to Mozilla policy.
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Technical_Constraints_or_Auditing.2FDisclosure_of_Intermediate_Certificates

I don't plan on taking action regarding this particular Netcraft report,
because the requirement to comply with the BRs was officially
communicated to CAs in Mozilla's program in January of this year
(https://wiki.mozilla.org/CA:Communications#January_10.2C_2013), and I
expected there to be a delay before CAs could get all of their
subordinate CAs into compliance with the BRs.

However, I applaud the Netcraft report, and I hope they will publish
another similar report in the first half of 2014. I will be very
interested in seeing the results then.

Kathleen

[Gervase Markham]

On 25/09/13 23:52, Kathleen Wilson wrote:
> My expectation is that CAs are complying as much as possible with the
> BRs now, and are working towards full BR compliance that will be
> confirmed soon via an audit statement.

Indeed. Some of what they mentioned, though, are EV violations (e.g. "
American Express [an EV certificate without an OCSP URL!]."). Do we have
a different attitude to those?

> However, I applaud the Netcraft report, and I hope they will publish
> another similar report in the first half of 2014. I will be very
> interested in seeing the results then.

I agree :-)

Gerv

[Kathleen Wilson]

On 9/26/13 5:45 AM, Gervase Markham wrote:
> Indeed. Some of what they mentioned, though, are EV violations (e.g. "
> American Express [an EV certificate without an OCSP URL!]."). Do we have
> a different attitude to those?

EV treatment is not given if OCSP isn't working.

https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements
"The server certificate must contain an Authority Information Access
(AIA) extension that carries an OCSP URI using the HTTP protocol.
Firefox must be able to complete an OCSP request and response
transaction with the given OCSP server. When an OCSP server connection
fails, Firefox treats the server certificate as invalid for EV.
....
OCSP must also work for the intermediate certificates. A failed OCSP
response will result in EV treatment not being given."


Kathleen

[Kathleen Wilson]

Ouch! Just saw
http://news.netcraft.com/archives/2013/09/26/wildcard-ev-certificates-supported-by-major-browsers.html

Looking into it, and will respond again soon.

Kathleen

[Kathleen Wilson]

Here's what I've found regarding EV treatment...

1) Currently the existence of OCSP URL in the AIA is not programatically
enforced. Firefox does enforce that there is fresh revocation
information via CRL (which the site contains) or OCSP.

https://bugzilla.mozilla.org/show_bug.cgi?id=585122
"In PSM don't provide EV when cert doesn't have AIA OCSP URI"


2) Currently Firefox does not programatically enforce the rule that EV
certificates cannot have wildcards in the alt-dns name and common name
fields.

I did not find a bug for this, so I just filed one:
https://bugzilla.mozilla.org/show_bug.cgi?id=921127
"In PSM don't provide EV treatment when cert includes wildcards in the
alt-dns name and common name fields"

Verizon sent me email saying that they have scanned their internal
databases looking for all EV certs with wildcard in the SAN, and found a
total of 5 certificates that they are promptly working to replace.
Additionally they are implementing a hot fix to add a software block of
wildcard in EV certs.


I have requested that the two bugs listed above be addressed very soon,
and will follow up on them.

Kathleen

[Rob Stradling]

On 26/09/13 19:45, Kathleen Wilson wrote:
<snip>

> Verizon sent me email saying that they have scanned their internal
> databases looking for all EV certs with wildcard in the SAN, and found a
> total of 5 certificates that they are promptly working to replace.
> Additionally they are implementing a hot fix to add a software block of
> wildcard in EV certs.

Deja vu. Cybertrust/Verizon have issued "Wildcard EV" certs before.

https://bugzilla.mozilla.org/show_bug.cgi?id=622589

Comment 5: "The offending wildcard certificate at Accenture has been
replaced and revoked"

Accenture were the customer identified in today's Netcraft report too!

Comment 4: "These issues occurred due to incorrect configuration of the
rule sets applied against certificates for these customers. The rule
sets have been modified to prevent wildcard issuance"

So, did Verizon subsequently modify the "rule sets" again to once more
allow "EV Wildcard" certs to be issued to Accenture?
If so, why?!?

Why should we believe that "a hot fix to add a software block..." will
be any more effective than "rule sets...modified to prevent wildcard
issuance"?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Brian Smith]

On Wed, Sep 25, 2013 at 11:32 AM, Patrick Tate <In...@eishundo.com> wrote:

> Netcraft published a blog post a few days ago, highlighting some of the
> issues with various CAs meeting the standards set (for themselves!) by the
> CABF Baseline Requirements:
>
>
> http://news.netcraft.com/archives/2013/09/23/certificate-authorities-struggle-to-comply-with-baseline-requirements.html
>
> Are Mozilla planning to take any action against the CAs comitting the
> violations?
>

Removing roots is a difficult thing for us to do because it hurts our users
and teaches them to click through the cert error warning they get for the
sites that don't immediately switch to another CA. I don't think we should
take this option off the table, but I personally would not spend too much
effort on beating the "root removal" drum.

When a CA doesn't conform to the baseline requirements for all their, we
*could* remove the EV indicator from all their roots. As far as I am
concerned, the EV indicator is primarily a way for CAs to make extra money
and it doesn't seem like much of a useful security feature for end-users,
so this would be a much more reasonable thing to do as it is much less
harmful to end-users but still sends a very strong message about
enforcement.

However, there is something that I think is an absolute no-brainer that we
can and should do: Use objective criteria to put CAs into three buckets:

1. CAs with Practices Notably Better than Mozilla's Minimum Requirements.
This would include CAs that implement Certificate Transparency, that do not
hold Mozilla to non-disclosure of information that is relevant to our
userbase, that issue certs where the EE OCSP response + cert chain fit
within 3 TCP packets (for performance reasons), and that do not have any
known policy violations in the last 12 months, etc.

2. CAs that have met Mozilla's Minimum Requirements for the Last 12 Months.

3. CAs that Mozilla Recommends Against Using Due to Non-conformance with
Mozilla's CA Policy.

It should be pretty straightforward for us to create a web page on
mozilla.org that contains these three sections, listing all the CAs in our
program in the bucket appropriate for them. Such a web page would likely
become a popular place on the internet and could have a substantial
business impact on CAs--especially the CAs in the first and third buckets.

It seems like the Cybertrust/Verizon Business roots should clearly be
> removed from trust stores as soon as possible - it's clear they aren't even
> remotely trying to adhere to the guidelines. The EV with no OCSP seems
> particularly egregious.
>

Cheers,
Brian

[Patrick Tate]

Brian,

"Removing roots is a difficult thing for us to do because it hurts our users"

And these repeated violations don't?

What is the point in having Mozilla require these external standards and adherence to guidelines if violations aren't punished or just brushed off?

Cybertrust/VB in particular are repeatedly and openly violating the requirements with no repercussions. Do we just wait until their next audit and see if they paid KPMG/E&Y enough to overlook the problems?

"Use objective criteria to put CAs into three buckets:"

What criteria? There already are criteria! There are public violations of them, and you suggest some other ethereal tier-ing of CAs into 'good' 'ok' and 'bad'?
You've been in politics before, am I right?


Here's a suggestion to do something if you're unwilling to do what you really should:
Make all certificates after today, issued by Cybertrust/VB, fail.
It shouldn't affect existing users.
It will make Cybertrust/VB take notice and suffer the business damage they frankly deserve for the ignoring of the set standards.
It'll act as a deterrent for other CAs.
Of course they could start back-dating certificates, but that should be detectable (expiring certs replaced with ones with past notBefore dates).

You could even pull the root on a future date - give them 60 days to warn their customers before having it removed in the next update.

Do something.

Mozilla just seem complicit in the further degradation of the already-strained CA 'trust' model.


Pat

[Jeremy Rowley]

The three packet limit starts to get tough when trying to meeting the BRs
and offer support to customers wanting 4096 bit certs that include three CT
proofs. Listing a CA in category 2 simply because they support this
ultra-configuration seems harsh when SSL3, small key sizes, and weak cipher
keys are still prominently supported.

We have publicly declared support for CT multiple times and keep our
certificate and OCPS response sizes small, but the 3 packet limit makes me
wonder how easily a CA can meet every requirement. If these requirements
diverge too much, a server will have to serve separate certs depending on
the browser being used simply to comply with the requirements! I doubt
anyone wants that.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Brian Smith
Sent: Thursday, September 26, 2013 1:21 PM
To: Patrick Tate
Cc: dev-secur...@lists.mozilla.org
Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any
consequences?

On Wed, Sep 25, 2013 at 11:32 AM, Patrick Tate <In...@eishundo.com> wrote:

> Netcraft published a blog post a few days ago, highlighting some of
> the issues with various CAs meeting the standards set (for
> themselves!) by the CABF Baseline Requirements:
>
>
> http://news.netcraft.com/archives/2013/09/23/certificate-authorities-s
> truggle-to-comply-with-baseline-requirements.html
>
> Are Mozilla planning to take any action against the CAs comitting the
> violations?
>

It seems like the Cybertrust/Verizon Business roots should clearly be
> removed from trust stores as soon as possible - it's clear they aren't
> even remotely trying to adhere to the guidelines. The EV with no OCSP
> seems particularly egregious.
>

Cheers,
Brian
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Eddy Nigg]

On 09/26/2013 10:17 PM, From Rob Stradling:

> Why should we believe that "a hot fix to add a software block..." will
> be any more effective than "rule sets...modified to prevent wildcard
> issuance"?

Doesn't every EV certificate has to be issued after review by at least
two persons (manual process)? Just sayin'...

--
Regards

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

[Brian Smith]

On Thu, Sep 26, 2013 at 12:58 PM, Patrick Tate <In...@eishundo.com> wrote:
>
> "Removing roots is a difficult thing for us to do because it hurts our users"
> And these repeated violations don't?

Please separate two ideas:

1. What I (Brian Smith) think we should do.
2. What I expect that Mozilla is willing to actually do.

I personally agree with you more than I disagree with you. I think we
should be much more careful about who we let into our root program and
we should be more eager to remove or restrict CAs. There are
definitely CAs in our program that I don't trust and that many other
people on our security teams do not trust. However, our policy is that
we let everybody in who can afford to pass an audit, regardless of how
honest/trustworthy we actually think they are, unless/until they
violate our trust in an extremely egregious and clearly-documented
manner. That is not a good place to be and I don't want us to be here.
But, we *are* here.

Netcraft's report on Verizon's non-conformance with our policy doesn't
show anything approaching the badness of trusting untrustworthy
organizations, and so I am skeptical that Mozilla would actually
remove them, given our past experience. Consequently, I encourage you
to keep pushing forward with your argument, but also I encourage you
to reconsider the merits of some things that may seem like
half-measures, because these alternative ideas are much more likely to
actually be implemented.

> What is the point in having Mozilla require these external standards and adherence
> to guidelines if violations aren't punished or just brushed off?

I agree with you 100%. I think where we disagree is on what the
enforcement mechanisms should be.

> Cybertrust/VB in particular are repeatedly and openly violating the requirements with
> no repercussions. Do we just wait until their next audit and see if they paid
> KPMG/E&Y enough to overlook the problems?

They are not the only ones and it isn't realistic to expect browsers
to remove all the CAs that are violating the baseline requirements at
this time, regardless of whether we "should." The advantage of
Certificate Transparency, the EFF SSL Observatory, and other surveys,
is that we will be able to clearly understand the extent of this
problem.

> You've been in politics before, am I right?

My political skills within Mozilla are somewhat infamous, based on the
gossip that gets back to me. And, keep in mind that Mozilla is, at its
heart, a political organization.

> Here's a suggestion to do something if you're unwilling to do what you really should:
> Make all certificates after today, issued by Cybertrust/VB, fail.

Comodo actually mis-issued certificates and we didn't do this to them.
TrustWave and TurkTrust egregiously violated our trust by giving away
MitM certs and we did nothing to them. CNNIC is part of an
organization that regularly and openly MitMs and censors an entire
country. And, it seems likely that CNNIC isn't the only trusted root
CA that is associated with human rights abuses. It isn't rationale to
expect us to do something worse for Verizon than we did for those CAs.

> Do something.

Again, the thing to realize that you are effectively advocating for
inaction because the step you are advocating for is one we are almost
guaranteed to never take, given the current circumstances.

> Mozilla just seem complicit in the further degradation of the already-strained CA 'trust' model.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Brian Smith]

On Thu, Sep 26, 2013 at 1:15 PM, Jeremy Rowley
<jeremy...@digicert.com> wrote:
> The three packet limit starts to get tough when trying to meeting the BRs
> and offer support to customers wanting 4096 bit certs that include three CT
> proofs. Listing a CA in category 2 simply because they support this
> ultra-configuration seems harsh when SSL3, small key sizes, and weak cipher
> keys are still prominently supported.

I understand what you are saying. I would like to talk to CAs about
this in a different thread. I have some ideas about how to mitigate
this and also how to better-define the goal. For example, if you told
me that all your cert chains + EE OCSP response were less than 3
packets as long as the keys were 2048 bits and only when the OCSP
response is "good", then I think we should consider that a big win.
For us (Mozilla's networking team) this is a big issue and I would
like to try to resolve it for as many of the common cases as possible,
without discouraging CT and without discouraging larger key sizes for
customers that want them.

> We have publicly declared support for CT multiple times and keep our
> certificate and OCPS response sizes small, but the 3 packet limit makes me
> wonder how easily a CA can meet every requirement.

The criteria I listed in my email are not set in stone. The main point
I want to make is that I think that we can use the mozilla.org website
to guide certificate purchasers towards CAs that are doing good things
and away from CAs that aren't.

> If these requirements
> diverge too much, a server will have to serve separate certs depending on
> the browser being used simply to comply with the requirements! I doubt
> anyone wants that.

I don't want to create a situation where we are discouraging CAs from
CT, even before Mozilla enforces it in Firefox (if we ever do), if
that's what you mean. In general, browser CA programs should have
requirements that compose well with each other.

The main place I see a potential need for something like what you are
afraid of would be multi-tenant certificates. I could see us getting
to a place where we (Mozilla) ask CAs to issue multi-tenant
certificates (such as my briansmith.org cert that I share with several
unrelated people/organizations) off of intermediates that are
actively-distrusted in Firefox. The idea would be that the website
would only use the multi-tenant certificates when SNI is not supported
and would use single-tenant certificates when SNI is supported. Soon
we should be able to guarantee that Firefox sends the SNI header in a
consistent enough fashion that such a policy change would become
reasonable.

Cheers,
Brian

>
> Jeremy
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
> .org] On Behalf Of Brian Smith
> Sent: Thursday, September 26, 2013 1:21 PM
> To: Patrick Tate
> Cc: dev-secur...@lists.mozilla.org
> Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any
> consequences?
>
> On Wed, Sep 25, 2013 at 11:32 AM, Patrick Tate <In...@eishundo.com> wrote:
>

>> Netcraft published a blog post a few days ago, highlighting some of
>> the issues with various CAs meeting the standards set (for
>> themselves!) by the CABF Baseline Requirements:
>>
>>
>> http://news.netcraft.com/archives/2013/09/23/certificate-authorities-s
>> truggle-to-comply-with-baseline-requirements.html
>>
>> Are Mozilla planning to take any action against the CAs comitting the
>> violations?
>>
>

> Removing roots is a difficult thing for us to do because it hurts our users

> It seems like the Cybertrust/Verizon Business roots should clearly be
>> removed from trust stores as soon as possible - it's clear they aren't
>> even remotely trying to adhere to the guidelines. The EV with no OCSP
>> seems particularly egregious.
>>
>

> Cheers,
> Brian
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[David E. Ross]

On 9/26/13 1:32 PM, Brian Smith wrote [in part]:

>
> Comodo actually mis-issued certificates and we didn't do this to them.
> TrustWave and TurkTrust egregiously violated our trust by giving away
> MitM certs and we did nothing to them. CNNIC is part of an
> organization that regularly and openly MitMs and censors an entire
> country. And, it seems likely that CNNIC isn't the only trusted root
> CA that is associated with human rights abuses. It isn't rationale to
> expect us to do something worse for Verizon than we did for those CAs.

Here is a process that can be implemented NOW, without waiting for the
next updates:

1. Create a new Web page under
<http://www.mozilla.org/projects/security/certs/> explaining in
user-oriented terms how to distrust a root certificate and how to
restore trust. Include instructions on how to trust an individual Web
site where the related root certificate is distrusted with a warning
about what this really means.

2. Add a link to that new Web page in
<https://wiki.mozilla.org/CA:Overview>.

3. Publicize root certificates that are non-compliant in this
newsgroup, cross-posted to mozilla.general and mozilla.announce. In the
message, include the link from #1 and say that users might consider
distrusting such certificates.

By the way, roots that are distrusted in my own installation are:
* CNNIC (all roots)
* Cybertrust Global Root
* SecureTrust Corporation
* Sonera (all roots)
* TÜRKTRUST Bilgi ?leti?im ve Bili?im Güvenli?i Hizmetleri A.?. (c)
Kas?m 2005
* (c) 2005 TÜRKTRUST Bilgi ?leti?im ve Bili?im Güvenli?i Hizmetleri A.?.

--
David E. Ross
<http://www.rossde.com/>

Where does your elected official stand? Which
politicians refuse to tell us where they stand?
See the non-partisan Project Vote Smart at
<http://votesmart.org/>.

[Kathleen Wilson]

On 9/26/13 3:19 PM, David E. Ross wrote:
> On 9/26/13 1:32 PM, Brian Smith wrote [in part]:
>>
>> Comodo actually mis-issued certificates and we didn't do this to them.
>> TrustWave and TurkTrust egregiously violated our trust by giving away
>> MitM certs and we did nothing to them. CNNIC is part of an
>> organization that regularly and openly MitMs and censors an entire
>> country. And, it seems likely that CNNIC isn't the only trusted root
>> CA that is associated with human rights abuses. It isn't rationale to
>> expect us to do something worse for Verizon than we did for those CAs.
>
> Here is a process that can be implemented NOW, without waiting for the
> next updates:
>
> 1. Create a new Web page under
> <http://www.mozilla.org/projects/security/certs/> explaining in
> user-oriented terms how to distrust a root certificate and how to
> restore trust.

https://wiki.mozilla.org/CA:UserCertDB

> Include instructions on how to trust an individual Web
> site where the related root certificate is distrusted with a warning
> about what this really means.

Do you mean the information that is here?
https://support.mozilla.org/en-US/kb/connection-untrusted-error-message

Or here?
https://support.mozilla.org/en-US/questions/754739

>
> 2. Add a link to that new Web page in
> <https://wiki.mozilla.org/CA:Overview>.

https://wiki.mozilla.org/CA:Overview#Policy_and_Included_CAs
Second main bullet:
- User Root Certificate Settings -- How to override the default root
settings in Mozilla products.

"User Root Certificate Settings" is a link to the above UserCertDB wiki
page.

[David E. Ross]

On 9/27/13 3:11 PM, Kathleen Wilson wrote:
> On 9/26/13 3:19 PM, David E. Ross wrote:
>> On 9/26/13 1:32 PM, Brian Smith wrote [in part]:
>>>
>>> Comodo actually mis-issued certificates and we didn't do this to them.
>>> TrustWave and TurkTrust egregiously violated our trust by giving away
>>> MitM certs and we did nothing to them. CNNIC is part of an
>>> organization that regularly and openly MitMs and censors an entire
>>> country. And, it seems likely that CNNIC isn't the only trusted root
>>> CA that is associated with human rights abuses. It isn't rationale to
>>> expect us to do something worse for Verizon than we did for those CAs.
>>
>> Here is a process that can be implemented NOW, without waiting for the
>> next updates:
>>
>> 1. Create a new Web page under
>> <http://www.mozilla.org/projects/security/certs/> explaining in
>> user-oriented terms how to distrust a root certificate and how to
>> restore trust.
>
>
> https://wiki.mozilla.org/CA:UserCertDB
>
>
>> Include instructions on how to trust an individual Web
>> site where the related root certificate is distrusted with a warning
>> about what this really means.

The warning needs to be on the same page as the procedure for trusting a
Web site.

>
> Do you mean the information that is here?
> https://support.mozilla.org/en-US/kb/connection-untrusted-error-message

A link to this page needs to be added to the "CA:UserCertDB" page.


> Or here?
> https://support.mozilla.org/en-US/questions/754739

The information here is quite old and needs updating.

>>
>> 2. Add a link to that new Web page in
>> <https://wiki.mozilla.org/CA:Overview>.
>
> https://wiki.mozilla.org/CA:Overview#Policy_and_Included_CAs
> Second main bullet:
> - User Root Certificate Settings -- How to override the default root
> settings in Mozilla products.
>
> "User Root Certificate Settings" is a link to the above UserCertDB wiki
> page.

The link to "User Root Certificate Settings" at <User Root Certificate
Settings> does not really belong under the heading "Policy and Included
CAs". It should stand out better, perhaps with its own heading.

>>
>> 3. Publicize root certificates that are non-compliant in this
>> newsgroup, cross-posted to mozilla.general and mozilla.announce. In the
>> message, include the link from #1 and say that users might consider
>> distrusting such certificates.
>>
>> By the way, roots that are distrusted in my own installation are:
>> * CNNIC (all roots)
>> * Cybertrust Global Root
>> * SecureTrust Corporation
>> * Sonera (all roots)
>> * TÜRKTRUST Bilgi ?leti?im ve Bili?im Güvenli?i Hizmetleri A.?. (c)
>> Kas?m 2005
>> * (c) 2005 TÜRKTRUST Bilgi ?leti?im ve Bili?im Güvenli?i Hizmetleri A.?.
>>
>

[Gervase Markham]

On 26/09/13 21:15, Jeremy Rowley wrote:
> If these requirements
> diverge too much, a server will have to serve separate certs depending on
> the browser being used simply to comply with the requirements! I doubt
> anyone wants that.

Not for this reason perhaps, but I strongly suspect this day is coming,
if only to support clients which still require 1024-bit certs (which,
after the deadline, will need to be issued off roots no longer trusted
in root programs).

Gerv

[Gervase Markham]

On 26/09/13 21:15, Jeremy Rowley wrote:

> If these requirements
> diverge too much, a server will have to serve separate certs depending on
> the browser being used simply to comply with the requirements! I doubt
> anyone wants that.

[Gervase Markham]

On 26/09/13 21:15, Jeremy Rowley wrote:

> If these requirements
> diverge too much, a server will have to serve separate certs depending on
> the browser being used simply to comply with the requirements! I doubt
> anyone wants that.

[Kathleen Wilson]

>>
>> Do you mean the information that is here?
>> https://support.mozilla.org/en-US/kb/connection-untrusted-error-message
>
> A link to this page needs to be added to the "CA:UserCertDB" page.

Done.
https://wiki.mozilla.org/CA:UserCertDB#Untrusted_Connection_Error_Messages

>>> 2. Add a link to that new Web page in
>>> <https://wiki.mozilla.org/CA:Overview>.
>>
>> https://wiki.mozilla.org/CA:Overview#Policy_and_Included_CAs
>> Second main bullet:
>> - User Root Certificate Settings -- How to override the default root
>> settings in Mozilla products.
>>
>> "User Root Certificate Settings" is a link to the above UserCertDB wiki
>> page.
>
> The link to "User Root Certificate Settings" at <User Root Certificate
> Settings> does not really belong under the heading "Policy and Included
> CAs". It should stand out better, perhaps with its own heading.
>

Done.
https://wiki.mozilla.org/CA:Overview#Override_Default_Root_Certificate_Settings


Thanks,
Kathleen

[Phillip Hallam-Baker]

As a general matter, isn't the purpose of putting the BR requirements
together and having a compliance date to enable browsers to start enforcing
these checks?

So while it is fun for us CAs to point out where our competitors have
mucked things up, this is a problem that is going to very quickly sort
itself out once those restrictions go live.

[Kaspar Brand]

On 26.09.2013 20:45, Kathleen Wilson wrote:
> Verizon sent me email saying that they have scanned their internal
> databases looking for all EV certs with wildcard in the SAN, and found a
> total of 5 certificates that they are promptly working to replace.
> Additionally they are implementing a hot fix to add a software block of
> wildcard in EV certs.

"promptly"... what's their definition of that term? From the Baseline
Requirements v1.1.6 ("effective 29 July, 2013"):

> 13.1.5 Reasons for Revoking a Subscriber Certificate
> The CA SHALL revoke a Certificate within 24 hours if one or more
> of the following occurs:
> [...]
> 9. The CA is made aware that the Certificate was not issued in accordance
> with these Requirements or the CA’s Certificate Policy or Certification
> Practice Statement;

"SHALL", "within 24 hours"... IOW, it's not really at their discretion
to define "promptly". So, let's have a look:

> $ openssl s_client -connect iag-moodle.cclearning.accenture.com:443 </dev/null |
> openssl x509 -noout -text -dates -serial |
> grep [=*]
> depth=3 C = US, O = GTE Corporation, OU = "GTE CyberTrust Solutions, Inc.", CN = GTE CyberTrust Global Root
> verify error:num=19:self signed certificate in certificate chain
> verify return:0
> DONE
> Issuer: O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
> Subject: C=US, ST=IL, L=Chicago/street=161 N Clark St/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=IL, O=Accenture LLP/businessCategory=V1.0, Clause 5.(b)/serialNumber=00622, CN=cclearning.accenture.com
> DNS:cclearning.accenture.com, DNS:*.cclearning.accenture.com
> notBefore=Jan 24 02:03:42 2013 GMT
> notAfter=Jan 24 02:03:42 2015 GMT
> serial=0200000000013C6A43C967C4CCC5

(Note that the subject DN still uses "V1.0, Clause..." business
categories which have been disallowed by the EV Guidelines V1.2 with an
effective date of 20 October, 2010. Note the notBefore date in the above
certificate, though.)

And next:

> $ curl -s http://crl.omniroot.com/SureServerEV.crl |
> openssl crl -inform der -noout -text |
> grep -EA2 "Issuer|CRL Number|0200000000013C6A43C967C4CCC5"
> Issuer: /O=Cybertrust Inc/CN=Cybertrust SureServer EV CA
> Last Update: Oct 2 01:29:08 2013 GMT
> Next Update: Oct 6 01:29:08 2013 GMT
> --
> X509v3 CRL Number:
> 9692
> Revoked Certificates:

(...CCC5 is the serial for the cert in question, see above)

Doesn't that call for more a rigorous action from the browser vendors
(given that Verizon is apparently no longer a CABF member, so the stick
of cancelling their membership is already ineffective)?

Kaspar

[Kaspar Brand]

My question to the browser vendors, in particular Mozilla, is still
unanswered:

> Doesn't that call for more a rigorous action from the browser vendors
> (given that Verizon is apparently no longer a CABF member, so the
> stick of cancelling their membership is already ineffective)?

As demonstrated by the cclearning.accenture.com case, Verizon does its
own "risk assessment", decides to not follow the BR, Mozilla (Corp.)
remains silent... and then everyone goes back to regular schedule? I
don't think that's an appropriate way of dealing with this issue.

Meanwhile I had another look at Verizon's EV SSL machinery. Since its
inception, the EV Guidelines have very clearly stated:

"CAs MUST support an OCSP capability for Subscriber Certificates that
are issued after Dec 31, 2010."

(Draft 11 from 20 October 2006 already had it, in version 1.4 it
disappeared due to the BR being incorporated by reference)

And
http://www.verizonenterprise.com/us/products/security/identity/ssl/evssl.xml
at least states:

"We support and use Version 1.3 of the Extended Validation
Certificate Guidelines developed by the CA/Browser Forum"

They refer to an older version of the EV Guidelines on their Web site,
but their CP/CPS
(http://cybertrust.omniroot.com/repository/Cybertrust_CPS_v_5_4.pdf) on
the other hand is fine when saying:

"SureServer EV issuance and management practices comply with the
current version of the said Guidelines."

Ok, then in 2013 there must sure[server]ly be an OCSP responder for
these EV thingies, right? Just an unfortunate glitch that they forgot to
include the respective URI in the cert... but nobody is perfect. Let's
see if we can figure out ourselves where that responder lives:

> $ openssl s_client -connect ev.omniroot.com:443 </dev/null 2>&0 | openssl x509 -noout -text | grep http > URI:http://crl.omniroot.com/SureServerEV.crl
> CPS: http://cybertrust.omniroot.com/repository

Ah, must be ocsp.omniroot.com, most likely. Let's try:

> $ host ocsp.omniroot.com
> ocsp.omniroot.com is an alias for evocsp.us.omniroot.com.
> evocsp.us.omniroot.com has address 64.18.17.38

Great! Apparently they operate a responder in the US. Let's try to ask
it for the status of the "ev.omniroot.com" cert, then:

> $ curl -siH Accept: http://ocsp.omniroot.com/ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en%2F2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAAAAAATOE8KOLdzwV
> HTTP/1.1 404 Not Found
> Date: Sun, 06 Oct 2013 14:13:55 GMT
> Server: Apache/2.2.15 (CentOS)
> Content-Length: 389
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>404 Not Found</title>
> </head><body>
> <h1>Not Found</h1>
> <p>The requested URL /ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en/2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAAAAAATOE8KOLdzwV was not found on this server.
> </p>
> <hr>
> <address>Apache/2.2.15 (CentOS) Server at ocsp.omniroot.com Port 80</address>
> </body></html>

Ouch. Hmm, apparently no GET support here yet - wasn't there a section
about this somewhere in the BR... (13.2.2)? Well, anyway, let's be nice
and try again, this time with POST:

> $ echo ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en/2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAAAAAATOE8KOLdzwV | openssl base64 -d -A | curl -iH "Content-Type: application/ocsp-request" -H Accept: --data-binary @- http://ocsp.omniroot.com
> HTTP/1.1 200 OK
> Date: Sun, 06 Oct 2013 14:14:04 GMT
> Server: Apache/2.2.15 (CentOS)
> Last-Modified: Mon, 18 Feb 2013 16:54:02 GMT
> ETag: "20117-7-4d6029275fa0f"
> Accept-Ranges: bytes
> Content-Length: 7
> Connection: close
> Content-Type: text/html; charset=UTF-8
>
> server

Wow, fantastic! It's telling us that it is a *server* (not some toy, in
case you were wondering). And of course text/html is perfectly matching
for a request of type application/ocsp-request, isn't it?

Going back to the first message in this thread and the Netcraft blog
entry, what is really egregious is not so much the fact that Netcraft
found "an EV certificate without an OCSP URL!" for
enroll.americanexpress.com - the point is that Verizon does not provide
a working OCSP responder for their EV certs *at all*... even though the
EV Guidelines made a responder mandatory as of January 1, 2011 (see above).

I fail to see a reason why Mozilla's next action should not consist of
reverting the Cybertrust-related changes committed with
https://bugzilla.mozilla.org/show_bug.cgi?id=493709, and only re-enable
Verizon for EV after they have completed a new full WebTrust EV audit.

Kaspar


P.S. Apart from the non-compliant businessCategory attributes mentioned
before, the issuer DN for the Verizon EV SSL CA also does not meet the
requirement from BR section 9.1.4: there's no countryName RDN (it's just
"O=Cybertrust Inc, CN=Cybertrust SureServer EV CA").

[Brian Smith]

On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand <dsp...@velox.ch> wrote:
> My question to the browser vendors, in particular Mozilla, is still
> unanswered:
>
>> Doesn't that call for more a rigorous action from the browser vendors
>> (given that Verizon is apparently no longer a CABF member, so the
>> stick of cancelling their membership is already ineffective)?

> As demonstrated by the cclearning.accenture.com case, Verizon does its
> own "risk assessment", decides to not follow the BR, Mozilla (Corp.)
> remains silent... and then everyone goes back to regular schedule? I
> don't think that's an appropriate way of dealing with this issue.

Hi Kasper,

I don't think there is much of a threat to our users from that
certificate. Also, please read Section 14.2.2 ("Enterprise RAs") of
the baseline requirements. Given that the EV requirements allow this
"Enterprise RA" practice and given that the *.cclearning.accenture.com
wildcard cert was at least "3rd level" it seems like a no harm / no
foul situation.

Given that we have Safe Browsing, and given that browsers highlight
the eTLD+1 in the address bar to reduce the effectiveness of spoofing
using subdomains (e.g. paypal.services.com), and given that the
subject name of the cert is shown in the address bar for EV certs,
perhaps it isn't so bad to even change the EV requirements to allow
wildcard EV certs when the the eTLD+1 wouldn't result in confusion.
And, conversely, perhaps we should tighten the baseline requirements
to prevent the issuance of ANY kind of confusing wildcard certs. For
example, *.services.com or *.banking.com seems bad no matter whether
it is EV or not. Conversely, *.cclearning.accenture.com seems mostly
benign to me.

> "CAs MUST support an OCSP capability for Subscriber Certificates that
> are issued after Dec 31, 2010."

In the abstract, I support the removal of the EV indicator for certs
from CAs that don't meet our requirements for OCSP, including the
requirement that OCSP responders must return a signed "unknown" or
signed "revoked" response for unknown certificates, and including the
requirement that there must be an OCSP responder URI in the end-entity
certificate. I think it would be unreasonable for us to enforce the
requirement for "GET" at this time considering Firefox doesn't even
try "GET" yet, but that would eventually happen too.

It would be great if a volunteer in this community could identify
which certificates in our EV program would be affected by such a
change, along with reproducable evidence of non-conformance. I think
that would educate us as to the extent of the change we would be
considering.

Do you think we should remove the EV indicator for *all* certificates
that a CA issued, even if some/most of them included a link to a
correctly-functioning OCSP responder? Or, is it reasonable to just not
show the EV indicator when we are unable to obtain an OCSP response
for a particular certificate in question? We already have somebody
working on implementing the latter in bug 585122 [1]. If you that we
should remove the EV indicator from all of a CA's EV certificates if
*any* of them are missing OCSP functionality, then should the
privilege of getting the "EV indicator" also be contingent on non-EV
certs by that CA also meeting the requirement (which is now a baseline
requirement, not just EV)?

I would like us to change our EV requirements so that a CA's entire
operation must be conformant to our policy (including the baseline
requirements, and including any externally-operated intermediates)
before we consider them to qualify for the EV privilege--i.e. we
should only give the EV-certificate-issuing privilege to our best
partners.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=585122

[Brian Smith]

On Sun, Oct 6, 2013 at 11:52 AM, Brian Smith <br...@briansmith.org> wrote:
> On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand <dsp...@velox.ch> wrote:

> Hi Kasper,

Sorry about the misspelling, Kaspar.

Cheers,
Brain

[Kaspar Brand]

On 06.10.2013 20:52, Brian Smith wrote:
> I don't think there is much of a threat to our users from that
> certificate.

Not going to comment on this further. The point is BR compliance and
enforcement of Mozilla's CA Certificate Maintenance Policy, not
individual case-by-case risk management.

>> "CAs MUST support an OCSP capability for Subscriber Certificates that
>> are issued after Dec 31, 2010."
>
> In the abstract, I support the removal of the EV indicator for certs
> from CAs that don't meet our requirements for OCSP, including the
> requirement that OCSP responders must return a signed "unknown" or
> signed "revoked" response for unknown certificates,

Fine. So in the case of Verizon, why does Mozilla not proceed with
removing their EV enablement? Their EV issuing CA has been non-compliant
for 2 years, 9 months, and 8 days by now. No wiggle room for any
discussion about effective dates etc., they undisputably failed to
implement a mandatory component of their revocation infrastructure (and
were certainly aware of this requirement in 2009, see
https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ).

> and including the requirement that there must be an OCSP responder
> URI in the end-entity certificate.

That's not mandated by either the EV Guidelines or the BR. Stapling is
another viable option, so obviously the fix for bug 585122 needs to be
smarter than to just checking for a URI (or drop CRL support).

> It would be great if a volunteer in this community could identify
> which certificates in our EV program would be affected by such a
> change, along with reproducable evidence of non-conformance. I think
> that would educate us as to the extent of the change we would be
> considering.

Ok, so volunteers step forward, please... if Mozilla's reaction will
mostly consist of "applauding" such work and making statements like
"(for now) I am OK with the OCSP issues that were noted", it seems that
there's relatively little incentive for undertaking such work.

Kaspar

[Chema Lopez]

I utterly agree with Kaspar.

There are CA's waiting to enable the EV check due to they did not support
GET OCSP (could anyone explain what justifies this requirement?) since
there are other CSP's "enjoying" its EV check without fulfilling the EV
Reqs.

On Sun, Oct 6, 2013 at 8:52 PM, Brian Smith <br...@briansmith.org> wrote:

> On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand <dsp...@velox.ch> wrote:

> > My question to the browser vendors, in particular Mozilla, is still
> > unanswered:
> >
> >> Doesn't that call for more a rigorous action from the browser vendors
> >> (given that Verizon is apparently no longer a CABF member, so the
> >> stick of cancelling their membership is already ineffective)?
>
> > As demonstrated by the cclearning.accenture.com case, Verizon does its
> > own "risk assessment", decides to not follow the BR, Mozilla (Corp.)
> > remains silent... and then everyone goes back to regular schedule? I
> > don't think that's an appropriate way of dealing with this issue.
>
> Hi Kasper,
>

> I don't think there is much of a threat to our users from that

> certificate. Also, please read Section 14.2.2 ("Enterprise RAs") of
> the baseline requirements. Given that the EV requirements allow this
> "Enterprise RA" practice and given that the *.cclearning.accenture.com
> wildcard cert was at least "3rd level" it seems like a no harm / no
> foul situation.
>
> Given that we have Safe Browsing, and given that browsers highlight
> the eTLD+1 in the address bar to reduce the effectiveness of spoofing
> using subdomains (e.g. paypal.services.com), and given that the
> subject name of the cert is shown in the address bar for EV certs,
> perhaps it isn't so bad to even change the EV requirements to allow
> wildcard EV certs when the the eTLD+1 wouldn't result in confusion.
> And, conversely, perhaps we should tighten the baseline requirements
> to prevent the issuance of ANY kind of confusing wildcard certs. For
> example, *.services.com or *.banking.com seems bad no matter whether
> it is EV or not. Conversely, *.cclearning.accenture.com seems mostly
> benign to me.
>

> > "CAs MUST support an OCSP capability for Subscriber Certificates that
> > are issued after Dec 31, 2010."
>
> In the abstract, I support the removal of the EV indicator for certs
> from CAs that don't meet our requirements for OCSP, including the
> requirement that OCSP responders must return a signed "unknown" or

> signed "revoked" response for unknown certificates, and including the

> requirement that there must be an OCSP responder URI in the end-entity

> certificate. I think it would be unreasonable for us to enforce the
> requirement for "GET" at this time considering Firefox doesn't even
> try "GET" yet, but that would eventually happen too.
>

> It would be great if a volunteer in this community could identify
> which certificates in our EV program would be affected by such a
> change, along with reproducable evidence of non-conformance. I think
> that would educate us as to the extent of the change we would be
> considering.
>

> Do you think we should remove the EV indicator for *all* certificates
> that a CA issued, even if some/most of them included a link to a
> correctly-functioning OCSP responder? Or, is it reasonable to just not
> show the EV indicator when we are unable to obtain an OCSP response
> for a particular certificate in question? We already have somebody
> working on implementing the latter in bug 585122 [1]. If you that we
> should remove the EV indicator from all of a CA's EV certificates if
> *any* of them are missing OCSP functionality, then should the
> privilege of getting the "EV indicator" also be contingent on non-EV
> certs by that CA also meeting the requirement (which is now a baseline
> requirement, not just EV)?
>
> I would like us to change our EV requirements so that a CA's entire
> operation must be conformant to our policy (including the baseline
> requirements, and including any externally-operated intermediates)
> before we consider them to qualify for the EV privilege--i.e. we
> should only give the EV-certificate-issuing privilege to our best
> partners.
>
> Cheers,
> Brian
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=585122
>
> Cheers,
> Brian
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--

m...@chemalogo.com

gplus.to/chemalogo

+34 666 429 224 (Spain)

@chemalogo <https://twitter.com/chemalogo>

www.linkedin.com/in/chemalogo

chemalogo

[Kaspar Brand]

On 08.10.2013 07:16, Kaspar Brand wrote:
> On 06.10.2013 20:52, Brian Smith wrote:

>> In the abstract, I support the removal of the EV indicator for certs
>> from CAs that don't meet our requirements for OCSP, including the
>> requirement that OCSP responders must return a signed "unknown" or
>> signed "revoked" response for unknown certificates,
>

> Fine. So in the case of Verizon, why does Mozilla not proceed with
> removing their EV enablement? Their EV issuing CA has been non-compliant
> for 2 years, 9 months, and 8 days by now. No wiggle room for any
> discussion about effective dates etc., they undisputably failed to
> implement a mandatory component of their revocation infrastructure (and
> were certainly aware of this requirement in 2009, see
> https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ).

Another 10 days have passed without any apparent sign of Mozilla's
willingness to address the case of the non-existence of an OCSP
responder for the Cybertrust SureServer EV CA.

Let me quote again from the Mozilla CA Certificate Policy:

CA Certificate Enforcement Policy, Version 2.2, item 2:
> Mozilla may, at its sole discretion, disable (partially or fully) or
> remove a certificate at any time and for any reason. Mozilla will
> disable or remove a certificate if the CA demonstrates ongoing or
> egregious practices that do not maintain the level of service that
> was established in the Inclusion Section of the Mozilla CA
> Certificate Policy or that do not comply with the requirements of the
> Maintenance Section of the Mozilla CA Certificate Policy.

CA Certificate Inclusion Policy, Version 2.2, item 19:
> We have appointed a CA certificate "module owner" and (optionally)
> one or more "peers" to evaluate CA requests on our behalf and make
> decisions regarding all matters relating to CA certificates included
> in our products. CAs or others objecting to a particular decision may
> appeal to the Mozilla governance module owner or peer(s), who will
> make a final decision.

Will Mozilla at least make its decision re: keeping the EV enablement
for Verizon public? Otherwise, the CA Certificate Policy is definitely
becoming nothing but a farce (cf. e.g. item 2 of the Inclusion Policy,
"a public process, based on objective and verifiable criteria"), and the
Enforcement Policy in particular will remain a paper tiger in all eternity.

Kaspar

[Michael Ströder]

Kaspar Brand wrote:
> Another 10 days have passed without any apparent sign of Mozilla's
> willingness to address the case of the non-existence of an OCSP
> responder for the Cybertrust SureServer EV CA.

And since CRL support was dropped in recent Firefox/Seamonkey releases there's
no revocation checking mechanism for those certs at all.

> Otherwise, the CA Certificate Policy is definitely
> becoming nothing but a farce (cf. e.g. item 2 of the Inclusion Policy,
> "a public process, based on objective and verifiable criteria"), and the
> Enforcement Policy in particular will remain a paper tiger in all eternity.

Is that news to you?

The policy discussions here are just security theater - since years...

Ciao, Michael.

[Kathleen Wilson]

>> Another 10 days have passed without any apparent sign of Mozilla's
>> willingness to address the case of the non-existence of an OCSP
>> responder for the Cybertrust SureServer EV CA.

Here is my opinion on this topic.

I don't believe there was an additional security risk caused by Verizon
not having the OCSP URI in their EV certificates, because Firefox will
not give EV treatment if there is no fresh revocation information via
CRL or OCSP.

Verizon had been asking for OCSP stapling before being required to
include the OCSP URI in the certs. Now that we have OCSP stapling
implemented in Firefox 25, I think we should allow Verizon some time to
move their customers from CRL to OCSP.

I don't think it actually helps anyone to remove Verizon's EV treatment
at this point in time. Many folks are of the opinion that EV treatment
should be removed for a few months as some sort of punishment, but I'm
not convinced that is actually necessary, because I think the negative
PR that Verizon got is sufficient at this time.

>
> And since CRL support was dropped in recent Firefox/Seamonkey
> releases there's
> no revocation checking mechanism for those certs at all.
>

That's not technically accurate for EV certificates. The user interface
to manually import CRLs was dropped, but CRLs are still being checked.
Currently for EV certs, if the OCSP URI is not present, then the CRL is
checked. EV treatment will not be given if current revocation status is
not successfully retrieved.

>
>> Their EV issuing CA has been non-compliant
>> for 2 years, 9 months, and 8 days by now. No wiggle room for any
>> discussion about effective dates etc., they undisputably failed to
>> implement a mandatory component of their revocation infrastructure
>> (and were certainly aware of this requirement in 2009, see
>>
https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ)
>

In that post Steven also made his plea for OCSP stapling: "We left that
meeting with a hope that ... we'd wait for TLS stapling of OCSP
responses to emerge before mandating OCSP for UI indication of an
Extended Validation process.

OCSP stapling has only just recently become available:
https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Stapling
"Release: Firefox 25"

>
>> So in the case of Verizon, why does Mozilla not proceed with
>> removing their EV enablement?

As I mentioned previously, I don't believe the lack of OCSP URI in those
EV certificates was causing security risk to end users. Now that OCSP
stapling is available, I think we should give Verizon a little bit of
time to move their customers to OCSP.

Additionally, Verizon may not be the only CA with this issue, so I think
it is better that we solve it by enforcing it in code.

https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
2013-07-11 17:09:40 PDT
"So, now we have OCSP stapling enabled. ... there is now a requirement
that OCSP responders MUST NOT provide "good" responses for unknown
certificates in effect; this is a feature that CRLs do not have.
Therefore, I think we're more than justified in requiring that
revocation information be provided by OCSP for EV certificates."


Kathleen

[Kathleen Wilson]

One more thing I want to point out...

Verizon has been saying all along that they need more time on this OCSP
requirement. As shown above, they requested things like OCSP stapling
support in browsers back in 2009, and Mozilla only recently made that
available. As a more recent example, look at Verizon's response to the
January CA Communication
(https://wiki.mozilla.org/CA:Communications#January_2013_Responses).
They made it clear then that they are working hard to get OCSP
implemented at all of their customer sites by May 15, 2014. You are
correct, that the date does not match the dates imposed by the CAB
Forum, but I don't really care about the specific date, so long as the
CA is working hard to become compliant as soon as they can. As per
Verizon's response to the CA Communication, they did not try to hide the
fact that they would not be able to meet the CAB Forum's dates, but they
specifically called out the areas that would be problematic for them,
and gave dates that they are targeting. Given their situation, I believe
the dates that they gave are reasonable, and I am fine with this approach.

Kathleen

[Eddy Nigg]

On 10/22/2013 09:02 PM, From Kathleen Wilson:

> As I mentioned previously, I don't believe the lack of OCSP URI in
> those EV certificates was causing security risk to end users. Now that
> OCSP stapling is available, I think we should give Verizon a little
> bit of time to move their customers to OCSP.
>

I've been on the sidelines for most of this and other discussions here,
however I don't think this is correct at all - if the server doesn't
provide a correct stapled response, the browser must still be able to
find the OCSP response on its own. Additionally servers usually will use
the exact same information to find a valid OCSP response to include as a
browser would, and this response must be fairly frequently updated too.
Except if the server admin bothers to configure that manually which I
doubt over the longer term for most.

There IS a significant risk if a certificate can't be revoked, this
isn't just about EV treatment. Stapling or not still requires to provide
a source to check for the certificates status independently, both for
the server AND in case stapling fails for this or the other reason
(outdated, wrong etc.).

[Kathleen Wilson]

On 10/22/13 1:19 PM, Eddy Nigg wrote:
>
> I've been on the sidelines for most of this and other discussions here,
> however I don't think this is correct at all - if the server doesn't
> provide a correct stapled response, the browser must still be able to
> find the OCSP response on its own. Additionally servers usually will use
> the exact same information to find a valid OCSP response to include as a
> browser would, and this response must be fairly frequently updated too.
> Except if the server admin bothers to configure that manually which I
> doubt over the longer term for most.

I'm not sure I understand your message. Are you saying that even if OCSP
stapling is used, the certs must have the OCSP URI in them, in case the
server's stapled response doesn't work, and the browser needs to
fallback to the OCSP URI in the cert?

>
> There IS a significant risk if a certificate can't be revoked, this
> isn't just about EV treatment. Stapling or not still requires to provide
> a source to check for the certificates status independently, both for
> the server AND in case stapling fails for this or the other reason
> (outdated, wrong etc.).
>

Again, not sure if I'm understanding your message.

In the case of EV certs, Mozilla is still checking the CRL when the OCSP
URI is not provided. 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."

Are you saying that (instead of the above proposal) the revocation
checking should do the following?
1) Check for OCSP stapling response from server.
2) If cannot get a valid OCSP stapling response, then use OCSP URI in
AIA to try to get OCSP response.
3) If these attempts fail, then check CRL.
4) If both OCSP and CRL fail, then EV treatment will not be given.

Regards,
Kathleen

[Kathleen Wilson]

Unfortunately, OCSP stapling support has been delayed due to issues that
recently were found.
https://bugzilla.mozilla.org/show_bug.cgi?id=929617

There is discussion about this in CAB Forum Public list
(pub...@cabforum.org)
"We added support for OCSP stapling to Firefox 25 (beta) and we just
had to temporarily disable it right before the Firefox 25 release
because of interoperability issues. ..."

Kathleen

[Eddy Nigg]

On 10/23/2013 10:31 PM, From Kathleen Wilson:

> I'm not sure I understand your message. Are you saying that even if
> OCSP stapling is used, the certs must have the OCSP URI in them, in
> case the server's stapled response doesn't work, and the browser needs
> to fallback to the OCSP URI in the cert?

Yes, exactly. Also servers can be configured the easiest by having it
simply use the included OCSP URI in the certificate.

>
> In the case of EV certs, Mozilla is still checking the CRL when the
> OCSP URI is not provided.

Since when does Firefox check CRLs? I believe it never did except if
configured manually (which is probably almost never).

> Are you saying that (instead of the above proposal) the revocation
> checking should do the following?
> 1) Check for OCSP stapling response from server.
> 2) If cannot get a valid OCSP stapling response, then use OCSP URI in
> AIA to try to get OCSP response.
> 3) If these attempts fail, then check CRL.
> 4) If both OCSP and CRL fail, then EV treatment will not be given.

That really would be perfect (I think the best it can get with current
implementations). However IMO the fallback to normal OCSP is a must.

[Eddy Nigg]

On 10/24/2013 08:30 AM, From Ben Wilson:
> So long story short, yes, the OCSP URI does need to be in the AIA of
> the certificate.

Thanks Ben, that's perfect.

[Kathleen Wilson]

On 10/23/13 3:14 PM, Eddy Nigg wrote:
>>
>> In the case of EV certs, Mozilla is still checking the CRL when the
>> OCSP URI is not provided.
>
> Since when does Firefox check CRLs? I believe it never did except if
> configured manually (which is probably almost never).
>

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.

However, the code change to remove the CRL check is now targeted for
Firefox 28.
https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
This will have the affect of requiring OCSP for EV certs. If a valid
OCSP response is not obtained (either via OCSP stapling or via the OCSP
AIA URI), then EV treatment will not be given.

Kathleen

[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.

[Michael Ströder]

Kathleen Wilson wrote:
>> And since CRL support was dropped in recent Firefox/Seamonkey
>> releases there's
>> no revocation checking mechanism for those certs at all.
>
> That's not technically accurate for EV certificates. The user interface to
> manually import CRLs was dropped, but CRLs are still being checked. Currently
> for EV certs, if the OCSP URI is not present, then the CRL is checked.

???

Yes, the CRL import UI was dropped and AFAIK there's no support for CRLDP
extension. So how is the right CRL imported?

Ciao, Michael.

[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.

[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

[Kathleen Wilson]

On 10/24/13 11:45 AM, Eddy Nigg wrote:
> 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.
>

Please feel free to comment in bug #585122.


Kathleen

[Jeremy Rowley]

Strongly disagree that the security benefits are illusions. Granted, they
are not as great as with hard fail, but they do provide some benefits over
absolutely no revocation mechanisms. Even with the soft-fail methods
currently used, they at least require an extended isolation of the user from
the revocation server.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi
Sent: Thursday, October 24, 2013 4:46 PM
To: "Michael Ströder"
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any
consequences?

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."
>

[Rick Andrews]

> 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, Ryan. I'm afraid you've stooped to the same level as the person you were criticizing.

>
> 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.

I agree with Jeremy that there are security benefits to revocation checking, even without hard-fail, and that they are not illusions. If a CA can serve an OCSP response to a browser before the browser gives up, the user may be alerted to a revoked certificate and may then choose to avoid the web site. A number of CAs have been actively working to improve the performance of their CA infrastructures, and have made significant improvements.

-Rick

[Eddy Nigg]

On 10/25/2013 11:47 PM, From Rick Andrews:

> A number of CAs have been actively working to improve the
> performance of their CA infrastructures, and have made significant
> improvements.

For reference: https://revocation-report.x509labs.com/

( just that the cert expired there :-) )

[Brian Smith]

On Fri, Oct 25, 2013 at 1:47 PM, Rick Andrews <r.an...@computer.org> wrote:
> I agree with Jeremy that there are security benefits to revocation checking, even without hard-fail, and that they are not illusions. If a CA can serve an OCSP response to a browser before the browser gives up, the user may be alerted to a revoked certificate and may then choose to avoid the web site. A number of CAs have been actively working to improve the performance of their CA infrastructures, and have made significant improvements.

Could you please quantify the security gain of soft-fail revocation
fetching? How often is it the case where ALL of the these are true:

0. The attacker is using a certificate that is valid in all respects
EXCEPT it has been revoked.
1. The attacker can manipulate the connection between the browser and
the website the user is visiting
2. The attacker CANNOT block an OCSP request or the response
3. The attacker does not have access to a non-expired OCSP response
for the certificate it is using? (Often these are valid for up to 10
days, so an attacker could use an OCSP response that is up to 10 days
old.)
4. The attacker cannot trick the browser into reporting an overridable
cert error (e.g. by omitting the intermediate certificate from the
cert chain, or by using an expired certificate for which revocation
information is no longer available) that would mask/prevent the
detection of the revocation OR the user would not click through the
cert errror?
5. The attack results in non-trivial injury to the end-user. For
example, a user who is curious about the LavaBit incident, but not a
LavaBit user, and browsed to https://lavabit.com without getting the
"revoked" error is not injured. An actual LavaBit uesr would be.
Perhaps a good proxy for this would be "Could the end-user have a
reasonable case for a lawsuit to recover damages?"
6. In the case of mis-issuance: the CA could not contact the browser
vendor in time to have the browser vendor send out an update (CRLSet
update, or whatever) to block the mis-issued certificate before the
user was harmed.
7. Regarding CRLs: The revocation of the mis-used certificate is
available via CRL but not via OCSP and the certificate is an EV
certificate AND the CRL was of a reasonable size for a (mobile)
browser to process.

It isn't clear that this is, or is likely to become, a common enough
occurrence to justify even the performance costs and other negative
side effects of of OCSP fetching, let alone CRL fetching.

I think it would be useful to look at a case study from the past where
all of the above was true. Then we can explore what we could have done
better in that scenerio. What case study could we use?

Also, in this unlikely scenerio, who is at fault? Along the lines of a
lawsuit, who would the end-user be likely to successfully sue for
damages? If the CA mis-issued the certificate, it is clearly the CAs
fault. CAs must not mis-issue certificates. If the CA knows that it
must support OCSP for EV certificates and it chooses not to, it is
clearly the CA's fault. If the website lost control of its private
key, it is clearly the website's fault. Websites need to protect their
private keys.

OCSP and CRL fetching isn't free to users. We have to make sure that
the costs of revocation checking are in line with the benefits. I
don't see how the costs of CRL fetching are in line with the benefits
that it provides now. Also, I think we can come up with better ways of
getting the benefits while minimizing the costs to users, and that is
exactly what I am working on along with others at Mozilla.

[Rick Andrews]

Brian, you seem to be saying that revocation checking adds value only when there's an attacker involved. If that's your point, I disagree. There are cases in which a CA revokes a certificate because the site has misrepresented itself, and revocation serves as a warning to the client.

[Brian Smith]

On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews <r.an...@computer.org> wrote:
> Brian, you seem to be saying that revocation checking adds value only when there's an attacker involved. If that's your point, I disagree. There are cases in which a CA revokes a certificate because the site has misrepresented itself, and revocation serves as a warning to the client.

Thanks for the clarification. Could you give an example where such a
revocation would be useful to know about to a Firefox user to the
extent where the cost of doing the revocation checking is justified?
So far, I'm of the opinion when there's no attacker, there's no
problem (no harm, no foul).

[Stephen Davidson]

Virtually every CA relying party agreement (RPA) that I know stipulates that a user must validate the SSL using CRL or OCSP in order to place any reliance on the certificate.

Removal of that capability from browsers renders those RPAs useless, and effectively removes warranties from the SSL sector.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] On Behalf Of Brian Smith
Sent: Monday, October 28, 2013 4:15 PM
To: Rick Andrews
Cc: dev-secur...@lists.mozilla.org
Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews <r.an...@computer.org> wrote:

> Brian, you seem to be saying that revocation checking adds value only when there's an attacker involved. If that's your point, I disagree. There are cases in which a CA revokes a certificate because the site has misrepresented itself, and revocation serves as a warning to the client.

Thanks for the clarification. Could you give an example where such a revocation would be useful to know about to a Firefox user to the extent where the cost of doing the revocation checking is justified?
So far, I'm of the opinion when there's no attacker, there's no problem (no harm, no foul).

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________

[Jeremy Rowley]

There are lots of occasions:
1) Where a server with a private key is missing but there isn't yet an
active attack
2) Where the key was compromised
3) Where an error occurred and the certificate information identified the
wrong entity
4) Where the certificate was issued in accordance with the then-applicable
standards but standards have made the certificate untrustworthy (internal
names, 1024, SHA1)
5) Where the certificate profile is incorrect (lacks the appropriate EKU or
requested with incomplete information)

All of these are security concerns that don't have an active attacker and
where even a soft-fail revocation effectively mitigates the risk.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Brian Smith
Sent: Monday, October 28, 2013 1:14 PM
To: Rick Andrews
Cc: dev-secur...@lists.mozilla.org
Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any
consequences?

On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews <r.an...@computer.org>
wrote:

Thanks for the clarification. Could you give an example where such a
revocation would be useful to know about to a Firefox user to the extent
where the cost of doing the revocation checking is justified?
So far, I'm of the opinion when there's no attacker, there's no problem (no
harm, no foul).

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Jeremy Rowley]

Of course, hard-fail will always provide a more robust mitigation
mechanism. However, with browsers unwilling to provide hard fail,
notification of a suspected problem/risk is preferable to none.

Thanks for the clarification. Could you give an example where such a
revocation would be useful to know about to a Firefox user to the extent
where the cost of doing the revocation checking is justified?
So far, I'm of the opinion when there's no attacker, there's no problem (no
harm, no foul).

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Brian Smith]

On Mon, Oct 28, 2013 at 12:28 PM, Jeremy Rowley
<jeremy...@digicert.com> wrote:
> There are lots of occasions:
> 1) Where a server with a private key is missing but there isn't yet an
> active attack
> 2) Where the key was compromised
> 3) Where an error occurred and the certificate information identified the
> wrong entity
> 4) Where the certificate was issued in accordance with the then-applicable
> standards but standards have made the certificate untrustworthy (internal
> names, 1024, SHA1)
> 5) Where the certificate profile is incorrect (lacks the appropriate EKU or
> requested with incomplete information)
>
> All of these are security concerns that don't have an active attacker and
> where even a soft-fail revocation effectively mitigates the risk.

Those all seem like valid reasons to revoke a certificate. But, those
aren't reasons for checking that a certificate has been revoked. In
order for the revocation to actually matter to a normal Firefox user,
the user must find himself in a scenerio like the one I previously
described, right?

Cheers,
Brian

> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
> .org] On Behalf Of Brian Smith
> Sent: Monday, October 28, 2013 1:14 PM
> To: Rick Andrews
> Cc: dev-secur...@lists.mozilla.org
> Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any
> consequences?
>
> On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews <r.an...@computer.org>
> wrote:

> Thanks for the clarification. Could you give an example where such a
> revocation would be useful to know about to a Firefox user to the extent
> where the cost of doing the revocation checking is justified?
> So far, I'm of the opinion when there's no attacker, there's no problem (no
> harm, no foul).
>

> Cheers,
> Brian
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Brian Smith]

On Mon, Oct 28, 2013 at 12:27 PM, Stephen Davidson
<S.Dav...@quovadisglobal.com> wrote:
> Virtually every CA relying party agreement (RPA) that I know stipulates that a user must validate the SSL using CRL or OCSP in order to place any reliance on the certificate.
>
> Removal of that capability from browsers renders those RPAs useless, and effectively removes warranties from the SSL sector.

Aren't these RPAs already useless?

Anyway, AFAICT Mozilla didn't agree to any RPA agreement with any CA.
Also, our users have not agreed to any such agreements. Perhaps it
worthwhile to clarify this by forbidding such requirements on relying
parties as part of our CA policy.

[Jeremy Rowley]

Depends on what you mean by "matter". I'd say it matters to a FireFox user
to know whether a site has the potential for a MITM attack even if the MITM
attack isn't currently underway. You said "No harm, no foul", but that
assumes no harm only encompasses immediate harm instead of both immediate
and potential harm. There is harm by allowing a revoked certificate to
continue to be trusted even if that harm is not immediately recognized.

> Thanks for the clarification. Could you give an example where such a
> revocation would be useful to know about to a Firefox user to the
> extent where the cost of doing the revocation checking is justified?
> So far, I'm of the opinion when there's no attacker, there's no
> problem (no harm, no foul).
>

> Cheers,
> Brian
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Brian Smith]

On Mon, Oct 28, 2013 at 12:54 PM, Jeremy Rowley
<jeremy...@digicert.com> wrote:
> Depends on what you mean by "matter". I'd say it matters to a FireFox user
> to know whether a site has the potential for a MITM attack even if the MITM
> attack isn't currently underway.

Why? Let's say we had a system that could perfectly prevent every
attack, but it could only do so at the exact instant that an attack
took place. Would you consider that to be an unacceptable alternative
to the current system? Or, are you just saying that, given the flaws
in the current system, it is better to be proactive about revocation
checking.

> You said "No harm, no foul", but that
> assumes no harm only encompasses immediate harm instead of both immediate
> and potential harm. There is harm by allowing a revoked certificate to
> continue to be trusted even if that harm is not immediately recognized.

There's always some potential for a MITM attack even if we did
hard-fail revocation checking on every connection. So, the question
isn't whether there's potential for a MitM attack, but whether there's
potential for a MitM attack that revocation checking would actually be
able to prevent. That means we need to consider how realistic it is
for such an attack to take place, and how likely it is that a
revocation check would prevent that attack. I hope you can understand
how a software engineer would have trouble arguing in favor of such an
expensive feature as CRL fetching (or even OCSP fetching) without a
valid argument in favor of doing it. Right now we're lacking valid
arguments for doing it.

Cheers,
Brian

[Eddy Nigg]

On 10/28/2013 09:51 PM, From Brian Smith:

Actually you did by adding a root who's policy Mozilla ought to know
fairly well. Mozilla is a relying and/or acts as a relying party on
parts of the obligations and on behalf of the user. A user using a
software that doesn't check revocation (knowingly) may NOT rely on a
certificate.

[fhw...@gmail.com]

‎Changing the subject line because compliance is at the heart of this issue. I also would like to thank Brian for his comment below, because it seems we're discussing less the merits of CRLs and more rationalizing the cost to implement.

Regarding the merits, here's a simple case that I hope will illustrate the importance of CRLs:

 - Site admin: someone hacked my server and probably took my private key and SSL certificate

‎ - CA: okay, generate a new key pair and send over the signing request and we'll get you a new certificate; in the mean time we'll issue a CRL so nobody uses the old cert anymore

 - Mozilla: meh, I don't see the big deal, I'm ‎sure everything will be fine if I continue to allow the cert anyway

So, to put it another way, the decision to use a revoked cert is not Mozilla's to make - - the decision to revoke has to be respected. Here's why:

 - Cert thief: c‎ool, all Firefox users will still recognize this cert so now I can sell it on the black market! Since this cert is for a high value target, I should be able to get some good money for it. I'll start the bidding at $50,000.

So...if Mozilla can't implement CRL support because of staffing issues and priorities, that's fine. Actually it's completely understandable. In the meantime, Mozilla is not 5280 compliant--and that should be a big deal. 

‎

... I hope you can understand

[Gervase Markham]

On 28/10/13 19:27, Stephen Davidson wrote:
> Virtually every CA relying party agreement (RPA) that I know
> stipulates that a user must validate the SSL using CRL or OCSP in
> order to place any reliance on the certificate.
>
> Removal of that capability from browsers renders those RPAs useless,
> and effectively removes warranties from the SSL sector.

To illuminate the debate: are you able to quote a case study from the
Web PKI where a relying party has successfully claimed on such a warranty?

Gerv

[Eddy Nigg]

On 10/29/2013 04:26 PM, From Gervase Markham:

> To illuminate the debate: are you able to quote a case study from the
> Web PKI where a relying party has successfully claimed on such a
> warranty?

And if not can we remove SSL please from the browsers? We don't need
that in that case since nobody was a victim (of a system that apparently
seems to work) who had to make claims against a CA.

[Kathleen Wilson]

On 10/29/13 5:20 AM, fhw...@gmail.com wrote:
> ‎Changing the subject line because compliance is at the heart of this
> issue. I also would like to thank Brian for his comment below, because
> it seems we're discussing less the merits of CRLs and more rationalizing
> the cost to implement.
>

<snip>

>
> So...if Mozilla can't implement CRL support because of staffing issues
> and priorities, that's fine. Actually it's completely understandable. In
> the meantime, Mozilla is not 5280 compliant--and that should be a big deal.
>
>

Please see https://wiki.mozilla.org/CA:ImprovingRevocation

There is also an interesting research paper attached to that page about
revocation.

Folks are working towards adding a revocation-push mechanism so that
Firefox preloads certain revocation information for intermediate and
end-entity certificates. I started the discussion about which types of
revocations should be included for intermediate certs here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ

There will be a similar discussion for end-entity cert revocations, I
just haven't started it yet.

The goal is for the revocation-push mechanism to be used instead of
traditional CRL checking, for reasons described in the wiki page and the
research paper.

In my opinion, the sequence in which certain changes (like ripping out
the CRL user interface) could have been better, such as happening after
the revocation-push mechanism was in place. But, in my opinion, we are
heading the right direction -- there will be revocation checking, it
just will be done in a better and more efficient way.

Kathleen

[fhw...@gmail.com]

‎This is good information, Kathleen, and I'm certainly in favor of making improvements. I do wish there was more info on the report author and any affiliations he might have.

That said I can't find clear, unambiguous detail on what CRL capabilities are actually working in Firefox, and for which versions. There ‎was some talk at one time how CRL never worked anyway or some such thing but I think we need clarification on that now.

The worst case here is that some capabilities are missing from current (and future) versions and the worst case for missing functionality could be very bad indeed.

Thanks.

From: Kathleen Wilson Sent: ‎Tuesday, October 29, 2013 1:38 PM To: ‎mozilla-dev-s...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280

On 10/29/13 5:20 AM, fhw...@gmail.com wrote:

> ‎Changing the subject line because compliance is at the heart of this
> issue. I also would like to thank Brian for his comment below, because
> it seems we're discussing less the merits of CRLs and more rationalizing
> the cost to implement.
>

<snip>

>
> So...if Mozilla can't implement CRL support because of staffing issues
> and priorities, that's fine. Actually it's completely understandable. In
> the meantime, Mozilla is not 5280 compliant--and that should be a big deal.
>
>

Please see https://wiki.mozilla.org/CA:ImprovingRevocation

There is also an interesting research paper attached to that page about
revocation.

Folks are working towards adding a revocation-push mechanism so that
Firefox preloads certain revocation information for intermediate and
end-entity certificates. I started the discussion about which types of
revocations should be included for intermediate certs here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ

There will be a similar discussion for end-entity cert revocations, I
just haven't started it yet.

The goal is for the revocation-push mechanism to be used instead of
traditional CRL checking, for reasons described in the wiki page and the
research paper.

In my opinion, the sequence in which certain changes (like ripping out
the CRL user interface) could have been better, such as happening after
the revocation-push mechanism was in place. But, in my opinion, we are
heading the right direction -- there will be revocation checking, it
just will be done in a better and more efficient way.

Kathleen

[Jean-Marc Desperrier]

Eddy Nigg a écrit :

> If Firefox really uses the CRLDP

No, it has never used the CRLDP to download the CRL.
People need to import the CRL manually and then activate the
auto-update, and nobody does it. What's more if the CRL becomes outdated
for some reason, there will be no warning.

The effective solution is rather to implement support for Google's
CRLSets within the Mozilla products :
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/crlsets

[Kathleen Wilson]

On 10/31/13 7:40 AM, Jean-Marc Desperrier wrote:
> Eddy Nigg a écrit :
>> If Firefox really uses the CRLDP
>
> No, it has never used the CRLDP to download the CRL.
> People need to import the CRL manually and then activate the
> auto-update, and nobody does it. What's more if the CRL becomes outdated
> for some reason, there will be no warning.
>

That's true for non-EV.

The validation path for EV is different.

Kathleen

[Matthias Hunstock]

Am 29.10.2013 19:37, schrieb Kathleen Wilson:
> The goal is for the revocation-push mechanism to be used instead of
> traditional CRL checking, for reasons described in the wiki page and the
> research paper.

Everyone with a "self-made" CA will be completely cut off from
revocation checking, except there is an OCSP responder?



Matthias

[Eddy Nigg]

On 10/31/2013 04:40 PM, From Jean-Marc Desperrier:

> Eddy Nigg a écrit :
>> If Firefox really uses the CRLDP
>
> No, it has never used the CRLDP to download the CRL.
> People need to import the CRL manually and then activate the
> auto-update, and nobody does it. What's more if the CRL becomes
> outdated for some reason, there will be no warning.

Thanks for confirming -Kathleen, Firefox by default doesn't use CRLs.

[Eddy Nigg]

On 10/31/2013 09:41 PM, From Kathleen Wilson:

>
> That's true for non-EV.
>
> The validation path for EV is different.

Which developer can confirm this? Where is the code for it? It's just
news for me and I'm a bit surprised, but enterily possible.

[fhw...@gmail.com]

‎So if this really is the case, it seems to me that this constitutes a zero day vulnerability in Firefox.  I don't mean to sound alarmist but...???

From: Eddy Nigg

‎Thanks for confirming -Kathleen, Firefox by default doesn't use CRLs.

[Eddy Nigg]

On 11/02/2013 12:32 AM, From fhw...@gmail.com:

> ‎So if this really is the case, it seems to me that this constitutes a
> zero day vulnerability in Firefox. I don't mean to sound alarmist
> but...???
>

It's not since it's always been like this and one of the reasons CAs
must provide OCSP revocation capability. It would be however /nice/ to
have a CRL fallback...

[fhw...@gmail.com]

‎I think that is correct, Matthias.

What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.)

‎

I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not.

From: Matthias Hunstock Sent: Friday, November 1, 2013 10:46 AM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280

Am 29.10.2013 19:37, schrieb Kathleen Wilson:

> The goal is for the revocation-push mechanism to be used instead of
> traditional CRL checking, for reasons described in the wiki page and the
> research paper.

Everyone with a "self-made" CA will be completely cut off from
revocation checking, except there is an OCSP responder?



Matthias

[fhw...@gmail.com]

Perhaps instead I should have said it's a minus-seventeen-years exploit? :-)

Seriously, though, anyone who has ever issued a CRL was basically wasting valuable electrons on something that doesn't get used (by FF--don't know about the others).

Or to put it another way, everyone could stop issuing CRLs immediately and have n‎o appreciable impact on Internet security. I think that would surprise many people. 

From: Eddy Nigg Sent: Friday, November 1, 2013 5:48 PM To: mozilla-dev-s...@lists.mozilla.org

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

On 11/02/2013 12:32 AM, From fhw...@gmail.com:

> ‎So if this really is the case, it seems to me that this constitutes a
> zero day vulnerability in Firefox. I don't mean to sound alarmist
> but...???
>

It's not since it's always been like this and one of the reasons CAs
must provide OCSP revocation capability. It would be however /nice/ to
have a CRL fallback...

--
Regards

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

[Eddy Nigg]

On 11/02/2013 01:00 AM, From fhw...@gmail.com:

> Or to put it another way, everyone could stop issuing CRLs immediately
> and have n‎o appreciable impact on Internet security. I think that
> would surprise many people.

Obviously it would have an impact on other browsers and systems. But
true, it wouldn't affect Firefox and friends (this time in the negative
way). It's however nothing new, it would be news to me that it checks
any CRL at all.

[fhw...@gmail.com]

‎And...this is a great way for hackers, fraudsters, and the NSA (is there a difference?) to attack users of Firefox. All I have to do is steal a private key, grab the cert chain, and I can go about setting up a fake site that will ensnare hapless surfers. It might not be a perfect attack but it doesn't need to be in order to be "successful".

I keep looking for someone ‎at Mozilla to say this is a big deal and that it can be fixed by a date certain. Instead all I've been able to gather is that they will implement a better solution at some point and then...?

From: Eddy Nigg Sent: Friday, November 1, 2013 6:04 PM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

On 11/02/2013 01:00 AM, From fhw...@gmail.com:

> Or to put it another way, everyone could stop issuing CRLs immediately
> and have n‎o appreciable impact on Internet security. I think that
> would surprise many people.

Obviously it would have an impact on other browsers and systems. But
true, it wouldn't affect Firefox and friends (this time in the negative
way). It's however nothing new, it would be news to me that it checks
any CRL at all.

[Brian Smith]

On Fri, Nov 1, 2013 at 2:08 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 10/31/2013 09:41 PM, From Kathleen Wilson:
>>

>> That's true for non-EV.
>>
>> The validation path for EV is different.
>

> Which developer can confirm this? Where is the code for it? It's just news
> for me and I'm a bit surprised, but enterily possible.

Here is the logic we *currently* use:

Does the end-entity certificate have an EV policy OID from any of our
EV CAs? If so, verify that the certificate is valid for that policy
OID, trusting only that CA's root. During this validation, check OCSP,
and fall back to CRLs using CRLDP. If that validation succeeds, then
return "Good EV certificate." If that validation fails, check the
certificate using the normal certificate checking path.

The normal certificate checking path does not do CRL fetching, and it
*never* has. So, for any CA that isn't in our EV program, Firefox has
never done CRL fetching.

The CABForum EV guidelines have required EV CAs to support OCSP for a
very long time. So, there's no justification for Firefox to fall back
to CRL fetching for EV certificate verification any more. Accordingly,
to avoid various problems that CRLs pose on us, our users, and on CAs,
we'll stop doing the fallback to CRLs for EV certificates very soon.

Once that happens, for all practical purposes, Firefox will not have
anything to do with CRLs. The only exception is that, if you use some
specialized tools to important CRLs into Firefox's certificate
database, then Firefox will recognize those specially-imported CRLs
for a while. However, it is likely that that will stop too, when we
switch to the new certificate validation library.

The source code for this is here:
http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150

[Brian Smith]

On Fri, Nov 1, 2013 at 4:29 PM, <fhw...@gmail.com> wrote:

> ‎And...this is a great way for hackers, fraudsters, and the NSA (is there
> a difference?) to attack users of Firefox. All I have to do is steal a
> private key, grab the cert chain, and I can go about setting up a fake site
> that will ensnare hapless surfers. It might not be a perfect attack but it
> doesn't need to be in order to be "successful".
>

Hi, I suggest that you go back and re-read my earlier messages in this
thread. It isn't black-and-white. Basically, all this revocation checking
stuff--OCSP and CRLs--are mostly giving people a false sense of security. I
have found that, whenever I explain to people exactly how it works, and
more importantly when and how it *doesn't* work, most people tend to agree
that it is a waste of effort for us to be doing OCSP or CRL fetching at all.

> I keep looking for someone ‎at Mozilla to say this is a big deal and that
> it can be fixed by a date certain. Instead all I've been able to gather is
> that they will implement a better solution at some point and then...?
>

We are actively implementing better solutions now. We're working to make
OCSP stapling work. We're actively working on Must-Staple functionality to
make revocation checking clearly meaningful in terms of security. We're
working (on this mailing list) with CAs to define when and how CAs notify
us about security-critical revocations, to work around the serious
deficiencies in how browsers (not just Firefox) have done revocation
checking through OCSP and CRL fetching.

If I may speak frankly, for once: The transition from revocation checking
mechanisms that almost never do anything useful to revocation checking
mechanisms that are reliable and effective is not going to be 100% smooth.
We need to be willing to break some eggs and take some risks in order to
get to a better, reasonable, place. We (Firefox, Chrome, and other
browsers) are not in a reasonable place now.

[Brian Smith]

On Fri, Nov 1, 2013 at 4:00 PM, <fhw...@gmail.com> wrote:

> Seriously, though, anyone who has ever issued a CRL was basically wasting
> valuable electrons on something that doesn't get used (by FF--don't know
> about the others).
>

> Or to put it another way, everyone could stop issuing CRLs immediately and
> have n‎o appreciable impact on Internet security. I think that would
> surprise many people.
>

I agree with everything quoted above. Don't waste your time with CRLs if
you care only about browsers. Work on deploying OCSP stapling if you think
revocation checking is important.

[fhw...@gmail.com]

‎I think what you've said here, Brian, is basically what I was looking for. Actually I wanted you to tell me I'm completely misinformed and these are the ways people will be protected. 

I'm thinking it might be appropriate to have some sort of communique sent out to the CA's so that all of them understand this situation, can adjust their practices as necessary, and can educate their customers so the customers can make informed decisions.

We all know ‎there are people out there who think "well if something goes wrong I can just revoke the certificate or something". That thinking is flat out wrong.

Let me add that I am genuinely concerned about what this can mean for FF and maybe all browsers. I think there are admins and regulators and other "security folk" who might impose restrictions on Mozilla's products. I shudder to think anyone would say "for maximum security you should use MSIE".

From: Brian Smith Sent: Friday, November 1, 2013 7:12 PM To: fhw...@gmail.com Cc: Eddy Nigg; mozilla-dev-s...@lists.mozilla.org Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

[Eddy Nigg]

On 11/02/2013 02:00 AM, From Brian Smith:

> Does the end-entity certificate have an EV policy OID from any of our
> EV CAs? If so, verify that the certificate is valid for that policy
> OID, trusting only that CA's root. During this validation, check OCSP,
> and fall back to CRLs using CRLDP.

Thanks for confirming this, Brian.

> The normal certificate checking path does not do CRL fetching, and it
> *never* has. So, for any CA that isn't in our EV program, Firefox has
> never done CRL fetching.

But the code would actually exist to do that in that case.

> The CABForum EV guidelines have required EV CAs to support OCSP for a
> very long time.

Absolutely.

> So, there's no justification for Firefox to fall back
> to CRL fetching for EV certificate verification any more.

I don't really agree with that however - I've been an advocate to
certificate status checking along the lines Firefox apparently has done
for EV certificates. No infrastructure can be 100% perfect and for this
I think the fallback to CRLs is quite useful.

In numbers I assume that's small a minority and in case of EV I also
assume that the CRLs are fairly thin, not affecting performance a lot.
Of course I'd like to see this for all certificates, not only EV really.

[Gervase Markham]

On 01/11/13 23:00, fhw...@gmail.com wrote:
> Or to put it another way, everyone could stop issuing CRLs immediately
> and have n‎o appreciable impact on Internet security. I think that would
> surprise many people.

I don't think that's true, because direct client download of the CRL is
not the only mechanism by which information in CRLs could get to
clients. See Google's CRLsets, for example.

Gerv

[fhw...@gmail.com]

‎I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too?  Or...?

Thanks.

From: fhw...@gmail.com Sent: Friday, November 1, 2013 5:50 PM To: Matthias Hunstock; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280

‎I think that is correct, Matthias.

What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.)

‎

I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not.

From: Matthias Hunstock Sent: Friday, November 1, 2013 10:46 AM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280

Am 29.10.2013 19:37, schrieb Kathleen Wilson:

> The goal is for the revocation-push mechanism to be used instead of
> traditional CRL checking, for reasons described in the wiki page and the
> research paper.

Everyone with a "self-made" CA will be completely cut off from
revocation checking, except there is an OCSP responder?



Matthias

[Rick Andrews]

Brian, Kathleen,

The idea of removing Firefox's ability to fetch an OCSP response from a CA seems to me to be a significant policy shift. But it's being discussed here in this thread (with an unrelated Subject line) which many may miss. Why not add it to https://wiki.mozilla.org/CA:ImprovingRevocation so that everyone's aware of what you're considering?

[Jeremy Rowley]

I imagine every CA would agree with you. OCSP stapling is a great idea, but the number of servers deploying it are very low. I don’t believe any CAs support the idea of getting rid of revocation checking.

From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of fhw...@gmail.com
Sent: Friday, November 08, 2013 6:42 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Mozilla not compliant with RFC 5280



‎I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too? Or...?



Thanks.


From: fhw...@gmail.com

Sent: Friday, November 1, 2013 5:50 PM

To: Matthias Hunstock; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



‎I think that is correct, Matthias.



What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.)

‎

I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not.




From: Matthias Hunstock

Sent: Friday, November 1, 2013 10:46 AM

To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



Am 29.10.2013 19:37, schrieb Kathleen Wilson:

> The goal is for the revocation-push mechanism to be used instead of
> traditional CRL checking, for reasons described in the wiki page and the
> research paper.

[Phillip Hallam-Baker]

I don't believe there are any parties who you would want as CAs that

support the idea of getting rid of revocation checking.

> > The goal is for the revocation-push mechanism to be used instead of
> > traditional CRL checking, for reasons described in the wiki page and the
> > research paper.
>

> Everyone with a "self-made" CA will be completely cut off from
> revocation checking, except there is an OCSP responder?
>
>
>
> Matthias
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Website: http://hallambaker.com/

[fhw...@gmail.com]

‎I would hope not! And yet...Firefox has no revocation checking right now (or if you prefer, for the last 17 years).

So what's a Firefox user to do...besides not use Firefox?

From: Phillip Hallam-Baker Sent: Friday, November 8, 2013 11:51 AM To: Jeremy Rowley Cc: fhw...@gmail.com; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280

I don't believe there are any parties who you would want as CAs that support the idea of getting rid of revocation checking.

On Fri, Nov 8, 2013 at 9:35 AM, Jeremy Rowley <jeremy...@digicert.com> wrote:

I imagine every CA would agree with you.  OCSP stapling is a great idea, but the number of servers deploying it are very low.  I don’t believe any CAs support the idea of getting rid of revocation checking.



From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of fhw...@gmail.com
Sent: Friday, November 08, 2013 6:42 AM

To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Mozilla not compliant with RFC 5280



I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too?  Or...?



Thanks.


From: fhw...@gmail.com

Sent: Friday, November 1, 2013 5:50 PM

To: Matthias Hunstock; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



I think that is correct, Matthias.



What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.)



I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not.




From: Matthias Hunstock

Sent: Friday, November 1, 2013 10:46 AM

To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



Am 29.10.2013 19:37, schrieb Kathleen Wilson:

> The goal is for the revocation-push mechanism to be used instead of
> traditional CRL checking, for reasons described in the wiki page and the
> research paper.

Everyone with a "self-made" CA will be completely cut off from
revocation checking, except there is an OCSP responder?



Matthias
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy





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

--
Website: http://hallambaker.com/

[Jeremy Rowley]

They currently check revocation information, just not in the most ideal way.

1) They don’t check intermediates. Fortunately, intermediates are rarely revoked, and a CA can email Mozilla when it happens.

2) They don’t check CRLs, which is one of the reasons the CAB Forum requires CAs to provide OCSP information.

3) They do check end-entity OCSP responses, which all CAs are required to provide.



Since every CA provides OCSP, there are assurances that users will be aware when a certificate is revoked. If Mozilla removes OCSP checks, CAs won’t be able to provide revocation information. Although Mozilla will check stapled responses, use of OCSP stapling on servers is low. Even with Mozilla driving clients to OCSP stapling, any transition will take a minimum of two years. FireFox users will be unable to really rely on a certificate until that time.



The change also raises questions on how this affects CA practices. Many CAs invested substantially in infrastructure to provide reliable OCSP services. Most of us boast more than a 99.9% uptime with servers distributed throughout the world. What does this mean for CAs who, relying on Mozilla’s checking of OCSP and support of the baseline requirements, established an expensive and geographically diverse infrastructure?



Mozilla’s main argument is that revocation checking without hard-fail provides little security. Although I disagree with the premises, if the lack of hard-fail is really the issue, the obvious solution is to turn it on. Most of the CAs would be happy about that.

From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of fhw...@gmail.com
Sent: Friday, November 08, 2013 11:09 AM
To: dev-secur...@lists.mozilla.org
Subject: Re: Mozilla not compliant with RFC 5280



‎I would hope not! And yet...Firefox has no revocation checking right now (or if you prefer, for the last 17 years).



So what's a Firefox user to do...besides not use Firefox?


From: Phillip Hallam-Baker

Sent: Friday, November 8, 2013 11:51 AM

To: Jeremy Rowley

Cc: fhw...@gmail.com; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



I don't believe there are any parties who you would want as CAs that support the idea of getting rid of revocation checking.







On Fri, Nov 8, 2013 at 9:35 AM, Jeremy Rowley <jeremy...@digicert.com> wrote:

I imagine every CA would agree with you. OCSP stapling is a great idea, but the number of servers deploying it are very low. I don’t believe any CAs support the idea of getting rid of revocation checking.

From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley <mailto:dev-security-policy-bounces%2Bjeremy.rowley> =digice...@lists.mozilla.org] On Behalf Of fhw...@gmail.com
Sent: Friday, November 08, 2013 6:42 AM

To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Mozilla not compliant with RFC 5280



I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too? Or...?



Thanks.


From: fhw...@gmail.com

Sent: Friday, November 1, 2013 5:50 PM

To: Matthias Hunstock; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



I think that is correct, Matthias.



What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.)



I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not.




From: Matthias Hunstock

Sent: Friday, November 1, 2013 10:46 AM

To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: Mozilla not compliant with RFC 5280



Am 29.10.2013 19:37, schrieb Kathleen Wilson:

> The goal is for the revocation-push mechanism to be used instead of
> traditional CRL checking, for reasons described in the wiki page and the
> research paper.

[Eddy Nigg]

On 11/08/2013 09:02 PM, From Jeremy Rowley:

> What does this mean for CAs who, relying on Mozilla’s checking of OCSP and support of the baseline requirements, established an expensive and geographically diverse infrastructure?

Probably get a smaller bill at the end of the month ;-)

> Mozilla’s main argument is that revocation checking without hard-fail provides little security. Although I disagree with the premises, if the lack of hard-fail is really the issue, the obvious solution is to turn it on. Most of the CAs would be happy about that.

+1

[fhw...@gmail.com]

There are a couple good points here, starting with hard-fail. Why is it not already turned on by default? What is the argument against it? 

An even better question is how many people in this forum have turned it on, and what has your experience been? I just turned it on myself...once I found the stupid check box (but I digress).

‎The other good point is that good, truly global CA's really need to have a worldwide presence with their OCSP servers. Under the assumption that doing so keeps delay to a minimum this is good thing. Less impact to the user means increased adoption of security measures...?

I'm still approaching this from the NSA/attacker standpoint of "now that I've stolen this private key, what can I do with it?". I think Firefox users remain a prime target but the jury is still out in my mind.

From: Eddy Nigg Sent: Monday, November 11, 2013 2:39 PM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280

On 11/08/2013 09:02 PM, >From Jeremy Rowley:

> What does this mean for CAs who, relying on Mozilla’s checking of OCSP and support of the baseline requirements, established an expensive and geographically diverse infrastructure?

Probably get a smaller bill at the end of the month ;-)

> Mozilla’s main argument is that revocation checking without hard-fail provides little security. Although I disagree with the premises, if the lack of hard-fail is really the issue, the obvious solution is to turn it on. Most of the CAs would be happy about that.

+1

--
Regards

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

[Kathleen Wilson]

On 11/12/13 11:31 AM, fhw...@gmail.com wrote:
> There are a couple good points here, starting with hard-fail. Why is it
> not already turned on by default? What is the argument against it?

OCSP responders are not yet reliable enough for us to do hard fail.

This is old news:
http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html

OCSP stapling will help to make hard-fail possible.
Must-Staple will be a way to opt into hard-fail.

Kathleen

[fhw...@gmail.com]

‎Finally getting back to this one, and renaming the subject 

From: Kathleen Wilson Sent: Wednesday, November 13, 2013 1:31 PM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280

On 11/12/13 11:31 AM, fhw...@gmail.com wrote:

> There are a couple good points here, starting with hard-fail. Why is it
> not already turned on by default? What is the argument against it?

OCSP responders are not yet reliable enough for us to do hard fail.

This is old news:
http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html

OCSP stapling will help to make hard-fail possible.
Must-Staple will be a way to opt into hard-fail.

Kathleen

[fhw...@gmail.com]

‎Oops, hit send by mistake. 

I realize that "stolen cert" is not accurate, strictly speaking, but I think it might paint a better picture of the the situation that leads to the risk/danger...?

In any case, thanks for providing that link Kathleen. It is informative but the situation Netcraft describes in the article is child's play because there are many other ways to harvest credentials and there are many ways to resist that from happening. 

Rather, I'm thinking of the more nefarious cases where you are just browsing along and poof! your machine is infected with malware and you don't have any idea that anything happened. For example: you click on a banner ad which takes you to a site that has the info you want. Everything has https and only the domain you're going to appears so you're fine...except you now have malware on your machine.

What happened is that someone stole a cert for that site's domain. Maybe it's a wildcard cert, maybe it's a cert to a site with some ancillary purpose like gathering metrics...doesn’t matter. With this "stolen cert" the attacker is able to set up a fake server and use it to infect anyone who comes along. ‎In essence, the fake server will use Firefox cert revocation vulnerabilities to run scripts or whatever that exploit other FF vulnerabilities that lead to infecting your machine with malware. 

From what I've read in this forum and elsewhere it seems there is no way to stop this from happening. If someone knows of a way I'd be very interested in knowing. Absent some solution, it seems to me some very bad things can (do?) happen.

From: fhw...@gmail.com Sent: Friday, December 6, 2013 8:27 AM To: Kathleen Wilson; mozilla-dev-s...@lists.mozilla.org Subject: Firefox users vulnerable to cert theft (was: Mozilla not compliant with RFC 5280)

‎Finally getting back to this one, and renaming the subject 

From: Kathleen Wilson Sent: Wednesday, November 13, 2013 1:31 PM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280

On 11/12/13 11:31 AM, fhw...@gmail.com wrote:

> There are a couple good points here, starting with hard-fail. Why is it
> not already turned on by default? What is the argument against it?

OCSP responders are not yet reliable enough for us to do hard fail.

This is old news:
http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html

OCSP stapling will help to make hard-fail possible.
Must-Staple will be a way to opt into hard-fail.

Kathleen

[David Keeler]

I think there's a bit of confusion here. First, malware can be be
delivered over http, so there's no need to steal a certificate. Second,
an attacker can easily buy a domain-validated certificate for a
throwaway domain they've registered using a stolen or fake identity and
serve their malware over https, so again there is no need to steal a
certificate.

There is a danger of an attacker stealing a code-signing certificate to
sign malware. This would affect Firefox when verifying addons and
packaged apps, but this doesn't affect verifying TLS connections.

> *From: *fhw...@gmail.com
> *Sent: *Friday, December 6, 2013 8:27 AM
> *To: *Kathleen Wilson; mozilla-dev-s...@lists.mozilla.org
> *Subject: *Firefox users vulnerable to cert theft (was: Mozilla not
> compliant

> with RFC 5280)
>
>
> ‎Finally getting back to this one, and renaming the subject
>

> *From: *Kathleen Wilson
> *Sent: *Wednesday, November 13, 2013 1:31 PM
> *To: *mozilla-dev-s...@lists.mozilla.org
> *Subject: *Re: Mozilla not compliant with RFC 5280

>
>
> On 11/12/13 11:31 AM, fhw...@gmail.com wrote:

>> There are a couple good points here, starting with hard-fail. Why is it
>> not already turned on by default? What is the argument against it?
>

> OCSP responders are not yet reliable enough for us to do hard fail.
>
> This is old news:
> http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html
>
> OCSP stapling will help to make hard-fail possible.
> Must-Staple will be a way to opt into hard-fail.
>
> Kathleen
>

[fhw...@gmail.com]

Sure, there are other ways to accomplish malware infection, but the issue remains: if I steal your certificate, I can use it anyway I want and there is no way for you to stop me‎...and that's a big problem. 

A code signing cert is a good ‎example, too, of how losing control of a cert can cause all types of damage. 

> *Subject: *Firefox users vulnerable to cert theft (was: Mozilla not
> compliant

> with RFC 5280)
>
>
> ‎Finally getting back to this one, and renaming the subject
>
> *From: *Kathleen Wilson
> *Sent: *Wednesday, November 13, 2013 1:31 PM
> *To: *mozilla-dev-s...@lists.mozilla.org

> *Subject: *Re: Mozilla not compliant with RFC 5280

>
>
> On 11/12/13 11:31 AM, fhw...@gmail.com wrote:

>> There are a couple good points here, starting with hard-fail. Why is it
>> not already turned on by default? What is the argument against it?
>

> OCSP responders are not yet reliable enough for us to do hard fail.
>
> This is old news:
> http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html
>
> OCSP stapling will help to make hard-fail possible.
> Must-Staple will be a way to opt into hard-fail.
>
> Kathleen
>

[fhw...@gmail.com]

‎I would like to point out that the ANSSI MITM intermediate cert situation presents many of the same problems as cert theft. Namely:

1) A software download and install is the only remedy (which should bother people). Not everyone will be able to upgrade, and not everyone will upgrade. Those who can't / don't  upgrade remain vulnerable.

2) ‎The ANSSI intermediate cert is still useful and can be used to commit site forgery and other mischief on those who are vulnerable. In other words, I could sell or steal the private key and use it to create a viable attack.

The fact that some browsers will stop allowing that cert is not important. It has value today and will continue to have value. The best thing would be to destroy the private key, assuming that the ANSSI is even able to do that. 

‎

> *Subject: *Firefox users vulnerable to cert theft (was: Mozilla not
> compliant

> with RFC 5280)
>
>
> ‎Finally getting back to this one, and renaming the subject
>
> *From: *Kathleen Wilson
> *Sent: *Wednesday, November 13, 2013 1:31 PM
> *To: *mozilla-dev-s...@lists.mozilla.org
> *Subject: *Re: Mozilla not compliant with RFC 5280
>
>
> On 11/12/13 11:31 AM, fhw...@gmail.com wrote:

>> There are a couple good points here, starting with hard-fail. Why is it
>> not already turned on by default? What is the argument against it?
>

> OCSP responders are not yet reliable enough for us to do hard fail.
>
> This is old news:
> http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html
>
> OCSP stapling will help to make hard-fail possible.
> Must-Staple will be a way to opt into hard-fail.
>
> Kathleen
>