On Monday, March 20, 2017 at 9:50:38 AM UTC-7, Gervase Markham wrote: > 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.
added > > * 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". done > > * 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)? Turns out that the date widget in the survey tool allows for 1/1/2015. (I had previously tested the date widget within Salesforce records) > > * Action 2: as the two choices are mutually exclusive, I would expect > radio buttons rather than a checkbox. done > > * Action 3: "in github" -> "on Github". done > > * 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 Thanks. > > * 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? Yes, I think that makes sense. > > * 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. Good idea. Added to https://wiki.mozilla.org/CA_Bug_Triage#CA_Certificate_Issuance_Problems_and_Incidents I will be updating all of the open CA Incident and BR Compliance bugs to move them into a new component: mozilla.org :: CA Certificates Mis-Issuance (Currently these bugs may be found in NSS :: CA Certificates and mozilla.org :: CA Certificates.) While I'm at it, I'll update the bug summary as you suggested, and I'll update the whiteboard: [ca-investigation] -- Concern has been raised about certificates that a CA has issued. Investigation and/or discussion in progress. [ca-incident-response] -- The concern about a CA's certificates has been confirmed, and the CA has follow-up action items [ca-compliance] -- The concern about a CA's certificates is in regards to failure to comply with Mozilla policy and/or the CA/Browser Forum's Baseline Requirements, and is determined to not be an imminent security concern. Then I'll update https://wiki.mozilla.org/CA/ca-bugs to use the new whiteboard tags. > > * 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? Changed to checkboxes and a follow-up text field. Please review. > > 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> added > > 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 Added > > 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. Added, but please carefully review -- not sure I got it correct. > > 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> added > > 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> > added Thanks, Kathleen _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
