On Fri, Jun 30, 2017 at 9:00 PM, Gervase Markham <[email protected]> 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. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
