Policy 2.7.1: Process Overview

[Ben Wilson via dev-security-policy]

 Re-posting this email to start it with its own subject line and to start a
new thread:

There have been questions about the process being followed and the comment
period.  Here is where it now stands.

I intend to introduce the remaining discussion topics over the next three
weeks. I did not announce an end to the discussion period on purpose, so
that we can have as full of a discussion as possible. Also, in the next
three weeks, I intend to start summarizing the discussions and coming up
with new suggested language on those issues that have been discussed. I
expect that during December we will start to solidify the amendments to
MRSP (v.2.7.1), and that in January I'll announce a "last call" on the
amendments. Following that I will "summarize a consensus that has been
reached, and/or state the official position of Mozilla" - see
https://wiki.mozilla.org/CA/Updating_Root_Store_Policy.

Part of the discussion that will still need to take place deals with
implementation deadlines, timing, etc. Let's discuss that now for the
non-controversial items, and then in late December / early January for
those that are more contentious (assuming they remain in this batch of
changes).

Sincerely yours,
Ben Wilson
Mozilla Root Store
___
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 Mon, Nov 9, 2020 at 11:53 AM Clemens Wanko via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan, hi all,
> well, isn’t the point to make here just, that there are multiple ways to
> ensure proper auditor qualification? No matter which way you like to go
> however, you must define the details of your regime: what is the criteria
> you require the auditor to fulfill, how do you organize that these criteria
> are checked, how do you ensure the quality of this process, how do you
> publish any results with regard to the auditors qualification, etc.


Clemens,

I see you doubled down on this approach, but I already responded
previously. I think this mindset to compliance does a great disservice, and
also substantially misrepresents, the values and principles at play here.
That is, you've again anchored on the notion here tha compliance should be
a checklist - this exact approach and mindset that has led to countless
security issues and incidents. This is the fundamentally wrong approach
here that I think bears calling out, and it's worth again, emphasizing,
that no, it doesn't have to be like how you describe, and also
(unsurprisingly) overlooks the downsides.

If you examine the posts I referenced previously, you'll see this in
action, so I do hope you will. So your questions are a bit nonsense here,
because they start from a conceptually bad foundation.



> Certainly, there are always alternatives. But the alternative should be
> clearly defined and described in order to allow an evaluation of all the
> options before taking a decision. In the current case I like to understand
> the alternatives you suggest for Mozilla.
>

You've turned this thread into a broader discussion of ETSI standards, and
while many criticisms could be fairly stated, I think that detracts from
this thread, and ignores the very thing it was started to discuss. I'd like
to reorient you back to the original purpose, of bringing transparency to
the auditor skills and competencies. It would seem your position is that
there should be no independent evaluation, by affected software vendors, of
the skills and competencies of the auditor or how they perform the audit.
You would like us to rely solely on the NAB and Supervisory Body for
carrying that out, even for a totally unrelated audit scheme (the eIDAS
Regulation), which can incidentally make use of largely-unrelated standards
for audits (the EN 319 403 series). You seem to argue that's superior to
any form of transparency or accountability, and seem to reject the notion
that, were auditors skills and qualifications known and part of the report,
it can tangibly lead to improvements on the requirements.

Frankly, I think that idea is nonsense. We know, from the Supervisory
Bodies involved in the eIDAS Regulation, that there are vast differences in
quality and expectation from CABs. Browsers have shared those same concerns
to ENISA, and ACAB'c seems to recognize it as well, from its very
existence. Yet you seem to reject efforts to improve that, and suggest that
we simply "trust the process" that it'll get sorted out. We have ample
evidence, from Certificate Transparency, about how bringing transparency
reveals systemic issues and flaws. Yet, rather than embrace this for
audits, it's seemingly rejected with unsubstantiated roadblocks.

You've not responded, in substance, to my previous message, and so I'm not
sure how to interpret that, especially since this largely repeats the same
points.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

Step 6 of CA Application Process
:  *Summary of Discussion
and Resulting Decision:*

One commenter stated that it appeared that a few certificates were
misissued, i.e. that the stateOrProvinceName field (“S” field) should
probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city.  A
NAVER representative responded that it had fixed the DN structure with L
equal to "Seongnam-si" as city name and S field as "Gyeonggi-do" for
province name.  NAVER also added a procedure, in compliance with ISO
3166-2, to put province information correctly in the S field of user DN for
newly issued certificates.

A second commenter noted that: (1) wording in the CPS could allow NAVER to
avoid revoking problematic certificates by relying on Korean law; (2)
“relevant legislation” was not referenced in
sections 9.14 and 9.16.3 as required by BR section 9.16.3; and (3) the list
of events logged did not include "All verification activities" as required
by BR section 5.4.1(2).

Responses to the foregoing included the following: (1) a certificate not
revoked because of Korean law would be a BR violation and the CA would be
required to previously disclose this according to BR section 9.16.3 (the
conflicting requirement could be modified “to the minimum extent necessary
to make the requirement valid and legal” and the CA would have to notify
the CA/Browser Forum of such practice change so that the Forum could react
appropriately. NAVER also stated, “we found that there are no South Korea’s
laws and regulations which affect or refuse the revocation of certificates
that violated the BRs issued by a commercial CA”.  (2) A third commenter
stated, “Note that, in this case, the particular language you're concerned
about is part of the BRs themselves, in 4.9.5. However, this is about
‘when’ to revoke.  I think you raise an interesting point that would
benefit from clarification from NAVER, because I think you're correct that
we should be concerned that the shift from ‘when’ to revoke has become
‘whether’ to revoke, and that is an important difference.” As a result of
these comments, NAVER amended sections 4.9.5, 9.14, and 9.16.3.

Section 4.9.5 of the NAVER CPS now reads, “The period from receipt of the
Certificate Problem Report or revocation-related notice to published
revocation must not exceed the time frame set forth in Section 4.9.1.1. The
date selected by NAVER Cloud will consider the following criteria: …
Relevant legislation.”

Section 9.14 of the NAVER CPS now states, “This CPS is governed, construed
and interpreted in accordance with the laws of Republic of Korea. This
choice of law is made to ensure uniform interpretation of this CPS,
regardless of the place of residence or place of use of NAVER Cloud
Certificates or other products and services. The law of Republic of Korea
applies also to all NAVER Cloud commercial or contractual relationships in
which this CPS may apply or quoted implicitly or explicitly in relation to
NAVER Cloud products and services where NAVER Cloud acts as a provider,
supplier, beneficiary receiver or otherwise.”

(Note that section 1.1 of the NAVER CPS states, “In the event of any
inconsistency between this CPS and the Baseline Requirements, the Baseline
Requirements take precedence over this document.”)

Section 9.16.3 has been amended by adding a paragraph reading, “In the
event of a conflict between CABF Baseline Requirements and a law,
regulation or government order (hereinafter ‘Law’) of any jurisdiction in
which a CA operates or issues certificates, NAVER Cloud modifies any
conflicting requirement to the minimum extent necessary to make the
requirement valid and legal in the jurisdiction. This applies only to
operations or certificate issuances that are subject to that Law. In such
event, NAVER Cloud immediately (and prior to issuing a certificate under
the modified requirement) includes in Section 9.16.3 of this CPS a detailed
reference to the Law requiring a modification of these Requirements under
this section, and the specific modification to these Requirements
implemented by NAVER Cloud.”

(3) Section 5.4.1 now states that “NAVER Cloud records at least the
following events:  … 2. Subscriber Certificate lifecycle management events,
including:  … b. All verification activities stipulated in these
Requirements and the CA’s Certification Practice Statement”.

A key take-away from a review of these comments and responses is the need
for each CA’s CPS language to provide a firm commitment to revoke
certificates on a timely basis. I think members of the Mozilla community do
not want to have to worry about “when” or “whether” a certificate will be
revoked. In sections 4.9.1.1 and 4.9.5 of the NAVER CPS, NAVER has adopted
essentially the 24-hour and 5-day timeframes of sections 4.9.1.1 and 4.9.5
of the Baseline Requirements. Certainly, all CAs could improve the
descriptions of their revocation processes, but this language in the NAVER
CPS meets 

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

[Dimitris Zacharopoulos via dev-security-policy]

Thank you Ben, this is really helpful.

Dimitris.

On 2020-11-09 6:52 μ.μ., Ben Wilson via dev-security-policy wrote:

Hi Dimitris,

I intend to introduce the remaining discussion topics over the next three
weeks. I did not announce an end to the discussion period on purpose, so
that we can have as full of a discussion as possible. Also, in the next
three weeks, I intend to start summarizing the discussions and coming up
with new suggested language on those issues that have been discussed. I
expect that during December we will start to solidify the amendments to
MRSP (v.2.7.1), and that in January I'll announce a "last call" on the
amendments. Following that I will "summarize a consensus that has been
reached, and/or state the official position of Mozilla" - see
https://wiki.mozilla.org/CA/Updating_Root_Store_Policy.

Part of the discussion that will still need to take place deals with
implementation deadlines, timing, etc. Let's discuss that now for the
non-controversial items, and then in late December / early January for
those that are more contentious (assuming they remain in this batch of
changes).

Sincerely yours,
Ben Wilson
Mozilla Root Store


On Mon, Nov 9, 2020 at 2:45 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:



On 7/11/2020 3:12 μ.μ., Ryan Sleevi wrote:


On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos
mailto:ji...@it.auth.gr>> wrote:


 I will try to further explain my thoughts on this. As we all know,
 according to Mozilla Policy "CAs MUST follow and be aware of
 discussions in the mozilla.dev.security.policy
  forum,
 where Mozilla's root program is coordinated". I believe Mozilla
 Root store managers' minimum expectations from CAs are to _read
 the messages and understand the content of those messages_. Right
 now, we have [1], [2], [3], [4], [5], [6], [7], [8], [9]
 policy-related threads opened up for discussion since October 15th.

 If every post in these threads contained as much information and
 complexity as your recent reply to Clemens,


This seems like a strawman argument,  ht I don’t think it’s intentional.

You’re arguing that “if things were like this hypothetical situation,
that would be bad”. However, they aren’t like that situation, as the
evidence you provided shows. This also goes back to the “what is your
desired outcome from your previous mail”, and trying to work out what
a clear call to action to address your concerns. Your previous
message, especially in the context of your (hypothetical) concern,
reads like you’re suggesting “Mozilla shouldn’t discuss policy changes
with the community”. I think we’re all sensitive and aware of the
desire not to have too many parallels discussions, which is exactly
why Ben’s been only introducing a few points a week, to facilitate
that and make progress without overwhelming.

To the contrary, I want more people to be able to participate in these
discussions, which is precisely why I "complained" about the size of
your response to Clemens :-) Keeping our replies to reasonable levels,
with a mindset that this is an International Internet community and
people might be interested to participate (even auditors that are not
native-English speakers), I believe is a good thing.

I also see that Ben has introduced a lot of policy proposal topics for
discussion in a short period of time, but I don't know what the
expectations about their "discussion time" are. Should anyone just pick
any topic and start a discussion? That might introduce a lot of parallel
discussions and I'm not sure if this is desirable by Ben. Perhaps we
need some coordination on these topics, for example "please send
feedback for topics 1 and 2 before the end of week X. If no feedback is
received, we'll deem the proposal accepted", something like that, before
moving to other topics.


As it relates to this thread, or any other thread, it seems the first
order evaluation for any CA is “Will the policy change”, followed by
“What do I need to do to meet the policy?”, both of which are still
very early in this discussion. You’re aware of the policy discussion,
and you’re aware a decision has not been made yet: isn’t that all you
need at this point? Unlike some of the other proposals, which require
action by CAs, this is a proposal that largely requires action by
auditors, because it touches on the audit framework and scheme. It
seems like, in terms of expectations for CAs to participate,
discussing this thread with your auditor is the reasonable step, and
working with them to engage here.

Hopefully that helps. Your “but what if” is easily answered as “but
we’re not”, and the “this is a lot, what do I need to do” is simply
“talk with your auditor and make sure they’re aware of discussions
here”. That seems a very simple, digestible call to action?


It helps me understand your point of view but it seems that you don't
acknowledge the need to keep these 

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

[Clemens Wanko via dev-security-policy]

Hi Ryan, hi all,
well, isn’t the point to make here just, that there are multiple ways to ensure 
proper auditor qualification? No matter which way you like to go however, you 
must define the details of your regime: what is the criteria you require the 
auditor to fulfill, how do you organize that these criteria are checked, how do 
you ensure the quality of this process, how do you publish any results with 
regard to the auditors qualification, etc. 

Now, what we have in place with the EU ETSI scheme (or with WebTrust) is a 
regime which provides 
-   normative options specifically adopted to address CA/B-Forum/Browser 
requirements as well as 
-   a system to ensure auditor qualification is there and kept upright over 
time.
The regime is there, proven and flexible to make proper use out of it. And 
constant effort is made from ETSI as well as from the auditors (ACAB’c) to the 
Forum in order to incorporate CA/B Forum requirements.

Certainly, there are always alternatives. But the alternative should be clearly 
defined and described in order to allow an evaluation of all the options before 
taking a decision. In the current case I like to understand the alternatives 
you suggest for Mozilla.
Best regards
Clemens


On Friday, 6 November 2020 at 20:35:40 UTC+1, Ryan Sleevi wrote:
> On Fri, Nov 6, 2020 at 12:00 PM Clemens Wanko via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > Hi Ryan, hi all, 
> > three things to comment on that: 
> > 
> > 1. How is the EU ETSI audit scheme thought and what is it intended to 
> > provide to Mozilla and the CA/Browser ecosystem? 
> 
> The European scheme of technical standards for CA/TSP developed by ETSI was 
> > made and is constantly adopted to integrate CA/Browser requirements. The 
> > main standards I am referring to are: ETSI EN 319 401, EN 319 411-1 and EN 
> > 319 411-2. With regard to auditor guidance specifically for the CA/Browser 
> > ecosystem, ETSI even developed and maintains the TS 119 403-2 “Part 2: 
> > Additional requirements for Conformity Assessment Bodies auditing Trust 
> > Service Providers that issue Publicly-Trusted Certificates”. 
> > For auditors using such technical standards Europe has established a well 
> > thought through scheme based upon organizations (accredited audit bodies) 
> > which job it is – amongst others – to ensure auditors (the natural person) 
> > qualification, independence, etc. This scheme turned out to be of high 
> > trustworthiness, reliability, robustness, etc. And it works very well over 
> > here since years. 
> >
> I'm sure something is lost in translation, but this does not address any of 
> the concerns raised. The ETSI standards here are not relevant; voluntary 
> standards, in and of themselves, are not binding. The fact that a standard 
> exists is not relevant, since what matters is how the standard is adhered 
> to and supervised. 
> 
> Your subsequent statement is simply "Well, they're auditors, people trust 
> them to do this", without any form of meaningful engagement on the why. 
> "It's their job to ensure independence" - yes, but that says nothing about 
> the performance of the job, that your measure of independence is consistent 
> with another measure, etc. Your entire appeal here simply is "We say we're 
> trustworthy, so of course we're trustworthy", which would be farcical if it 
> wasn't presented so seriously.
> > 2. Transparency 
> > The transparency lies in the European scheme with independent skilled 
> > bodies auditing each other in order to ensure conformant implementation of 
> > technical standards as well as of operational requirements for audit bodies 
> > as well as for the single auditor (natural person).
> This is, again, a restatement of "Trust us, because we declared we're 
> trustworthy". For something such as trust, there's no question of "but 
> verify". Your appeal to SDOs is not relevant here, because as you and I are 
> both aware, the SDO just makes (voluntary) standards, and doesn't enforce 
> them. And this gets to the heart of the matter: the question about how each 
> of these dimensions are interpreted is something you would prefer the CABs 
> to self-declare, and the suggestion here is "Sure, you can say that, but 
> you need to also help us understand why that's true".
> > Not only the requirements for the qualification/independence/etc. of the 
> > auditor (natural person) are clearly defined within the ISO/ETSI but also 
> > the management requirements of the body in order to ensure that they are 
> > kept upright – btw. BSI C5 controls, section 4.4.9 is meant similar to 
> > that. 
> > Every accredited body is audited at least once a year by its NAB which 
> > checks conformant audit processing (e.g. according to ISO/IEC17065 in 
> > combination with ETSI EN 319 403). 
> >
> This is the first time in this e-mail that you remotely come to 
> establishing a "why". As we both know full well, the authority of the CAB 
> (and its 

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

[Ben Wilson via dev-security-policy]

Hi Dimitris,

I intend to introduce the remaining discussion topics over the next three
weeks. I did not announce an end to the discussion period on purpose, so
that we can have as full of a discussion as possible. Also, in the next
three weeks, I intend to start summarizing the discussions and coming up
with new suggested language on those issues that have been discussed. I
expect that during December we will start to solidify the amendments to
MRSP (v.2.7.1), and that in January I'll announce a "last call" on the
amendments. Following that I will "summarize a consensus that has been
reached, and/or state the official position of Mozilla" - see
https://wiki.mozilla.org/CA/Updating_Root_Store_Policy.

Part of the discussion that will still need to take place deals with
implementation deadlines, timing, etc. Let's discuss that now for the
non-controversial items, and then in late December / early January for
those that are more contentious (assuming they remain in this batch of
changes).

Sincerely yours,
Ben Wilson
Mozilla Root Store


On Mon, Nov 9, 2020 at 2:45 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:

>
>
> On 7/11/2020 3:12 μ.μ., Ryan Sleevi wrote:
> >
> >
> > On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos
> > mailto:ji...@it.auth.gr>> wrote:
> >
> >
> > I will try to further explain my thoughts on this. As we all know,
> > according to Mozilla Policy "CAs MUST follow and be aware of
> > discussions in the mozilla.dev.security.policy
> >  forum,
> > where Mozilla's root program is coordinated". I believe Mozilla
> > Root store managers' minimum expectations from CAs are to _read
> > the messages and understand the content of those messages_. Right
> > now, we have [1], [2], [3], [4], [5], [6], [7], [8], [9]
> > policy-related threads opened up for discussion since October 15th.
> >
> > If every post in these threads contained as much information and
> > complexity as your recent reply to Clemens,
> >
> >
> > This seems like a strawman argument,  ht I don’t think it’s intentional.
> >
> > You’re arguing that “if things were like this hypothetical situation,
> > that would be bad”. However, they aren’t like that situation, as the
> > evidence you provided shows. This also goes back to the “what is your
> > desired outcome from your previous mail”, and trying to work out what
> > a clear call to action to address your concerns. Your previous
> > message, especially in the context of your (hypothetical) concern,
> > reads like you’re suggesting “Mozilla shouldn’t discuss policy changes
> > with the community”. I think we’re all sensitive and aware of the
> > desire not to have too many parallels discussions, which is exactly
> > why Ben’s been only introducing a few points a week, to facilitate
> > that and make progress without overwhelming.
>
> To the contrary, I want more people to be able to participate in these
> discussions, which is precisely why I "complained" about the size of
> your response to Clemens :-) Keeping our replies to reasonable levels,
> with a mindset that this is an International Internet community and
> people might be interested to participate (even auditors that are not
> native-English speakers), I believe is a good thing.
>
> I also see that Ben has introduced a lot of policy proposal topics for
> discussion in a short period of time, but I don't know what the
> expectations about their "discussion time" are. Should anyone just pick
> any topic and start a discussion? That might introduce a lot of parallel
> discussions and I'm not sure if this is desirable by Ben. Perhaps we
> need some coordination on these topics, for example "please send
> feedback for topics 1 and 2 before the end of week X. If no feedback is
> received, we'll deem the proposal accepted", something like that, before
> moving to other topics.
>
> >
> > As it relates to this thread, or any other thread, it seems the first
> > order evaluation for any CA is “Will the policy change”, followed by
> > “What do I need to do to meet the policy?”, both of which are still
> > very early in this discussion. You’re aware of the policy discussion,
> > and you’re aware a decision has not been made yet: isn’t that all you
> > need at this point? Unlike some of the other proposals, which require
> > action by CAs, this is a proposal that largely requires action by
> > auditors, because it touches on the audit framework and scheme. It
> > seems like, in terms of expectations for CAs to participate,
> > discussing this thread with your auditor is the reasonable step, and
> > working with them to engage here.
> >
> > Hopefully that helps. Your “but what if” is easily answered as “but
> > we’re not”, and the “this is a lot, what do I need to do” is simply
> > “talk with your auditor and make sure they’re aware of discussions
> > here”. That seems a very simple, digestible call to action?
> >
>
> It 

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

[Dimitris Zacharopoulos via dev-security-policy]

On 7/11/2020 3:12 μ.μ., Ryan Sleevi wrote:



On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos 
mailto:ji...@it.auth.gr>> wrote:



I will try to further explain my thoughts on this. As we all know,
according to Mozilla Policy "CAs MUST follow and be aware of
discussions in the mozilla.dev.security.policy
 forum,
where Mozilla's root program is coordinated". I believe Mozilla
Root store managers' minimum expectations from CAs are to _read
the messages and understand the content of those messages_. Right
now, we have [1], [2], [3], [4], [5], [6], [7], [8], [9]
policy-related threads opened up for discussion since October 15th.

If every post in these threads contained as much information and
complexity as your recent reply to Clemens,


This seems like a strawman argument,  ht I don’t think it’s intentional.

You’re arguing that “if things were like this hypothetical situation, 
that would be bad”. However, they aren’t like that situation, as the 
evidence you provided shows. This also goes back to the “what is your 
desired outcome from your previous mail”, and trying to work out what 
a clear call to action to address your concerns. Your previous 
message, especially in the context of your (hypothetical) concern, 
reads like you’re suggesting “Mozilla shouldn’t discuss policy changes 
with the community”. I think we’re all sensitive and aware of the 
desire not to have too many parallels discussions, which is exactly 
why Ben’s been only introducing a few points a week, to facilitate 
that and make progress without overwhelming.


To the contrary, I want more people to be able to participate in these 
discussions, which is precisely why I "complained" about the size of 
your response to Clemens :-) Keeping our replies to reasonable levels, 
with a mindset that this is an International Internet community and 
people might be interested to participate (even auditors that are not 
native-English speakers), I believe is a good thing.


I also see that Ben has introduced a lot of policy proposal topics for 
discussion in a short period of time, but I don't know what the 
expectations about their "discussion time" are. Should anyone just pick 
any topic and start a discussion? That might introduce a lot of parallel 
discussions and I'm not sure if this is desirable by Ben. Perhaps we 
need some coordination on these topics, for example "please send 
feedback for topics 1 and 2 before the end of week X. If no feedback is 
received, we'll deem the proposal accepted", something like that, before 
moving to other topics.




As it relates to this thread, or any other thread, it seems the first 
order evaluation for any CA is “Will the policy change”, followed by 
“What do I need to do to meet the policy?”, both of which are still 
very early in this discussion. You’re aware of the policy discussion, 
and you’re aware a decision has not been made yet: isn’t that all you 
need at this point? Unlike some of the other proposals, which require 
action by CAs, this is a proposal that largely requires action by 
auditors, because it touches on the audit framework and scheme. It 
seems like, in terms of expectations for CAs to participate, 
discussing this thread with your auditor is the reasonable step, and 
working with them to engage here.


Hopefully that helps. Your “but what if” is easily answered as “but 
we’re not”, and the “this is a lot, what do I need to do” is simply 
“talk with your auditor and make sure they’re aware of discussions 
here”. That seems a very simple, digestible call to action?




It helps me understand your point of view but it seems that you don't 
acknowledge the need to keep these emails to a reasonable and digestible 
size, regardless if the intended recipients are auditors, CAs, Relying 
Parties. You seem to dismiss my point and the fact that some messages on 
this list have been, in fact, very long and very complicated which makes 
participation and contributions very difficult. I trust that we are both 
interested in truly meeting Mozilla's goal for an open Internet 
community (which includes contributions from International 
participants), so please help the community by trying to break down 
complicated responses into simpler ones, and let's all try to use 
shorter answers and to the point.


Indeed, this particular policy change proposal seems to mainly affect 
Auditors, but individual members of this community (either representing 
CAs or as Relying Parties) might also be interested to participate, just 
as Auditors and Relying Parties may participate in discussions around 
policy change proposals that affect CAs. FWIW, I think changing the 
rules for auditors also affects CAs because it creates an opportunity 
for CAs to have engagements with individual auditor persons, as long as 
they are accepted by Mozilla.


___