[cabf_validation] Making progress on disclosures of data sources
Ryan Sleevi
sleevi at google.com
Fri Apr 10 09:27:13 MST 2020
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/20200410/76c09f54/attachment.html>
More information about the Validation
mailing list