|
|
| (48 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| === Process for Updating the Policy ===
| | __NOTOC__ |
|
| |
|
| The general process that will be followed to update the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] is as follows:
| | ==2.9== |
| # Public discussion to identify the list of things to consider adding or clarifying in the policy.
| |
| # Public Discussion of each item in the list determined in #1.
| |
| #* General agreement on intent of the item
| |
| #** A representative of Mozilla will state when the official position of Mozilla differs from what has been posted in a discussion.
| |
| #* Propose and discuss how to modify the policy for the item
| |
| # Draft updated policy.
| |
| # Create a bug in Mozilla's [http://bugzilla.mozilla.org/ Bugzilla issue tracking system.]
| |
| #* The bug should be left open for a reasonable amount of time after closing the newsgroup discussion before implementing the update, in order to provide adequate opportunity to ensure all issues have been discussed.
| |
| # Continue Public Discussion
| |
| #* Discuss the draft updated policy, e.g. the actual text changes/additions to be made to the policy and differences from the previous version.
| |
| #* A representative of Mozilla will summarize a consensus that has been reached, and/or state the official position of Mozilla.
| |
| # Approval of final draft.
| |
| #* Close discussion, and recommend approval in bug.
| |
| #* After reasonable amount of time, approve changes in bug.
| |
| # Post official update.
| |
| # Notify people of the update.
| |
| #* Post notice in the m.d.s.policy, m.d.security, and m.governance forums.
| |
| #* Send email communication to CAs, indicate date by which they should comply with the updated policy.
| |
|
| |
|
| A [https://wiki.mozilla.org/Modules/Activities#Mozilla_CA_Certificate_Policy Mozilla CA Certificate Policy Module Owner or a Peer] performs the following actions.
| | * [https://github.com/mozilla/pkipolicy/blob/2.9/rootstore/policy.md Policy document] |
| * Moderate the public discussions | | * Finalized date (GitHub): September 1, 2023 |
| ** State the official position of Mozilla when it differs from the discussion | | * Publication date (www.mozilla.org): September 12, 2023 |
| * Propose the draft of the changes to make to the policy | | * Effective (compliance) date: September 1, 2023 |
| * Create the corresponding bug, recommend approval, approve the bug.
| | ** For CAs capable of issuing email certificates, for audit periods ending after October 30, 2023, period-of-time audits must be performed in accordance WebTrust/ETSI criteria |
| * Post the official policy update, after another Mozilla representative, such as a CA Certificate Policy Module Owner or a Peer, has reviewed and approved the changes. | | ** For CAs capable of issuing TLS server certificates, compliance self-assessments must be submitted for “BR Audit Period End Dates” after December 31, 2023 |
| * Posts notices in discussion forums and sends communication to CAs. | | * [https://github.com/mozilla/pkipolicy/pull/273/files List of changes and diff] |
|
| |
|
| === Previous Versions of the Policy === | | ==2.8.1== |
|
| |
|
| * [[CA:Policy|Changes to Mozilla's CA Certificate Policy]] -- How to view changes to the policy | | * [https://github.com/mozilla/pkipolicy/blob/2.8.1/rootstore/policy.md Policy document] |
| * [[CA:Policy#Snapshots_of_Previous_Versions_of_the_Policy | Snapshots of Previous Versions of the Policy]] | | * Finalized date (GitHub): January 31, 2023 |
| | * Publication date (www.mozilla.org): February 10, 2023 |
| | * Effective (compliance) date: February 15, 2023 |
| | * [https://github.com/mozilla/pkipolicy/pull/265/files List of changes and diff] |
|
| |
|
| [[CA:CertificatePolicyV2.0 | Version 2.0 of the Mozilla CA Certificate Policy]] was published on February 2, 2011. The changes are described in {{Bug|609945}}. For the list of items that were considered in this update [[CA:PolicyVersion2.0 | click here.]]
| | ==2.8== |
|
| |
|
| The Policy has been divided into three sections:
| | * [https://github.com/mozilla/pkipolicy/blob/2.8/rootstore/policy.md Policy document] |
| # Applying for Inclusion of Root Certificates in Mozilla Products
| | * Finalized date (GitHub): April 26, 2022 |
| #* This is mostly the original policy, so diff information between this section and version 1.2 of the policy was provided in [https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c4 bug #609945.]
| | * Publication date (www.mozilla.org): April 29, 2022 |
| # Maintaining Confidence in Included Root Certificates
| | * Effective (compliance) date: June 1, 2022, except: |
| #*This section is completely new.
| | ** July 1, 2022: CAs SHALL NOT sign SHA-1 hashes over end entity certificates with an EKU extension containing the id-kp-emailProtection key purpose. |
| # Enforcing the Mozilla CA Certificate Policy
| | ** July 1, 2022: Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST be disclosed in the CCADB. |
| #* This section is completely new.
| | ** October 1, 2022: |
| | *** CA operators with intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store SHALL populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs. |
| | *** CAs MUST be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist, and MUST provide CRL and OCSP services and responses in accordance with the policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist. |
| | *** New Section 6.1.1 - When a TLS server certificate is revoked for keyCompromise, privilegeWithdrawn, cessationOfOperation, affiliationChanged, or superseded, the CRLReason MUST be included in the reasonCode extension of the CRL entry corresponding to the end entity TLS certificate. If the certificate is revoked for a different or unspecified reason, then the reasonCode extension MUST NOT be provided in the CRL. |
| | **** The CA operator's subscriber agreement for TLS server certificates [[CA/Revocation_Reasons#Communication_to_Subscribers|must inform certificate subscribers about the revocation reason options]], and tools must be updated to enable certificate subscribers to specify these revocation reason options. |
| | ** December 31, 2022: CA operators will need to maintain (in their online policy repository) all older (and available) versions of each CP and CPS (or CP/CPS), regardless of changes in ownership or control of the root CA, until the entire root CA certificate hierarchy operated in accordance with such documents is no longer trusted by the Mozilla root store. |
| | ** July 1, 2023: CAs SHALL NOT sign SHA-1 hashes over certificates with an EKU extension containing the id-kp-ocspSigning key purpose; intermediate certificates that chain up to roots in Mozilla's program; OCSP responses; or CRLs. |
|
| |
|
| [http://www.mozilla.org/projects/security/certs/policy/ Version 2.1 of the Mozilla CA Certificate Policy] was published on February 14, 2013. The changes are described in {{Bug|763758}}. For the list of items that were considered in this update [[CA:PolicyVersion2.1 | click here.]] | | * [https://github.com/mozilla/pkipolicy/pull/245/files List of changes and diff] |
|
| |
|
| === Transitioning to the Updated Policy Version 2.0=== | | ==2.7.1== |
|
| |
|
| [[CA:CertificatePolicyV2.0 | Version 2.0 of the Mozilla CA Certificate Policy]] was published on February 2, 2011. | | * [https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.7.1/rootstore/policy.md Policy document] |
| * All CAs with root certificates in Mozilla products shall be in full compliance with [[CA:CertificatePolicyV2.0 | Version 2.0 of the Mozilla CA Certificate Policy]] no later than August 8, 2011. | | * Finalized date (GitHub): March 30, 2021 |
| * Certificates issued before August 8, 2011, must at least meet the requirements of [[CA:CertificatePolicyV1.2 | Version 1.2 of the Mozilla CA Certificate Policy.]] | | * Publication date (www.mozilla.org): April 12, 2021 |
| * Any certificate authority requesting a root inclusion/update after February 2, 2011 must comply with [[CA:CertificatePolicyV2.0 | Version 2.0 of the Mozilla CA Certificate Policy.]] | | * Effective (compliance) date: May 1, 2021, except: |
| * CAs should comply with the latest published policy when they do their annual audit, and this should be checked by a Mozilla representative when their annual audit report becomes available.
| | ** October 1, 2021: CAs MUST validate dNSName or IPAddress in SAN/commonName within 398 days prior to certificate issuance |
| | ** July 31, 2021: CAs MUST update section 4.9.12 of their CPSes to clearly specify the methods that parties may use to demonstrate private key compromise |
|
| |
|
| '''Note:''' I have been informed by some CAs that more time is needed to replace certain certificates that have been issued to customers, or to allow customers time to implement the necessary infrastructure changes to support the new certs. I will be separately tracking the exceptions that I have been informed of, and have agreed to (e.g. there are valid reasons for these exceptions).
| | * [https://github.com/mozilla/pkipolicy/pull/223/files List of changes and diff] |
|
| |
|
| === Transitioning to the Updated Policy Version 2.1=== | | ==2.7== |
|
| |
|
| [https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy Click here] to see the time frames for included CAs to comply with the changes in version 2.1 of Mozilla's CA Certificate Policy. | | * [https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.7/ccadb/policy.md Common CCADB Policy] |
| | * Publication date: December 10, 2019 |
| | * Effective (compliance) date: January 1, 2020, except: |
| | ** April 1, 2020: CPs and CPSes published after this date MUST be structured according to RFC 3647 and MUST: |
| | *** Include at least every section and subsection defined in RFC 3647; and, |
| | *** Only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and, |
| | *** Contain no sections that are blank and have no subsections. |
| | ** July 1, 2020: End-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage. |
| | * [https://github.com/mozilla/pkipolicy/pull/199/files List of changes and diff] |
|
| |
|
| === Transitioning to the Updated Policy Version 2.2=== | | ==2.6.1== |
|
| |
|
| [https://wiki.mozilla.org/CA:CertificatePolicyV2.2 Click here] to see the time frames for included CAs to comply with the changes in version 2.2 of Mozilla's CA Certificate Policy. | | * [https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy] |
| | * Publication date: August 13, 2018 |
| | * Effective (compliance) date: August 13, 2018, except: |
| | ** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3 |
| | * [https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 List of changes and diff] |
|
| |
|
| === Consider for Version 2.3 === | | ==2.6== |
| ==== Corrections / Minor Updates ==== | |
| The following corrections are going to be made to Mozilla's CA Certificate Policy.
| |
|
| |
|
| # Update BR section numbers to correspond with BR version 1.3 that was published in April. https://cabforum.org/wp-content/uploads/RFC3647_Comparison_Table_for_Baseline_Requirements.pdf
| | * [https://github.com/mozilla/pkipolicy/blob/0fef6af7ea0455bd350c489c3d35be4ee2ce2567/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.6/ccadb/policy.md Common CCADB Policy] |
| #* Note that this also applies to the process/policy wiki pages.
| | * Publication date: June 29, 2018 |
| # Update item #12 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] to refer to a more recent version of the [https://www.cabforum.org/documents.html CA/Browser Forum Baseline Requirements]. And add "or later" to the BR version number.
| | * Effective (compliance) date: July 1, 2018, except: |
| #* Use BR version 1.3, but in a separate wiki page provide a timeline for CAs to come into compliance with the updated policy, similar to the [[CA:CertificatePolicyV2.2|wiki page for upgrading policy version 2.2]]
| | ** January 1, 2019: Separation of id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in newly created intermediate certificates as described in section 5.3 |
| # Remove "ISO 21188:2006 Public key infrastructure for financial services -- Practices and policy framework;" from item #11 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Inclusion Policy].
| | * [https://github.com/mozilla/pkipolicy/pull/143/files List of changes and diff] |
| # In the first bullet point of item #9 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy] remove the "after June 30, 2011" and add MD2 and MD4.
| |
| #* Current text: "after June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used;"
| |
| #* Proposed new text: "software published by Mozilla will return an error when a certificate with an MD2, MD4, or MD5-based signature is used;"
| |
| # Update the second bullet point of item #9 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy] to say that certs < 2048 bits now return an error.
| |
| #* Current text: "all end-entity certificates with RSA key sizes smaller than 2048 bits must expire by December 31, 2013;"
| |
| #* Proposed new text: "software published by Mozilla will return an error when SSL/TLS or Code Signing certificates have RSA key sizes smaller than 2048 bits."
| |
| # Delete the third bullet point of item #9 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy].
| |
| #* Current text to be deleted: "after December 31, 2013, Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits;"
| |
| # Update section 11 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Inclusion Policy] to refer to and link to more recent versions of the audit criteria.
| |
|
| |
|
| ==== To Be Discussed ==== | | ==2.5== |
| The following items will be discussed in regards to version 2.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy.] Please add any new suggestions at the end, to avoid changing the numbering.
| |
|
| |
|
| # Clean up the [[CA:Problematic_Practices#Other_considerations_when_updating_the_CA_Certificate_Policy|"Other considerations when updating the CA Certificate Policy"]] section of the [[CA:Problematic_Practices|Potentially Problematic Practices]] page. i.e. figure out which items should be put directly into Mozilla's CA Certificate Policy.
| | * [https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md Common CCADB Policy] |
| # [https://www.cabforum.org/documents.html CA/Browser Forum Baseline Requirements] version 1.1.6 added a requirement regarding technically constraining subordinate CA certificates, so item #9 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] may refer to the BR for details about how to technically constrain a subordinate CA certificate that can sign SSL certs.
| | * The "Mozilla CCADB Policy" document is now part of the main Policy |
| # Make the timeline clear about when the audit statements and disclosure has to happen for new audited/disclosed subCAs. According to the Baseline Requirements section 17 and 17.4, pre-issuance Readiness Audit is to be done before the SubCA begins issuing publicly-trusted certs. Then a complete audit is due within 90 days of issuing the first publicly-trusted cert.
| | * Publication date: June 23, 2017 |
| # In item #8 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy] recommend that CAs avoid SHA-512 and P-521, especially in their CA certificates. This is to ensure interoperability, as SHA-512 and (especially) P-521 are less well-supported than the other algorithms. (Note: On the page you linked to, P-521 is incorrectly spelled "P-512".)
| | * Compliance date: June 23, 2017, except: |
| #* Update reference to SHA-512 -- {{Bug|1129083}}
| | ** Technical constraints for email intermediates, which is ('''erratum''') November 15, 2017 for existing non-qualifying intermediates to cease issuing, and April 15 2018 for them to be revoked or audited |
| #* Update reference to P-512 -- {{Bug|1129077}}
| | ** Using the Ten Blessed Methods for domain validation, which is July 21, 2017 |
| # Make it clearer that producing [https://mozillacaprogram.secure.force.com/Communications/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented syntactically valid certificates] is '''required'''. In particular, I think that Mozilla should audit a CA's recently-issued certificates and automatically reject a CA's request for inclusion or membership renewal if there are a non-trivial number of certificates that have the problems mentioned in [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Mozilla's list of Things for CAs to Fix]]
| | * [https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 List of changes and diff] |
| # When an OCSP response signing certificate expires before the OCSP responses signed by the certificate expire, multiple websites break, particularly sites that use OCSP stapling. Make it a requirement that every OCSP response must have a nextUpdate field that is before or equal to the notAfter date of the certificate that signs it. This should be easy for CAs to comply with.
| |
| # Add a requirement that every OCSP response must have a nextUpdate field. This is required to ensure that OCSP stapling works '''reliably''' with all (at least most) server and client products.
| |
| # Add a requirement that the nextUpdate field must be no longer than 72 hours after the thisUpdate field, i.e. that OCSP responses expire within 3 days, for every certificate, for both end-entity certificates and CA certificates.
| |
| # Make it very clear that a CA with a root certificate included in Mozilla's program is ultimately responsible for every certificate issued that directly or indirectly chains up to the included certificate. If a CA's subcontractors (RAs, subCAs, etc.) have their own practice documentation, it must be inclusive of the CA's practices.
| |
| #* The subcontractors may have their own practices '''in addition''' to the practices that the CA's CP/CPS impose on them. And the CA's CP/CPS must impose practices that are in line with Mozilla's CA Certificate Policies and CA/Browser Forums Baseline Requirements (depending on the types of certs the function '''is capable''' of issuing).
| |
| #* The contracting CA must include documentation about the policies/practices that they require the contracted CA to comply with (i.e. in regards to the BRs and Mozilla policy). So the contracting CA's CPS needs to say that the contracted CA must include those things in their CPS, and be audited accordingly.
| |
| #* The subcontractor may have their own audit, but it is the CA's responsibility to ensure proper auditing is happening, and to publicly disclose such audits according to section 10 of Mozilla's CA Certificate Inclusion Policy.
| |
| #* The CA is responsible for making sure their subcontractors are acting in accordance with Mozilla's CA Certificate Policy and the BRs, including practices and audits. If it is found that a certificate has been mis-issued in the CA's hierarchy, the CA will be held accountable for the mistake, and the root certificate may be removed according to Mozilla's CA Certificate Enforcement Policy.
| |
| # Add requirement for CAs to send Mozilla revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. <https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates>
| |
| #* [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates|When to notify Mozilla]]
| |
| #* Time frames for notifying Mozilla, and time frames for the change to happen in OneCRL
| |
| # Add requirement for CAs to send Mozilla revoked end-entity certificates under certain circumstances by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. <https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates>
| |
| #* [[CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates|When to notify Mozilla]]
| |
| #** e.g. CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as: Wrong Key Usage, Certificate issued for a domain to somebody that doesn't own/control that domain, Mistakenly set isCA=true
| |
| #** The cert was issued or used in a way not consistent with the BRs.
| |
| #* Time frames for notifying Mozilla, and time frames for the change to happen in OneCRL
| |
| # For Code Signing certs, add requirement to comply with the CA/Browser Forum's Code Signing BRs.
| |
| # Consider requiring CAs to publish all issued SSL certs issued by non-technically-constrained certificates. CT is one possible way to meet this requirement.
| |
| #* [https://groups.google.com/d/msg/mozilla.dev.security.policy/czwlDNbwHXM/axKc1KSG5KkJ From m.d.s.policy:] Although CT would not have prevented issuance, requiring CT for all certificates would have detected the misissuance much sooner. Maybe Mozilla should be the first to require CT for all certificates?
| |
| # Consider adding "except as permitted under CT" to item #4 of the Inclusion Policy, where it says "duplicate issuer names and serial numbers". Then it becomes: "…duplicate issuer names and serial numbers, except as permitted under CT;”
| |
| #* Bugzilla {{Bug|1016587}}
| |
| #* Note that version 1.2.2 of the BRs added Appendix B section 5: For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.
| |
| # Deprecate SHA-1 Hash Algorithms in certs.
| |
| #* https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
| |
| #* Bugzilla {{Bug|942515}}
| |
| # In item #11 of the Inclusion policy, remove ISO 21188:2006...
| |
| # Policy changes regarding [https://wiki.mozilla.org/CA:ImprovingRevocation Improving Revocation.]
| |
| # Audit equivalencies from Government CAs MUST incorporate the CABF BR into their local audit criteria.
| |
| # Add statement of purpose as described in the [https://groups.google.com/d/msg/mozilla.dev.security.policy/SzSGHbrcBe0/hSGt50rJfYMJ policy framework discussion.]
| |
| # Figure out a way to draw a line to say that certain types of actions cannot be taken by the same company/organization that includes the operation of a publicly trusted CA. Things to consider:
| |
| #* Government sanctioned/initiated/controlled projects
| |
| #* Legally forced participants
| |
| #* Ability for one corporation to completely support a spying system like PRISM functionality (physical lines, access nodes, data center/hosting resources, backbone level Internet controls, DNS etc.)
| |
| # Address issue of [https://groups.google.com/d/msg/mozilla.dev.security.policy/WveW8iWquxs/S2I8yC36y2EJ trustworthy CAs]
| |
| #* knowingly were involved in active attacks against internet users, e.g. by installing software without user consent
| |
| #* have a conflict of interest by being involved in the development or sales of software or hardware designed to perform man-in-the-middle attacks on SSL connections
| |
| # Make it clear in the [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Enforcement Policy] that disablement or removal of a root certificate may be scheduled for a future date, in order to allow for customers to transition off of the hierarchy to be distrusted.
| |
| # Simplify item #9 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] by using Baseline Requirements #9.7, "Technical Constraints in Subordinate CA Certificates via Name Constraints & EKU".
| |
| # ETSI seems to be changing their standards, or at least the numbering of them. TS 101 456 and TS 102 042 -> EN 319 411-4 (which is the 4th section of a wider standard, with the whole thing being numbered EN 319 401, note the 0). Updated every year. This change is part of a process numbered STF 458. Planned for draft publication in April 2014, and final in October 2015. This standard will then shadow CAB Forum requirements, and attempt to incorporate changes within 9 months (requires review by 27 member states). Arno and Inigo are the two people to talk to.
| |
| # If a government CA does not use a 3rd-party auditor, then the domains that they can issue for should be constrained.
| |
| #* Note that when scrolling through the Auditor column in the [http://www.mozilla.org/projects/security/certs/included/index.html included spreadsheet] it looks like distinguishing based on the auditing would only currently find one included CA. However, this still may be worth considering, as there are other CAs who have applied for inclusion and have their audits done by internal government organizations.
| |
|
| |
|
| ==== Will NOT Do ==== | | ==2.4.1== |
| ''These items have been considered and discussed in mozilla.dev.security.policy, and will '''not''' be added to Mozilla's CA Certificate Policy:''
| |
| # ''In item #8 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy] add DSA 2048. -- [https://groups.google.com/d/msg/mozilla.dev.security.policy/JFmDFlHILOY/KHJzcJezpnQJ Discussion result:]No, we should not add DSA support to Mozilla's CA Certificate Policy, and mozilla::pkix does not need to support DSA certificates.''
| |
|
| |
|
| === Items to Add/Update in the Policy ===
| | * [https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/mozilla.md Mozilla CCADB Policy] |
| | * Publication date: March 31, 2017 |
| | * Compliance date: March 31, 2017 (except "CP/CPS in English", which is June 1, 2017) |
| | * This version has no changes in normative requirements over version 2.4; it is a rearrangement and reordering of the existing policy. |
|
| |
|
| Below is a list of items to consider adding or clarifying in the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy]. Many of these items are already included in our current practices, and documented in either the [[CA:Recommended_Practices | Recommended Practices]] or the [[CA:Problematic_Practices | Potentially Problematic Practices]] wiki pages.
| | ==2.4== |
|
| |
|
| The purpose of this list is to itemize (and eventually prioritize) the items that we would like to discuss in regards to the Mozilla CA Certificate Policy. However, the end result could be that the item gets added to (or remains in) the Recommended Practices or Potentially Problematic Practices wiki page, rather than being added to the policy.
| | * [https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md Policy document], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md Common CCADB Policy], [https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/mozilla.md Mozilla CCADB Policy] |
| | * Publication date: February 28, 2017 |
| | * Compliance date: February 28, 2017 (except "CP/CPS in English", which is June 1, 2017) |
| | * [https://github.com/mozilla/pkipolicy/compare/2.3...2.4 List of changes and diff] |
|
| |
|
| '''Important: The information below includes a collection of comments to be considered when each item is discussed. These comments may not actually be in agreement with current or future policy or recommended practice.'''
| | ==2.3== |
|
| |
|
| ===== General =====
| | * [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Policy document] |
| Errors and minor tweaks that we should consider addressing in the next version of the policy.
| | * Publication date: December 19, 2016 |
| | * Compliance date: December 19, 2016 |
| | * [https://github.com/mozilla/pkipolicy/compare/2.2...2.3 List of changes and diff] |
|
| |
|
| * List is currently empty.
| | ==2.2== |
|
| |
|
| ===== RAs =====
| | * [https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md Policy document] |
| * Currently an RA is effectively a CA, so RAs must be subject to the same scrutiny as CAs.
| | * Publication date: July 26, 2013 |
| ** RAs are essentially doing cert issuance if the inputs to the signing process are controlled by completely automated systems implemented with hardcoded authentication tokens on systems outside of the CA's controls.
| | * Compliance date: July 26, 2013 ([[CA/CertificatePolicyV2.2#Time_Frames_for_included_CAs_to_comply_with_version_2.2_of_the_policy|more specific details]]) |
| ** The term “Reseller” means that the “parent” CA does all the CA functions, including all verifications, itself. This is different from RA. | | * List of changes: {{Bug|868144}} |
| ** RAs are third party entities which perform verification, i.e. a core function of the CA. According to WebTrust (http://www.webtrust.org/item27804.pdf): "The CA or RA verifies the identity of the subscriber in accordance with the CA’s established business practices (that may be contained in a certification practice statement), and then issues a digital certificate." And "An RA is an entity that is responsible for the identification and authentication of subscribers, but does not sign or issue certificates."
| |
| *** Does an RA issue certs? Does it verify identity? I think that any entity that has the operational and/or cryptographic ability to issue certs (directly, or by asserting identity to an entity that issues the certs) should be audited and publicly disclosed.
| |
| *** IMHO, the whole concept of RAs is directly against our policy, because they are not part of the audit (as you say), neither are they are not approved by us (which is what would still be missing). | |
| ** Audits are also necessary. How often would you propose that they happen? Must an audit be done of every RA before they begin operations? | |
| *** There needs to be some sort of auditing that covers the RAs, and the CPS should also address that. (maybe need similar delineations as in the sub-CA checklist?)
| |
| *** An audit should address how effective the certificate authority supervises any third-party entities such as RAs and subordinate CAs.
| |
| ** Following the Comodo incident, it is a Mozilla position that it is best practice not to have automated certificate issuance trigger-able by entities which have not been audited to the same standard as the CA.
| |
| ** The Mozilla position is that for every certificate issuance, the CA itself (as opposed to the RA) should perform some sort of check which is not fool-able by a rogue/compromised RA. This could be: | |
| *** Challenge/response with a contact from whois
| |
| *** Challenge/response with a "well-known" address at the domain
| |
| *** Download of a secret value at a defined URL on the domain
| |
| *** Telephoning the company and speaking to the CEO
| |
| *** or whatever. The key thing to avoid is the idea that an RA can say "please give me a certificate for domain X", and it gets issued without any interaction between the CA and the owners of domain X. That sort of thing leads to the problems we've had recently.
| |
| ** Mozilla does not object to the idea of third parties (RAs) doing some of the work of verifying statements to be inserted into certificates. This is often appropriate when a CA has a local RA who may have offices to whom applicants can report, or may know the local law and documents better.
| |
|
| |
|
| * Consider lessons learned from the [[CA:Comodo_Misissuance_Response | Comodo incident.]]
| | ==2.1== |
| ** Require that all CAs arrange things so that each RA issues from a different internally-operated subordinate cert.
| |
| ** Require that RAs are audited to the same standards as CAs.
| |
| ** Require that all RA functions are protected by two-factor authentication and/or IP address restrictions.
| |
| ** Require DNS Name Constraints to a specified number of [http://publicsuffix.org/ Public Suffixes] to be put on any non-leaf certificate the CA issues which it does not control (e.g. subordinate CAs).
| |
|
| |
|
| ===== Audits =====
| | * [[CA/CertPolicyV2.1|Policy document]] |
| | * Publication date: February 14, 2013 |
| | * Compliance date: February 14, 2014 ([[CA/CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy|more specific details]]) |
| | * Items considered: [[CA/PolicyVersion2.1]] |
| | * List of changes: {{Bug|763758}} |
|
| |
|
| * [[CA:Problematic_Practices#Improve_definition_of_.22independent.22.3B_add_idea_of_.22trustworthy.22 | Improve definition of independent; add idea of trustworthy]]
| | ==2.0== |
| ** Currently, the guidelines talk about an auditor having to be both "independent" and "competent". It has been suggested that the definition of independent should be changed to be more like that the inverse of the MPL's definition of You:
| |
| ** "For legal entities, "You" includes any entity which controls, is controlled by, or is under common control with You. For purposes of this definition, "control" means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity."
| |
| ** Additionally, a new "trustworthiness" requirement would be added, which would address some of the issues currently listed under "independent", such as being bound to render a true judgement. This is because one could imagine an auditor who was (under the above definition) independent and also competent, but may nevertheless always provide "the right result" on payment of a fee.
| |
|
| |
|
| ===== Compelled CAs =====
| | * [[CA/CertificatePolicyV2.0|Policy document]] |
| | * Publication date: February 2, 2011 |
| | * Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions) |
| | * Items considered: [[CA/PolicyVersion2.0]] |
| | * List of changes: {{Bug|609945}} |
|
| |
|
| * Hostile jurisdiction compelled certificate creation attack
| | ==Earlier== |
| ** Some CAs have been asked to update their CP/CPS to address concerns about being compelled by third parties to inappropriately issue an intermediate or end-entity certificate. Current recommendation from the discussions appears to be to provide information about which regulatory and legal framework/jurisdiction the CA is primarily beholden to; and add a statement that the CA will duly verify that an order from a government or other such organization is lawful before executing the order.
| |
| ** http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/a858fa5b15b88ac2#
| |
|
| |
|
| * [[CA:Problematic_Practices#Restrict_government_roots_to_their_TLDs | Restrict government roots to their TLDs]] | | * [[CA/CertificatePolicyV1.2|Version 1.2]] -- January 2008 |
| ** A suggestion for a future revision of the policy is: we should restrict government run/sponsored roots to only issuing certificates for the corresponding TLD. There are, of course, questions such as the following would need to be discussed.
| | * [[CA/CertificatePolicyV1.1|Version 1.1]] -- November 2007 |
| *** What defines a government root?
| | * [[CA/CertificatePolicyV1.0|Version 1.0]] -- November 2005 |
| *** What if they have all the necessary audits anyway?
| | * [[CA/CertificatePolicyV0.4|Version 0.4]] -- March 2004 |
| *** The purpose of this would be to limit the use of government roots to only within the government's jurisdiction. In the USA, however, federal, state, and local governments use the TLD ..gov. The federal government does not have jurisdiction over state and local Web sites and vice versa. How would this restriction apply to the Basque certificate authority Izenpe, whose jurisdiction lies entirely within Spain and the TLD .es?
| |
| ** This has been requested in regards to specific roots, such as CNNIC: Have Firefox provide a warning when the CNNIC ROOT CA is used to authenticate web sites outside the jurisdiction of the Chinese government.
| |
| ** [https://bugzilla.mozilla.org/show_bug.cgi?id=555701 Bug #555701]
| |
| ** Should the rules regarding constraining a CA to a TLD apply to all CAs, and not just government CAs?
| |
| | |
| * Disclosure of organizational hierarchy: In the Inclusion section in #6, add a bullet point that the CA must fully disclose the hierarchy of corporations, associations, or government agencies owning the CA.
| |
| | |
| ===== Policy Enforcement =====
| |
| | |
| * Penalty for CA mistakes
| |
| ** We need toothier responses for CAs breaking the rules. We can't keep playing the game of "when you catch us, we'll fix those ones."
| |
| ** In NSS it should be possible to mark a root certificate as "questionable". When a subscriber certificate chains to a questionable root, a warning popup should appear informing the user -- in brief terms readily understood by end-users -- that the safety expected by the user might not exist.
| |
| ** Sometimes, CAs, even CAs in Mozilla's trusted root list, make some of the same mistakes the amateurs make, mistakes like:
| |
| *** issuing certs with duplicate serial numbers from the same issuer name
| |
| *** subordinate CA certs expire before they are replaced
| |
| *** OCSP responder certs expire before they are replaced
| |
| *** OCSP responder certs don't conform to RFC 2560.
| |
| ** The only stick we've ever discussed is the big one: removing the CA from the trusted list. And I think history has shown that there's no sin so great, so unpardonable, that committing it would cause a CA to be removed from Mozilla's list (but perhaps my memory is failing me).
| |
| ** Can we devise a smaller stick? Is there something less than the axe and the chopping block that will motivate CAs to take care?
| |
| ** Monetary penalty fee. Something substantial, like a fixed fee plus actual damages plus damages for soft values like reputation and health.
| |
| ** How about a "hall of shame"? Possibities include:
| |
| *** A web page that publicly records a history of incidents of CA malfeasance. When we learn about such incidents, they go on that page and STAY THERE FOREVER. After a while, CAs learn about this, and begin to do their best to stay off that page. They pay attention to the mistakes that have gotten other CAs names put onto that page.
| |
| *** A change to NSS that would allow a root certificate to be marked as listed in the "Hall of Shame". Then, when chaining up to that root, a warning popup would appear: "You are attempting to establish a secure Internet connection via a root certificate that is known to have questionable trust. Do you wish to continue?" The popup would have "yes", "no", and "more info" buttons; the latter would cause the display of the "Hall of Shame" Web site, which would provide details about the problem. Furthermore, if a certificate authority takes serious remedial action, perhaps the "Hall of Shame" listing and the NSS marking need not be permanent.
| |
| | |
| * Some CAs have disclaimers in their CP/CPS to relieve them of liability to the end users. They limit their liability to relying parties.
| |
| | |
| ===== General Policy Items =====
| |
| | |
| * Sufficient Information in "O" field of root certificates
| |
| *# All certs to be included in the trusted store have a "proper" O= field for both the Subject and Issuer ("proper" means it isn't garbage and reasonably matches the organization requesting its inclusion)
| |
| *# A "strict checking" mode will expect O= for every subsequent cert in the chain, but certs without an O= field will be allowed for backward-compatibility purposes (Note: I'm moving a little past just inclusion here and touching upon cert chain validation by the Mozilla products in real-time!)
| |
| *# An allowance that end-point certs (for hosts and individuals) my omit the O= for those cases where they are acting autonomously and not as the agent of some organization (again, a validation step as opposed to inclusion in the trust store)
| |
| | |
| * [[CA:Problematic_Practices#Root_Count_Restrictions | Root Count Restrictions:]] It has been suggested that, when the CA cert policy is revised, we restrict the number of roots any one CA may have to e.g. 3. This is because more roots increases the download size of the product. | |
| | |
| * [[CA:Problematic_Practices#Actual_Paperwork | Actual Paperwork:]] It has been suggested that CAs should submit some paperwork, such as a formal inclusion request, which might help Mozilla in the case of legal problems in the future. A PDF file should suffice unless an embossed or holographic seal is needed.
| |
| ** It has been suggested that each CA be required to specify their contract with each of the key users: Mozilla's typical user, Mozilla, and Subscribers. The CA should also identify the risks, liabilities and obligations for each of those users. For a typical CA, the response could be a Relying Party Agreement (RPA), a Root Distribution License (RDL) or some sort of agreement with Mozilla, and a Subscriber Agreement.
| |
| | |
| * CA's must provide reasonable support to their end users.
| |
| **A certificate authority must provide a method whereby a user who is not a customer can communicate certificate problems. This method should be readily found and usable by a typical user. Furthermore, a user should be able to complain effectively to the certificate authority (i.e., with results) about the symptom of a missing intermediate certificate from a subscriber of that authority; that is, the authority should be held responsible for ensuring that its subscribers (customers) configure their servers appropriately. Also a certificate authority must respond promptly when notified by a user who is not a customer that its own infrastructure is malfunctioning.
| |
| ** [[CA:Problematic_Practices#Lack_of_Communication_With_End_Users | Lack of Communication With End Users]]
| |
| ** Example:I have a real problem with the (lack of) uptime of the OCSP responder belonging to one of our trusted CAs. It happens that I frequently use the services of web sites whose certs are issued by this CA, and when its OCSP responder is down or having troubles (sending bogus replies), I'm faced with the choice of turning off OCSP or waiting for hours or days for it to be fixed. I've tried contacting the CA's customer service department, and that's always been an exercise in futility and frustration.
| |
| *** I'd like to see Mozilla policy set an uptime requirement, and I'd like Mozilla to make at least some small attempt to measure conformance to that policy. A few systems, scattered around the world, that did OCSP revocation tests on a fixed set of certs from various issuers, some fixed number of times per day, would do it. NSS already has a test program that is completely capable of doing the job (ocspclnt). It would just need to wrapped in a shell script. I'd volunteer to work on the script if Mozilla would add the requirement to the policy and operate the systems.
| |
| *** What does it help if after failing to check all OCSP responder locations, the CRL distribution points are IGNORED? And how about traversing through all OCSP (and CRL) locations before giving up?
| |
| | |
| * The CP and CPS published by CAs must be under terms which allow redistribution, excerpting, quotation, archiving and all the other things needed for making good trust decisions. There is language in there about this already but it needs clarification. We often get CPs and CPSes which claim "all rights reserved". We could either require or strongly recommend that CAs publish these documents under a non-NC Creative Commons license.
| |
| | |
| ===== Domain Names =====
| |
| | |
| * Proposal that Mozilla includes a clause of "only identity information verified with (or through a chain of) authenticated credentials issued by a state-instituted authoritative public record keeper, and which matches what is in those records, may appear in the DN and SAN". The current wording permits verification to be performed against any entity, not constrained to the set of authoritative-for-their-namespaces state-instituted entities.
| |
| ** IP addresses are managed by ICANN, instituted by US state authority.
| |
| ** DNS names are managed by ICANN, instituted by US state authority.
| |
| ** Email address namespaces depend on DNS names and/or IP addresses; as a result, ICANN is ultimately responsible for email addresses as well.
| |
| ** Distinguished Names are assigned and managed by the civil register (the clerks of vital statistics) and the corporate register (the secretaries of state).
| |
| ** Telephone network addresses (phone numbers) are managed by the ITU, which is instituted by authority of international treaty.
| |
| ** Stating this would make it clear that private addresses and non-qualified host names are prohibited, and non-public authority DNS-like root servers are also prohibited. Remember the new.net fiasco, where they tried to hijack the DNS roots by abuse of ISP capacity to change their nameservers? The current wording permits this. The proposed wording makes it clearly impermissible.
| |
| | |
| * [[CA:Problematic_Practices#Wildcard_DV_SSL_certificates | Wildcard DV SSL certificates]] | |
| ** Wildcard SSL certificates should not be issued except to subscribers whose actual identity has been validated with organizational validation (OV).
| |
| ** Bug 481725 -- Add validation requirement for wild card certificate to Mozilla CA Policy
| |
| | |
| * [[CA:Recommended_Practices#Document_Handling_of_IDNs_in_CP.2FCPS | International Domain Names:]] If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.
| |
| ** [https://bugzilla.mozilla.org/show_bug.cgi?id=279099 Bug #279099]
| |
| | |
| ===== Subscriber Verification =====
| |
| | |
| * Clarify and provide more details in section 7 of the Mozilla CA Cert Policy, in regards to verification of domain name, email address, and identity of code signing cert subscribers.
| |
| ** For the first three bullets under #7 of the existing policy, we need statements that are more specific than "reasonable measures to verify". Don't dictate what those measures should be, but specify what results are required when those measures are used. Also state if there are measures that are considered to be unacceptable.
| |
| ** Given that the audit checks that the CPS is adhered to, the Mozilla CA Certificate Policy should include clear rules about what the CPS must say; e.g. in regards to verification of domain name, email address, and identity of cert subscriber.
| |
| ** Should the policy make more clear what the audit must cover, especially in regards to section 7 of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy]? For example, "the auditor must check that the code-signing certs are only given to well-identified parties."
| |
| | |
| *Clearly define and differentiate between DV, OV, and EV. Add minimum standards for DV (e.g. maximum validity of cert) and OV (e.g. include a statement of what constitutes minimum validation of the organization and address fields).
| |
| ** For OV, have UI display the O, OU, ST, L, and C in the dialog that pops up when you click the lock on an OV certificate. It could say something amounting to "These details were not validated to EV standards"
| |
| *** DV = Domain validation only, mostly via an automated email challenge to an acceptable email address on the domain(s) to be included in the certificate. Add in some automated risk checking (whitelists, blacklists, suspicious IP origin checking, etc) and a little human review for the risky looking stuff. The O, ST, and L fields are going to be left blank anyway. I'm not aware of DV cert vendors putting unvalidated O, ST, L fields in certs (is anyone out there aware of the practice?)
| |
| *** OV = DV + validating the organization to be listed in the O field - making sure public record and government resources can verify the address, existence, and good legal standing of the organization itself. Verifying that the whois listed address matches the verified address, and any other additional checks that a given CA lists in its CPS. OV certs are going to have O, ST, L, C set in all cases I know of. Some have more.
| |
| *** EV = OV++ (the EV guidelines spell out the requirements and acceptable methods of verification in good detail, and all CAs issuing EV certs are following the same playbook.)
| |
| ** Why so much formality -- why not just say "If you put O, ST, L, C into a cert, you should validate that data by at least verifying that you can find the organization in public records (and maybe one or two more points.)" Then, enable the cert details fields to be shown for CAs that meet your standard. Just add a bit to the root store to track whether a given root CA has sufficient OV practices that if you see an end-entity cert with an O, you can show it instead of saying "(unknown)" It certainly seems like one of those "smaller sticks" that Mozilla has been yearning for: the ability for some CAs to have their verified O shown in the cert viewer because Mozilla trusts they validate the data to a good enough standard that didn't necessarily have to be all the way to EV.
| |
| ** A possible minimum OV standard is that all organization information included in a certificate has to be validated using reliable third party documentation. An even lower standard is that all organization information has to be reasonably validated prior to issuance.
| |
| ** Possible wording for DV certs: limit the validity period of end-entity SSL certificates to 24 months or less when the identity and organization of the certificate subscriber have not been verified.
| |
| ** Reverification:
| |
| ***DV: Domain still exists and is owned/controlled by the same applicant. Email still exists and is owned/controlled by the same applicant.
| |
| *** OV: Organization is still in business and registered. Organization is still with the same details as published in the certificate (e.g. name, street, locality, state, country).
| |
| *** IV: Individual is still alive and hasn't changed names. Individual is still with the same details as published in the certificate (e.g. name, street, locality, state, country).
| |
| | |
| === Items that belong in the Recommended Practices Wiki Page ===
| |
| | |
| List of items that may belong in the [[CA:Recommended_Practices | Recommended Practices]] wiki page:
| |
| | |
| * [[CA:Recommended_Practices#Publicly_Available_CP_and_CPS | CP/CPS documents:]] Further recommendations about CP/CPS documents
| |
| * [[CA:Recommended_Practices#CA_Hierarchy | CA Hierarchy:]] A hierarchical structure of a single root with intermediate/subordinate certs is preferred. | |
| * [[CA:Recommended_Practices#Audit_Criteria | Audit Criteria:]] Further information about Audit Criteria
| |
| * [[CA:Recommended_Practices#Verifying_Domain_Name_Ownership | Domain Name Verification:]] More specific information about the requirements for verifying domain name ownership
| |
| * [[CA:Recommended_Practices#Verifying_Email_Address_Control | Email Address Verification:]] More specific information about the requirements for verifying email address ownership
| |
| * [[CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber | Verification of Identity of Code Signing Certificate Subscriber:]] More specific information about the requirements for verifying that the entity submitting the certificate signing request is the same entity referenced in the certificate, or has been authorized by the entity referenced in the certificate.
| |
| * [[CA:Recommended_Practices#OCSP | OCSP Recommendations:]] How to test OCSP in Firefox, commonly encountered error codes, etc.
| |
| * [[CA:Recommended_Practices#Notes_for_future_work | Non US-ASCII character sets in certs]]
| |
| | |
| === Items that belong in the Potentially Problematic Practices Wiki Page ===
| |
| | |
| Items that may belong in the [[CA:Problematic_Practices | Potentially Problematic Practices]] wiki page.
| |
| | |
| * [[CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties | Delegation of Domain / Email validation to third parties:]]
| |
| * [[CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots | Issuing end entity certificates directly from roots]]
| |
| * [[CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs | Allowing external entities to operate subordinate CAs]]
| |
| * [[CA:Problematic_Practices#Distributing_generated_private_keys_in_PKCS.2312_files | Distributing generated private keys in PKCS#12 files]]
| |
| * [[CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root | OCSP Responses signed by a certificate under a different root]]
| |
| * [[CA:Problematic_Practices#CRL_with_critical_CIDP_Extension | CRL with critical CIDP Extension]]
| |
| * [[CA:Problematic_Practices#Generic_names_for_CAs | Generic names for CAs]]
| |