[cabfpub] Ballot 169 - Revised Validation Requirements

Doug Beattie doug.beattie at globalsign.com
Fri Jul 22 18:48:44 UTC 2016


Ryan,

As the person that added the Test Certificate section, I accept your recommendation. We did not intend for the issuing CA to ever chain to anything other than non-public roots where non-public roots are those roots which were never in nor are planned to be enrolled in any root program or be used in support of issuing certificates that comply with the BRs.

Assuming this works, we can change this:
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.
To this:
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 is issued under a CA where there are no certificate paths/chains to a root certificate subject to these Requirements.


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Friday, July 22, 2016 2:26 PM
To: Ben Wilson
Cc: CABFPub
Subject: Re: [cabfpub] Ballot 169 - Revised Validation Requirements

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<mailto: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<http://example.co.uk>" or "example.com<http://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/ffc44812/attachment-0003.html>


More information about the Public mailing list