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

[Kathleen Wilson via dev-security-policy]

On 10/16/20 11:26 PM, Ryan Sleevi wrote:

Because of this, it seems that there is a simpler, clearer, unambiguous
path for CAs that seems useful to move to:
- If a CA is trusted for purpose X, that certificate, and all subordinate
CAs, should be audited against the criteria relevant for X



I am in favor of this approach for a future version of Mozilla's Root 
Store Policy, but I prefer not to try to tackle it in this v2.7.1 
update.  So I filed a github issue to remind us to consider this in the 
next version:


https://github.com/mozilla/pkipolicy/issues/220


I have added a section called "EV TLS Capable" to the wiki pages, and I 
will appreciate feedback on it:


https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable

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


Thanks,
Kathleen

___
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 #192: Require information about auditor qualifications in the audit report

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 5, 2020 at 7:00 PM Wojtek Porczyk 
wrote:

> On Thu, Nov 05, 2020 at 11:48:20AM -0500, Ryan Sleevi via
> dev-security-policy wrote:
> > competency is with individuals, not organizations.
>
> [snip]
>
> > I find the appeal to redundancy and the NAB, and further, the suggestion
> of
> > GDPR, to be a bit insulting to this community. This opposition to
> > transparency fundamentally undermines the trust in ETSI provided audits,
> or
> > this appeal to the eIDAS scheme, which has limited relevance given it's a
> > fundamentally different audit scheme, beggars belief. If you'd like to
> > raise Fear/Uncertainty/Doubt about GDPR, I believe you owe this
> community a
> > precise and detailed explanation about what you believe, relevant to the
> > auditor professional experience, would be problematic.
>
> Not the original poster, but
> 1) I understand that the very general language of OP, which you dismiss as
> FUD, is because this is "consult your own lawyer" area;
> 2) contrary to what you have written, the onus is on Mozilla to demonstrate
> the compliance with GDPR and not the other way around.
>

I think this is significantly misstating things.

Without opining on the legal statements you've offered, the reality is that
fundamentally, if we cannot achieve reasonable evidence to trust the
auditor - specifically, the individuals that make up the audit team (both
the audit members and any relevant technical experts that may have
contributed) - then there's no objective reason to accept the audit. The
concerns you raised are secondary to that, and so the objection to
something *cannot* be provided simply means that it would limit the
utility, reliability, and trustworthiness of those audits and potentially
make them unacceptable. The need for objective, transparent understanding
about the skills and competencies is as paramount as the need for an
objective, transparent understanding about the CA itself, and for which
audits exist. The attestation of the CAB is demonstrably insufficient for
purpose, in the same way as a CA saying "I solemnly swear I'm up to good"
would not somehow invite trust.

I understand that the appeal is "Well, the NAB oversees the CAB, you see,
and EA oversees the NABs, and through the power of Regulation 765/2008,
trust is imbued", but that of course fails the very basic test of having
concrete, objective data for the consumer of the audit (e.g. Mozilla, but
also this broader community). It entirely outsources the supervision,
without providing any evidence of meeting the requirement, for a core
product security requirement. Rather than accept such risk, it becomes just
as reasonable to reject such audits.

I highlight this because to suggest something *cannot* be done is to
unquestionably invite the assertion of FUD. If there are *challenges* to
doing so, we should try to find solutions. But outright dismissal, or
suggesting somehow that transparency is not necessary because *handwave*
this other scheme *handwave* doesn't inspire confidence, nor does it
achieve the necessary transparency. This is clearly not insurmountable, as
discussed previously, and in the worst case, might mean that rather than
arbitrarily accepting audits, Mozilla would contractually negotiate with
potential auditors to ensure the necessary skills and qualifications were
met (e.g. as widely practiced in other industries).
___
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 #192: Require information about auditor qualifications in the audit report

[Wojtek Porczyk via dev-security-policy]

On Thu, Nov 05, 2020 at 11:48:20AM -0500, Ryan Sleevi via dev-security-policy 
wrote:
> competency is with individuals, not organizations.

[snip]

> I find the appeal to redundancy and the NAB, and further, the suggestion of
> GDPR, to be a bit insulting to this community. This opposition to
> transparency fundamentally undermines the trust in ETSI provided audits, or
> this appeal to the eIDAS scheme, which has limited relevance given it's a
> fundamentally different audit scheme, beggars belief. If you'd like to
> raise Fear/Uncertainty/Doubt about GDPR, I believe you owe this community a
> precise and detailed explanation about what you believe, relevant to the
> auditor professional experience, would be problematic.

Not the original poster, but
1) I understand that the very general language of OP, which you dismiss as
FUD, is because this is "consult your own lawyer" area;
2) contrary to what you have written, the onus is on Mozilla to demonstrate
the compliance with GDPR and not the other way around.

If Mozilla (or you personally, in your capacity as peer, doesn't matter)
intend to keep track of competency of people (like "physical people" and not
corporations), those people (at least those, who perform audits in Europe)
have certain rights from Mozilla under GDPR. You can't have it both ways
-- either you keep trust in organisations and ignore GDPR, or you keep trust
in people, and then you have all those GDPR requirements. Those are not hard
to fulfill, but they would have to be thought through before the policy takes
effect. I have found nothing in either the proposed change, or your response,
that this problem has been thought through.

For example, art. 13 of GDPR specifies that the data subject (the auditor) is
to be provided with information that the data about her/him is processed. In
the spirit of transparency, could you post an example notice which would be
sent to the auditor in question?

What would be the legal basis? (art. 6) If (e) or (f), the auditor has a right
to object; what would happen after the objection?

Have Mozilla appointed a representative in the EU (art. 27)? (I just checked
and I have found only "Attn: Legal" address in USA). If not, why? If yes,
what's his/her name and contact details?


-- 
pozdrawiam / best regards
Wojtek Porczyk
 
 I do not fear computers,
 I fear lack of them.
-- Isaac Asimov


signature.asc
Description: PGP signature
___
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 #192: Require information about auditor qualifications in the audit report

[Ryan Sleevi via dev-security-policy]

That sounds like a great idea, and sounds like a good compliment to an
approach that several (Root) CAs have taken, of requiring all their
externally-operated subordinate CAs review their auditors and audit scope
with the root CAO, before finalizing the audit engagement.

An example of how the public review has been done in the past is available
at
https://groups.google.com/g/mozilla.dev.security.policy/c/sRJOPiePUvI/m/oRmRffaQmcYJ

On Thu, Nov 5, 2020 at 4:53 PM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ben,
>
> We're concerned that these changes could unintentionally prevent many new
> auditors from being able to conduct audits, despite being Qualified
> Auditors.  The problem is that CAs will understandably be very hesitant to
> use a new auditor, as they cannot risk having an audit conducted, and then
> not accepted by Mozilla.  An unfortunate effect of that is that CAs will
> likely only consider auditors who have a previous history of being accepted
> as qualified.
>
> One potential solution is to allow CAs to ask Mozilla to "pre-vet" a
> potential auditor they would like to use.  Mozilla policy already has a
> process in the next paragraph to provide opinions on auditors who "do not
> fit the definition of Qualified Auditor" that could potentially be
> re-used.  Unfortunately, as the paragraph is currently worded, it can only
> be used for auditors who are *NOT* Qualified, which is really weird.
>
> It would be helpful to clarify that CAs MAY use the same procedure to work
> with Mozilla to determine whether a particular auditor is Qualified or not,
> prior to the beginning an engagement.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy 
> On
> > Behalf Of Ben Wilson via dev-security-policy
> > Sent: Tuesday, November 3, 2020 6:53 PM
> > To: Mozilla 
> > Subject: Policy 2.7.1: MRSP Issue #192: Require information about auditor
> > qualifications in the audit report
> >
> > Historically, Mozilla Policy required that CAs "provide attestation of
> their
> > conformance to the stated verification requirements and other operational
> > criteria by a competent independent party or parties with access to
> details of
> > the CA's internal operations."
> > https://wiki.mozilla.org/CA:CertificatePolicyV1.0  "Competency" was "for
> > whom there is sufficient public information available to determine that
> the
> > party is competent to judge the CA's conformance to the stated criteria.
> In the
> > latter case the '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."
> >
> > Today, section 3.2 of the MRSP
> >  > group/certs/policy/#32-auditors>
> > states, "In normal circumstances, Mozilla requires that audits MUST be
> > performed by a Qualified Auditor, as defined in the Baseline Requirements
> > section 8.2," but under section 2.3  > US/about/governance/policies/security-group/certs/policy/#23-baseline-
> > requirements-conformance>,
> > "Mozilla reserves the right to accept audits by auditors who do not meet
> the
> > qualifications given in section 8.2 of the Baseline Requirements, or
> refuse
> > audits from auditors who do."
> >
> > Section 8.2 of the Baseline Requirements states an auditor must have:
> > 1. Independence from the subject of the audit; 2. The ability to conduct
> an
> > audit that addresses the criteria specified in an Eligible Audit Scheme
> (see
> > Section 8.1); 3. Employs individuals who have proficiency in examining
> Public
> > Key Infrastructure technology, information security tools and techniques,
> > information technology and security auditing, and the third-party
> attestation
> > function; 4. (For audits conducted in accordance with any one of the ETSI
> > standards) accredited in accordance with ISO 17065 applying the
> requirements
> > specified in ETSI EN 319 403; 5. (For audits conducted in accordance
> with the
> > WebTrust standard) licensed by WebTrust; 6. Bound by law, government
> > regulation, or professional code of ethics; and 7. Except in the case of
> an
> > Internal Government Auditing Agency, maintains Professional
> Liability/Errors
> > & Omissions insurance with policy limits of at least one million US
> dollars in
> > coverage
> >
> > It is proposed in Issue #192
> >  that information about
> > individual auditor's qualifications be provided--identity, competence,
> > experience and independence. (For those interested as to this
> independence
> > requirement, Mozilla Policy v.1.0 required either disclosure of the
> auditor's
> > compensation or the 

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

[Tim Hollebeek via dev-security-policy]

Ben,

We're concerned that these changes could unintentionally prevent many new 
auditors from being able to conduct audits, despite being Qualified Auditors.  
The problem is that CAs will understandably be very hesitant to use a new 
auditor, as they cannot risk having an audit conducted, and then not accepted 
by Mozilla.  An unfortunate effect of that is that CAs will likely only 
consider auditors who have a previous history of being accepted as qualified.

One potential solution is to allow CAs to ask Mozilla to "pre-vet" a potential 
auditor they would like to use.  Mozilla policy already has a process in the 
next paragraph to provide opinions on auditors who "do not fit the definition 
of Qualified Auditor" that could potentially be re-used.  Unfortunately, as the 
paragraph is currently worded, it can only be used for auditors who are *NOT* 
Qualified, which is really weird.

It would be helpful to clarify that CAs MAY use the same procedure to work with 
Mozilla to determine whether a particular auditor is Qualified or not, prior to 
the beginning an engagement.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Tuesday, November 3, 2020 6:53 PM
> To: Mozilla 
> Subject: Policy 2.7.1: MRSP Issue #192: Require information about auditor
> qualifications in the audit report
> 
> Historically, Mozilla Policy required that CAs "provide attestation of their
> conformance to the stated verification requirements and other operational
> criteria by a competent independent party or parties with access to details of
> the CA's internal operations."
> https://wiki.mozilla.org/CA:CertificatePolicyV1.0  "Competency" was "for
> whom there is sufficient public information available to determine that the
> party is competent to judge the CA's conformance to the stated criteria. In 
> the
> latter case the '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."
> 
> Today, section 3.2 of the MRSP
>  group/certs/policy/#32-auditors>
> states, "In normal circumstances, Mozilla requires that audits MUST be
> performed by a Qualified Auditor, as defined in the Baseline Requirements
> section 8.2," but under section 2.3  US/about/governance/policies/security-group/certs/policy/#23-baseline-
> requirements-conformance>,
> "Mozilla reserves the right to accept audits by auditors who do not meet the
> qualifications given in section 8.2 of the Baseline Requirements, or refuse
> audits from auditors who do."
> 
> Section 8.2 of the Baseline Requirements states an auditor must have:
> 1. Independence from the subject of the audit; 2. The ability to conduct an
> audit that addresses the criteria specified in an Eligible Audit Scheme (see
> Section 8.1); 3. Employs individuals who have proficiency in examining Public
> Key Infrastructure technology, information security tools and techniques,
> information technology and security auditing, and the third-party attestation
> function; 4. (For audits conducted in accordance with any one of the ETSI
> standards) accredited in accordance with ISO 17065 applying the requirements
> specified in ETSI EN 319 403; 5. (For audits conducted in accordance with the
> WebTrust standard) licensed by WebTrust; 6. Bound by law, government
> regulation, or professional code of ethics; and 7. Except in the case of an
> Internal Government Auditing Agency, maintains Professional Liability/Errors
> & Omissions insurance with policy limits of at least one million US dollars in
> coverage
> 
> It is proposed in Issue #192
>  that information about
> individual auditor's qualifications be provided--identity, competence,
> experience and independence. (For those interested as to this independence
> requirement, Mozilla Policy v.1.0 required either disclosure of the auditor's
> compensation or the establishment that the auditor "is bound by law,
> government regulation, and/or a professional code of ethics to render an
> honest and objective judgement regarding the CA.")
> 
> While subsection 3 of BR 8.2 requires "individuals who have proficiency in
> examining Public Key Infrastructure technology, information security tools and
> techniques, information technology and security auditing, and the third-party
> attestation function," that fact needs evidence in order to be established. 
> The
> proposed resolution of this Issue #192 intends to accomplish that.
> 
> This proposal to require disclosure of individual auditor qualifications is 
> very
> similar to the approach adopted by the U.S. Federal PKI
> 

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

[Tim Hollebeek via dev-security-policy]

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.

-Tim

[*] I'm going to use the terms CAx, where x = { Organization, Certificate,
Key }, to avoid the ambiguities in the term "CA".

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, November 4, 2020 2:04 PM
> To: Corey Bonnell 
> Cc: Mozilla 
> Subject: Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous
Audits
> 
> (Aside: Congrats on the new e-mail address)
> 
> The question here is what does "the grave" mean. A common response from
> CAs is "Oh, we stopped issuing TLS certificates from that X years ago,
that's
> why we don't have audits this year", even though a given root (**or**
> subordinate) is still included/transitively trusted.
> 
> The goal is to capture that the obligation of a CA exists until they are
fully
> removed, or until they destroy the key.
> 
> This also addresses another concern that we saw with the SHA-1
deprecation,
> in which CA's would give notice on a Monday "Please remove our root
> certificate", and then expect that, by Tuesday, they could ignore Mozilla
policy
> requirements and the BRs. That doesn't work, because unless/until the CA
is
> fully removed, Mozilla users, and the broader ecosystem, are at risk. So
this is
> intended to prevent that scenario, by highlighting that merely asking for
> removal isn't sufficient, the removal needs to be completed. And, if that
takes
> too long, the CA has an option to destroy the key (e.g. if they're going
out of
> business).
> 
> For the situation you describe, of transference of key material
> control/ownership, that responsibility still continues, plus the added
> intersection of the Section 8 requirements regarding such transfer. The
new
> organization is responsible for providing those continuing audits, or, if
they
> don't like that obligation, the destruction of key material. There's still
> "devious" things that can happen; e.g. old-CA notifies Mozilla on Monday,
> Mozilla approves on Tuesday, new CA requests removal on Wednesday, new
> CA begins shenanigans on Thursday, it's reasonable to ask whether or not
old-
> CA knew that new-CA was going to get up to mischief and what the
> implications are. But that's stuff that would nominally get sorted out on
> Tuesday.
> 
> Note that some of this discussion comes from 2 years ago in the CA/B Forum
in
> Shanghai, at https://cabforum.org/2018/10/18/minutes-for-ca-browser-
> forum-f2f-meeting-45-shanghai-17-18-october-2018/#28-Audit-requirements-
> over-the-lifecycle-of-a-root
> 
> On Wed, Nov 4, 2020 at 10:14 AM Corey Bonnell via dev-security-policy <
dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > I reviewed the associated GitHub commentary on the following change:
> >
> > "Full-surveillance period-of-time audits MUST be conducted and updated
> > audit information provided no less frequently than **annually** until
> > the CA certificate is no longer trusted by Mozilla's root store.
> > Successive audits information provided no less frequently than
> > **annually** from the time of CA key pair generation until the CA
> > certificate is no longer trusted by Mozilla's root store or until all
> > copies of the CA private key have been completely destroyed, as
> > evidenced by a Qualified Auditor's key destruction report, whichever
> > occurs sooner."
> >
> > and I'm having difficulty understanding why there is a new stipulation
> > to allow for key destruction reports to 

Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Ben Wilson via dev-security-policy]

This email begins discussion of a potential change to section 6 of the
Mozilla Root Store Policy
.


The method by which a person may provide a CA with proof of private key
compromise has been an issue discussed on the mdsp list

this past year.

According to section 4.9.1.1 of the CA/Browser Forum's Baseline Requirements
, key compromise is
one reason for certificate revocation within a 24-hour period, and section
4.9.3 of the Baseline Requirements requires that CAs provide "clear
instructions for reporting suspected Private Key Compromise ..." and that
they "publicly disclose the instructions through a readily accessible
online means and in section 1.5.2 of their CPS."  However, in many of the
CPSes reviewed by Mozilla, the only information appearing is a contact
person's street address, email address, and sometimes a telephone number.
Seldom is this information provided in the context of revocation for key
compromise, and in many situations, email is an inadequate method of
communicating key compromises, especially at scale. Some CAs have portals
(e.g. DigiCert 
and Sectigo ) in
addition to an email address to submit revocation requests. There is also
an open-source ACME server which is designed for the sole purpose of
receiving revocations: https://github.com/tobermorytech/acmevoke.

Github Issue #205  notes
that the best place for disclosure of such revocation methods would be in
section 4.9.12 of a CA's CPS. Section 4.9.12 of the RFC 3647 outline
 is titled "Special
requirements re key compromise". Not only will this requirement make it
easier for the Mozilla community to report key compromises, but it will
also help streamline key-compromise-based revocations, thereby reducing the
number of Bugzilla incidents filed for delayed revocation.

Draft language in
https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4
proposes to add a last sentence to section 6 of the MRSP reading "Section
4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may
use to demonstrate private key compromise."

We recognize that there is some overlap with the BR 4.9.3 requirement that
certain instructions be provided in section 1.5.2 of the CPS, but we
believe that the overlap can be worked through during this discussion and,
if not, a related discussion within the CA/Browser Forum.

We look forward to your comments and suggestions on this issue.

Sincerely yours,
Ben Wilson
Mozilla Root Store Program
___
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 #192: Require information about auditor qualifications in the audit report

[Ryan Sleevi via dev-security-policy]

Hi Clemens,

I think this fundamentally misunderstands the proposal. As Ben mentioned,
and as countless other schemes have highlighted, competency is with
individuals, not organizations. While the eIDAS Scheme is relevant for
eIDAS qualification, I think it's important to highlight that browsers are
not, nor have they ever, relied upon the Qualified Trust List, nor on the
eIDAS Framework, as they are fundamentally separate trust frameworks. I
understand you see this redundant, but given that browsers are not relying
on the Supervisory Body function, since they are different trust
frameworks, it's absolutely vital for transparency to be able to provide
that information.

While something may be acceptable for the eIDAS Certification scheme,
audits exist to support those consuming them, and it's important to make
sure they are addressed. WebTrust equally has an approach like you
describe, but what is being suggested here is that is not sufficient for
the need and use case, and I fully support that. I can understand that
professional accountability is scary, because it might mean that audits
that might be acceptable for eIDAS are rejected as unacceptable for
Mozilla, but again, that's a reflection of the different nature of trust
frameworks.

I find the appeal to redundancy and the NAB, and further, the suggestion of
GDPR, to be a bit insulting to this community. This opposition to
transparency fundamentally undermines the trust in ETSI provided audits, or
this appeal to the eIDAS scheme, which has limited relevance given it's a
fundamentally different audit scheme, beggars belief. If you'd like to
raise Fear/Uncertainty/Doubt about GDPR, I believe you owe this community a
precise and detailed explanation about what you believe, relevant to the
auditor professional experience, would be problematic.

The suggestion here that this is somehow unique or untowards is deeply
concerning. I note, for example, that BSI's own C5 controls are designed
around transparency, and Section 4.4.9 on auditor qualification similarly
places provisions for transparency.

Without making an appeal to either the NAB or the Supervisory Body, both of
which are relevant for eIDAS but not acting in a function for browser trust
frameworks (nor can they), what alternative would you propose to help
community members here have verifiable evidence and confidence in the
auditor's qualifications?

On Thu, Nov 5, 2020 at 10:54 AM Clemens Wanko via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ben,
> in order to avoid for every single audit the compilation work for the
> auditor (in person) on his qualification, independence, etc. as well as the
> need to crosscheck the statements he made, that was covered for the EU
> ETSI/eIDAS scheme by the accreditation of the body (organization; example:
> I am member/employee of TUV Austria CERT as accredited body) employing and
> using that auditor (in person) for a specific audit. The body will
> receive/keep its accreditation only in case it proves in annual audits with
> its accreditation body, that the following auditor related aspects were
> covered in the audit projects performed throughout the past audit period:
>
> ISO/IEC17065 - I listed the relevant chapters only:
> 6 Resource requirements ... 31
> 6.1 Certification body personnel ... 31
> 6.1.1 General .. 31
> 6.1.2 Management of competence for personnel involved in the certification
> process . 31
> 6.1.3 Contract with the personnel  33
> 6.2 Resources for evaluation. 33
> 6.2.1 Internal resources  33
> 6.2.2 External resources (outsourcing) ... 33
>
> …amended by guidance documentation in the following areas:
> Annex A (informative) Principles for product certification bodies and
> their certification activities ... 63
> A.1 General .. 63
> A.2 Impartiality  63
> A.3 Competence .. 65
> A.4 Confidentiality and openness . 65
> A.4.1 General .. 65
> A.4.2 Confidentiality .. 65
> A.4.3 Openness .. 65
> A.4.4 Access to information .. 65
> A.5 Responsiveness to complaints and appeals
> .. 65
> A.6 Responsibility ... 67
>
> For ETSI/eIDAS auditors the ISO/IEC17065 is detailed by the following
> mandatory ETSI EN 319 403 (updated version: ETSI EN 319 403-1)
> requirements. I listed 

Re: NAVER: Public Discussion of Root Inclusion Request

[Sooyoung Eo via dev-security-policy]

Thank you all for the comments during the public discussion phase.
All matters raised in this public discussion has been fixed and then published
our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14, and 
9.16.3.

You can find the revised CPS v1.5.0 at our repository.
https://certificate.naver.com/bbs/initCrtfcJob.do
(directly download link: 
https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf)

To minimize confusion,  I would like to metion that "NAVER BUSINESS PLATFORM" 
has been renamed to "NAVER Cloud" without any changes on the ownership of 
the company and Certification Authority on October 26, 2020.

Kind Regards,
Sooyoung Eo


2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용:
> The 3-week public discussion was to close on Monday, but I'd like Naver to 
> provide any further final comments and give anyone else an opportunity to 
> comment through this Thursday, and then I will proceed with Steps 6-10 
> (summarize matters, note any remaining items, and make a last call for 
> objections).
> On Fri, Oct 23, 2020 at 10:04 AM Sooyoung Eo via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:
> > > Minor but it seems like all certificates with a stateOrProvinceName 
> > field are misissued. The ST field should probably be the "Gyeonggi-do" as 
> > the "Seongnam-si" entered is a city. 
> > > 
> > > 
> > > 
> > > ‐‐‐ Original Message ‐‐‐ 
> > > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy < 
> > dev-secur...@lists.mozilla.org> wrote: 
> > > 
> > > > Dear All, 
> > > > 
> > > > This is to announce the beginning of the public discussion phase of 
> > the 
> > > > Mozilla root CA inclusion process, 
> > > > https://wiki.mozilla.org/CA/Application_Process#Process_Overview, 
> > (Steps 4 
> > > > through 9). Mozilla is considering approval of NAVER Business Platform 
> > > > Corp.’s request to include the NAVER Global Root Certification 
> > Authority as 
> > > > a trust anchor with the websites trust bit enabled, as documented in 
> > the 
> > > > following Bugzilla case: 
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby 
> > initiate a 
> > > > 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 the 
> > CCADB: 
> > > > 
> > > > 
> > https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261
> >  
> > > > 
> > > > *NAVER Global Root Certification Authority, *valid from 8/18/2017 to 
> > > > 8/18/2037 
> > > > 
> > > > SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265 
> > > > 
> > > > https://crt.sh/?id=1321953839 
> > > > 
> > > > Root Certificate Download: 
> > > > 
> > > > 
> > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_real_file_nm=naverrca1.crt
> >  
> > > > 
> > > > CP/CPS: 
> > > > 
> > > > Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29) 
> > 
> > > > through 42 in Bugzilla contain discussion concerning the CPS and 
> > revisions 
> > > > thereto. 
> > > > 
> > > > Current CPS is version 1.4.3: 
> > > > 
> > > > 
> > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf_real_file_nm=NBP
> >  
> > Certification Practice Statement v1.4.3.pdf 
> > > > 
> > > > Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do 
> > > > 
> > > > BR Self Assessment (Excel file) is located here: 
> > > > 
> > > > https://bugzilla.mozilla.org/attachment.cgi?id=9063955 
> > > > 
> > > > Audits: Annual audits are performed by Deloitte according to the 
> > > > WebTrust Standard and WebTrust Baseline Requirements audit criteria. 
> > See 
> > > > webtrust.org. The last complete audit period for NAVER was from 1 
> > December 
> > > > 2018 to 30 November 2019 and no issues were found. However, the audit 
> > > > report was dated 28 April 2020, which was more than three months 
> > following 
> > > > the end of the audit period. The explanation for the delay in 
> > obtaining the 
> > > > audit report was as follows, “NBP had received a notification mail on 
> > > > updating the audit information from CCADB support in March since the 
> > Root 
> > > > certificate is only included into Microsoft Root Program. According to 
> > > > instructions on the email, I explained that NBP would submit the audit 
> > > > update information in April to Microsoft.” The current audit period 
> > ends 
> > > > 30 November 2020. 
> > > > 
> > > > *Mis-Issuances * 
> > > > 
> > > > According to crt.sh and censys.io, the issuing CA under this root 
> > > > (NAVER Secure 

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

[Clemens Wanko via dev-security-policy]

Hi Ben, 
in order to avoid for every single audit the compilation work for the auditor 
(in person) on his qualification, independence, etc. as well as the need to 
crosscheck the statements he made, that was covered for the EU ETSI/eIDAS 
scheme by the accreditation of the body (organization; example: I am 
member/employee of TUV Austria CERT as accredited body) employing and using 
that auditor (in person) for a specific audit. The body will receive/keep its 
accreditation only in case it proves in annual audits with its accreditation 
body, that the following auditor related aspects were covered in the audit 
projects performed throughout the past audit period:

ISO/IEC17065 - I listed the relevant chapters only:
6 Resource requirements ... 31
6.1 Certification body personnel ... 31
6.1.1 General .. 31
6.1.2 Management of competence for personnel involved in the certification 
process . 31
6.1.3 Contract with the personnel  33
6.2 Resources for evaluation. 33
6.2.1 Internal resources  33
6.2.2 External resources (outsourcing) ... 33

…amended by guidance documentation in the following areas: 
Annex A (informative) Principles for product certification bodies and their 
certification activities ... 63
A.1 General .. 63
A.2 Impartiality  63
A.3 Competence .. 65
A.4 Confidentiality and openness . 65
A.4.1 General .. 65
A.4.2 Confidentiality .. 65
A.4.3 Openness .. 65
A.4.4 Access to information .. 65
A.5 Responsiveness to complaints and appeals 
.. 65
A.6 Responsibility ... 67

For ETSI/eIDAS auditors the ISO/IEC17065 is detailed by the following mandatory 
ETSI EN 319 403 (updated version: ETSI EN 319 403-1) requirements. I listed the 
relevant chapters only:
“Electronic Signatures and Infrastructures (ESI); Trust Service Provider 
Conformity Assessment; Part 1: Requirements for conformity assessment bodies 
assessing Trust Service Providers”:
6 Resource requirements 
...
 11
6.1 Conformity Assessment Body personnel 
.
 11
6.1.1 General 

 11
6.1.2 Management of competence for personnel involved in the audit 
process... 11
6.1.2.0 General requirements 

 11
6.1.2.1 Management of 
competence..
 11
6.1.2.2 Training of audit teams 
.
 12
6.2 Resources for evaluation 
..
 12
6.2.0 General requirements 
..
 12
6.2.1 Internal resources 

 12
6.2.1.0 General requirement 
..
 12
6.2.1.1 Competence of Conformity Assessment Body personnel 
. 12
6.2.1.2 Competences for all functions 
...
 12
6.2.1.3 Competences for application review 
.
 13
6.2.1.4 Competences and prerequisites for 
auditing..
 13
6.2.1.5 Competences for review