On 17/03/17 15:30, Gervase Markham wrote: > The URL for the draft of the next CA Communication is here: > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
* Action 1 should say that if in future additional specific methods are defined by the CAB Forum, then they will be permitted also. * Clarifying: "so the subsections of version 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are still BR-compliant" -> "so the subsections of section 3.2.2.4 in 1.4.1 that are marked "Reserved" in version 1.4.2 of the BRs are still BR-compliant under 1.4.2". * Action 1: Kathleen, I believe you said that 1/1/2016 is the earliest date the widget will do, but the text asks for 1/1/2015 (if you don't have the Websites trust bit)? * Action 2: as the two choices are mutually exclusive, I would expect radio buttons rather than a checkbox. * Action 3: "in github" -> "on Github". * Action 5: policy 2.4 has some of these requirements but not all. I've filed an issue to add any extra ones. https://github.com/mozilla/pkipolicy/issues/66 * Action 7: some of the BR Compliance bugs relate to CAs which are no longer trusted, like StartCom. If StartCom does become a trusted CA again, it will be with new systems which most likely do not have the same bugs. Should we close the StartCom compliance bugs? * Action 7: I have updated these bugs to have a convention of putting the CA name at the start of the bug summary. This allows sorting "by CA" if you sort by Summary. * Action 8: Can we provide more structure here, by perhaps putting some boilerplate text in the answer box or something like that? Or at least list the sections and actions we expect to have been done? I would also like to add the following questions/actions: A) Does your CA have an RA program, whereby non-Affiliates of your company perform aspects of certificate validation on your behalf under contract? If so, please tell us about the program, including: * How many companies are involved * Which of those companies do their own domain ownership validation * What measures you have in place to ensure this work is done to an appropriate standard If you do not have an RA program, write "Not Applicable". <Free text box> B) Your attention is drawn to the cablint and x509lint tools, which you may wish to incorporate into your certificate issuance pipeline to get early warning of circumstances when you are issuing certificates which do not meet the Baseline Requirements (cablint) or X509 standards (x509lint). https://github.com/kroeckx/x509lint XXX What's the URL for cablint? [ ] I am now aware of these tools C) CAA The CAB Forum recently passed ballot 187, which updated the Baseline Requirements to make CAA (RFC 6844) checking mandatory at time of certificate issuance in almost all circumstances. Please provide a list of the domain names which your CA plans to recognise in a CAA record's issue and issuewild property tags as permitting it to issue. If certain identifiers only permit under certain circumstances, please explain. <Free text box> Mozilla plans to make a central list of these identifiers. D) Problem Reporting Mechanism Please explain how your CA meets the following requirement from the BRs section 4.9.3: “The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.” Please detail both the mechanism and the location(s) where you publicly disclose it. Mozilla plans to make a central list of these mechanisms. You are encouraged to make an email address at least one of your provided options. <Free text box> E) SHA-1 and S/MIME Does your CA issue SHA-1 S/MIME certificates? If so, please explain your plans for ceasing to do so, and any self-imposed or external deadlines you are planning to meet. Mozilla plans to make policy in this area in the future, so please explain any facts or constraints which you think might be relevant to our considerations. If none of your roots have the Email trust bit set, write "Not Applicable". <Free text box> Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
