[cabfpub] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft (2)

[Peter Bowen]

> On Apr 20, 2017, at 10:57 AM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> 
> 
> On Thu, Apr 20, 2017 at 12:39 PM, Gervase Markham via Public <public at cabforum.org> wrote:
> 
> 1) In section 1.3.2 of the Baseline Requirements, replace the following sentence:
> 
> "The CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2."
> 
> with:
> 
> "With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2."
> 
> 
> Based on our description, I believe your intent is also to cover Section 3.2.2.6, correct?
> 
> The concern raised in Raleigh that this introduces is that it effectively forbids Enterprise RAs from managing the validation of domains beneath the Domain Namespace that the CA has verified. This is because Enterprise RAs are Delegated Third Parties.
> 
> Is your intent to restrict such Enterprise RAs to only performing Subject Name validation?
> 
> At present, 3.2.2.4 (nor the proposed updates in Ballot 190) permit blanket authorizations by Domain Namespace. I suspect that if Section 3.2.2.4 were modified to permit the validation of such requests at the Domain Namespace level, and the corresponding reuse of such information permitted, then the meaningful benefit of an Enterprise RA could be met without the necessity of introducing the concept.

3.2.2.4 already does permit this for many methods.  Looking at BR 1.4.1:

3.2.2.4.1: Clearly covers namespace, as it only uses Base Domain Name (put another way, reuse of validation information is valid across full namespace)

3.2.2.4.2: same as .1

3.2.2.4.3: same as .1

3.2.2.4.4: uses Authorization Domain Name, which creates namespace

3.2.2.4.5: same as .1

3.2.2.4.6: same as .4

3.2.2.4.7: same as .4

3.2.2.4.8: Just for specific FQDN

3.2.2.4.9: same as .4

3.2.2.4.10: same as .4

So 9 of the 10 methods cover Domain Namespace because they either refer to “Base Domain”, “Domain Contact” which in turn references “Base Domain”, or “Authorization Domain”.

> That is, if 3.2.2.4 were worded to somehow suggest that:
> "The CA SHALL confirm that, as of the date the Certificate issues, the CA has validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below, or is within the Domain Namespace of a Fully-Qualified Domain Name (FQDN) that has been validated using at least one of the methods listed below. "
> 
> Then this might be able to satisfy the concern over Enterprise RAs. It changes the relationship from permitting an Enterprise RA to have unconstrained issuance, but contractual restriction, to being one of technical restriction, by requiring that for every FQDN, the CA validate it is within the Domain Namespace of a (potentially previously) validated FQDN.

I would push this a step further and require Enterprise RAs to only approve issuance when the CA has performed domain validation and subject identity validation for all attributes to be in the subject listed in 7.1.4.2.2.  The Enterprise RA’s primary job then is to confirm the authority of the Applicant Representative under BR Section 3.2.5.

Thanks,
Peter