[Servercert-wg] [EXTERNAL] State or Province

[Ryan Sleevi]

On Thu, Sep 5, 2019 at 7:48 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> On Thu, Sep 5, 2019 at 4:18 PM Tim Hollebeek via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> I agree that a discussion of the goals for this certificate field might
>> help us select a list (I’d throw out that it also might not).  I personally
>> don’t have any strong opinions on the goals, other than a desire for clear
>> requirements and uniformity.
>>
>>
>>
>> Regarding requirements around disclosure of reasons for violating the
>> SHOULD, I’m curious how that would actually work at the scale required.
>> Especially since we have had no previous successes with that sort of
>> requirement.  I’m worried that trying to solve that problem might
>> unfortunately prevent progress on this important issue.
>>
>>
>>
>
> When has this type of reporting has been required in the past?
>

9.16.3 of the BRs, introduced by Gerv, which has had demonstrable success.

The CA MUST also (prior to issuing a certificate under the modified
requirement) notify the CA/Browser
Forum of the relevant information newly added to its CPS by sending a
message to questions at cabforum.org
and receiving confirmation that it has been posted to the Public Mailing
List and is indexed in the Public Mail
Archives available at https://cabforum.org/pipermail/public/ (or such other
email addresses and links as the
Forum may designate), so that the CA/Browser Forum may consider possible
revisions to these
Requirements accordingly.


> There would even be value in requiring CAs to document exceptions with no
> reporting requirement. If the requirement was something like "MUST populate
> the Subject:stateOrLocality field with a valid ISO 3166-2 subdivision, or
> else must document that an exception was made and the reason for it", then
> we'd be reasonably confident that any exceptions found in CT are really
> problems that need to be solved (as opposed to someone just ignoring a
> SHOULD).
>

I do not think we'll reasonably get that result. We've already seen trouble
with at least two CAs ignoring that provision of 9.16.3 in the past, but at
least that's a bit more objectively quantifiable as a CA failure when they
try to post-hoc justify.

The substantive challenge with proposals of 'Just use CT' is that CT should
not replace meaningful compliance measurements. Or, put differently, we
should not be more confident in adopting riskier propositions.

I think the canonical example of a SHOULD failing is SHA-1, which
unfortunately didn't see meaningful traction, or the enumeration on issues,
until well after the MUST. There was, of course, apocrapha (spelling
intentional), and "customer surveys" which provided no actionable data that
would assess options, scope, or impact, and given that we continue to see
that same approach years later, I do worry that a change that simply says
"SHOULD" would not have any meaningful change. A key challenge here is that
it leaves it up to individual CAs to determine whether, for example, SHOULD
applies at a per-certificate level ("We should think about this requirement
for each certificate we issue"), or whether it's coarser, such as
per-customer ("We decided to grant this customer an exception, and thus all
further checks were disabled, even for different localities"), per-country
("We decided this country is hard"), or even for the entire corpus of its
issuance ("We'd have to license the data for commercial use, so we decided
to use our own in-house database instead"). There's no way to guarantee
consistency, and no way to feed data back.

Considering that we're seeing CAs (or, more commonly, sub-CAs who's parent
CAs see the only obligation as being obtaining the audit report, not
actually evaluating the issues) fail to perform their patch assessment on
the regular, or working with auditors that may not be familiar on what
patches are or what systems they should apply to.

I realize this all sounds deeply cynical, but it's illustrative of the
problem with SHOULDs: They leave these subjective in a way that many
interpretations can be offered, and it's up to the community to understand
them after the fact. The design of 9.16.3 of the BRs was meant to combat
that, and especially to ensure "show your work" on certificates. A recent
example of this was the context of PSD2, and the attempt at framing the
violations of the EVGs as a 9.16.3-sanctioned action, even though such
violations were not actually required by law. This is where having a
virtuous feedback cycle, which allows any CA to deal with, helps us find
solutions that work for everyone - CAs, Relying Parties, Root Stores, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190905/231cc68c/attachment.html>