[cabfpub] Ballot 169 - Revised Validation Requirements

[Ryan Sleevi]

Regrettably, despite multiple readings throughout this, I appear to have
missed some things in the definitions.

I'm mostly hoping for clarification, as it might simply be wording issues
that can be corrected without changing the substance or intent of the
ballot.

On Fri, Jul 22, 2016 at 11:06 AM, Ben Wilson <ben.wilson at digicert.com>
wrote:


> *Base Domain Name:* The portion of an applied-for FQDN that is the first
> domain name node left of a registry-controlled or public suffix plus the
> registry-controlled or public suffix (e.g. "example.co.uk" or "example.com").
> For gTLDs, the domain www.[gTLD] will be considered to be a Base Domain.
>

Why the "For gTLDs" clause? Is "www.[gTLD]" reserved by ICANN? Is this
meant as a clause for Spec-13 situations? For example, as I read it, if
Google wanted to get a certificate for "foo.google", the combined
definition of "Authorization Domain Name" and "Base Domain Name" would
potentially prohibit this - that is, as worded, it suggests "For gTLDs" is
mutually exclusive with the preceding sentence.

I'm unclear if this was meant to be "will also be" - but if so, it's
unclear why the gTLD case isn't handled previously. Is it meant to permit
the WHOIS lookups for such spec-13 gTLDs? If so, it would only be necessary
if you're applying for a bare certificate (either "*.[gTLD]" or [gTLD], and
the latter is either prohibited or strongly-discouraged per ICANN SSAC on
single-label hosts)

QUESTION: Can someone explain the context/intent of this clause?
SUGGESTION: Can this clause be removed? Would the addition of the word
"also" change the semantic meaning or interpretation?


> *Test Certificate:* A Certificate with a maximum validity period of 30
> days and which i) includes a critical extension with the specified Test
> Certificate CABF OID, or ii) which chains to a root certificate not subject
> to these Requirements.
>

The only change of potential substance is with ii).

Consider a case of the following hierarchy:
Root A - publicly trusted, complies with the BRs
Root B - not meant to comply with the BRs, an independent infrastructure
Intermediate B - a version of Root B (same name/keypair) signed by Root A,
and subsequently revoked (perhaps during the CA complying with the BRs, or
perhaps the CA did not train its staff appropriately and assumed they knew
not to cross-sign B).

The question is whether Root B can be used to issue Test Certificates. My
reading is that it could, just as Root B could potentially issue any other
type of certificates within the current BRs (it'd be strongly inadvisable,
but not unheard of for a CA to screw this up).

Now consider another scenario:
Root A - publicly trusted, complies with the BRs
Root B - not meant to comply with the BRs, and independent infrastructure
Int 1 - An intermediate signed by Root A, within scope of the BRs and audits
Int 1-B - The same name/keypair as Int 1, but signed by Root B.

Can Int 1 be used to issue test certificates? As currently worded, it seems
to suggest it can be, because there exists a path such that Int 1-B chains
to a root which is not subject to these requirements, even though Int 1
does. Now, if Int 1 issues a "Test Certificate" (that is, operationally,
the 'intermediate subject to the BRs'), is this a violation? Within the
context of the rest of the ballot, it seems like Int 1 has *not* violated
the BRs, solely because of Int 1-B's existence.

SUGGESTION: Modify ii) to express the inverse : "there are no [certificate
paths/chains] to a root certificate subject to these Requirements"

It doesn't solve the first problem, but in trying to slightly tweak the
wording, attempts to guard against a misinterpretation that leads to the
second problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160722/d20e0513/attachment-0003.html>