Re: Summary of Responses to the November CA Communication

2018-01-26 Thread Ryan Sleevi via dev-security-policy
I don't think that's terribly germane to the discussion here, but you can see more details at https://cabforum.org/pipermail/public/2018-January/012851.html As it relates to *this* discussion, however, is an understanding that the current set of CA/Browser Forum issues with respect to adhering to

Re: Summary of Responses to the November CA Communication

2018-01-26 Thread James Burton via dev-security-policy
You really should set up a emergency conference call with all members of the CAB Forums and talk about these issues with chair. If you and other members feel that the answers are not satisfactory then you can vote to remove the Chair for dereliction of duty and place the sub-Chair in charge of the

Re: Summary of Responses to the November CA Communication

2018-01-26 Thread Ryan Sleevi via dev-security-policy
On Fri, Jan 26, 2018 at 5:43 AM Gervase Markham wrote: > On 24/01/18 13:56, Ryan Sleevi wrote: > >> more frequently when requirements change. I propose that we require CAs > to > >> update their CPS to comply with version 2.5 of the Mozilla root store > >> policy no later than

Re: Summary of Responses to the November CA Communication

2018-01-26 Thread Gervase Markham via dev-security-policy
On 24/01/18 21:41, Wayne Thayer wrote: > First off, I question if we would really use lesser sanctions more often. I > think we would still want to coordinate their implementation with other > user agents, and that is a tedious process. I think it's important for root programs to make independent

Re: Summary of Responses to the November CA Communication

2018-01-26 Thread Gervase Markham via dev-security-policy
On 24/01/18 13:56, Ryan Sleevi wrote: >> more frequently when requirements change. I propose that we require CAs to >> update their CPS to comply with version 2.5 of the Mozilla root store >> policy no later than 15-April 2018. I think Ryan is right here; the deadline for complying with most of

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: 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: 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: 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

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

Summary of Responses to the November CA Communication

2018-01-23 Thread Wayne Thayer via dev-security-policy
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 good news, no new concerns related to the suspected .tg Registry compromise were reported (Action #8) * The deadline for submitting