Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy
On Monday, March 20, 2017 at 2:43:22 PM UTC-7, Gervase Markham wrote: > On 20/03/17 15:33, Kathleen Wilson wrote: > >> * 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

Re: Next CA Communication

2017-03-20 Thread Gervase Markham via dev-security-policy
On 20/03/17 13:07, Peter Bowen wrote: >> 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

Re: Next CA Communication

2017-03-20 Thread Gervase Markham via dev-security-policy
On 20/03/17 15:33, Kathleen Wilson wrote: >> * 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

Re: Next CA Communication

2017-03-20 Thread Peter Bowen via dev-security-policy
On Mon, Mar 20, 2017 at 4:52 PM Rob Stradling wrote: > On 20/03/17 17:07, Peter Bowen via dev-security-policy wrote: > > >> B) Your attention is drawn to the cablint and x509lint tools, which you > >> may wish to incorporate into your certificate issuance pipeline to

Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy
On Monday, March 20, 2017 at 1:37:32 PM UTC-7, Jeremy Rowley wrote: > Something like: "Does your CA have any third-party Registration Authority > (RA)s program that the CA relies on to perform the domain validation > required under Section 3.2.2.4 of the Baseline Requirements." Updated

RE: Next CA Communication

2017-03-20 Thread Jeremy Rowley via dev-security-policy
I only understand this "independent validation of domain control" because I'm on the thread. I don't think CAs who aren't actively involved will understand what it means. DigiCert has an RA. It's DigiCert. We validate our certificate orders and submit them to the CA for issuance. I think it

Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy
On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote: > On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via > > [JR] This should be limited to SSL certs IMO. With client certs, you're > > going > > to get a lot more RAs that likely function under the standard or legal > > framework

Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy
On Friday, March 17, 2017 at 9:17:07 AM UTC-7, Peter Bowen wrote: > I would replace this with: > > + Distinguished name and SHA-256 hash of the SubjectPublicKeyInfo of > each certificate issuer covered by the audit scope > + Clear indication of which in-scope certificate issuers are Root CAs >

Re: Next CA Communication

2017-03-20 Thread Peter Bowen via dev-security-policy
On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via dev-security-policy wrote: > 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

Re: Next CA Communication

2017-03-20 Thread Gervase Markham via dev-security-policy
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=a050S00G3K2 * Action 1 should say that if in future additional specific