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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Wed Sep 16 10:30:17 MST 2020


You seem to be conflating my role, as Chair, with HARICA and how HARICA 
evaluates changes in ballots.

I'd like to start off by clarifying that each Member (HARICA as one of 
the voting Members), reviews each ballot independently and votes after 
evaluating the changes of each individual ballots. When a ballot passes, 
this means that each Member must prepare for the changes to be effective 
as soon as the IPR period is over. This has nothing to do with having 
2-3 ballots being added in a single new version of the new Guideline, 
because the Member has already been aware of the upcoming changes 
because of the already voted ballot. This is my personal understanding 
of the situation, and I would even say that it's common sense.

As the Chair, to the best of my ability I interpret the Bylaws, and with 
the help of the Vice Chairs (who have worked with me as officers for 
almost two years) I am ultimately responsible for producing the 
necessary documents and all other activities according to the Bylaws. 
Aggregating ballots to a single version of a Guideline is not 
prohibited, it has been used several times already, yet you found an 
opportunity to attack me personally and imply things for HARICA that are 
totally irrelevant with this issue.

More answers inline.


On 2020-09-16 6:13 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Sep 16, 2020 at 2:12 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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 <mailto: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.
>

I still can't find the relevance of a CA doing its due diligence to 
review the ballots that were voted, with the production of an aggregated 
or individual Guideline. Perhaps someone else with better understanding 
of the issue could rephrase it so I can see how these two are connected. 
Dean, Wayne, can you please assist here?

>>     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
>     <mailto: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.

My "personal judgement" on this topic was after consulting with the Vice 
Chairs and having exercised this practice 3-4 times already, publicly 
and transparently. So I don't understand where all this is suddenly 
coming from. If you had concerns about this practice, you had several 
opportunities to express them. Nevertheless, you expressed your concerns 
now, so we are discussing, publicly, to see if your concerns are well 
founded so we can make progress addressing them.

>
> 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.

No, that's not the case at all. It wasn't just me that though it's very 
reasonable. As I already mentioned, we had a discussion with the vice 
Chairs before following this aggregation practice. Right now, you are 
the only person that thinks that aggregating the final Guideline is not 
reasonable.


> 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.

The aggregation approach is only in the final Guideline, not the ballot. 
Each ballot is voted independently and each CA Member knows the changes 
that are voted on.

>
> 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.
>

This doesn't make much sense to me. The changes will become effective on 
the same day, regardless if we publish 1 version of the Guideline or 3. 
Awareness-wise, it's the same and I would argue that it's easier for a 
CA to send one updated document to their compliance department to check 
what becomes effective, than three documents. All the important 
information for each change is in the independent ballots that don't 
just include the changes but also some rationale and even discussion 
that takes place before the vote.

The Chair has no control of when ballots enter the discussion and voting 
period. Proposers should be aware of other ballots being in the 
discussion period and should know when additional changes will become 
effective almost at the same time.

If proposers believe that the volume of changes is a critical point to 
adoption from the CAs, then it would make more sense to break down 
ballots, like the browser alignment ballot, into smaller ones, with 
enough time in between, so that CAs can adapt to fewer changes before 
introducing another set of changes.

> 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.

HARICA was overloaded and thus we respectfully requested from the SCWG 
and the proposer of a particular ballot, to delay the voting so we can 
have more time to review the changes of *the Ballot*. Once the ballot 
passed, it means it will eventually become effective. It will become 
effective when the next version of the Guideline document is published. 
Whether that document contains changes of more than one ballot, is not 
an issue, because as a CA HARICA has to adapt and comply with everything 
that this document introduces.

>
> 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.

Wait, are you implying that the aggregation of guidelines has anything 
to do with impacting the ability for CAs to adhere to the produced 
Guidelines? And you are accusing me of being responsible for that? I 
hope this is just another misunderstanding otherwise I would kindly ask 
this to be clarified by the Vice Chairs because this sound like an 
unfounded accusation.


> 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.

Aggregated guidelines or separate guidelines, the result is the same, 
the work product is the same, Browser Members will effectively supervise 
the same requirements whether that is in one or three documents being 
published on the same day. They will supervise the last version of the 
Guideline that will include the changes of the other two, so I honestly 
don't understand why we seem to have such a big disconnect.

>     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.

Ok, then we will stop this practice going forward. That's all you had to 
say. I expect Members to raise concerns when they think something is 
off. I don't consider me, or Dean, or Wayne to be perfect in 
interpreting the Forum's documents although in this particular case we 
decided on a practice that was not forbidden (you also agreed to that), 
had good reasons to do it, and went ahead with it without objections 
from Members.

Despite personally feeling that the final result is ultimately the same, 
I will respect your request and stop this practice.

>>         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 used your words. You said "there's nothing in our IP policy I'm aware 
of that requires you to send them as a combined review." and I believe 
you implied it was not forbidden. I may have expressed it in bad English 
so you can address it to anything else other than malice. Even the fact 
that you would consider me being "malicious" after my efforts and 
contributions to this Forum, makes me sad and disappointed.

>>         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.

I already responded to that earlier.

>>         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?

Wow! After all the work I did for this Forum, is this what I deserve? 
This statement made me even more disappointed and sad. I hope other 
Members don't feel the same way about my work at the Forum and how I 
exercised my duties as Chair.

>     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.

I believe your assumptions that aggregating guidelines lead CAs to be 
unable to follow the introduced changes are unfounded, as I explained 
earlier. CAs have to adapt to the changes that become effective 
regardless if they are included in 1, 2 or 3 versions of the Guideline 
being published on the same day. The latest version will include the 
changes of the previous documents issued on the same day.

In conclusion, as mentioned, we will stop this practice going forward. 
Please let me know if you would like to reset the Review period and 
create two separate review notices which will produce two distinct final 
guidelines and then figure out how to combine them (since both redlines 
will be against the current version).

Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200916/67b0776e/attachment-0001.html>


More information about the Public mailing list