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

Ryan Sleevi sleevi at google.com
Mon Apr 24 14:06:25 UTC 2017


On Sun, Apr 23, 2017 at 10:35 PM, Peter Bowen <pzb at amzn.com> wrote:
>
> 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)
>

The data or documents obtained are valid across the Base Domain Name, but I
don't think you can argue reuse is consistent for all sub-methods equally.

For example, 3.2.2.4.1(1) requires a contact consistent with 3.2.5. That
would need to be performed every validation. (2) and (3), however, could be
reused.


> 3.2.2.4.2: same as .1
>

How do you argue this? The random value must be unique and cannot be reused
> 30 days, so the documents and data obtained would need to be redone.

That was somewhat my point - that it's not explicitly permitted to cover
the domain namespace, and so there's no explicit permission to reuse,
either under 3.2.2.4 (which is explicitly scoped to per-FQDN, not domain
namespace) or in the method.

To make sure I understand the interpretation you're advancing:
- Authorization Domain Name permits validation of any names constructed
from the FQDN, removing labels until encountering a Base Domain Name.
- That is, "www.example.com" is an FQDN, but it can be validated as "
example.com" as the Authorization Domain Name, because that's constructed
by removing a label 'www'
  - Since 'example.com' is a Base Domain Name, you cannot validate '
www.example.com' using 'com'
- If you issue a cert for 'www.example.com', but authorized it using an ADN
of 'example.com', then pursuant to 3.2.2.4, the completed confirmation is
for the ADN, not the FQDN, and thus can be reused for other FQDNs that
share an ADN of 'example.com'

Is that (roughly) correct?

And I suppose the interpretation that I'm taking is that 3.2.2.4 doesn't
enumerate ADN, but does enumerate FQDN, and the confirmation applies to the
FQDN, not the ADN, even if the FQDN was confirmed using an ADN. Because of
this, "completed confirmations" refers to the FQDN - so you can reissue
certificates for the same names, but you cannot add new names, even if an
ADN is used.

On first reading, I was inclined to support your interpretation (if we made
it explicitly worded), but one problem with that interpretation is the
intersection with CAA. If we allow the ADN authorization to be reused, then
it allows bypassing the CAA checks for the FQDN, does it not? Or would you
agree that 3.2.2.8 applies regardless of the reuse of information - that
every FQDN must have CAA checked, regardless if authority was validated
using a (reused) ADN validation?

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.
>

That seems a reasonable way of delegating.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170424/4b814498/attachment-0003.html>


More information about the Public mailing list