On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote: > All, > > I would like to start drafting the next CA Communication, with the goal > of sending it around the end of February. > > For reference, previous CA Communications are here: > https://wiki.mozilla.org/CA:Communications >
I will greatly appreciate your feedback on the following draft of the March 2016 CA Communication. Are the appropriate topics covered? Are the questions and available responses clear and sufficient? Do you have suggestions about when the 'TBD' dates should be? Any other thoughtful and constructive feedback on this will also be appreciated. I delayed the CA Communication in order to add further customization to the CA Community in Salesforce that will enhance how the communication and survey responses are done. CAs will respond to this communication by logging in to the CA Community in Salesforce. To view the draft of the March 2016 CA Communication as it will appear for each CA in Salesforce, please browse to https://wiki.mozilla.org/CA:Communications#March_2016 and click on "Link to DRAFT of March 2016 CA Communication" The differences between this page and what the CA will see in the CA Community in Saleforce are: - The date picker fields, check boxes, and text entry fields are not clickable/editable. - There is no 'Submit' button at the bottom of the page. For your convenience I have copy-and-pasted the text from that page below. ~~~ March 2016 CA Communication Dear Certification Authority, This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program by [DATE TBD]. To respond to this survey, please login to the CA Community in Salesforce, click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA Communication' survey. Please enter your initial response by [DATE TBD]. After that, you may update your responses until the survey Expiration Date of [TBD], by following these same steps. A compiled list of CA responses to the survey action items will be automatically published. In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements. Your contributions to the discussions will help shape the future of Mozilla's CA Certificate Program. Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. Regards, Kathleen Wilson Mozilla CA Program Manager ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. Check your systems and those of your subordinate CAs to ensure that SHA-1 certificates chaining up to your included root certificates are no longer being issued. Please enter the last date that a SHA-1 certificate was issued that chained up to your root certificate(s) included in Mozilla's program. (Required) ACTION #1b: Enter the date when all of the SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program will either expire or be revoked. As previously communicated we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. (Required) ACTION #1c: Enter the date by which safeguards will be put into place that will prevent the future issuance of SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program. If you have already completed this, then please enter the approximate date when those safeguards were completed. (Required) ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the requirement that CAs must provide public-facing documentation about certificate verification requirements and annual public attestation of conformance to the stated certificate verification requirements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the PEM data, CP/CPS, and audit statements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. This includes every intermediate certificate (chaining up to your root certificates in Mozilla's program with the Websites trust bit enabled) that is not Technically Constrained via Extended Key Usage and Name Constraint settings. The date that you enter must be on or before [DATE TBD]. (Required) ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. The date that you enter must be on or before [DATE TBD]. (Required) ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI, we plan to remove these workarounds in Firefox 49. This means that if a certificate has a notBefore date after May 31, 2016, and is affected by any of these workarounds (see below), it will not validate successfully in Firefox 49. The purpose of this question is to identify interoperability problems that may arise when we make the planned code changes, so we will appreciate your diligence in investigating your certificate issuance practices and previously issued certificates before you respond to this question. Please select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that will be valid after the release of Firefox 49 in September 2016. The Bug Numbers below refer to Bugzilla Bugs. (Required) - id-Netscape-stepUp in Extended Key Usage extension instead of id-kp-serverAuth. Workaround to be removed in Bug #982932. - DER: default value of OPTIONAL BOOLEAN explicitly encoded. Workaround to be removed in Bug #989518. - DER: pathLenConstraint included when cA:False. Workaround to be removed in Bug #985025. - Use of subject CN for naming information. Workaround to be removed in Bug #1245280. - Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #[TBD]. - nameConstraints/subjectAlternativeName encoding mismatches. Workaround to be removed in Bug #[TBD]. - Empty SEQUENCE in OCSP responses. Workaround to be removed in Bug #[TBD]. - keyUsage lacking keyEncipherment for certs with RSA keys. Workaround to be removed in Bug #[TBD]. - None of the above ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, when the last of those certificates were issued, and when the last of those certificates expire. ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know which of your root certificates may be removed, and when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Issuer Field and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed. (Required) ACTION #6: All certificates that directly or transitively chain to your root certificate(s) included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates. [TBD] What else should we say here? -- What sort of responses to we want from CAs? -- Rules about testing and test certs (per Symantec incident) -- What sorts of things do we want to make sure CAs do and don't do regarding testing? (Required) ~~~ END As always, I will appreciate your thoughtful and constructive feedback. Thanks, Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
