DRAFT April 2021 CA Communication and Survey

380 views
Skip to first unread message

Ben Wilson

unread,
Apr 6, 2021, 7:20:18 PM4/6/21
to dev-secur...@mozilla.org
All,

Kathleen and I have drafted a potential CA Communication and survey, and will greatly
appreciate your input on it.


Note that the links in the Survey will be updated this week to point to Mozilla Root Store Policy v. 2.7.1. (They currently point to MRSP version 2.7.)  However, MRSP v. 2.7.1 is still available here: 

Thanks,

Ben

Corey Bonnell

unread,
Apr 7, 2021, 2:10:54 PM4/7/21
to Ben Wilson, dev-secur...@mozilla.org

Hi Ben,

I have two comments on the survey:

 

  1. Items 4-6 have responses that separate “our Audit Team is aware” vs. “we will advise our auditor”. Is the expectation that CAs discuss these changes with their auditor prior to submitting the survey (as that seems to be the only way to accurately answer these questions)? If that’s the case, then I think a general statement at the top of the Survey requesting CAs to discuss the changes with their auditor prior to completion of the Survey and the removal of the “we will advise our auditor” option will clarify expectations.
  2. Item 8 has a cutoff date of July 1st, 2012 for pre-BR root certificates. While this is the effective date of v1.0 of the BRs, Mozilla did not require adherence to the BRs until v2.1 of Mozilla Policy, which had an effective date of February 15, 2013 [1]. Given this, it may be preferable to align the cutoff date on when Mozilla first required CAs to adhere to the BRs.

 

Thanks,

Corey

 

[1] https://wiki.mozilla.org/CA:CertificatePolicyV2.1

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ec2dd1bd-d5ed-428d-8119-de2e91e3de44n%40mozilla.org.

Ryan Sleevi

unread,
Apr 7, 2021, 2:38:26 PM4/7/21
to Corey Bonnell, Ben Wilson, dev-secur...@mozilla.org
On Wed, Apr 7, 2021 at 2:10 PM 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:
  1. Item 8 has a cutoff date of July 1st, 2012 for pre-BR root certificates. While this is the effective date of v1.0 of the BRs, Mozilla did not require adherence to the BRs until v2.1 of Mozilla Policy, which had an effective date of February 15, 2013 [1]. Given this, it may be preferable to align the cutoff date on when Mozilla first required CAs to adhere to the BRs. 


Note that Mozilla did not actually enforce their policy until after May 2014, as shown by the CA Communications sent at that time [1] and the responses of notable non-compliance.

If memory serves, it was not until May 2016 (as shown by the May 2015 communication still having significant non-BR-audited roots that were subsequently removed) [2]

Ben Wilson

unread,
Apr 9, 2021, 5:37:31 PM4/9/21
to Ryan Sleevi, Corey Bonnell, dev-secur...@mozilla.org
Ryan and Corey,
Thanks for your comments. The reasons for these survey questions (e.g. Item 8 with dates of July 1 2006 and 2012) is to gather information and to get CAs thinking. We can fine-tune the cut-off dates and proposed schedule once we have more information. If some CAs have plans to retire roots created in the 2012-2016 timeframe, that would be good to know, and so we could create an additional question for that, but the discussion has to start somewhere.
Thoughts?
Thanks again,
Ben

dr. Szőke Sándor

unread,
Apr 12, 2021, 9:08:28 AM4/12/21
to Ben Wilson, dev-secur...@mozilla.org

Hi Ben,

 

let me have a comment to the "ITEM 8:  Removal of Old Root CA Certificates"

 

I fully understand and support the idea of gradually phasing out pre-BR roots from the Trusted Root Store, but for some users, this can cause serious problems.

 

TLS certificates are only used during the validity time of the certificates, making it relatively easy to migrate to another CA hierarchy within a few years.

 

However, the Mozilla root store is used not only during website authentication by browser, but also in many other PKI applications.

The most critical is probably the digital signature when you have to preserve the validity of the signature for long term.

Timestamps are typically issued for more than ten years, and digitally signed and timestamped documents must be valid during this period.

If Mozilla completely removes a root certificate from the root store, it can cause problems for a huge number of signed documents during the validation, because the certificate chain cannot be built to a valid and trusted anchor.

 

Can it be an option to clear only the TLS trust bit of the old roots instead of completely distrust them?

 

 

Best Regards,

 

Sándor

 

Dr. Sándor SZŐKE

dep. Director of eIDAS Trust Services

 

 

Microsec Ltd.  |  Ángel Sanz Briz Road 13.

Budapest, H-1033 Hungary
Graphisoft Park Southern Area, Building C, 3th floor

T: +36 1 802-4418  |   +36 1 505-4477 / 488
sandor...@microsec.com
microsec.com

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
Sent: Wednesday, April 7, 2021 1:20 AM
To: dev-secur...@mozilla.org
Subject: DRAFT April 2021 CA Communication and Survey

 

All,

--

image001.png

Ryan Sleevi

unread,
Apr 12, 2021, 9:34:39 AM4/12/21
to dr. Szőke Sándor, Ben Wilson, dev-secur...@mozilla.org
On Mon, Apr 12, 2021 at 9:08 AM dr. Szőke Sándor <szoke....@microsec.hu> wrote:

However, the Mozilla root store is used not only during website authentication by browser, but also in many other PKI applications.

The most critical is probably the digital signature when you have to preserve the validity of the signature for long term.

Timestamps are typically issued for more than ten years, and digitally signed and timestamped documents must be valid during this period.


By who?

Mozilla's trust store has never involved these trust purposes, so it seems like a misuse if someone is assuming a set of TLS and S/MIME CAs are appropriate for timestamping documents. Even the old object signing purpose (for Java JARs) wasn't appropriate for this.

Do you have examples of such applications? 

Kathleen Wilson

unread,
Apr 12, 2021, 1:32:28 PM4/12/21
to dev-secur...@mozilla.org, dev-secur...@mozilla.org, szoke....@microsec.hu
This helps me prioritize one of the items on my to-do list, which is to write a security blog post to remind folks that they should always consider the trust bits for the root certificates in the root store that they are using, because root store managers only verify that the CA is following the rules for those trust bits.

If you know people who are incorrectly trusting the NSS root store (aka Mozilla root store) for usages other than TLS server authentication and S/MIME, please point them to https://www.ccadb.org/resources where they can find a list of the root certificates that Microsoft has the Code Signing trust bit enabled for. This list is pulled directly from the CCADB, in which Microsoft maintains the data pertaining to their root store.

Thanks,
Kathleen

Ben Wilson

unread,
Apr 12, 2021, 5:47:57 PM4/12/21
to dev-secur...@mozilla.org
All,

I am still looking for any additional input on the draft CA survey.

I have revised proposed question 8 as follows:

ITEM 8: Removal of Old Root CA Certificates

Mozilla intends to work towards removal of old root CA certificates (e.g. those created before the EV Guidelines and then before the Baseline Requirements). To ensure complete compliance with the Baseline Requirements, we would like to get to the point that all root certificates issued before 1 July 2012 (BR effective date) are removed and replaced in our root store. We will appreciate your input into creating a plan to achieve this goal.

8.a. What challenges should Mozilla anticipate in this effort to remove older root CA certificates?

8.b. What alternative strategies should Mozilla adopt in this effort to remove older root CA certificates?

8.c. What, if any, are your 3-year timeline and strategies to replace any of your Mozilla-trusted root CAs that were created before 1 July 2006?

8.d. What, if any, are your longer-term timeline and strategies to replace any of your Mozilla-trusted root CAs that were created between 1 July 2006 and 1 July 2012?


I'm hoping to get as much useful feedback on this issue as possible, so if you have suggested wording changes or additional questions, let me know.

Thanks,


Ben



--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0fdb8a30-6e02-4d92-b640-561332157c1an%40mozilla.org.

Ponds-White, Trevoli

unread,
Apr 12, 2021, 7:51:21 PM4/12/21
to Ben Wilson, dev-secur...@mozilla.org

I had similar feedback as Corey.

 

For Item 4 what is the distinction between:

We intend to comply and our Audit Team is aware of these requirements.

And

We intend to comply, and we will advise our auditor about these requirements before they issue our next audit statements.

 

Maybe just make the second option: We intend to comply, and we have/will advise our auditor about these requirements before they issue our next audit statements.

 

Similar feedback for Items 5 and 6.

 

I think the changes you propose for 8 make it more clear that you are looking for feedback not introducing a new requirement. For 8 maybe add “What information can Mozilla provide that would help CAs with this effort?”

 

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
Sent: Monday, April 12, 2021 14:48
To: dev-secur...@mozilla.org
Subject: RE: [EXTERNAL] DRAFT April 2021 CA Communication and Survey

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

dr. Szőke Sándor

unread,
Apr 13, 2021, 8:43:08 AM4/13/21
to Kathleen Wilson, dev-secur...@mozilla.org, dev-secur...@mozilla.org

I know that the primary focus of Mozilla is Network Security, but NSS is a free and open source library that is widely used in several software projects.

NSS supports standard PKCS functions that are very useful if you need to communicate with hardware devices such as HSM or PKI tokens or smartcards.

It is also an advantage that it is available on different platforms.

These features makes NSS an ideal tool for digital signature creation and validation applications.

However, I understand that Mozilla has never guaranteed supporting these types of use cases, so it is the risk of the developers to use this product this way.

 

This type of use does not necessarily mean that the same ICA is used for issuing TLS certificates and Signing certificates.

Mozilla Root Store trust root certificates, not intermediate certificates, which makes it possible to set up separate ICA-s to issue TLS certificates and other type of certificates.

CA-s can issue certificates for digital signing by using dedicated CA-s and not TLS CA-s.

CABF Code Signing BR Appendix B contains explicit requirements for subordinate CA-s that exclusively issue Code Signing and/or Timestamping certificates.

 

I did a quick survey. I know many of our partners used NSS years ago, but I have no information about the current situation.

Microsec has also used NSS in the past, but it is not currently used in our applications.

 

If Mozilla intends to support this use case, it would be good idea to ask other CA-s about this as part of the planned survey.

 

 

Best Regards,

Sándor

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Ryan Sleevi

unread,
Apr 13, 2021, 1:39:39 PM4/13/21
to dr. Szőke Sándor, Kathleen Wilson, dev-secur...@mozilla.org
I think you're conflating two very different things.

You're correct that NSS, as a software library, can and is used in a variety of applications, including to support digital signatures. That's entirely fine and reasonable.

However, the Mozilla Root Certificate Store, which is included in NSS, has only ever supported three explicit purposes, themselves reflected throughout the code and API contracts: TLS (as used by Mozilla Firefox), S/MIME (as used by Mozilla Thunderbird), and Code Signing (as used by a long-discontinued experiment regarding JavaScript signing). CAs included in the Mozilla Root Certificate Store are only enabled for those explicit purposes, and only after review for those policies against those purposes.

That means that even if a root is included, for TLS, it cannot be assumed to be trusted for any other purpose, whether S/MIME (a supported purpose) or document signing (a never-supported purpose). Any use/assumption of that is unquestionably a critical security vulnerability in the product making that assumption, and if you're aware of such products, you should absolutely report it as a critical security vulnerability, as it is functionally no different than the failure to validate signatures at all.

Mozilla's own FAQ [1] has long stated something to that effect, since 2014 [2]

So using NSS for digital signature creation and validation applications is fine, but it means you, the application developer, need to supply a trust store appropriate for and specific for that case. NSS already provides all of that functionality, as a programming library, to supply your own root store for purposes not supported (and never supported) by Mozilla's Root Store that is presently included by default within NSS.


Bruce Morton

unread,
Apr 13, 2021, 5:23:56 PM4/13/21
to dev-secur...@mozilla.org, bwi...@mozilla.com
Ben, it would be great if the survey could provide a problem statement as to why roots need to be removed. This would help the CAs with 8.b and provide alternative strategies to address the problem.

Thanks, Bruce.

Ryan Sleevi

unread,
Apr 13, 2021, 8:35:35 PM4/13/21
to Bruce Morton, dev-secur...@mozilla.org, bwi...@mozilla.com
Doesn't the current question already include that (emphasis added via ** and bold below)

Mozilla intends to work towards removal of old root CA certificates (e.g. those created before the EV Guidelines and then before the Baseline Requirements). **To ensure complete compliance with the Baseline Requirements, we would like to get to the point that all root certificates issued before 1 July 2012 (BR effective date) are removed and replaced in our root store**. We will appreciate your input into creating a plan to achieve this goal.


So is there further detail to be expanded upon, given CAs should be following m.d.s.p. and policy discussions? Just curious what sort of improvements would be useful here to the language, since it seemed plain from the existing feedback.

Ben Wilson

unread,
Apr 14, 2021, 1:19:16 AM4/14/21
to Ponds-White, Trevoli, dev-secur...@mozilla.org
On Mon, Apr 12, 2021 at 5:51 PM Ponds-White, Trevoli <trev...@amazon.com> wrote:

I had similar feedback as Corey.

 

For Item 4 what is the distinction between:

We intend to comply and our Audit Team is aware of these requirements.

And

We intend to comply, and we will advise our auditor about these requirements before they issue our next audit statements.

 

Maybe just make the second option: We intend to comply, and we have/will advise our auditor about these requirements before they issue our next audit statements.


Similar feedback for Items 5 and 6.


I've made changes to Items 4, 5 and 6. 

 

I think the changes you propose for 8 make it more clear that you are looking for feedback not introducing a new requirement. For 8 maybe add “What information can Mozilla provide that would help CAs with this effort?”

 


I've added that question and I also changed 8.b. to say, "What alternative strategies might Mozilla adopt that can be used to reasonably track the removal of older, non-BR-compliant root CA certificate hierarchies?"

Rob Stradling

unread,
Apr 14, 2021, 7:09:59 AM4/14/21
to ry...@sleevi.com, Bruce Morton, dev-secur...@mozilla.org, bwi...@mozilla.com
Hi Ryan.  I've reviewed the links that you provided to Bruce, but I'm still unclear about the real motivation for this.
 
Consider the case of a CA that is able to provide a Root Key Generation Ceremony report and cradle-to-now contiguous period-of-time audit reports for a Root Certificate and its Private Key that were issued/generated prior to the effective date of BRs v1.0.

Why would such a Root Certificate need to be removed?
In particular, can you provide a list of the relevant BR requirements that you believe such a CA would be unable to demonstrate that they were compliant with prior to 1st July 2012?

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ryan Sleevi <ry...@sleevi.com>
Sent: 14 April 2021 01:35
To: Bruce Morton <bruce....@entrust.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>; bwi...@mozilla.com <bwi...@mozilla.com>
Subject: Re: DRAFT April 2021 CA Communication and Survey
 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Ryan Sleevi

unread,
Apr 14, 2021, 11:31:07 AM4/14/21
to Rob Stradling, ry...@sleevi.com, Bruce Morton, dev-secur...@mozilla.org, bwi...@mozilla.com
On Wed, Apr 14, 2021 at 7:09 AM Rob Stradling <r...@sectigo.com> wrote:
Consider the case of a CA that is able to provide a Root Key Generation Ceremony report and cradle-to-now contiguous period-of-time audit reports for a Root Certificate and its Private Key that were issued/generated prior to the effective date of BRs v1.0.

Why would such a Root Certificate need to be removed?
In particular, can you provide a list of the relevant BR requirements that you believe such a CA would be unable to demonstrate that they were compliant with prior to 1st July 2012?

I definitely appreciate the thought experiment being posed, and am sensitive to how it attempts, whether intentionally or not, to shift the burden of evidence of discussion. It might be useful for the discussion if you could give such an example. Personally, I'm not aware of one existing, and so it might be a useful exercise to demonstrate concretely how things have changed or may not be sufficient, using an example CA you believe would meet this criteria. I think the challenges surrounding such audits, both in terms of when and how the first version of WebTrust SSL BRs was structured, with its clear effective date requirement, and in terms of auditor experience and understanding in those requirements, strongly suggests that there will be difficulties doing so.

However, even if we were to assume that such a hypothetical report exists, it seems that underlying the question is a potential assumption that "contemporaneously good enough" is "good enough for the future". Or, put differently, if something was fine at time X, there are no facts or understandings that may reveal at any time greater than X that what was provided at time X was insufficient.

To avoid falling into the same rhetorical trap I'm pointing out that you slipped into, I'll give a concrete example. Consider the recent efforts regarding audit letter validation, and ensuring that the scope was appropriate inclusive. It would hopefully be uncontroversial to point out that a number of CAs, and, in turn, a number of auditors, had historically failed to achieve clean ALV results, omitting key pieces of infrastructure that were relevant to understanding the CA operations, and which were only noticed due to the heroic efforts of Kathleen, Ben, and Wayne at Mozilla, and the support from Mike, Karina, and Jody at Microsoft in the infrastructure enabling ALV. What conclusions should be drawn now regarding those audit reports prior to the ones that failed ALV validation, and how should that provide assurance to relying parties in the present day? It seems reasonable to say that "the assurance we have now is less than we had at the time, because the report hasn't changed, but the understanding has".

One can extrapolate this sort of chronological impedance across the WebTrust SSL BRs, Mozilla policy, and the BRs themselves: how many times have things believed to been clear and uncontroversial (such as "no interception CA certificates") had to been clarified post-incident? What conclusions can or should be drawn about reports or CAs prior to those clarifications, where either the auditor or the CA may have incorrectly believed such actions were permitted?

Likewise, when we look at such seminal work as ZLint [1], we can see that there's a whole lot of historic misissuance that was not reflected in audits, or necessarily disclosed, contemporaneously or after the fact. How should such situations be handled? I think a good example of this discussion having played out was during the Symantec distrust, in which several 3P CAs (under the GeoTrust brand) had demonstrated significant and meaningful non-compliance, despite Symantec asserting that Symantec themselves had met the obligations solely by virtue of obtaining audit reports, even if they failed to take appropriate action to correct the issues.

Ultimately, audit reports provide a reflection of the current auditor's understanding, tempered by the CA's current understanding of the requirements, but provides little assurance after the fact when it's revealed that either the auditor or the CA failed to understand or meet the obligation. Not only do they reflect the issuance, but also the infrastructure and operation of it, ranging from physical security and key protection to validation processes and people. When it comes to trust, the bedrock of the CA ecosystem, this undercuts it, and the only ability to redress that is to "start clean", from a known point in time, and work forwards.

For lack of a better analogy, and since this message started with a thought experiment posed by you and it feels appropriate to close on one, imagine a bank account for which the starting balance is unknown. Imagine there are now a series of deposits and withdrawals to this account. For most of the deposits, and most of the withdrawals, the sum of that transaction is known, although there are some that are not known (perhaps the receipts were lost, the ink has smudged, or the method of calculating it later turned out to be wrong). What is the ending balance of that bank account? The answer is ineffable, because without a solid foundation, and without solid accounting throughout, no one can really say. Even with perfect record keeping of the deposits/withdrawals, we might be able to suppose what the difference in the account is, but that doesn't say what the absolute value is.

While the above remarks are in a personal capacity, given the long-standing (and long-documented in this Forum) personal interest in this exact matter, and by no means authoritative for Mozilla, I think you can also refer to past discussions in this Forum about regularly requiring roots to rotate, in order to ensure a continued "start from a solid foundation". These are not new discussions - here's something from just under 4 years ago discussing these principles. [2]

(Wearing a Google Hat) It's these principles that have lead, unsurprisingly, to the top-most priority given to CA requests in the Chrome Root Policy [3] is to "CAs that are widely trusted, and which are replacing older certificates with certificates and key material created within the past 5 years". That, more than anything else, is what we give priority in processing to (explicitly, the replacement, not the addition), and which will almost certainly become a mandatory requirement in the future. While Mozilla has chosen a much more conservative approach, currently proposing a rather shocking 9 years, the choice of 5 years was not accidental: it was the compromise between the more reasonably secure date of post-2019 (reflecting ZLint and ALV becoming mainstream) and the post-2016 period where both Google and Mozilla, enabled by Certificate Transparency, were able to more consistently enforce their policies and the Baseline Requirements on the CAs that reportedly adhered to them, but in practice did not.

dr. Szőke Sándor

unread,
Apr 14, 2021, 1:44:16 PM4/14/21
to ry...@sleevi.com, Kathleen Wilson, dev-secur...@mozilla.org

You are right, NSS supports building an application- and customer-specific own root store.

 

The customer should be able to choose the CA she/he trusts and the ASP shall provide a list of roots that are technically compatible with its application.

 

It is already possible and if a CA announces the planned removal of a given root in advance, the ASPs will have enough time to make the necessary developments on their systems.

 

This means that removing a root in 3-year time should not cause great problems for users, because by that time the application will be ready to validate the signature using a method other than the standard NSS internal root store.

Reply all
Reply to author
Forward
0 new messages