[cabf_validation] Making progress on disclosures of data sources

Doug Beattie doug.beattie at globalsign.com
Wed Apr 22 13:44:25 MST 2020


Ryan,

 

I understand what you are asking for, but the question is why is this needed?  There is always room for improvement, but is this necessary and why, from a security and “Ecosystem” perspective, is this the most important “next thing” for CAs to do?  I’m hopeful that when this is turned into a ballot there is sufficient background and driving motivation for the ballot so we all understand why we’re going to spend the time working on this.  If you already have a list of reasons, then great, post them along with the preballot and we can all better understand the motivation.  

 

I’m not necessarily against the ballot because it will level the playing field and we’ll all need to use “good” sources, but is that a known issue that is impacting the security of the ecosystem?  Given Google is against identity in TLS certificates and has removed all EV chrome treatment, it seems like an odd item for Google to be advocating.

 

Doug

 

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Wednesday, April 22, 2020 4:12 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Making progress on disclosures of data sources

 

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 <mailto: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/043899a2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5688 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20200422/043899a2/attachment-0001.p7s>


More information about the Validation mailing list