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
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
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 15-April 2018.
>
>
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
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 th
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 the EV
> indicator for
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
to
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, either as relying pa
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 suggesting is that we add
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 imm
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
as
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
som
There is no easy way to temporary sanction non-compliant CAs for lateness
of documents, incidents and etc.
There needs to be a switch developed which allows program members to
disable features such as EV without messing around in code.
James
On Wed, Jan 24, 2018 at 1:56 PM, Ryan Sleevi via dev-s
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 goo
On 24/01/18 00:47, Wayne Thayer 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 we should have a more general stipulation that Mozilla does not
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
16 matches
Mail list logo
