[Servercert-wg] Ballot SC30: Disclosure of Registration / Incorporating Agency

[Ryan Sleevi]

On Tue, Jun 23, 2020 at 1:52 PM Entschew, Enrico <e.entschew at d-trust.net>
wrote:

> Hallo,
>
>
>
> I have no content-specific comments but I would like to suggest some
> changes to make it more readable for non-native English speakers.
>

Thanks! This is really appreciated.


> I would also emphasize to use either SHALL or MUST to be more consistent.
>

Sure, this should have been "The CA MUST perform some action" and "The
action SHALL be performed in this way". I think you went the other way (the
CA SHALL do something), but it seems like the EVGs are more consistently
that the CA MUST do something, and the something SHALL be a certain way.


> -----------------
>
> Changed:
>
> (line 508) Effective as of 1 October 2020, the CA SHALL ensure that the
> Registration Number is valid according to at least one format disclosed by
> the CA for that applicable Registration Agency or Incorporating agency. The
> CA has to disclose a set of acceptable format or formats for Registration
> Numbers for the applicable Registration Agency or Incorporating Agency, as
> described in Section 11.1.3.
>

My worry here is that it loses the "optional" disclosure that some CAs felt
was important. That is, the CA MAY choose to not disclose and/or restrict
the Registration Number (e.g. some Registration/Incorporating Agencies
don't disclose the format or intentionally discourage assuming a format).

I agree, it's worded a bit clunky as-is, but it's trying to capture that
the enforcement is required, if, and only if, they've also disclosed a
format. I'm wondering if you have any suggestions on how to preserve this
optional nature. This seems important to get right, especially if your
reword didn't preserve it as optional because you didn't read it as
optional :)


>
>
> Changed:
>
> (line 760) Effective as of 1 October 2020 the CA SHALL publicly disclose
> Agency Information about the Incorporating Agency or Registration Agency
> before using an Incorporating Agency or Registration Agency to fulfill
> these verification requirements. This SHALL be through an appropriate and
> readily accessible online means.
>

The current language was trying to mirror the Section 8.2.2 language
regarding CP/CPSes. I thought that parallel (and to the BRs Section 2.2)
would make this easier? I worry that "this" may be seen as ambiguous.


> […]
>
> (line 765) * The acceptable forms or syntax of such Numbers, if the CA
> restricts the form or syntax of the Registration Number used by the
> Incorporating Agency or Registration Agency; and,
>

Yeah, this seems reasonable. The current wording was trying to highlight
and address some CAs' concern about it being optional (see above).


> […]
>
> -----------------
>
>
>
> I hope you find this useful.
>
>
>
> Thanks,
>
> Enrico
>
>
>
> *Von:* Servercert-wg <servercert-wg-bounces at cabforum.org> *Im Auftrag von
> *Ryan Sleevi via Servercert-wg
> *Gesendet:* Wednesday, June 17, 2020 1:32 AM
> *An:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Betreff:* [Servercert-wg] Ballot SC30: Disclosure of Registration /
> Incorporating Agency
>
>
>
> This begins the discussion period for Ballot SC30: Disclosure of
> Registration / Incorporating Agency
>
>
>
>
> *Purpose of Ballot: *
> 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.
>
> This was originally drafted in
> https://github.com/sleevi/cabforum-docs/pull/11 , and as a pull request
> is available at https://github.com/cabforum/documents/pull/194
>
> The following motion has been proposed by Ryan Sleevi of Google and
> endorsed by Ben Wilson of Mozilla and Dimitris Zacharopoulos of HARICA.
>
> *— MOTION BEGINS —*
>
> This ballot modifies the “Guidelines for the Issuance and Management of
> Extended Validation Certificates” (“EV Guidelines”) as follows, based on
> version 1.7.2:
>
> ADD a paragraph to Section 9.2.4 of the EV Guidelines as defined in the
> following redline:
> https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09..33de720df2af6328922524e675f02cb4468a9609
>
> ADD a paragraph to Section 9.2.5 of the EV Guidelines as defined in the
> following redline:
> https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09..33de720df2af6328922524e675f02cb4468a9609
>
> ADD a Section 11.1.3 to the EV Guidelines as defined in the following
> redline:
> https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09..33de720df2af6328922524e675f02cb4468a9609
>
> The Chair or Vice-Chair is permitted to update the Relevant Dates of the
> EV Guidelines as appropriate, such as in the following redline:
> https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09..33de720df2af6328922524e675f02cb4468a9609
>
> *— MOTION ENDS —*
>
> This ballot proposes a Final Maintenance Guideline.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
> Start Time: 17-June 2020 00:00 UTC
> End Time: 24-June 2020 12:00 UTC
>
> Vote for approval (7 days)
> Start Time: TBD
> End Time: TBD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200623/e616ac5e/attachment.html>