[cabf_validation] Making progress on disclosures of data sources

[Ryan Sleevi]

I'm hoping we'll be able to make quantifiable progress here on our upcoming
call tomorrow. Given the energy and excitement around our last call, I'm
hoping something more concrete can be shared by CAs as to the challenges
they anticipate? As it stands, it does seem like a September date is
reasonable, even in light of global events, so if there's a
misunderstanding about the challenges being faced, or impact being
overlooked, it'd be great to get that feedback.

On Fri, Apr 10, 2020 at 12:27 PM Ryan Sleevi <sleevi at google.com> wrote:

> We had a lot of interesting conversation about
> https://github.com/sleevi/cabforum-docs/pull/11 yesterday and I'd like to
> make sure we don't lose the momentum, or at least arrive at a clearer
> position for next steps.
>
> There seemed to be some confusion about the language, so I'm hoping folks
> take a quick minute to review
> https://github.com/sleevi/cabforum-docs/pull/11/files about the proposal
> itself, and what the language requires.
>
> From yesterday's call, the substantive concerns I noted, and hopefully am
> not misrepresenting:
>
>    - At some CAs, validation agents are currently empowered to
>    individually decide whether or not the Agency of Incorporation / Agency of
>    Registration is permitted, according to the EV Guidelines. At these CAs,
>    this would create significant burden, because every validation agent would
>    need to be able to update the list.
>    - Moving to an allowlist style approach, of only allowing validation
>    agents to select from pre-approved (disclosed) sources would require new
>    development. and half a year is not sufficient time to implement such
>    controls. For some CAs, it may take a year or more, based on current
>    resourcing, to implement such a restriction.
>    - For some CAs, the compliance team does not have the technical
>    permissions and/or ability to "publicly disclose" things. For example, if
>    disclosing on a website, disclosures must go through a website team, which
>    may take time, and the CAs with such a split do not want to have to wait
>    for this in order to be able to issue certificates.
>    - Even for those CAs who agree with and are capable of implementing
>    the proposed solution, these CAs are concerned that other CAs may not be
>    able to do so within the time specified. There is concern that if the
>    ballot timeline is adjusted so that every CA can successfully meet these
>    requirements, that will miss the opportunity for disclosure and discussion
>    sooner.
>    - Similarly, with the CAA discussion, the disclosures generally did
>    not happen until the very week of the deadline. There's concern that a
>    timeline set forth in September means progress may not be made for half a
>    year, after having already spent half a year trying to get CAs to
>    voluntarily disclose their sources. There's a desire to find a quicker
>    solution for disclosure, but perhaps without requiring the full technical
>    implementation and automation.
>    - Whether or not a third-party website (for example, an online
>    document service, a CDN or a source-control service) can be used to satisfy
>    "readily accessible online means that is available on a 24x7 basis"
>    requirement, or whether that website would become a Delegated Third Party
>    and to what extent Section 8.4 would apply.
>
> As mentioned on the call, I think some of these concerns may have merit,
> but require more detail in order to make effective changes, so I'm hoping
> to get that feedback.
>
> That said, I'm concerned that quite a bit of feedback fits into a common
> theme we've seen regarding other ballots and proposals, and so I think it's
> important to address that up front. There seems to be an assumption that
> the status quo is acceptable or desirable, both in terms of how things are
> done and the pace of change. Here at Google, I don't think we share that
> view: there is always room for improvement, and the ecosystem needs to be
> orders of magnitude more agile than it is in order to effectively serve end
> users' needs. In that view, our goal is not "What is the most time it would
> take to make this change", but rather "What is the most /reasonable/ time
> it would take to make this change".
>
> To that end, it's important to help us understand concrete, rather than
> abstract, concerns. This helps us understand what's reasonable and
> unreasonable, and from an ecosystem perspective, not just the perspective
> of individual CAs. For example, if a timeline of September creates
> challenges with other pending requirements, that's useful to know. As far
> as I can tell, the only pending modification CAs have to make to their
> systems is the reduction of certificate lifetime to comply with browser
> program requirements, and that doesn't seem to interact negatively with
> this at all. If there's disagreement about that statement, providing
> concrete details is useful.
>
> In terms of what changes are required for a CA, the belief is that the
> proposed language would permit the following implementations:
>
> Human Control:
>
>    - Validation Agent receives Registration Agency / Incorporating Agency
>    details
>    - Validation Agent examines list of CA disclosed sources (for example,
>    by visiting the website)
>    - If the Agency is listed, the Validation Agent continues the existing
>    process (e.g. moves to issuance queue)
>    - If the Agency is not listed, the Validation Agent moves it to a
>    disclosure queue
>
> Or Automated Control:
>
>    - Validation Agent receives Registration Agency / Incorporating Agency
>    details
>    - The Validation Agent selects, from a pre-configured list of
>    previously-disclosed sources, the current Agency
>    - If the Agency is not listed, the Validation Agent moves it to a
>    disclosure queue
>
> That does not seem an unreasonable burden, on its face, in that it permits
> both manual and automated controls. It's hard to see how this would be
> difficult to implement, even with training of validation agents, within the
> timeline provided.
>
> While concerns were raised that a "disclosure queue" would be an
> unreasonable delay in issuance, the disclosure process is highly flexible.
> As such, any delays in that queue are fully in the CA's control, and they
> can design and/or staff their system in whatever manner that they wish to
> achieve their desired response time. Further, any delays that exist only
> exist for the first issuance using a new data source, and it also seems
> like allowing half a year for CAs to examine their past issuance and
> compile an initial list would largely, if not entirely, ameliorate that
> concern. Even for new approvals of data sources, the CA does not need to
> update their Legal Repository, nor do they need to notify the CA/Browser
> Forum or seek approval. The ability to add, edit, and remove at will,
> without requiring any third-party approvals, seems like it wholly addresses
> this concern.
>
> We're sympathetic to the concern that having data sooner than later is
> valuable, and potentially with an allowance for "after the fact" disclosure
> (e.g. up to 7 days after issuance using a new data source). The reason for
> the choice of dates was largely because this would require CAs to update
> their CP/CPS to disclose where the datasource is located. Without such a
> requirement, it becomes difficult to impossible for Relying Parties to
> validate the disclosure was made and how/where to examine that data source.
> CAs have consistently stated it may take several months for them to update
> CP/CPSes, hence September.
>
> As such, it's hard to see how to ensure prompt but useful disclosure on
> any time sooner. I can totally appreciate the value in having early
> disclosure of a post-issuance data source, in advance of achieving the
> originally-proposed pre-issuance disclosure in the CP/CPS. However, the
> only alternative that I could come up that could achieve this without
> requiring the CP/CPS update would be to use language such as in 9.16.3.
> This would require CAs disclose to the CA/Browser Forum sooner (e.g. via
> the questions@ list), such as three months from now, while requiring a
> CP/CPS update in September. However, that seemed unnecessarily burdensome
> and for only short-term gains, and it seemed achieving that September
> timeline was far more useful.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200422/91580321/attachment.html>