[Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi]

On Wed, Sep 16, 2020 at 2:12 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2020-09-16 2:43 π.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>>
>>
>> On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
>>
>>
>>
>> Sure, I can do that but in any case I forwarded it the argument on the
>> list. I also support this argument that aggregating new versions of the
>> documents saves time.
>>
>
> While you're the only one qualified to measure whether it saves time, as a
> browser, this raises a host of questions for understanding how CAs are
> staying abreast of changes and reviewing them. This is actually critical,
> given that I've seen multiple CA incidents where CAs have reported that
> they have trouble staying abreast of changes, even for ballots they voted
> for! So it suggests to me that some of the current ways that CAs are
> keeping up to date are flawed, or lend themselves to easy mistakes.
>
>
> I hope you realize that this is not related with Forum's activities. The
> Forum produces standards/Guidelines. Whether CAs, Relying Parties adhere to
> those standards/Guidelines and update their processes/products is a
> different issue.
>

I hope you realize that questions about the working mode of the Forum
impacting the ability to make reliable use of the Forum's work product is,
of course, essential to the continued value and participation in the Forum.

If the view of the Chair of the Forum is that the Forum should not consider
how usable its work product is, which is voluntary standards that can be
used by Browsers, then I think it raises deep concerns about the value of
the Forum.



> Naturally, if we had the specific member, we could ask them to describe
> their process for staying aware of changes, and why one document makes that
> easier. For example, I'd be deeply concerned if a CA was looking at an
> aggregated SC28+SC35, since they might mistake a meaningful normative
> change as a cleanup or clarification, or similarly, mistake or overlook an
> important clarification because they're distracted by logging changes.
>
>
> I don't think that's necessary. It seems very reasonable to me that
> reviewing one redline document that introduces changes from two or three
> ballots, is more convenient and simpler than having to review two or three
> redline documents to reach the same result.
>
> If there are questions about a new requirement or an introduced change,
> the discussion of the specific ballot that introduced the change is there
> for anyone to review and get a better understanding on the rationale and
> get clarifications. In some cases, even that is not enough, and we
> encourage people to submit questions to the questions at cabforum.org, or if
> these questions come from Members, they can post questions directly to the
> WG public mailing list.
>

I am concerned that you're allowing your personal judgement, which
unfortunately is seemingly clouded by confusion of the issues, to impair
your ability to effectively and respectfully Chair, by selectively picking
and choosing which viewpoints are respected.

I realize you believe it's very reasonable, but that appears to be a lack
of familiarity with the issues we, as browsers, are seeing. As a Forum CA
Member, that's concerning for HARICA, but as a Chair, that's even more
inexcusable. Ballots are specifically produced to group their logical
related changes within a single ballot, to make it clear the many related
things that need to change in order to accomplish a particular goal, as
stated in the Ballot. The aggregation approach destroys that contextually
relevant information.

Your further suggestion that it's confusion that a CA is actively aware of,
and thus can and should avail themselves of questions, when that cannot be
further from what I stated. It is the lack of awareness that causes the
issue, and this lack of awareness is heightened by the increasing number of
changes that come in aggregation.

As a member, HARICA represented that it was overloaded with reviewing
changes, and concerned about the quality of results at the continued
cadence in light of COVID. I would expect that you (HARICA), of all
organizations, should thus be familiar with the risk of many changes
causing important changes to be *overlooked*, rather than misunderstood.

Ultimately, I understand that you, individually, have a workmode that works
for you. However, that workmode is demonstrably not working in industry. As
Chair, I'm requesting you do not impose your preferences on the Forum,
particularly when doing so impairs and impacts the ability for CAs to
adhere to these Guidelines, and thus greatly diminishes the value of the
Forum as a producer of such documents. Again, the relevance of the Forum is
how well it serves industry, and that has to be acknowledged as being how
well its voluntary Guidelines, such as the Baseline Requirements, provide
value to browser members as an alternative to direct vendor auditing, as
practiced in many other ISMS-vendor relationships.


> My priority here is to serve the SCWG and the Forum in a compliant and
> productive manner. If the SCWG Members have no objection to the current
> practice of aggregating Final Guidelines when we have timelines that permit
> this aggregation, I will continue with this practice.
>

Our concern is with aggregation, and while we recognize the value it brings
to making the Chair's role easier, our belief is that it actively harms
compliance and comprehension, and thus request you stop.


> Can you point me to where you believe this practice is forbidden?
>>
>
> Can you mention where I said it was forbidden? I'm not sure how best to
> answer your question, and so I think this might require disentangling what
> you think I said versus what I said.
>
>
> Perhaps I misunderstood this particular statement:
>
>    - "The IP review necessitates the production of the Final document, so
>    that sounds like more work, rather than less, and it seems to run in the
>    same problem of commingling outputs."
>
> I'm glad we are in agreement that this practice is not forbidden and, of
> course, not required.
>
I hope you can recognize the logical fallacy in your statement, which I
hope we can chalk to ignorance rather than malice.

You indeed misunderstood the statement, which is discussing Section 4.1 of
the IPR policy.



> I honestly don't mind the extra work of creating more Guidelines but it
>> seems pointless to create a document that nobody will ever read because it
>> will be valid for just a few seconds.
>>
>
> I described, at length, why it was meaningful, from both an IP perspective
> and from a document versioning perspective. It sounded like you agreed
> with, or at least understood, those challenges, so I'm not sure I
> understand what you're trying to say here.
>
>
> What I'm trying to say is that creating a document with version 1.2.2 and
> 5 minutes later another with version 1.2.3, makes 1.2.2 valid for just 5
> minutes because everyone will just download and read 1.2.3 that
> incorporates the changes introduced in 1.2.2. It seems meaningless (from a
> practical standpoint) to create 1.2.2 since it will not be of use by almost
> anyone.
>

I've repeatedly described to you how it's used, and you repeatedly appear
to be dismissive of this. At this point, it's unclear to me whether this is
deliberate, but I would encourage you that if something isn't clear to you,
perhaps forming questions rather than stating absolutes would be useful.

This goes back to the questions you dismissed as outside the remit of the
Forum at the outset, so perhaps by not being so dismissive, we can find
common ground. Understanding the value of 1.2.2 vs 1.2.3 necessitates
understanding how CAs are reviewing and integrating changes, and working to
identify what good practices are to ensure good compliance. What we
unambiguously know is that present practices are failing, and most
recently, related to an aggregated version you produced. I'm sure it's easy
to dismiss this as the "problem of the CA", but the very purpose of
incident reports is to help effect systemic change. One of the systemic
issues involves understanding how the work product is consumed, and that's
absolutely in the realm of a Forum designed to help encourage good
practices.


> Documents with the *same effective date* would create a lot of confusion
>> to CAs and Relying Parties.
>>
>
> I'm also not really sure I understand this. It appears you're saying here
> that CAs ignore the version, and focus on the date, while in the past,
> you've specifically objected to changes in versioning, because you've
> argued that CAs focus on the version.
>
> Are you saying that having a BRs 1.2.0, 1.2.1, and 1.2.2, and 1.2.3
> creates a lot of confusion to CAs and Relying Parties? Because that's
> /four/ versions within the 3 day window of the Bylaws. (14 Oct - 16 Oct).
>
> But if the review periods end Oct 14 - 16, I will prefer to spend one day
> working with the final guidelines and post the results. I probably don't
> want to spend one day producing 1.2.1, publish the resulting document to
> the mailing lists, update the web site, then do the same the next day for
> 1.2.2. This means that all these Guidelines will be sent (and thus become
> effective) on -say- 16 Oct.
>

OK, so don't run for Chair then?


> From a compliance perspective, all 4 documents (with 4 distinct versions)
> would be effective on 16 Oct which might create challenges and confusion. I
> would like to avoid that an either aggregate or ensure we have different
> effective dates so that at every single day there is one and only one
> normative version of the Guideline in effect. Hope this makes more sense
> then the previous attempt.
>

Thanks. Then it is clear that your argument has limited basis in
demonstrated reality, as you appear to be unaware of it being harmful, and
appear to be shutting down discussion about improving it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200916/1233ec06/attachment-0001.html>