Re: About upcoming limits on trusted certificates

2020-03-12 Thread Kathleen Wilson via dev-security-policy
On 3/12/20 5:52 AM, Doug Beattie wrote: Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently.

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

2020-03-12 Thread Ryan Sleevi via dev-security-policy
Responses inline. On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > * Microsec issued two certificates in 2018 with 3-year validity periods > [1]. > > The certificates were issued for CISCO VPN servers. After receiving

Re: Proper place for the Private Key Compromise information in CPS

2020-03-12 Thread Sándor dr . Szőke via dev-security-policy
2020. március 12., csütörtök 18:16:54 UTC+1 időpontban Ryan Sleevi a következőt írta: > On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < > > > So according to the RFC3647 the chapter 1.5.2 shall contain the contact > > person information who is responsible for the

Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours

2020-03-12 Thread Joanna Fox via dev-security-policy
Matt, Our investigation reopened at March 9, 9:36 AM based on the information you provided in this forum. We were able to research and run appropriate testing which led to evidence of key compromise being determined March 9, 10:24 AM. We continued our diligence in accordance with the Baseline

Re: Proper place for the Private Key Compromise information in CPS

2020-03-12 Thread Ryan Sleevi via dev-security-policy
On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > So according to the RFC3647 the chapter 1.5.2 shall contain the contact > person information who is responsible for the management of the CPS, > but the BR requires, that

Re: About upcoming limits on trusted certificates

2020-03-12 Thread Ryan Sleevi via dev-security-policy
On Thu, Mar 12, 2020 at 10:58 AM Jeremy Rowley wrote: > I think this statement is not accurate: "As a result, CAs don’t pursue > automation, or when they support it, neither promote nor require it." I > know very few CAs who want to spend extra resources on manual validations > and just as few

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

2020-03-12 Thread Sándor dr . Szőke via dev-security-policy
2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > This request is for inclusion of the Microsec e-Szigno Root CA 2017 > trust anchor and to EV-enable the currently included Microsec e-Szigno > Root CA 2009 trust anchor as documented in the following bug: >

Proper place for the Private Key Compromise information in CPS

2020-03-12 Thread Sándor dr . Szőke via dev-security-policy
The CABF BR section 2.2. PUBLICATION OF INFORMATION contains the following requirement: The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. The CABF BR section 4.9.3. Procedure for

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

2020-03-12 Thread Sándor dr . Szőke via dev-security-policy
2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > This request is for inclusion of the Microsec e-Szigno Root CA 2017 > trust anchor and to EV-enable the currently included Microsec e-Szigno > Root CA 2009 trust anchor as documented in the following bug: >

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

2020-03-12 Thread clemens.wanko--- via dev-security-policy
Situation from ACAB'c ETSI auditors point of view: On one hand it is quite simple: if the auditor cannot perform the audit as foreseen in the certification program no certificate can be issued. In case a surveillance audit cannot be performed, the certification body must withdraw the affected

RE: About upcoming limits on trusted certificates

2020-03-12 Thread Jeremy Rowley via dev-security-policy
I think this statement is not accurate: "As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it." I know very few CAs who want to spend extra resources on manual validations and just as few who don't support some level of automation. The manual methods

Re: About upcoming limits on trusted certificates

2020-03-12 Thread Ryan Sleevi via dev-security-policy
The Baseline Requirements allow a number of methods that aren’t easily automated, such as validation via email. As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it. This leads CAs to be opposed to efforts to shorten the reuse time, as they have

RE: About upcoming limits on trusted certificates

2020-03-12 Thread Doug Beattie via dev-security-policy
Kathleen, Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently. This would be a sudden and large

Re: About upcoming limits on trusted certificates

2020-03-12 Thread Julien Cristau via dev-security-policy
Hi Kathleen, all, Is there a reason domain validation information needs to be reused for more than, say, 30 days? For the manual parts of identity validation I understand you don't want to repeat the process too often, but domain validation can be entirely automated so it doesn't seem like long