[cabfpub] [CABFORUM] Re: Domain validation

Anoosh Saboori ansaboor at microsoft.com
Wed May 6 19:49:23 MST 2015


Correct, we want to change #2.

________________________________________
From: Peter Bowen <pzbowen at gmail.com>
Sent: Wednesday, May 6, 2015 7:07 PM
To: Anoosh Saboori
Cc: Ryan Sleevi; public at cabforum.org
Subject: [CABFORUM] Re: [cabfpub] Domain validation

On Wed, May 6, 2015 at 4:46 PM, Anoosh Saboori <ansaboor at microsoft.com> wrote:
> What you stated below partly is the main reason for us not supporting #6 .
> Another example is Azure tenant who is assigned “example.clouapp.net”. While
> the tenant can pass the test in #6  by inserting nonce in
> “example.cloudapp.net/.well-known/certificate”, they are not the real owner
> for that domain name, Azure is.

I think you may be misunderstanding what is being certified by the CA.
According to the Baseline Requirements (from v1.3.0):

3.2.2.4. For each Fully‐Qualified Domain Name listed in a Certificate,
the CA SHALL confirm that, as of the date the Certificate was issued,
the Applicant (or the Applicant’s Parent Company, Subsidiary Company,
or Affiliate, collectively referred to as “Applicant” for the purposes
of this section) either is the Domain Name Registrant or has control
over the FQDN

7.1.4.2.1 The CA MUST confirm that the Applicant controls the
Fully‐Qualified Domain Name or IP address or has been granted the
right to use it by the Domain Name Registrant or IP address assignee,
as appropriate.

9.6.1 Right to Use Domain Name or IP Address: That, at the time of
issuance, the CA (i) implemented a procedure for verifying that the
Applicant either had the right to use, or had control of, the Domain
Name(s) and IP address(es) listed in the Certificate’s subject field
and subjectAltName extension (or, only in the case of Domain Names,
was delegated such right or control by someone who had such right to
use or control);

EV certificates have the same requirements:

11.7.1 For each Fully-Qualified Domain Name listed in a Certificate,
the CA SHALL confirm that, as of the date the Certificate was issued,
the Applicant (or the Applicant’s Parent Company, Subsidiary Company,
or Affiliate, collectively referred to as “Applicant” for the purposes
of this section) either is the Domain Name Registrant or has control
over the FQDN.

There is not a requirement that the applicant be the Domain Name
Registrant, just that they control the Fully Qualified Domain Name.
So there is no reason that Contoso Pty Ltd could not get an EV, OV, or
DV certificate for example.cloudapp.net if that is a hostname they are
able to reasonably control (assuming Contoso Pty Ltd is a real company
that meets the EV criteria).   The same would go for
example.appspot.net.

As it stands today, certificates under CABForum requirements may state
two things:
1. Identity of the certificate applicant
2. FQDNs which the applicant controls (for SSL certificates)
These are point in time assertions (e.g. the CA certifies that as of
date X, applicant Y controlled FQDN Z).

The only thing that varies between Baseline and EV certificates is the
detail to which #1 is validated and the detail included in the
certificate.  #2 is identical for all certificate types.

It sounds like you (and presumably Microsoft) are suggesting that you
want to change #2.

Thanks,
Peter

> ________________________________
> From: Ryan Sleevi <sleevi at google.com>
> Sent: Wednesday, May 6, 2015 3:49 PM
> To: Anoosh Saboori
> Cc: Eddy Nigg; public at cabforum.org
> Subject: Re: [cabfpub] Domain validation
>
>
>
> On Wed, May 6, 2015 at 3:37 PM, Anoosh Saboori <ansaboor at microsoft.com>
> wrote:
>>
>> Reviving this older thread. It seems that both:
>>
>>
>>
>> 1.       Forum has concerns around relying only on whois database or email
>> address since the whois database might not be accurate
>>
>> 2.       MS still has concerns for #6 not being at par with the rest of
>> validation mechanism proposed
>>
>>
>>
>> So, can we get to a point where both concerns are addressed by modifying
>> the requirement as: “#6 continues to be accepted, only if other validation
>> methods failed to work. CAs then keep documentation on why they decided to
>> accept #6. “
>>
>>
>
> I'm still not sure why Microsoft doesn't feel that #6 is not on-par with the
> rest. It would be very helpful if you could elaborate what properties you
> feel that the other methods offer that #6 does not. In digging through your
> past replies, it only seems that you've highlighted it's "not as strong" -
> but you haven't clarified what property is absent.
>
> If I understand by reading between the lines, your concern is that method #6
> allows verification to happen by any attacker who can gain filesystem-level
> access, whereas the other methods require some level of password compromise
> (e.g. email, methods 1/2/4 from the original message), remote code execution
> (e.g. TLS bindings, method 11 from the original message), or has compromised
> the domain management (methods 7/8 from the original message). Is that
> correct?
>
> I'm surprised that Microsoft hasn't highlighted Item 9 (IP address
> validation) as similarly weaker in guarantees. For example, in a shared
> hosting service, foo.com and bar.com may both be hosted on the same IP, and
> use SNI (for HTTPS) and the Host: header (for HTTP) to disambiguate which
> host the client wishes to talk to. As presently worded, it seems like
> bar.com MAY be able to apply for a certificate for foo.com.
>
> Now, I know that's not the intent, but that strikes me as an area that needs
> further clarification about what "controls an IP address" means (e.g. does
> it mean looking in the appropriate RIR for that Netblock and confirming the
> applicant through a Reliable Means of Communication?)
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>


More information about the Public mailing list