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

722 views
Skip to first unread message

Patrick Tate

unread,
Sep 25, 2013, 2:32:29 PM9/25/13
to
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

unread,
Sep 25, 2013, 4:52:47 PM9/25/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 26, 2013, 8:45:23 AM9/26/13
to Kathleen Wilson
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

unread,
Sep 26, 2013, 11:30:34 AM9/26/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 26, 2013, 12:00:50 PM9/26/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 26, 2013, 2:45:46 PM9/26/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 26, 2013, 3:17:28 PM9/26/13
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 26, 2013, 3:21:11 PM9/26/13
to Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Sep 26, 2013, 3:58:07 PM9/26/13
to
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

unread,
Sep 26, 2013, 4:15:57 PM9/26/13
to Brian Smith, Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Sep 26, 2013, 4:23:17 PM9/26/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 26, 2013, 4:32:08 PM9/26/13
to Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Sep 26, 2013, 4:52:18 PM9/26/13
to Jeremy Rowley, Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Sep 26, 2013, 6:19:14 PM9/26/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 27, 2013, 6:11:58 PM9/27/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Sep 28, 2013, 12:34:38 AM9/28/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 1, 2013, 5:08:08 AM10/1/13
to Jeremy Rowley, Brian Smith, Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Oct 1, 2013, 5:08:08 AM10/1/13
to Jeremy Rowley, Brian Smith, Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Oct 1, 2013, 5:08:08 AM10/1/13
to Jeremy Rowley, Brian Smith, Patrick Tate, dev-secur...@lists.mozilla.org
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

unread,
Oct 1, 2013, 12:50:12 PM10/1/13
to mozilla-dev-s...@lists.mozilla.org
>>
>> 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

unread,
Oct 1, 2013, 1:20:57 PM10/1/13
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 2, 2013, 12:50:57 AM10/2/13
to dev-secur...@lists.mozilla.org
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

unread,
Oct 6, 2013, 10:36:53 AM10/6/13
to dev-secur...@lists.mozilla.org
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

unread,
Oct 6, 2013, 2:52:49 PM10/6/13
to Kaspar Brand, dev-secur...@lists.mozilla.org
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

unread,
Oct 6, 2013, 3:06:54 PM10/6/13
to Kaspar Brand, dev-secur...@lists.mozilla.org
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

unread,
Oct 8, 2013, 1:16:54 AM10/8/13
to dev-secur...@lists.mozilla.org
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

disable-cybertrust-ev.diff

Chema Lopez

unread,
Oct 9, 2013, 6:19:20 AM10/9/13
to Brian Smith, dev-secur...@lists.mozilla.org, Kaspar Brand
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

unread,
Oct 19, 2013, 2:13:46 AM10/19/13
to dev-secur...@lists.mozilla.org
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

unread,
Oct 19, 2013, 6:15:50 AM10/19/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 22, 2013, 2:02:03 PM10/22/13
to mozilla-dev-s...@lists.mozilla.org
>> 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

unread,
Oct 22, 2013, 2:20:17 PM10/22/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 22, 2013, 4:19:11 PM10/22/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 23, 2013, 3:31:44 PM10/23/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 23, 2013, 4:03:12 PM10/23/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 23, 2013, 6:14:34 PM10/23/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 3:03:43 AM10/24/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 1:01:28 PM10/24/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 2:45:23 PM10/24/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 5:43:46 PM10/24/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 5:47:53 PM10/24/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 6:46:15 PM10/24/13
to "Michael Ströder", mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 6:49:04 PM10/24/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 24, 2013, 8:36:38 PM10/24/13
to ryan-mozde...@sleevi.com, "Michael Ströder", mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 25, 2013, 4:47:11 PM10/25/13
to

> 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

unread,
Oct 25, 2013, 5:27:15 PM10/25/13
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 25, 2013, 6:39:39 PM10/25/13
to Rick Andrews, dev-secur...@lists.mozilla.org
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

unread,
Oct 28, 2013, 2:31:04 PM10/28/13
to
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

unread,
Oct 28, 2013, 3:14:25 PM10/28/13
to Rick Andrews, dev-secur...@lists.mozilla.org
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

unread,
Oct 28, 2013, 3:27:16 PM10/28/13
to Brian Smith, Rick Andrews, dev-secur...@lists.mozilla.org
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

unread,
Oct 28, 2013, 3:28:51 PM10/28/13
to Brian Smith, Rick Andrews, dev-secur...@lists.mozilla.org
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

unread,
Oct 28, 2013, 3:32:21 PM10/28/13
to dev-secur...@lists.mozilla.org
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

unread,
Oct 28, 2013, 3:42:46 PM10/28/13
to Jeremy Rowley, dev-secur...@lists.mozilla.org, Rick Andrews
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

unread,
Oct 28, 2013, 3:51:13 PM10/28/13
to Stephen Davidson, dev-secur...@lists.mozilla.org, Rick Andrews
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

unread,
Oct 28, 2013, 3:54:12 PM10/28/13