[cabfpub] Pre-ballot for Ballot 190

[Ryan Sleevi]

On Fri, Jun 30, 2017 at 9:00 PM, Gervase Markham <gerv at mozilla.org> wrote:
> On 29/06/17 11:51, Ryan Sleevi via Public wrote:
>> My concrete suggestion: Remove the entire "Note" section to avoid the
>> hopefully unintentional ambiguity. This same probably, notably, persists
>> through every "Note" being introduced - in the effort of trying to
>> introduce clarity, it actually introduces conflicting language that
>> either disagrees with the definition of ADN, or redefines it.
>
> I think the Note sections make (reasonably) clear what was implicit but
> unclear in previous versions, and so are helpful. Unless you think
> that's not true, and they make normative changes (if so, what exactly?)
> then it would be useful if you were to suggest a form of words which
> expresses what we all know we are trying to say.

Gerv,

As highlighted by Kirk's response, I don't think it's reasonably clear
- which is why I highlighted the terminology.

Further, as it relates to 3.2.2.4.1, it is a reasonable question as to
whether the intent is to allow the Base Domain Name to suffice as an
Authorization Domain Name, or whether the intent is to allow the Base
Domain Name validation to be reused across multiple FQDNs.

Perhaps it would be more productive if you clarify what you believe
it's trying to say, using alternative phrasing, and then from there,
it's clearer about what you're trying to say. Because, given both the
wording and Kirk's reply, it's eminently not clear, and seems very
much a repeat of the ambiguity with "wildcard character in the
left-most label" that we saw take nearly a year (and many misissued
certificates) to resolve.


> At the moment, many CAs are technically using "any other method"
> validations to use validation methods which correspond to some of the
> ones we are reintroducing but which are not currently in the document.
>
> Do you have a way we can distinguish, in text, between that situation
> and the situation where a CA has just made up some random method?

Sure. Without introducing any changes, it should hopefully be clear
that data and documents obtained in a way compliant with the new-190
methods - even if under the 'any other method' aegis - may be reused.
I say "hopefully", because it's that same logical extension that CAs
today are relying on to permit them to reuse validations, data, and
documents across multiple revisions.

Put differently, if you were to make it more explicit - that all
validations, data, and documents must have been obtained in a manner
consistent with the currently-published BRs - then it would hopefully
make it explicit that "any other method" (of arbitrary purpose) is not
acceptable, while if a CA can demonstrate that the data, documents,
and validations were compliant with the text, that all is good.

Perhaps the disconnect is that nothing within 3.2.2.4 states that you
must have done it with a specific subbullet, merely, the process and
data acceptable to issue. This is the same logic that would allow us
to renumber methods - as otherwise, we would always be using an
append-only construction to keep the numbers the same.

Without the additions to 4.2.1, the only revalidations necessary would
be if data and documents were obtained in a manner non-compliant with
any of the equivalently acceptable methods. This would predominantly
affect those CAs that used an alternative method for .6 (file-based
demonstration of control), or which did not maintain easily accessible
records for how they validated (but they MUST maintain such records,
per the audit)

> Additionally, some of the methods currently documented were "any other
> method" methods before we expanded the list. Again, do you have a way to
> distinguish? Particularly as they might have been exactly the same as
> that now documented, or different in one or more particulars. How do we
> decide what's material?

Does the above hopefully clarify? CAs will have already recorded the
appropriate information in their audit records. A CA that maintains
such validation information next to the customer information would
have no impact, while a CA that maintains such validation information
in some other form would either need to reexamine that information or
revalidate, whichever was more expedient.

I'm not sure how to make this point clearer, however, and it sounds
like there's some disconnect, so perhaps as a hypothetical:

"CA Foo" uses TLS Test Certificates, in a way compliant with the new
method. "CA Foo" was previously doing so relying on the "Any other
method" clause. Per the audit requirements, they maintained all
records related to their validation, and similarly, maintained
information about the age of the validation and information. Their
CP/CPS described a process that is equivalent to what is proposed by
Ballot 190.

"CA Foo" may then continue to rely on the data and documents, as they
were obtained in a manner compliant with the BRs, to issue
certificates under the new, non-any-other method, for the validity
period of that information/validation.

"CA Bar" uses an ad-hoc method where they had subscribers demonstrate
control over www.example.com/myca.txt, which was expected to contain
the order request number. "CA Bar" was relying on a file-based
demonstration of control (not any other method). Under Ballot 190, the
data and documents were not obtained in a manner compliant, and thus
"CA Bar" would need to revalidate the customers' authorization. This
is desirable - their old method was a security disaster.

"CA Baz" validated subscribers, but did not maintain easily searchable
or retrievable information about how they validated. That is, they
recorded it in their audit logs, but they designed their systems
simply to say "Revalidate at Date X". This CA did not consider future
changes or modifications - despite the two years of discussion with
190 - and likely presumed that they would be able to delay
adoption/phase in. With the adoption of Ballot 190, "CA Baz" would
need to (a) examine their CP/CPS to determine if any of their methods
for validation were not in compliance with the BRs, post-190 (b)
examine their audit logs to examine which certificates/data and
documents were issued in accordance with 190, and update the
revalidation date to either be "immediately" (if non-compliant) or to
the validity period expressed in 190 or (c) revalidate the domains.

"CA Bat" validated subscribers by making them pinky-promise they own
the domain, under the basis of "Any other method". Under 190, this
would no longer be permitted - the data, documents, or validations are
not in compliance with post-190 3.2.2.4 - and thus any certificates
issued after the adoption of 190 relying on that pinky-promise would
be misissued. The CA would need to revalidate those certificates. This
is desirable for security.

Hopefully this covers the various permutations of possibilities - all
of which are accomplished without any modifications.