[cabfpub] Pre-ballot for Ballot 190

[Ryan Sleevi]

On Thu, Jun 29, 2017 at 7:59 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
wrote:

> I can only respond to two of your questions.
>
>
>
> As to your first question, a third level domain can be referred to as
> “higher” than a second level domain, and so on:
>
> https://www.techopedia.com/definition/23811/third-level-domain
>

Unfortunately, like many random pages on the Internet, it's not correct.

https://tools.ietf.org/html/rfc1034#section-3.1 outlines the relevant
terminology here

Quoting:
The domain name of a node is the list of the labels on the path from the
node to the root of the tree.  By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).

Hopefully this makes it clear that the current wording is technically
incorrect.


>
>
> But I also see places where a third level domain is referred to as “lower”
> than a second level domain also.
>
>
>
> I’m not confident our current definitions of Authorization Domain Name and
> Base Doman Name can be substituted for “higher domain name” without adding
> unwelcome complications – they doesn’t clearly say that once a CA has
> validated an Authorization Domain Name (which is *before* pruning), the
> CA can then issue for other FQDNs with more nodes (higher level in my
> parlance) that are not the original Authorization Domain Name without
> revetting the new FQDN.  Plus there is the language “the Domain Name used
> to obtain authorization” which introduces a new complication.
>

I'm not sure how best to address the confusion on your part - I suspect
that, much like the use of 'higher level' being incorrect, the confusion
you mention may be the result of improper use of terminology.

We've established that 3.2.2.4 and 4.2.1, as argued, allow for the reuse of
validation. If a method explicitly permits an Authorization Domain Name (or
Base Domain Name), then the validation (or documents or data) apply to that
Authorization Domain Name / Base Domain Name. To argue otherwise would be
to argue against the practice of CAs, and I know you're not inclined to do
so.

The point, as it relates, is that 3.2.2.4.1 previously made use of Base
Domain Name without invoking the Authorization Domain Name, but this note
introduces a normative ambiguity here, hence the highlighting of the
concern.


> I agree that we can do more work on this in the future, but for now, I
> think the Ballot 190 language is clear enough (Ballot 190 says a validated
> FQDN can be used to issue certs “for FQDNs for higher level domain levels *that
> end in the validated FQDN*”, so clearly the additional FQDN has to be
> longer than the validated FQDN, and not shorter).
>

However, as both the terminology - and it's conflict with (or
incompatibility with) authorization domain name - hopefully show, it's
actually not clear enough on this point. Worse, it's actually materially
incorrect.


> The only other question I can respond to is at the end of your message.
> Bear in mind that after Ballots 180/181, many validations over many months
> were done using new Methods 1 through 4 and 7 through 9 (as previously
> approved in Ballot 169) but these only happened under the Method 11 “any
> other method”, as these were not specifically re-authorized for many months
> (in fact, they are not specifically re-authorized yet – that’s what Ballot
> 190 is about).  So if we wipe out those prior validations under Method 11,
> we are eliminating many prior validations that clearly complied with our
> new Methods 1-10 – something we don’t want to do.  There’s really no way
> around it.
>

Sure there is. As has been highlighted since the beginning of the
(conflicting) discussion, Section 4.2.1 has allowed - and continues to
allow - the reuse of documents and data. Similarly, Section 3.2.2.4's
preface allows for the reuse of the validation.

This means that for those CAs - which, as you note, has been virtually
every CA - that have adopted the new validation methods, and if their
validation documents and data comply with the post-190 language (meaning
that no further complications since 169 have been entered into 190), then
they can reuse those documents or data - or previous validations - in full
compliance with the BRs.

The only issue that is created is for those CAs that continued to use an
insecure file-based demonstration of control outside of those permitted
under 6, or which, such as you have noted for Entrust, failed to maintain
an efficient and appropriate record keeping to allow them to determine
whether or not they have properly complied with Methods 1-4 and 7-9 in the
manner prescribed by 190. It is those CAs - which is a very limited subset,
based on public evidence - that would need to do revalidation.

To put it differently: If a CA has adopted Methods 1-4, or 7-9, as a result
of previous discussions, then they would not need to revalidate.

Hopefully, with this greater clarity, you can see why the issues being
introduced with the proposed language changes - issues that pose real risk
to the stability and security of the PKI - are issues that can be entirely
avoided, and with minor to no inconvenience to CAs that have adopted secure
practices.


> Again, I’d suggest we get Ballot 190 passed, then return immediately to
> address and improve the new language.
>

Respectfully, Ballot 190 presents real security risk. Can you clarify what
the 'rush' is? I would have hoped the unfortunate exercise of Ballot 193,
Ballot 194, and Ballot 197 would highlight why rushing to get a ballot
passed is detrimental to our long term interests.

Similarly, as you can see from the discussions related to Ballot 190,
"improve the new language" is equally something that may take two years, so
we should be careful to introduce known-flawed and security-risky language,
and instead make sure we get it right the first time, as we simply may not
have the opportunity - or, as Ballot 192 nearly risked, the quorum - to
make much needed and necessary improvements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170630/e497a6f7/attachment-0001.html>