CA:CertificatePolicyV2.3: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (added link)
 
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Changes Under Consideration for Version 2.3 of Mozilla's CA Certificate Policy =
= About Mozilla's CA Certificate Policy Version 2.3 =


The DRAFT of Version 2.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] is here: http://mozilla.github.io/ca-policy/
== Purpose of this update ==


== Changes Made to DRAFT Version 2.3 ==
The purpose of this update to [https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Version 2.3] was to officially publish some agreed-upon changes which had been made a year or more before the date of publication and which had been <i>de facto</i> adopted but had not been officially published. Also, we added information about new versions of the ETSI audit standards.


This is the list of changes that have been made to the DRAFT of Version 2.3 in [https://github.com/mozilla/ca-policy github], with public view here: http://mozilla.github.io/ca-policy/
== Time Frames for included CAs to comply with version 2.3 of the policy ==


* (C1) 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
Immediate - Even though [[CA:CertPolicy#2.3|Version 2.3 was published December 19, 2016]], the changes had already been adopted in practice.
** Also update the process/policy wiki pages to reference the new section numbers
== Changes ==
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/004uvRRnVyY/OZ2O4vfQHAAJ Remove Code Signing Trust Bit]
[https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fcompare%2F2.2...2.3&sa=D&sntz=1&usg=AFQjCNGl2ZmFwusBMep6gh0Jwo2NFZwZPA Change log]
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/004uvRRnVyY/UAU7adNMBAAJ Decision]: Remove references to code signing from Mozilla's CA Certificate Policy, then (after version 2.3 of the policy is published) turn off all code signing trust bits on root certs included in NSS, and remove any root certs that do not have any trust bits enabled.
<br />
** Original proposals:
Summary of changes:
*** '''Approved:''' (D28) Remove Code Signing trust bits. As of Firefox 38, add-ons are signed using Mozilla's own roots. There doesn't appear to be anyone else using the roots in the NSS root store for Code Signing.
* Remove references to code signing; Mozilla's root program no longer covers this
*** '''Not approved:''' (D12) For Code Signing certs, add requirement to comply with the CA/Browser Forum's Code Signing BRs.
* Update references to the Baseline Requirements to account for the rearrangement of that document
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/GTvNPY2F-j8/IUAMs85XFgAJ Corrections / Minor Updates]
* Update ETSI audit standards document names and numbers
** (C2) 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.
* Update minimum version of the BRs to 1.3
*** 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]]
** (C3) 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].
*** (D16) In item #11 of the Inclusion policy, remove ISO 21188:2006...
** (C4) 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;"
** (C5) 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."
** (C6) 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;"
** (C7) 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.
*** (D24) 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.
**** Recommendation from ETSI:  keep the old and the new references of the ETSI standards to allow a smooth transition. When the time comes (in about roughly 2 years) the reference to the TS 102042 and 101456 may be withdrawn.
 
== Proposed Changes That Have Been Discussed ==
 
=== Approved ===
The following changes have been discussed in the mozilla.dev.security.policy forum, and '''need to be made''' to the [https://github.com/mozilla/ca-policy DRAFT of version 2.3 of the policy in GitHub].
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/QJ2HypQRvxA/TeNM5Pk6BAAJ Refer to BRs for Name Constraints Requirement]
** (D23) Simplify item #9 of the Inclusion Policy by using Baseline Requirements #9.7, "Technical Constraints in Subordinate CA Certificates via Name Constraints & EKU".
** (D2) [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.
** '''Approved Text:''' ''9. We encourage CAs to technically constrain all subordinate CA certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.''
*** ''If the certificate includes the id-kp-serverAuth extended key usage, then the certificate must be Name Constrained as described in section 7.1.5 of version 1.3 or later of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.''
*** ''If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use.''
 
=== Declined ===
The following changes have been discussed in the mozilla.dev.security.policy forum, and the proposal was either declined or postponed to be re-considered in a future version of the policy.
* POSTPONED: [https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/M6OpyA5FBAAJ Remove the Email Trust Bit]
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/ORqkOowGw8M/VIlMJyt8BQAJ Decision]: Keep Email trust bit, and status quo for now. Re-evaluate for next version of policy. If no work has been done to create a separate S/MIME policy or to fix S/MIME bugs, then remove.
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/ycC96j6PBAAJ Summary of current problems with Email trust bit]
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/ORqkOowGw8M/enJH7mSeAwAJ S/MIME work that needs to be done in 2016]
*** Create a separate S/MIME policy
*** Fix S/MIME bugs in NSS
*  POSTPONED: [https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/M6OpyA5FBAAJ Specify audit criteria according to trust bit]
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/j_YBIraRBQAJ Decision]: Don't separate out audit criteria according to trust bit in this policy update. Re-visit when the discussion about the E-mail trust bit is re-visited.
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/j_YBIraRBQAJ Discussion re-started on October 19] proposing that we don't do this change in version 2.3 of the policy; rather wait for a separate S/MIME policy.
** (D27) Clarify which audit criteria are required depending on which trust bits are set. In particular, root certs with only the S/MIME trust bit set will have different audit criteria requirements than root certs with the Websites trust bit set.
 
== Proposed Changes Currently in Discussion ==
The following changes are currently under discussion in the mozilla.dev.security.policy forum.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/U7DMI67L7PY/d0FFjA9KBAAJ Align policy with RFC 3647 now]
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/EDRp1Fil3u8/ub33LOoDAgAJ Timeline for disclosing new subCAs]
**  (D3) Make the timeline clear about when the audit statements and disclosure has to happen for new audited/disclosed subCAs. According to section 8.1 of version 1.3 of the Baseline Requirements, 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.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/smAUN2Rtc78/T5rEAFmMAwAJ Key Sizes]
** (D4) 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".)
*** Update reference to SHA-512 -- {{Bug|1129083}}
*** Update reference to P-512 -- {{Bug|1129077}}
** (D15) 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}}
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zCrSaJSHEwQ/_w0hOujsBwAJ Translate Complete CP/CPS into English]
** (D26) Add a requirement for CAs to provide English-translated versions of their complete CP / CPS
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/RmEDMqiff3Y/oTVKfbIMAQAJ Audit Report Timing]
** The current CA policy does not specify when audit reports are due to Mozilla relative to the end date of the audit period.  It only says that CAs must provide the reports to Mozilla within 30 days of receiving the report from their auditor. For the next version of the CA policy, I suggest that this be remedied.
 
== Proposed Changes That Need To Be Discussed ==
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.]  
 
=== General Policy Cleanup ===
* (D19) Add statement of purpose as described in the [https://groups.google.com/d/msg/mozilla.dev.security.policy/SzSGHbrcBe0/hSGt50rJfYMJ policy framework discussion.]
* (D22) 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.
* Require CAs to publish their CPs and CPSes under one of the following Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND. This is so that there is no legal impediment to their proper storage, scrutiny etc. by relying parties.
* Require at least 20 bits of entropy in the cert serial number.
** Change [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy] section 9 from: "all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number)."
** to "all new end-entity certificates must contain at least 20 bits of unpredictable random data in the serial number."
* Remove duplication with the BRs.
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Inclusion Policy] Duplication with the BRs:
*** Section 9 re technical constraints -- already handled via D23.
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Maintenance Policy] Duplication with the BRs:
*** Section 2 re reasons for revocation
*** Section 3 re CRL/OCSP repositories
*** Section 8 re algorithms and key sizes
*** Section 9 re preventing algorithm attacks
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Enforcement Policy] Duplication with the BRs:
*** None
 
=== Transparency ===
* (D13) 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?
* (D14) 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.
 
=== Accountability ===
* (D5) 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]]
* (D9) 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.
* (D21) 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
 
=== Revocation ===
* (D6) 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.
* (D7) 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.
* (D8) 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.
* (D10) 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
* (D11) 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
* (D17) Policy changes regarding [https://wiki.mozilla.org/CA:ImprovingRevocation Improving Revocation.]
* {{Bug|643916}} -- Minimize allowed staleness of OCSP/CRL response info in CA root inclusion policy
 
=== Government CAs ===
* (D18) Audit equivalencies from Government CAs MUST incorporate the CABF BR into their local audit criteria.
* (D20) 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.)
* (D25) 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.
* Add text to the policy regarding root certificates that are constrained. i.e. if the root is constrained, then the rest of the CA hierarchy is constrained, even if the subCA certs do not have name constraints. Of course the overarching CP/CPS needs to commit to complying with the BRs, and needs to be complaint with Mozilla policy. But would the subCAs all be considered technically constrained even though they do not have name constraints directly in them.
 
=== Remaining Cleanup ===
* (D1) 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.
** Putting this item last, because most of it will be discussed via the other topics, so will probably just need to go back and clean up this wiki page.
 
= Proposed Changes we will NOT make to Mozilla's CA Cert Policy =
''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.''

Latest revision as of 18:36, 19 December 2016

About Mozilla's CA Certificate Policy Version 2.3

Purpose of this update

The purpose of this update to Version 2.3 was to officially publish some agreed-upon changes which had been made a year or more before the date of publication and which had been de facto adopted but had not been officially published. Also, we added information about new versions of the ETSI audit standards.

Time Frames for included CAs to comply with version 2.3 of the policy

Immediate - Even though Version 2.3 was published December 19, 2016, the changes had already been adopted in practice.

Changes

Change log
Summary of changes:

  • Remove references to code signing; Mozilla's root program no longer covers this
  • Update references to the Baseline Requirements to account for the rearrangement of that document
  • Update ETSI audit standards document names and numbers
  • Update minimum version of the BRs to 1.3
Retrieved from "https://wiki.allizom.org/index.php?title=CA:CertificatePolicyV2.3&oldid=1157359"