Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

Here is my attempt to reword section 3.2 based on combining MRSP version
2.4.1 with version 2.7.
My approach was to align the concepts of "competent", "independent" and
"qualified" with their more-accepted meanings.
Version 2.4.1 and earlier versions of the Mozilla Root Store Policy mixed
some of these concepts together.

3.2 Auditors

Mozilla requires that audits MUST be performed by a competent, independent,
qualified party.

The burden is on the CA to prove *establish* that it*s auditor* has me*e*t
*s* the below requirements *below*.

However*,* the CA MAY request a preliminary determination from us regarding
the acceptability of the criteria and/or the competent, independent,
qualified party or parties by which it proposes to meet the requirements of
this policy.

By "competent party" we mean a person or other entity *group of persons* who
is authorized to perform audits according to the stated criteria (e.g., by
the organization responsible for the criteria or by a relevant agency) or
for whom there is sufficient public information available to determine that
the party is competent *has sufficient education, experience, and ability*
to judge the CA’s conformance to the stated criteria.

In the latter case, "Public information" referred to SHOULD include
information regarding the party’s:
- knowledge of CA-related technical issues such as public key cryptography
and related standards;
- experience in performing security-related audits, evaluations, or
risk analyses;
and
- honesty and objectivity *ability to deliver an opinion as to the CA’s
compliance with applicable requirements*.

By "independent party" we mean a person or other entity *group of persons* who
is not affiliated with the CA as an employee or director and for whom at
least one of the following statements is true:

the party is not financially compensated by the CA;

the nature and amount of the party's financial compensation by the CA is
publicly disclosed; or

the party is bound by law, government regulation, and/or a professional
code of ethics to render an honest and objective judgement regarding the CA.

By "qualified party" we mean a person or other entity or group of persons who
meets  *meeting *the requirements of section 8.2 of the Baseline
Requirements.

If a CA wishes to use auditors who do not fit the definition in section 8.2
of the Baseline Requirements, they MUST receive written permission from
Mozilla to do so in advance of the start of the audit engagement.

Mozilla will make its own determination as to the suitability of the
suggested party or parties, at its sole discretion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

[Ben Wilson via dev-security-policy]

All,

Based on the comments received, I am inclined to clarify the proposed
language under Issues #154 and #187 with reference to a CA's Bugzilla
compliance bugs rather than "incidents".  The existing language in section
2.4 of the MRSP already requires the CA to promptly file an Incident Report
in Bugzilla for all incidents.

My proposal for Issue #154 is to add a final sentence to MRSP section 2.4
which would say, "If being audited according to the WebTrust criteria, the
CA’s Management Assertion letter MUST include a complete list of the CA's
Bugzilla compliance bugs that were unresolved at any time during the audit
period."

Under Issue #187, I propose that new item 11 in MRSP section 3.1.4 (required
publicly-available audit documentation) would read:  "11.  a complete list
of the CA’s Bugzilla compliance bugs that were unresolved at any time
during the audit period."

Regarding guidance on excluding bugs that are flagged as "Invalid" or
"Duplicate" - I propose that we add a section to
https://wiki.mozilla.org/CA/BR_Audit_Guidance and hyperlink to it from the
words "CA's Bugzilla compliance bugs".  The guidance would say that invalid
or duplicate bugs do not need to be included in the list.

Also, in response to Jeff's comment, if a bug is in an unresolved status
spanning two audit periods, I think it should still appear in both
management assertions and audit reports because one of the primary
rationales for these requirements is to ensure that auditors are aware of
the CA's compliance status.

Thoughts?

Thanks,

Ben



On Fri, Nov 6, 2020 at 10:36 AM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, October 22, 2020 at 1:53:40 PM UTC-5, Ben Wilson wrote:
> > The purpose of this email is to begin public discussion on the addition
> of
> > a subsection 11 to section 3.1.4 of the Mozilla Root Store Policy. Issue
> > #187  in GitHub
> proposes
> > to require audit reports to list all incidents occurring (or open)
> during
> > the audit period of which the auditor has been made aware or to state
> that
> > the auditor is unaware of any incidents. This is related to Issue #154
> >  (management assertion
> > disclosures). That proposal is to have section 2.4 read as follows: "If
> > being audited to the WebTrust criteria, the Management Assertion letter
> > MUST include all known incidents that occurred or were still
> > open/unresolved at any time during the audit period."
> >
> > Proposed language may be found in the following commits:
> >
> > -
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/f6639f503b743aae402dc0f4841dc3dd5ba88753
> > -
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/6c07c44e4db473dc4d34009f1bc955a0e18cb4c1
> > -
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/5dec00e53b4c6361d85af7644660fe185fcf463d
> >
> > Proposed language for section 3.1.4 is:
> >
> > "11. all incidents (as defined in section 2.4) that occurred or were
> still
> > open/unresolved at any time during the audit period, or a statement that
> > the auditor is unaware of any;"
> >
> > I look forward to your comments, suggestions and discussions.
> >
> > Ben
>
> Thanks for bringing this up Ben.  It is important to consider this
> requirement in conjunction with #154 and address them together. It seems
> reasonable to require a CA to disclose all known incidents that are
> applicable during a given period. It would be important, however, to define
> “known incident” as a “verified bug” and exclude items such as bugs closed
> as a duplicate, invalid, etc.  It would also make sense to clarify that an
> incident should only be disclosed once and eliminate duplication when an
> incident spans two audit periods.
>
> Also keep in mind an auditor typically issues an opinion on management’s
> assertion of its controls. Audit opinions do not make negative assurance
> statements, such as not being aware of any incidents during the period. If
> the CA is required to make this assertion, the auditor’s opinion will
> consider that statement.
>
> Thanks,
>
> Jeff
> ___
> 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 Camerfirma's Compliance Issues

[Watson Ladd via dev-security-policy]

On Sunday, January 24, 2021 at 11:58:29 AM UTC-8, Ramiro Muñoz wrote:

> 
> Thanks everyone for your valuable contribution to the discussion. We’ve 
> prepared a throughful Remediation Plan that addresses all areas of 
> improvement emerged both in this public discussion as well as direct contacts 
> with some of the members 
> https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing.
>  The plan is very ambitious but, we’ve our BoD commitment to align Camerfirma 
> to the highest level of standards of the Mozzilla community. Please feel free 
> send us any request for clarification or any suggestion to improve the 
> attached document. 

The remediation plan seems to raise, not eliminate issues:

- Action point 1 raises the possibility that anomalous actions are possible. 
Why aren't the issuance processes automated and logged already?

- Action point 2 will not work. Humans are bad at monitoring for rare 
conditions. Some of the issues were not misspellings or confusion over the name 
of a company, but syntactic defects that machines could detect. It should at 
minimum be paired with automated validation.

- Action point 5 should already be achieved as a result of commitments made in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30

- Action point 9 should be trivial. But it isn't. Why not?

Beyond that all of these are actions that should have been undertaken in 
remediation of the past issues when they happened. I see very little that would 
remediate the risks of missussance, such as e.g exiting the sub-CA business, 
and migrating to a proven CA infrastructure rather than the homegrown one that 
seems to give operators plenty of scope to make mistakes. There's no issuance 
freeze to permit these necessary controls to be in place before resuming.

Sincerely,
Watson Ladd

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

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

As an alternative for this addition to MRSP section 5.3, please consider
and comment on:

Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
Program MUST disclose in the CCADB all non-technically constrained CA
certificates they issue that chain up to that CA certificate trusted in
Mozilla’s CA Certificate Program. This applies to all non-technically
constrained CA certificates, including those that are self-signed,
doppelgänger, reissued, or cross-signed.


On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson  wrote:

> Jakob,
>
> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>> an included root CA?
>>
>>
>> To clarify, the title of section 5.3 is "Intermediate Certificates".
> Also, both subsection (1) and (2) under the proposed amendment reference
> "intermediate certificates" -  "(1) ...the Subject Distinguished Name in a
> CA certificate or *intermediate certificate* that is in scope according
> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
> certificate*." And finally, additional
> language would try and make this clear by saying, "Thus, these
> requirements also apply to so-called reissued/doppelganger CA certificates
> (roots *and intermediates*) and to cross-certificates."
>
> I hope this answers your question.
>
> Sincerely,
>
> Ben
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Ben Wilson via dev-security-policy]

In line with the proposed hyperlink to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable from
"capable of issuing EV certificates" (see Issue #147), then I don't think
the proposed parenthetical is necessary anymore, and I think this issue can
be considered resolved without needing to explain policy constraints for EV
audit exceptions in the MRSP.


On Fri, Nov 6, 2020 at 4:43 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  >> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
>  >> occurrence of "capable of issuing EV certificates" link to
>  >> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> > In the definition of EV TLS Capable, I'd move the last bullet up to the
> top.
> >
>
> Done. Thanks!
>
>
> ___
> 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: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

In addition to the original proposal, I propose that we hyperlink "capable
of issuing EV certificates" to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable.

On Thu, Nov 12, 2020 at 11:23 AM Ben Wilson  wrote:

>
> On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via
> dev-security-policy  wrote:
>
>> I see that this is related to
>> https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
>> Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
>> does not assert the anyPolicy or the CA's EV policy OID, including the
>> CA/B Forum EV OID, regardless of what the end-entity certificate asserts.
>>
>> That's correct.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

As proposed, changes to section 3.1.3 of the MRSP do not make any
distinction between root CAs and subordinates.  Nonetheless, what if we
added this sentence to MRSP section 3.1.3, "This cradle-to-grave audit
requirement applies equally to subordinate CAs as it does to root CAs."?
If that does not resolve the issues raise, please provide recommended edits
to section 3.1.3 of the MRSP that will make it more clear and less
susceptible to misinterpretation.

On Sun, Jan 24, 2021 at 12:55 PM Ben Wilson  wrote:

> I agree that we should add language that makes it more clear that the key
> destruction exception for audit only applies to the CA certificates whose
> key has been destroyed.  I'm also hoping that a CAO wouldn't destroy a Root
> CA key if there were still valid subordinate CAs that the CAO might need to
> revoke.
>
> On Fri, Nov 6, 2020 at 10:49 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 2020-11-05 22:43, Tim Hollebeek wrote:
>> > So, I'd like to drill down a bit more into one of the cases you
>> discussed.
>> > Let's assume the following:
>> >
>> > 1. The CAO [*] may or may not have requested removal of the CAC, but
>> removal
>> > has not been completed.  The CAC is still trusted by at least one public
>> > root program.
>> >
>> > 2. The CAO has destroyed the CAK for that CAC.
>> >
>> > The question we've been discussing internally is whether destruction
>> alone
>> > should be sufficient to get you out of audits, and we're very skeptical
>> > that's desirable.
>> >
>> > The problem is that destruction of the CAK does not prevent issuance by
>> > subCAs, so issuance is still possible.  There is also the potential
>> > possibility of undisclosed subCAs or cross relationships to consider,
>> > especially since some of these cases are likely to be shutdown
>> scenarios for
>> > legacy, poorly managed hierarchies.  Removal may be occurring
>> *precisely*
>> > because there are doubts about the history, provenance, or scope of
>> previous
>> > operations and audits.
>> >
>> > We're basically questioning whether there are any scenarios where
>> allowing
>> > someone to escape audits just because they destroyed the key is likely
>> to
>> > lead to good outcomes as opposed to bad ones.  If there aren't
>> reasonable
>> > scenarios where it is necessary to be able to remove CACs from audit
>> scope
>> > through key destruction while they are still trusted by Mozilla, it's
>> > probably best to require audits as long as the CACs are in scope for
>> > Mozilla.
>> >
>> > Alternatively, if there really are cases where this needs to be done, it
>> > would be wise to craft language that limits this exception to those
>> > scenarios.
>> >
>>
>> I believe that destruction of the Root CA Key should only end audit
>> requirements for the corresponding Root CA itself, not for any of its
>> still trusted SubCAs.
>>
>> One plausible (but hypothetical) sequence of events is this:
>>
>> 1. Begin Root ceremony with Auditors present.
>>
>> 1.1 Create Root CA Key pair
>> 1.2 Sign Root CA SelfCert
>> 1.3 Create 5 SubCA Key pairs
>> 1.4 Sign 5 SubCA pre-certificates
>> 1.5 Request CT Log entries for the 5 SubCA pre-certificates
>> 1.6 Sign 5 SubCA certificates with embedded CTs
>> 1.7 Sign, but do not publish a set of post-dated CRLs for various
>> contingencies
>> 1.8 Sign, but do not publish a set of post-dated revocation OCSP
>> responses for those contingencies
>> 1.9 Sign, but do not yet publish, a set of post-dated non-revocation
>> OCSP responses confirming that the SubCAs have not been revoked on each
>> date during their validity.
>> 1.10 Destroy Root CA Key pair.
>>
>> 2. Initiate audited storage of the unreleased CRL and OCSP signatures.
>>
>> 3. End Root ceremony, end root CAC audit period.
>>
>> 4. Release public audit report of this ceremony, this ends the ordinary
>> audits required for the Root CA Cert.  However audit reports that only
>> the correct contingency and continuation OCSP/CRL signatures were
>> released from storage remain technically needed.
>>
>> 5. Maintain revocation servers that publish the prepared CRLs and OCSP
>> answers according to their embedded dates.  Feed their publication queue
>> from audited batch releases from the storage.
>>
>> 6. Operate the 5 SubCAs under appropriate security and audit schemes
>> detailed in CP/CPS document pairs.
>>
>> 7. Apply for inclusion in the Mozilla root program.
>>
>>
>> In the above hypothetical scenario, there would be no way for the the
>> CAO to misissue new SubCAs or otherwise misuse the root CA Key Pair, but
>> still the usual risks associated with the 5 SubCA operations.
>>
>> Also the CAO would have no way to increase the set of top level SubCAs
>> or issue revocation statements in any yet-to-be-invented data formats,
>> even if doing so would be legitimate or even required by the root
>> programs.
>>
>> Thus the hypothetical scenario could land the CAO in an impossible
>> situation, if root 

Re: Summary of Camerfirma's Compliance Issues

[Ramiro Muñoz via dev-security-policy]

El jueves, 3 de diciembre de 2020 a las 19:01:55 UTC+1, Ben Wilson escribió:
> All, 
> 
> We have prepared an issues list as a summary of Camerfirma's compliance 
> issues over the past several years. The purpose of the list is to collect 
> and document all issues and responses in one place so that an overall 
> picture can be seen by the community. The document is on the Mozilla wiki: 
> https://wiki.mozilla.org/CA:Camerfirma_Issues. 
>  
> 
> I will now forward the link above to Camerfirma to provide them with a 
> proper opportunity to respond to the issues raised and to ask that they 
> respond directly in m.d.s.p. with any comments, corrections, inputs, or 
> updates that they may have. 
> 
> If anyone in this group believes they have an issue appropriate to add to 
> the list, please send an email to certif...@mozilla.org. 
> 
> Sincerely yours, 
> Ben Wilson 
> Mozilla Root Program

Thanks everyone for your valuable contribution to the discussion. We’ve 
prepared a throughful Remediation Plan that addresses all areas of improvement 
emerged both in this public discussion as well as direct contacts with some of 
the members 
https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing.
 The plan is very ambitious but, we’ve our BoD commitment to align Camerfirma 
to the highest level of standards of the Mozzilla community. Please feel free 
send us any request for clarification or any suggestion to improve the attached 
document. 

Thanks for your contribution.


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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

I agree that we should add language that makes it more clear that the key
destruction exception for audit only applies to the CA certificates whose
key has been destroyed.  I'm also hoping that a CAO wouldn't destroy a Root
CA key if there were still valid subordinate CAs that the CAO might need to
revoke.

On Fri, Nov 6, 2020 at 10:49 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2020-11-05 22:43, Tim Hollebeek wrote:
> > So, I'd like to drill down a bit more into one of the cases you
> discussed.
> > Let's assume the following:
> >
> > 1. The CAO [*] may or may not have requested removal of the CAC, but
> removal
> > has not been completed.  The CAC is still trusted by at least one public
> > root program.
> >
> > 2. The CAO has destroyed the CAK for that CAC.
> >
> > The question we've been discussing internally is whether destruction
> alone
> > should be sufficient to get you out of audits, and we're very skeptical
> > that's desirable.
> >
> > The problem is that destruction of the CAK does not prevent issuance by
> > subCAs, so issuance is still possible.  There is also the potential
> > possibility of undisclosed subCAs or cross relationships to consider,
> > especially since some of these cases are likely to be shutdown scenarios
> for
> > legacy, poorly managed hierarchies.  Removal may be occurring *precisely*
> > because there are doubts about the history, provenance, or scope of
> previous
> > operations and audits.
> >
> > We're basically questioning whether there are any scenarios where
> allowing
> > someone to escape audits just because they destroyed the key is likely to
> > lead to good outcomes as opposed to bad ones.  If there aren't reasonable
> > scenarios where it is necessary to be able to remove CACs from audit
> scope
> > through key destruction while they are still trusted by Mozilla, it's
> > probably best to require audits as long as the CACs are in scope for
> > Mozilla.
> >
> > Alternatively, if there really are cases where this needs to be done, it
> > would be wise to craft language that limits this exception to those
> > scenarios.
> >
>
> I believe that destruction of the Root CA Key should only end audit
> requirements for the corresponding Root CA itself, not for any of its
> still trusted SubCAs.
>
> One plausible (but hypothetical) sequence of events is this:
>
> 1. Begin Root ceremony with Auditors present.
>
> 1.1 Create Root CA Key pair
> 1.2 Sign Root CA SelfCert
> 1.3 Create 5 SubCA Key pairs
> 1.4 Sign 5 SubCA pre-certificates
> 1.5 Request CT Log entries for the 5 SubCA pre-certificates
> 1.6 Sign 5 SubCA certificates with embedded CTs
> 1.7 Sign, but do not publish a set of post-dated CRLs for various
> contingencies
> 1.8 Sign, but do not publish a set of post-dated revocation OCSP
> responses for those contingencies
> 1.9 Sign, but do not yet publish, a set of post-dated non-revocation
> OCSP responses confirming that the SubCAs have not been revoked on each
> date during their validity.
> 1.10 Destroy Root CA Key pair.
>
> 2. Initiate audited storage of the unreleased CRL and OCSP signatures.
>
> 3. End Root ceremony, end root CAC audit period.
>
> 4. Release public audit report of this ceremony, this ends the ordinary
> audits required for the Root CA Cert.  However audit reports that only
> the correct contingency and continuation OCSP/CRL signatures were
> released from storage remain technically needed.
>
> 5. Maintain revocation servers that publish the prepared CRLs and OCSP
> answers according to their embedded dates.  Feed their publication queue
> from audited batch releases from the storage.
>
> 6. Operate the 5 SubCAs under appropriate security and audit schemes
> detailed in CP/CPS document pairs.
>
> 7. Apply for inclusion in the Mozilla root program.
>
>
> In the above hypothetical scenario, there would be no way for the the
> CAO to misissue new SubCAs or otherwise misuse the root CA Key Pair, but
> still the usual risks associated with the 5 SubCA operations.
>
> Also the CAO would have no way to increase the set of top level SubCAs
> or issue revocation statements in any yet-to-be-invented data formats,
> even if doing so would be legitimate or even required by the root
> programs.
>
> Thus the hypothetical scenario could land the CAO in an impossible
> situation, if root program requirements or common CA protocols change,
> and those changes would require even one additional signature by the
> root CA Key Pair.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>