Re: Mozilla's Response to Camerfirma's Compliance Issues

[Watson Ladd via dev-security-policy]

On Monday, January 25, 2021 at 9:21:53 PM UTC-8, Ben Wilson wrote:
> Dear All, 
> 
> We appreciate your comments and participation in the discussion about the 
> Summary of Camerfirma's Compliance Issues, 
> https://wiki.mozilla.org/CA:Camerfirma_Issues. 
> 
> Mozilla has not yet made a decision about Camerfirma's continuation in our 
> root store. We intend to continue with our public discussion process to 
> determine whether Camerfirma's root certificates can remain included in 
> Mozilla's root store, and what actions they need to take. 
> 
> Camerfirma has responded to the list of issues by providing a Remediation 
> Plan, 
> https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing,
>  
> with a commitment to align Camerfirma to the highest level of standards of 
> the Mozilla community. 
> 
> They asked if there are parts of the Remediation Plan that need 
> clarification and for suggestions to improve the Remediation Plan. 
> 
> We will appreciate your constructive feedback on it. 
> 
> - Do the proposed actions in the Remediation Plan address the underlying 
> issues? 

In my opinion they do not. Camerfirma has demonstrated that they do not know 
what good management is, yet they ask us to trust in their ability to evaluate 
their sub CAs. Camerfirma has a history of not following through on their 
commitments, with multiple incidents with similar root causes despite committed 
to addressing the root causes. Camerfirma seems to depend on human evaluation 
in the issuance process  to an alarming extent. I think it's worth revising the 
BRs to require extensive process automation.

> 
> - If Camerfirma fully executes on this plan, will that be sufficient to 
> regain trust so that they can remain a CA in Mozilla's root store? 

I don't think this plan goes beyond what a reasonable person would have done in 
response to the incidents. It's too little, too late. The repetition of already 
existing commitments is alarming. Either they reneged then, or they are lying 
now.
> 
> - Do you have additional recommendations for steps that you think 
> Camerfirma should take? 

Camerfirma should at minimum insource all subCA operations. Camerfirma should 
automate all BR requirements and steps in the issuance process that is humanly 
possible to automate, and ensure that all manual actions are reviewed 
independently before and after being acted upon. Camerfirma should also replace 
its current legal counsel with a competent one, and ask them to review all 
existing subscriber agreements and other contracts and the BRs and Mozilla root 
program requirements and determine if any conflicts exist, and if so remedy 
them. If conflicts are unresolveable Camerfirma should be distrusted. 
Camerfirma should halt all issuance until the plan is implemented. 

Given the extent of the possible SubCA problems all issuance from the old roots 
should sunset or be limited to explicitly disclosed intermediate certificates, 
no new ones created. Then new roots should be created and a de novo application 
for inclusion created. I'm not sure even this would assauge my worries. 
Ultimately the trust one can place in individuals is dependent upon their 
character, and Camerfirma has a history of being dilatory and lackadaisical 
with critically important issues, and I'm not sure what can change that kind of 
organizational rot.

Sincerely,
Watson Ladd 
> 
> Thanks, 
> 
> Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ryan Sleevi via dev-security-policy]

Hey Ben,

I know discussion here has been quiet, but in light of other threads going
on, I actually want to say I'm very supportive of GlobalSign's plan here,
and surprised they didn't call more attention to it, because it's something
to be proud of.

As I understand it, and happy to be corrected if I've made a mistake here,
GlobalSign is actively working to transition their hierarchy to one that
reflects a modern, good practice implementation. That's something they
should be proud of, and something all CAs should take note of. In
particular, they're transitioning to single-purpose roots (e.g. all TLS,
all e-mail), in order to reduce the risk to relying parties from roots that
exist cross-purposes.

You're absolutely correct for calling out GlobalSign's past incidents, and
I don't want to appear to be suggesting that simply spinning up new roots
wipes the old slate clean, but this is a huge step in the right direction,
and does reflect good practice. I will disclose that GlobalSign reached
out, as have several other CAs (PKIoverheid, Sectigo, DigiCert), to invite
feedback in their design and discuss some of their challenges, and I think
that's also the kind of positive, proactive behavior worth encouraging.

Within the context of the incident reports, I do want to also acknowledge
that GlobalSign has consistently improved the quality of their reports. As
the OCSP issue shows, the level of detail and clarity in their
communications, and their providing artifacts, has been a huge help in
addressing and assuaging concerns. Rather than purely looking at the number
of incidents, and instead looking at how the incident reports are handled,
this is good progress. While some bugs did feel like they dragged out (e.g.
1575880), even then, GlobalSign was proactive in communicating both the
completion of past actions as well as next steps, with clear timetables.

GlobalSign has already proactively addressed some of the other things one
might expect from a "modern" CA - for example, supporting and enabling
automation for their customers, both "retail" and "managed CA/Enterprise"
(via AEG), and so I do see a positive trend in addressing some of the
systemic issues here.

That's not to say things are perfect: for example, the mixing of TLS
profiles (DV, OV, EV) in a single hierarchy means that there are still a
number of systemic risks which we've seen as patterns, both from GlobalSign
and other CAs, in terms of audit and audit scopes and proper validation of
information, but I do think this is trending closer to what would be good
for all CAs  to think about.

The sooner we can get to sunsetting GlobalSign's legacy roots, the better,
and so I definitely think it would be encouraging to see them help migrate
customers sooner than waiting on natural expiration alone, just like I
think continuing to shorten lifetimes would be another very positive sign.
However, I understand and recognize there are complexities here that may
prevent that, but I didn't want folks to think this was "as good as it
gets" ;)

On Mon, Jan 11, 2021 at 7:59 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for GlobalSign.
>
> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4 through 9).
>
> GlobalSign has four (4) new roots to include in the root store.  Two roots,
> one RSA and another ECC, are to support server authentication (Bugzilla Bug
> # 1570724 ) while
> two
> other roots are for email authentication, RSA and ECC (Bugzilla Bug #
> 1637269 ).
>
> Mozilla is considering approving GlobalSign’s request(s). This email begins
> the 3-week comment period, after which, if no concerns are raised, we will
> close the discussion and the request may proceed to the approval phase
> (Step 10).
>
> *A Summary of Information Gathered and Verified appears here in these two
> CCADB cases:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>
> *Root Certificate Information:*
>
> *GlobalSign Root R46 *
>
> crt.sh -
>
> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>
> Download - https://secure.globalsign.com/cacert/rootr46.crt
>
> *GlobalSign Root E46*
>
> crt.sh -
>
> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>
> Download - https://secure.globalsign.com/cacert/roote46.crt
>
> *GlobalSign Secure Mail Root R45 *
>
> crt.sh -
>
> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>
> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>
> *GlobalSign Secure Mail Root E45 *
>
> crt.sh -
>
> 

Re: Root Store Policy Suggestion

[Burton via dev-security-policy]

Hi Ryan,

These are good questions! I'll get back to you tomorrow with the answers to
your questions. I want to research and give you the right information.

Thank you

Burton

On Wed, Jan 27, 2021 at 7:54 PM Ryan Sleevi  wrote:

>
>
> On Wed, Jan 27, 2021 at 2:45 PM Burton  wrote:
>
>> I included the remediation plan in the proposal because a CA will mostly
>> always include a remediation plan when they reach the stage of serious
>> non-compliance investigation by root store policy owners.
>>
>
> Sure, but I was more asking: are you aware of any point in the past where
> the remediation plan has been valuable, useful or appropriate? I'm not.
>
> The expectation is continuous remediation, so any remediation plan at a
> later stage seems too little, too late, right? The very intentional goal of
> the incident reporting was to transition to a continuous improvement
> process, where the CA was evaluated based on their
> contemporaneous remediation to incidents, rather than waiting until things
> get so bad they pile up and a remediation plan is used.
>
> So I'm trying to understand what a remediation plan would include, during
> discussion, that wouldn't (or, more explicitly, shouldn't) have been
> included in the incident reports as they happened?
>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy Suggestion

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 27, 2021 at 2:45 PM Burton  wrote:

> I included the remediation plan in the proposal because a CA will mostly
> always include a remediation plan when they reach the stage of serious
> non-compliance investigation by root store policy owners.
>

Sure, but I was more asking: are you aware of any point in the past where
the remediation plan has been valuable, useful or appropriate? I'm not.

The expectation is continuous remediation, so any remediation plan at a
later stage seems too little, too late, right? The very intentional goal of
the incident reporting was to transition to a continuous improvement
process, where the CA was evaluated based on their
contemporaneous remediation to incidents, rather than waiting until things
get so bad they pile up and a remediation plan is used.

So I'm trying to understand what a remediation plan would include, during
discussion, that wouldn't (or, more explicitly, shouldn't) have been
included in the incident reports as they happened?

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

Re: Root Store Policy Suggestion

[Burton via dev-security-policy]

Hi Ryan,

I included the remediation plan in the proposal because a CA will mostly
always include a remediation plan when they reach the stage of serious
non-compliance investigation by root store policy owners. The first
remediation plan is always a draft version as it's updated as the
discussion is ongoing. Take the recent discussion for example, the
remediation plan is version 5 which seems to be the final version.

New evidence does sometimes appear in public discussions about the CA that
wasn't found or documented earlier and I included that in the proposal as
requests for additional information.

I do agree that CAs who reach the stage of non-compliance investigation
should submit new roots.

Thank you

Burton

On Wed, Jan 27, 2021 at 6:58 PM Ryan Sleevi  wrote:

>
>
> On Wed, Jan 27, 2021 at 10:11 AM Burton  wrote:
>
>> Hello,
>>
>> The Mozilla root store policy should include a section that sets out time
>> limit periods in numbered stages for non-compliance CA discussions. That
>> way everything is fair, can't be disputed and everyone knows when the
>> discussion of the non-compliance CA will conclude. Then the decision from
>> the root store policy owners will proceed shortly afterwards to either
>> accept the remediation plan from the CA or proceed with the partial or
>> complete removal of the CA from the root store.
>>
>> These time limits below should be enough ample time for the discussion to
>> take place between the CA, the community and the root store policy owners.
>>
>> Stage 1 (Discussion Period: *1 Week*):
>>
>>- Official notification to all that an investigation regarding the
>>non-compliance issues of the CA has started.
>>- Requests for additional information, etc.
>>
>> Stage 2 (Discussion Period: *4 Weeks*):
>>
>>- The CA to produces a draft remediation plan.
>>- The CA answers all questions from the root store policy owners and
>>the community.
>>- Requests for additional information, etc.
>>
>> Stage 3 (Discussion Period: *2 Weeks*):
>>
>>- Discussion of the final remediation plan proposed by the CA.
>>- Discussion of whether to partial distrust or full distrust of the
>>CA.
>>- Requests for anymore additional information.
>>
>> The decision by the root store policy owners.
>>
>
> From a proposal standpoint, could you explain a bit more about the goals
> of a "draft remediation plan"?
>
> The point and purpose of Incident Reports is so that CAs are continuously
> improving, and adopting meaningful improvements and remediations. At the
> point at which a CA is being discussed, isn't that already evidence alone
> that the CA's failure to remediate not just the incidents, but the systemic
> root issues, has failed?
>
> Recent replies such as
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg14089.html
> and
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg14090.html
> have captured how, given the nature of how PKI works, the only viable
> remediation plans are those that transition to new roots. This is something
> that, for example, Google Chrome explicitly recommends and encourages, at
> https://g.co/chrome/root-policy , as a way of minimizing the risk to
> their users.
>
> Without expressing opinions on the current, ongoing discussion for
> Mozilla, it may be useful to examine past CA incidents, as it seems that
> there were several remediation plans posed by CAs in the past, yet
> consistently, every single one of them failed to adequately address the
> very core issues, and every one of them revealed actions the CA was already
> expected to be taking, either in light of incidents or as part of the bare
> minimum expectation of CAs.
>
> I mention all of this because your emphasis on remediation plan does seem
> to suggest you see there being viable paths forward, other than (at a
> minimum), a transition from problematic roots to new roots, so I was hoping
> you could expand, using perhaps past CA discussions rather than the current
> one, as they provide ample evidence of problematic patterns.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy Suggestion

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 27, 2021 at 10:11 AM Burton  wrote:

> Hello,
>
> The Mozilla root store policy should include a section that sets out time
> limit periods in numbered stages for non-compliance CA discussions. That
> way everything is fair, can't be disputed and everyone knows when the
> discussion of the non-compliance CA will conclude. Then the decision from
> the root store policy owners will proceed shortly afterwards to either
> accept the remediation plan from the CA or proceed with the partial or
> complete removal of the CA from the root store.
>
> These time limits below should be enough ample time for the discussion to
> take place between the CA, the community and the root store policy owners.
>
> Stage 1 (Discussion Period: *1 Week*):
>
>- Official notification to all that an investigation regarding the
>non-compliance issues of the CA has started.
>- Requests for additional information, etc.
>
> Stage 2 (Discussion Period: *4 Weeks*):
>
>- The CA to produces a draft remediation plan.
>- The CA answers all questions from the root store policy owners and
>the community.
>- Requests for additional information, etc.
>
> Stage 3 (Discussion Period: *2 Weeks*):
>
>- Discussion of the final remediation plan proposed by the CA.
>- Discussion of whether to partial distrust or full distrust of the
>CA.
>- Requests for anymore additional information.
>
> The decision by the root store policy owners.
>

>From a proposal standpoint, could you explain a bit more about the goals of
a "draft remediation plan"?

The point and purpose of Incident Reports is so that CAs are continuously
improving, and adopting meaningful improvements and remediations. At the
point at which a CA is being discussed, isn't that already evidence alone
that the CA's failure to remediate not just the incidents, but the systemic
root issues, has failed?

Recent replies such as
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg14089.html
and
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg14090.html
have captured how, given the nature of how PKI works, the only viable
remediation plans are those that transition to new roots. This is something
that, for example, Google Chrome explicitly recommends and encourages, at
https://g.co/chrome/root-policy , as a way of minimizing the risk to their
users.

Without expressing opinions on the current, ongoing discussion for Mozilla,
it may be useful to examine past CA incidents, as it seems that there were
several remediation plans posed by CAs in the past, yet consistently, every
single one of them failed to adequately address the very core issues, and
every one of them revealed actions the CA was already expected to be
taking, either in light of incidents or as part of the bare minimum
expectation of CAs.

I mention all of this because your emphasis on remediation plan does seem
to suggest you see there being viable paths forward, other than (at a
minimum), a transition from problematic roots to new roots, so I was hoping
you could expand, using perhaps past CA discussions rather than the current
one, as they provide ample evidence of problematic patterns.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Root Store Policy Suggestion

[Burton via dev-security-policy]

Hello,

The Mozilla root store policy should include a section that sets out time
limit periods in numbered stages for non-compliance CA discussions. That
way everything is fair, can't be disputed and everyone knows when the
discussion of the non-compliance CA will conclude. Then the decision from
the root store policy owners will proceed shortly afterwards to either
accept the remediation plan from the CA or proceed with the partial or
complete removal of the CA from the root store.

These time limits below should be enough ample time for the discussion to
take place between the CA, the community and the root store policy owners.

Stage 1 (Discussion Period: *1 Week*):

   - Official notification to all that an investigation regarding the
   non-compliance issues of the CA has started.
   - Requests for additional information, etc.

Stage 2 (Discussion Period: *4 Weeks*):

   - The CA to produces a draft remediation plan.
   - The CA answers all questions from the root store policy owners and the
   community.
   - Requests for additional information, etc.

Stage 3 (Discussion Period: *2 Weeks*):

   - Discussion of the final remediation plan proposed by the CA.
   - Discussion of whether to partial distrust or full distrust of the CA.
   - Requests for anymore additional information.

The decision by the root store policy owners.

Thank you

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