Hi Ben,
I have two comments on the survey:
Thanks,
Corey
--
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.
- 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.
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,
--
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.
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.
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. |
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabLTPwTMyP1TPskR-naHQGsvNcg9V94c9NTUAV3q9vuBw%40mail.gmail.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/017a01d73062%248ae79500%24a0b6bf00%24%40microsec.hu.
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.
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?”
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?
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.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGK2igvNvvDGZSM1jNzW%2Bt3LCPLmmgo1p5F7aekt8f-8Q%40mail.gmail.com.