Re: Summary of Responses to the November CA Communication

[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 its
Bylaws has a negative affect on the policy objectives and understanding,
and thus bear consideration in the CA communications.

On Fri, Jan 26, 2018 at 4:00 PM, James Burton  wrote:

> 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 forums until the end of current term or until you appoint new
> chair.
>
> James
>
> On Fri, Jan 26, 2018 at 1:58 PM, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 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.
>> >
>> > I think Ryan is right here; the deadline for complying with most of the
>> > new changes was "immediately" - in part, that was due to the nature of
>> > the changes, in that this was possible, and also we put out a call for
>> > "does anyone need an implementation period for any of these things", and
>> > the only response was from Globalsign, which led to the modification of
>> > the email intermediate compliance dates.
>> >
>> > I realise that updating one's CPS to match changes in practice can't be
>> > done overnight - there are change control procedures - but taking 15
>> > months is ridiculous. We should get back to Microsec and tell them that
>> > this is unacceptable. If we do set a "new" deadline for CPS updates, it
>> > should be closer than mid-April, and we should update our policy to make
>> > it clear how fast we expect CPSes to be updated in the wake of
>> > "immediate" new requirements - either from a new version of the policy,
>> > or from some emergency action we take.
>> >
>> > > 2 should be inconsequential, but 1 has a very real effect -
>> unless/until
>> > > the CA updates their CP/CPS to explicitly state what methods they are
>> > using
>> > > (implicitly disavowing the 'any other method'), then a CA can receive
>> a
>> > > fully compliant audit, despite actively issuing certificates using
>> 'any
>> > > other method', in contravention of Mozilla Policy.
>> >
>> > Ryan: I thought you had previously made the case that all CAs actually
>> > had to abide by the latest version of the BRs? If that is so, then
>> > surely your point above is incorrect?
>>
>>
>> The CA/Browser Forum chair - an employee of Entrust - has been
>> irresponsibly derelict in his duties as Chair. He has failed to exercise
>> the Bylaws as required of him, has failed to inform the Forum about the IP
>> notices received (if any) or to update the Public Mail List and Public Web
>> Site, and as a result, created a situation where it is defensibly
>> ambiguous
>> as to whether only the “10 Blessed Methods” are used.
>>
>> It is unclear whether this is due to incompetence or malice, but the
>> consequence is such that a CA, such as Entrust, could attempt to argue
>> that
>> the CA/Browser Forum did not declare a version of the BRs post-Ballot 190
>> as Final, and thus avoid triggering that clause.
>>
>> The above remarks I highlighted would have allowed for a defense in depth
>> from the CA/Browser Forum chair failing or abusing their position, by
>> ensuring clear and unambiguous statements by CAs for security critical
>> matters.
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 forums until the end of current term or until you appoint new
chair.

James

On Fri, Jan 26, 2018 at 1:58 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.
> >
> > I think Ryan is right here; the deadline for complying with most of the
> > new changes was "immediately" - in part, that was due to the nature of
> > the changes, in that this was possible, and also we put out a call for
> > "does anyone need an implementation period for any of these things", and
> > the only response was from Globalsign, which led to the modification of
> > the email intermediate compliance dates.
> >
> > I realise that updating one's CPS to match changes in practice can't be
> > done overnight - there are change control procedures - but taking 15
> > months is ridiculous. We should get back to Microsec and tell them that
> > this is unacceptable. If we do set a "new" deadline for CPS updates, it
> > should be closer than mid-April, and we should update our policy to make
> > it clear how fast we expect CPSes to be updated in the wake of
> > "immediate" new requirements - either from a new version of the policy,
> > or from some emergency action we take.
> >
> > > 2 should be inconsequential, but 1 has a very real effect -
> unless/until
> > > the CA updates their CP/CPS to explicitly state what methods they are
> > using
> > > (implicitly disavowing the 'any other method'), then a CA can receive a
> > > fully compliant audit, despite actively issuing certificates using 'any
> > > other method', in contravention of Mozilla Policy.
> >
> > Ryan: I thought you had previously made the case that all CAs actually
> > had to abide by the latest version of the BRs? If that is so, then
> > surely your point above is incorrect?
>
>
> The CA/Browser Forum chair - an employee of Entrust - has been
> irresponsibly derelict in his duties as Chair. He has failed to exercise
> the Bylaws as required of him, has failed to inform the Forum about the IP
> notices received (if any) or to update the Public Mail List and Public Web
> Site, and as a result, created a situation where it is defensibly ambiguous
> as to whether only the “10 Blessed Methods” are used.
>
> It is unclear whether this is due to incompetence or malice, but the
> consequence is such that a CA, such as Entrust, could attempt to argue that
> the CA/Browser Forum did not declare a version of the BRs post-Ballot 190
> as Final, and thus avoid triggering that clause.
>
> The above remarks I highlighted would have allowed for a defense in depth
> from the CA/Browser Forum chair failing or abusing their position, by
> ensuring clear and unambiguous statements by CAs for security critical
> matters.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 15-April 2018.
>
> I think Ryan is right here; the deadline for complying with most of the
> new changes was "immediately" - in part, that was due to the nature of
> the changes, in that this was possible, and also we put out a call for
> "does anyone need an implementation period for any of these things", and
> the only response was from Globalsign, which led to the modification of
> the email intermediate compliance dates.
>
> I realise that updating one's CPS to match changes in practice can't be
> done overnight - there are change control procedures - but taking 15
> months is ridiculous. We should get back to Microsec and tell them that
> this is unacceptable. If we do set a "new" deadline for CPS updates, it
> should be closer than mid-April, and we should update our policy to make
> it clear how fast we expect CPSes to be updated in the wake of
> "immediate" new requirements - either from a new version of the policy,
> or from some emergency action we take.
>
> > 2 should be inconsequential, but 1 has a very real effect - unless/until
> > the CA updates their CP/CPS to explicitly state what methods they are
> using
> > (implicitly disavowing the 'any other method'), then a CA can receive a
> > fully compliant audit, despite actively issuing certificates using 'any
> > other method', in contravention of Mozilla Policy.
>
> Ryan: I thought you had previously made the case that all CAs actually
> had to abide by the latest version of the BRs? If that is so, then
> surely your point above is incorrect?


The CA/Browser Forum chair - an employee of Entrust - has been
irresponsibly derelict in his duties as Chair. He has failed to exercise
the Bylaws as required of him, has failed to inform the Forum about the IP
notices received (if any) or to update the Public Mail List and Public Web
Site, and as a result, created a situation where it is defensibly ambiguous
as to whether only the “10 Blessed Methods” are used.

It is unclear whether this is due to incompetence or malice, but the
consequence is such that a CA, such as Entrust, could attempt to argue that
the CA/Browser Forum did not declare a version of the BRs post-Ballot 190
as Final, and thus avoid triggering that clause.

The above remarks I highlighted would have allowed for a defense in depth
from the CA/Browser Forum chair failing or abusing their position, by
ensuring clear and unambiguous statements by CAs for security critical
matters.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 decisions,
therefore I would be uneasy about too high a level of coordination with
regard to CA sanctions.

Once two root programs have both decided to take similar action, it is
reasonable to coordinate to make sure the impact of the two requirements
is not disproportionate compared to the impact each individual root
program is attemping to have. But that's different from saying: "We are
going to sanction CA Foo - are you in?", or even "We'll sanction CA Foo
if you do."

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 the
new changes was "immediately" - in part, that was due to the nature of
the changes, in that this was possible, and also we put out a call for
"does anyone need an implementation period for any of these things", and
the only response was from Globalsign, which led to the modification of
the email intermediate compliance dates.

I realise that updating one's CPS to match changes in practice can't be
done overnight - there are change control procedures - but taking 15
months is ridiculous. We should get back to Microsec and tell them that
this is unacceptable. If we do set a "new" deadline for CPS updates, it
should be closer than mid-April, and we should update our policy to make
it clear how fast we expect CPSes to be updated in the wake of
"immediate" new requirements - either from a new version of the policy,
or from some emergency action we take.

> 2 should be inconsequential, but 1 has a very real effect - unless/until
> the CA updates their CP/CPS to explicitly state what methods they are using
> (implicitly disavowing the 'any other method'), then a CA can receive a
> fully compliant audit, despite actively issuing certificates using 'any
> other method', in contravention of Mozilla Policy.

Ryan: I thought you had previously made the case that all CAs actually
had to abide by the latest version of the BRs? If that is so, then
surely your point above is incorrect?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 the EV
> indicator for some period of time is appealing to me, but I think we need
> to take a step back and discuss whether or not this is really a good idea.
> Would Mozilla be better off in the long run having lesser sanctions readily
> at our disposal?
>
> 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.
>

While probably not your intent, that does mean that any program
requirements Mozilla imposes - for example, disclosing the BR validation
method used - that aren't also adopted by other Root Programs - would be
somewhat toothless. Why would another user agent take an action against a
root that failed to disclose the methods used, if they didn't require that?
And if taking action requires that degree of coordination, to what end?


> Second, what might be the unintended consequences? For example, would CAs
> shift their focus from maintaining trust to avoiding sanctions?
>

So, when the only option is distrust, and when it's seen as a heavy option
(rather than what I think it should be - a regular occurrence until things
improve), then the only thing a CA has to worry about is not being so bad
that you get distrusted. We know you shouldn't be PROCERT bad [1] , but you
can seemingly be Visa bad [2] - their first audit wasn't until September
2016, despite Mozilla clearly communicating expectations in May 2014 [3],
and they still weren't compliant by the time of discussion.

So it doesn't _seem_ like CAs are focused on maintaining trust, per-se -
more like maintaining the status quo, and only making changes when
required, where "required" means threat of removal, which is a high-bar
that apparently Visa did not rise to (sadly, surprisingly). Further, the
argument seems to have been accepted that once you're in, it should be
harder to remove than what would normally be a complete disqualification
for a new entrant. Sanctions, on the other hand, help balance that - by
actually and effectively communicating that requirements are requirements,
and leveraging the host of options available to a Root Store appropriate to
their role as gatekeepers of trust.

A UA/Root Store is ultimately balancing the risk of 'past certificates'
with the risk of 'new certificates' - and making it easier to more rapidly
mitigate the risk of 'new certificates' (such as distrust periods and
requiring new roots, limiting the types of issuance accepted, etc) are
effective means of minimizing the risk to 'past certificates'.
Alternatively, abilities to more effectively mitigate 'past certificates' -
such as whitelists (despite the size hit) - can also help express that
requirements _are_ requirements.

The challenge is the changes must be meaningful, and not just things to
dance around. Preventing new certs and requiring new roots are an effective
way of actually minimizing that legacy-compat risk, while providing real
protection

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Ymrpsm7s5_I/Gki--pwHBgAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/rae9kNkWAgAJ
[3] https://wiki.mozilla.org/CA/Communications#May_2014
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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
to take a step back and discuss whether or not this is really a good idea.
Would Mozilla be better off in the long run having lesser sanctions readily
at our disposal?

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.

Second, what might be the unintended consequences? For example, would CAs
shift their focus from maintaining trust to avoiding sanctions?

- Wayne

On Wed, Jan 24, 2018 at 9:24 AM, Ryan Sleevi  wrote:

> 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 some code change necessary to ensure both a sane/predictable default
> (in the event of persistent DoS to an update server) and a configurable
> flag for that which matters.
>
> On Wed, Jan 24, 2018 at 9:24 AM, James Burton  wrote:
>
>> 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
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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, either as relying parties (CAs that are not competent are allowed
> to continue to be incompetent) or for competent CAs (Mozilla's
> requests/requirements are not actual requirements, but merely suggestions)
>
> I have to agree with this sentiment. However, in this particular case I
suspect many CAs were unaware of the compliance date (as was I).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 suggesting is that we add the compliance date to the
policy and related communications.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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 immediately and we expect you to comply with it
> as soon as possible". Given this abuse, I'd prefer to put a date on each
> new version of the policy by which CAs are expected to comply with it. This
> date would be 2-3 months after the policy was announced, but would also
> allow specific carve-outs for changes that take longer.

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.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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
as soon as possible". Given this abuse, I'd prefer to put a date on each
new version of the policy by which CAs are expected to comply with it. This
date would be 2-3 months after the policy was announced, but would also
allow specific carve-outs for changes that take longer.

- Wayne

On Wed, Jan 24, 2018 at 3:01 AM, Gervase Markham  wrote:

> 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
> consider it reasonable to take more than N months to make an update to a
> CPS, with N being a number like 3 or 2.
>
> Now, a particular change my require code changes as well, and the CPS
> may only be updated when those are made, and that might take longer -
> that's fine. But if the requirement is e.g. "add some extra contact
> information", that's not fine. CAs should not be in the habit of having
> processes where their CPSes are only updated yearly.
>
> Gerv
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[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
some code change necessary to ensure both a sane/predictable default (in
the event of persistent DoS to an update server) and a configurable flag
for that which matters.

On Wed, Jan 24, 2018 at 9:24 AM, James Burton  wrote:

> 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-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 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 good news, no new concerns related to the suspected
>> > .tg Registry compromise were reported (Action #8)
>> > * The deadline for submitting the survey was 15-December, but Amazon,
>> > DSV-Gruppe, and Web.com required repeated prodding in January before
>> they
>> > responded. It may be that mid-December is not the best time of the year
>> for
>> > a survey deadline, but the response we received fell short of our
>> > expectations.
>> > * In action #1, CAs were asked to confirm that they comply with version
>> 2.5
>> > of the Mozilla root store policy. This policy took effect last June [2],
>> > but a number of CAs stated that they needed more time to bring their CPS
>> > into compliance. Most CAs said they would comply by 1-March, but some
>> > requested much more time. Microsec Ltd. stated that “The next version of
>> > our public documents will contain the exact reference to these BR
>> sections
>> > which will be issued by 2018-09-30.” I expect CAs to update their CPS
>> much
>> > 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.
>> >
>>
>> 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 parties (CAs that are not competent are allowed
>> to continue to be incompetent) or for competent CAs (Mozilla's
>> requests/requirements are not actual requirements, but merely suggestions)
>>
>> I am specifically concerned about the CP/CPS updates and the impact they
>> have to global trust. Am I mistaken in evaluating
>> https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 that the
>> substance
>> of those changes are:
>> 1) Documenting which of the 10 Blessed Methods a CA does not use
>> 2) Updating the version number and adding a dated change log
>>
>> 2 should be inconsequential, but 1 has a very real effect - unless/until
>> the CA updates their CP/CPS to explicitly state what methods they are
>> using
>> (implicitly disavowing the 'any other method'), then a CA can receive a
>> fully compliant audit, despite actively issuing certificates using 'any
>> other method', in contravention of Mozilla Policy.
>>
>> That seems concerning, and the effect is that delaying such updates to
>> 15-April-2018 would mean the community is being asked to accept, based on
>> the honor system, a CA's word that they're not issuing certificates using
>> arbitrary methods.
>>
>> Is my concern misplaced? This seems fairly critical to security, and given
>> the number of CA incidents over the past year, I have very little faith
>> that CAs are in compliance, and that some form of 'human error or
>> oversight' didn't cause them to 'forget' they were using Any-Other-Method.
>>
>> Does Mozilla plan to sanction non-compliant CAs, either now or in the
>> future? Certainly, it seems the removal of any EV status would be
>> appropriate for any CA still needing time to update their CP/CPS, as the
>> level of assurance provided by these CAs regarding their validation
>> methods
>> surely does not rise to the high levels of assurance EV is presumed to
>> convey. But more importantly, should new certificates be distrusted until
>> such a time as the CA can demonstrate compliance? I cannot help but think
>> that is the only way to ensure timely compliance - any CA found to need
>> more time to adjust to policy changes will have trust in their
>> certificates
>> immediately disabled, and for some fixed period (which may grow if the
>> incidents are repeated). 6 months seems an appropriate 

Re: Summary of Responses to the November CA Communication

[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 good news, no new concerns related to the suspected
> .tg Registry compromise were reported (Action #8)
> * The deadline for submitting the survey was 15-December, but Amazon,
> DSV-Gruppe, and Web.com required repeated prodding in January before they
> responded. It may be that mid-December is not the best time of the year for
> a survey deadline, but the response we received fell short of our
> expectations.
> * In action #1, CAs were asked to confirm that they comply with version 2.5
> of the Mozilla root store policy. This policy took effect last June [2],
> but a number of CAs stated that they needed more time to bring their CPS
> into compliance. Most CAs said they would comply by 1-March, but some
> requested much more time. Microsec Ltd. stated that “The next version of
> our public documents will contain the exact reference to these BR sections
> which will be issued by 2018-09-30.” I expect CAs to update their CPS much
> 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.
>

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 parties (CAs that are not competent are allowed
to continue to be incompetent) or for competent CAs (Mozilla's
requests/requirements are not actual requirements, but merely suggestions)

I am specifically concerned about the CP/CPS updates and the impact they
have to global trust. Am I mistaken in evaluating
https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 that the substance
of those changes are:
1) Documenting which of the 10 Blessed Methods a CA does not use
2) Updating the version number and adding a dated change log

2 should be inconsequential, but 1 has a very real effect - unless/until
the CA updates their CP/CPS to explicitly state what methods they are using
(implicitly disavowing the 'any other method'), then a CA can receive a
fully compliant audit, despite actively issuing certificates using 'any
other method', in contravention of Mozilla Policy.

That seems concerning, and the effect is that delaying such updates to
15-April-2018 would mean the community is being asked to accept, based on
the honor system, a CA's word that they're not issuing certificates using
arbitrary methods.

Is my concern misplaced? This seems fairly critical to security, and given
the number of CA incidents over the past year, I have very little faith
that CAs are in compliance, and that some form of 'human error or
oversight' didn't cause them to 'forget' they were using Any-Other-Method.

Does Mozilla plan to sanction non-compliant CAs, either now or in the
future? Certainly, it seems the removal of any EV status would be
appropriate for any CA still needing time to update their CP/CPS, as the
level of assurance provided by these CAs regarding their validation methods
surely does not rise to the high levels of assurance EV is presumed to
convey. But more importantly, should new certificates be distrusted until
such a time as the CA can demonstrate compliance? I cannot help but think
that is the only way to ensure timely compliance - any CA found to need
more time to adjust to policy changes will have trust in their certificates
immediately disabled, and for some fixed period (which may grow if the
incidents are repeated). 6 months seems an appropriate start.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Summary of Responses to the November CA Communication

[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 the survey was 15-December, but Amazon,
DSV-Gruppe, and Web.com required repeated prodding in January before they
responded. It may be that mid-December is not the best time of the year for
a survey deadline, but the response we received fell short of our
expectations.
* In action #1, CAs were asked to confirm that they comply with version 2.5
of the Mozilla root store policy. This policy took effect last June [2],
but a number of CAs stated that they needed more time to bring their CPS
into compliance. Most CAs said they would comply by 1-March, but some
requested much more time. Microsec Ltd. stated that “The next version of
our public documents will contain the exact reference to these BR sections
which will be issued by 2018-09-30.” I expect CAs to update their CPS much
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.
* A few CAs indicated that they are no longer issuing certificates, and
thus believe that they don’t need to meet some of the Mozilla program
requirements. I have emailed these CAs and asked them to either comply with
all the requirements or we will begin the process of removing their roots.
* In Action #1, CAs were reminded of the new requirement to disclose
unconstrained S/MIME subordinate CAs in CCADB by 15-April. However, over
200 undisclosed intermediates are currently reported by crt.sh [3].
* Responding to Action #5, many CAs requested extensions to the 31-Jan
deadline for submitting BR Self Assessments, with most requesting another
month or two. I propose that we extend the deadline to 15-April 2018 for
those CAs that requested more time. Responses will be tracked at [4].
* Action #6 requested CAs to provide any updates to their problem reporting
mechanism or recognized CAA domains. CCADB has been updated with these
changes. You can review and confirm the changes via the reports at [5] and
[6].

We are planning to directly notify CAs of the deadlines that I suggested
above.

- Wayne

[1] https://wiki.mozilla.org/CA/Communications#November_2017_Responses
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/lSyrFEkREZk/9c67Y7bNAQAJ
[3] https://crt.sh/mozilla-disclosures#undisclosed
[4]
https://docs.google.com/spreadsheets/d/1Lmdkl3gTpKyBgZwL_6j5ivClBXiGMUnZyAVJDTHtjO4/edit?usp=sharing
[5]
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
[6] https://ccadb-public.secure.force.com/mozilla/CAAIdentifiersReport
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy