Re: DRAFT January 2018 CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi wrote: > > > On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> > Is there a reason to make this deprecation conditional on the ballot? >> > Given what we know

Re: DRAFT January 2018 CA Communication

2018-01-24 Thread Ryan Sleevi via dev-security-policy
On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Is there a reason to make this deprecation conditional on the ballot? > > Given what we know about how the vulnerable methods are used in the wild, > > they have the same

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Ryan Sleevi via dev-security-policy
On Wed, Jan 24, 2018 at 4:41 PM, Wayne Thayer wrote: > To the best of my knowledge, the only "standard" sanction we have today is > complete distrust of a root or intermediate, and in practice that rarely > happens. On the surface, the idea of lesser sanctions like removing

Re: DRAFT January 2018 CA Communication

2018-01-24 Thread Jonathan Rudenberg via dev-security-policy
> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy > wrote: > > We could still choose to set that date in our own policy if the ballot were > to fail. The reasoning behind that date has been discussed on the > CA/Browser Forum lists. I

Re: DRAFT January 2018 CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg wrote: > > > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > 2. On 19-December, significant concerns were raised about the reliability > > of the

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
To the best of my knowledge, the only "standard" sanction we have today is complete distrust of a root or intermediate, and in practice that rarely happens. On the surface, the idea of lesser sanctions like removing the EV indicator for some period of time is appealing to me, but I think we need

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
On Wed, Jan 24, 2018 at 6:56 AM, Ryan Sleevi wrote: > This seems to be a perennial problem with CAs, and doesn't inspire > confidence in them or their operations. I am also concerned that an > extension of this nature does not inspire confidence in the Mozilla Root > Program,

Re: DRAFT January 2018 CA Communication

2018-01-24 Thread Jonathan Rudenberg via dev-security-policy
> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy > wrote: > > 2. On 19-December, significant concerns were raised about the reliability > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. > [3] Since then,

RE: DRAFT January 2018 CA Communication

2018-01-24 Thread Tim Hollebeek via dev-security-policy
Wayne, You might want to highlight that method 1 sub-method 3 would survive even if ballot 218 passes, as a new method 12 with some changes and improvements that CAs who use sub-method 3 should pay close attention to. With regards to TLS-SNI-01, I believe TLS-SNI-02 is also affected by the same

DRAFT January 2018 CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
I want to directly notify all CAs in the Mozilla program of the recently exposed issues with domain validation methods and of some upcoming deadlines. A draft is available below and at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your prompt and

RE: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Tim Hollebeek via dev-security-policy
That's a good point, thank you. I think I would lean towards making this an end-entity only requirement until we've thought through the details for other certificates. We've been burned by this before (requirements for OCSP related certificates were under-specified during the SHA1->SHA2

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Jakob Bohm via dev-security-policy
On 24/01/2018 13:54, Ryan Sleevi wrote: On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Wednesday, January 24, 2018 7:00 AM To: Doug Beattie

RE: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Tim Hollebeek via dev-security-policy
With respect to the action item, I'll add it to next week's VWG agenda. -Tim > -Original Message- > From: Doug Beattie [mailto:doug.beat...@globalsign.com] > Sent: Wednesday, January 24, 2018 11:02 AM > To: Tim Hollebeek ; Rob Stradling >

RE: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Doug Beattie via dev-security-policy
Can we consider this case closed with the action that the VWG will propose a ballot that addresses pre and postdating certificates? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
On Wed, Jan 24, 2018 at 9:54 AM, Gervase Markham wrote: > We do actually do that, it's just not written in the policy itself. See: > https://wiki.mozilla.org/CA/Root_Store_Policy_Archive > which gives all the publication dates and compliance dates. > > Good. Then all I'm

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Gervase Markham via dev-security-policy
On 24/01/18 16:44, Wayne Thayer wrote: > In the past, new policy versions have not had a clearly defined future > effective date. That seems to have led some CAs to interpret the timing for > making changes to be "whenever we get around to it" instead of the intent > of "the policy is effective

RE: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Tim Hollebeek via dev-security-policy
> > This incident makes me think that two changes should be made: > > > > 1) The Root Store Policy should explicitly ban forward and back-dating the > notBefore date. > > I think it would be reasonable and sensible to permit back-dating insofar as it is > deemed necessary to accommodate

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Wayne Thayer via dev-security-policy
In the past, new policy versions have not had a clearly defined future effective date. That seems to have led some CAs to interpret the timing for making changes to be "whenever we get around to it" instead of the intent of "the policy is effective immediately and we expect you to comply with it

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Ryan Sleevi via dev-security-policy
I didn't say it was easy, and I don't disagree that there are ways in which it can be improved (e.g. to include server side checks). However, there are some inescapable limitations in such approaches (e.g. users who cannot contact the Mozilla servers that govern such flags), thus there's always

Izenpe.com rootCA expiration

2018-01-24 Thread GarcĂ­a Jimeno , Oscar via dev-security-policy
Hi everyone, we have just reported in Bugzilla a bug to remove the following root CA, because it expires soon: CN = Izenpe.com O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8 SHA1= 4A 3F 8D 6B DC 0E 1E CF CD 72 E3 77 DE F2 D7 FF 92 C1 9B C7 Link to bugzilla ->

Re: Summary of Responses to the November CA Communication

2018-01-24 Thread Ryan Sleevi via dev-security-policy
On Tue, Jan 23, 2018 at 7:47 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Everyone, > > I have reviewed the responses we received from the November 2017 CA > Communication [1], and I have the following comments to share: > > * Beginning with the

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Ryan Sleevi via dev-security-policy
On Wed, Jan 24, 2018 at 6:52 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We don't allow customers to set the notBefore date into the past. > > And regarding the Mozilla checks for > https://bugzilla.mozilla.org/show_bug.cgi?id=908125, perhaps the >

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Ryan Sleevi via dev-security-policy
On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > -Original Message- > > From: Gervase Markham [mailto:g...@mozilla.org] > > Sent: Wednesday, January 24, 2018 7:00 AM > > To: Doug Beattie

RE: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Doug Beattie via dev-security-policy
> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Wednesday, January 24, 2018 7:00 AM > To: Doug Beattie ; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: Re: GlobalSign certificate with far-future notBefore > > Hi

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Gervase Markham via dev-security-policy
Hi Doug, Thanks for the quick response. On 24/01/18 11:52, Doug Beattie wrote: > In the case below, the customer ordered a 39 month certificate and > set the notBefore date for 2 months into the future. Momentary 2017/2018 confusion in my brain had me thinking that this was further into the

RE: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Doug Beattie via dev-security-policy
I'll try to respond to the few questions on the topic in this one email. In the case below, the customer ordered a 39 month certificate and set the notBefore date for 2 months into the future. The notAfter is within the allowed 39 month validity as measured from time of issuance. Posting the

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Rob Stradling via dev-security-policy
On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date This incident makes me think that two changes should be made: 1) The Root Store Policy should explicitly ban forward and

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Gervase Markham via dev-security-policy
On 24/01/18 04:57, David E. Ross wrote: > I am not sure about prohibiting forward-dating the notBefore date. I > can picture a situation where an existing site certificate is going to > expire. The site's administration decides to obtain a new certificate > from a different certification

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Gervase Markham via dev-security-policy
Hi Jonathan, On 23/01/18 22:55, Jonathan Rudenberg wrote: > A certificate issued by GlobalSign showed up in CT today with a notBefore > date of March 21, 2018 and a notAfter date of April 23, 2021, a validity > period of ~1129 days (more than three years). Thank you for pointing this out. This