Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SC30 - Disclosure of Registration/Incorporating Agency #194

Merged

Conversation

sleevi
Copy link
Contributor

@sleevi sleevi commented Jun 16, 2020

Purpose

The EV Guidelines aim to ensure a consistent and repeatable level of validation for certificates, regardless of the CA performing the validation, providing Relying Parties consistency for all certificates complying with these Guidelines. Although the Guidelines attempt to specify objective requirements, areas remain that rely on a subjective determination by the CA. One such area is determining whether a given Incorporating Agency or Registration Agency fulfills these Requirements.

As currently specified, it's possible for one CA to make a determination that a given Registration Agency or Incorporating Agency does meet the requirements of the EV Guidelines, while a different CA determines that same Agency does not. As the reliability of the information validated within the Certificate is tied to the reliability of the data source used to verify this information, this inconsistency undermines the assurance that EV Certificates are meant to provide.

While there is utility in being able to identify precisely what datasource(s) were used with a given Certificate, this ballot does not involve such work. It merely seeks to ensure that, for any given Organization, it can be validated consistently and to the same degree, regardless of the CA, by working to achieve consistency among all CAs in their selection of data sources.

Much like the work to remove "Any other method" from the validation of domain names, ensuring consistency, transparency, and objectivity in validating domain names, this ballot is the first step to doing the same for organization information.

A potential roadmap of ballots to to address these issues involves:

  • CAs publish the list of Registration Agencies / Incorporating Agencies they use (this ballot)
  • Create an allowed list of Registration Agencies / Incorporating Agencies and associated values, along with a process for updating and adding new ones, and requiring issuance exclusively use Agencies on this list.
  • If useful and relevant to Relying Parties, ensure each Certificate can be tied back to their Registration Agency / Incorporating Agency, such as disclosure within the Certificate itself, so they can unambiguously and uniquely determine the organization that has been validated.

A similar process may then be repeated for other forms of verification data sources, such as the QIIS, QTIS, and QGIS within the EV Guidelines, or the Reliable Data Sources within the Baseline Requirements.

sleevi and others added 7 commits June 16, 2020 18:33
Based on discussions on the 2020-02-27 Validation Subcommittee call,
this attempts to put in a basic requirement that the CA document
publicly what sources they use as a Registration Agency or
Incorporating Agency.

It is meant to be lightweight, while providing suitable transparency,
by merely requiring public documentation be made available what
source(s) will be used and what the allowed value(s) are for those
sources. The CA is not required to place this information in their
CP/CPS, but is required to place a pointer to this information so that
it can be discovered. Further, the CA is required to provide a basic
changelog that MUST minimally include a version and date, to avoid any
ambiguities when referencing this data.
Address a few concerns raised with the draft:

* Section 8.2 is more related to Certificate Policy OIDs. While disclosure requirements within the CP/CPS are captured here, instead move the disclosure of information sources closer to the verification process, since disclosure is required prior to use within verification
* There was concern that '24x7 availability' is at odds with a light touch approach that would permit disclosure via source control repositories (e.g. GitHub, GitLab) or online document services (e.g. Microsoft Office 365, Google G Suite). "readily accessible" is sufficient to indicate it must have more uptime than downtime
* Shift from 1 September to 1 October. This ensures "at least" three months, factoring in discussion, voting, and IP review, while avoiding any holiday freezes.
* Clarify that CAs only need to declare the sources they use, rather than any source they evaluate. CAs still need to disclose prior to use, and thus benefit from disclosing more early, but this does not require disclosure of every source evaluated, including those that are never used.
* Address default-deny concerns by making it clear that it's a minimum, not a maximum, for disclosure
Only require disclosure of form/syntax if the CA actually restricts.
Since this is only about disclosure, make it clear it is OK to disclose multiple values for the jurisdiction fields, if there really is a qualifying Agency which is authoritative for multiple distinct jurisdictions.
This addresses feedback from Tim and Doug regarding ambiguous
language:

1. "consistent with" in 9.2.4 has been replaced by instead clarifying
that, at time of issuance, the value must have been disclosed, and
must have been disclosed for the relevant Agency

2. "consistent with" in 9.2.5 is reworded to make it clear that the
disclosure of format is optional (addressing Doug's concern), but
if it is disclosed, the Registration Number must match (one of)
the formats disclosed for that Agency (addressing Tim's concerns)
Make it clear that you don't have to version for each individual line item change, but that you can batch changes. It's still necessary to publish prior to issuance.
Copy link

@jap122 jap122 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be acceptable to allow a certain margin to disclose the agency “after x days of issuance”, instead of forcing it to be always “prior”?

@sleevi
Copy link
Contributor Author

sleevi commented Jun 17, 2020

Would it be acceptable to allow a certain margin to disclose the agency “after x days of issuance”, instead of forcing it to be always “prior”?

https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001983.html

@sleevi sleevi changed the base branch from master to Ballot-SC30-and-31 July 17, 2020 20:10
@sleevi sleevi merged commit 4cf41b5 into cabforum:Ballot-SC30-and-31 Jul 17, 2020
@sleevi sleevi deleted the 2020-03-02-EVG-Jurisdiction branch July 17, 2020 20:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants