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
SC30 - Disclosure of Registration/Incorporating Agency #194
Conversation
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.
There was a problem hiding this 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”?
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001983.html |
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:
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.