[cabf_validation] Ballot 190

Jeremy Rowley jeremy.rowley at digicert.com
Mon May 8 08:39:16 MST 2017


Going through this, here’s what it looks like some of the validation processes will limit/include. Based on this, I’d like to include language in the preamble that states:

 

“A CA may rely on verification of an Authorization Domain Name under Section 3.2.2.4 to verify Domain Names subordinate to an Authorization Domain Name provided the verification was completed within the timeframe specified in Section 4.2.1.” Alternatively, we could specify this on each individual method. 

 

The current status:

1. Domain contact

Source: Base Domain

Permitted Reuse: 825 days

Compatible with previous version: Yes

Verification Scope: Only the FQDN

Verifies wildcards: Yes

 

2. WHOIS Email

Source: Base Domain

Permitted Reuse: 825 days

Compatible with previous version: Yes

Verification Scope: Depends on the email – “Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names”

Verifies wildcards: Yes

 

3. WHOIS Phone

Source: Base Domain

Permitted Reuse: 825 days

Compatible with previous version: Yes

Verification Scope: Depends on the phone call – “Each phone call SHALL be made to a single number and MAY confirm control of multiple FQDNs, provided that the phone number is identified by the Domain Registrar as a valid contact method for every Base Domain Name being verified using the phone call.”

Verifies wildcards: Yes

 

4. Constructed Email

Source: Authorization Domain

Permitted Reuse: 825 days

Compatible with previous version: Yes

Verification Scope: Depends on the email – “Each email MAY confirm control of multiple FQDNs, provided the Authorization Domain Name used in the email is an Authorization Domain Name for each FQDN being confirmed. “

Verifies wildcards: Yes

 

5. Domain Authorization Document

Source: Base Domain

Permitted Reuse: 825 days

Compatible with previous version: Yes

Verification Scope: Subdomains not explicitly permitted, but you could word the letter to say all FQDNs with the same WHOIS and then check WHOIS to make sure it’s the same 

Verifies wildcards: Yes

 

6. Agreed Upon Change

Source: Authorization Domain

Permitted Reuse: Questionable…. 

Compatible with previous version: No

Verification Scope: Subdomains not explicitly permitted. There is confusion about whether this is a documentation (825 days) or whether 30 days is only permitted (for the random value expiration) 

Verifies wildcards: Yes

 

7. DNS Change

Source: Authorization Domain

Permitted Reuse: Questionable…. 

Compatible with previous version: N/A

Verification Scope: Subdomains not explicitly permitted, but verification occurs at Authorization Domain. There is confusion about whether this is a documentation (825 days) or whether 30 days is only permitted (for the random value expiration) 

Verifies wildcards: Yes

 

8. IP Address

Source: FQDN

Permitted Reuse: 825 

Compatible with previous version: N/A

Verification Scope: Subdomains not explicitly permitted. Documentation is control over IP address

Verifies wildcards: Yes

 

9. Test Certificate

Source: FQDN

Permitted Reuse: Unknown 

Compatible with previous version: N/A

Verification Scope: Subdomains not explicitly permitted. Unknown whether sub domains are okay.

Verifies wildcards: Yes

 

10. TLS Using Random Number

Source: Authorization Domain

Permitted Reuse: Unknown 

Compatible with previous version: N/A

Verification Scope: Subdomains not explicitly permitted. Unknown whether sub domains are okay.

Verifies wildcards: Yes

 

 

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Validation
Sent: Thursday, May 4, 2017 7:08 PM
To: Peter Bowen <pzb at amzn.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabf_validation] Ballot 190

 

I guess my main concern is the language is not clear, and I can see multiple interpretations. I’d like to make sure the forum generally agrees that:

1) CAs can still validate sub-domains (with the customer’s permission) by relying on a previous validation of a base domain and 

2) I can reuse validation information for 825 days and not revalidate a reissue of the certificate if the initial issuance is over 30 days (causing the random value to expire). 

 

Jeremy

 

From: Peter Bowen [ <mailto:pzb at amzn.com> mailto:pzb at amzn.com] 
Sent: Thursday, May 4, 2017 6:48 PM
To: CA/Browser Forum Validation WG List < <mailto:validation at cabforum.org> validation at cabforum.org>
Cc: Doug Beattie < <mailto:doug.beattie at globalsign.com> doug.beattie at globalsign.com>; Jeremy Rowley < <mailto:jeremy.rowley at digicert.com> jeremy.rowley at digicert.com>
Subject: Re: [cabf_validation] Ballot 190

 

Jeremy,

 

While your table is correct according to 190, I think it points out we got things wrong in a few places.

 

6, 9, and 10 should probably be FQDN-only, as they only demonstrate control of a single host, not domain namespace.  8 should stay FQDN only.

 

I think the DAD already covers base domain/authorization domain implicitly, as the document could easily say “Applicant Y is authorized to request certificates for example.com <http://example.com>  and all FQDNs below example.com <http://example.com> .”

 

The definitions have: "Domain Contact: The Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record.”

 

This seems to say Base Domain is the only acceptable thing for 1, 2, and 3.

 

Does that make sense?

 

Thanks,

Peter

 

 

 

On May 4, 2017, at 3:39 PM, Jeremy Rowley via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

 

For 1-3, the method permits you verify with a Domain Contact. The Domain Contact is defined as one at the FQDN or base level.  No authorization domain is permitted in the definition. 

 

DAD cannot be used for Authorization Domain or Base Domain. The method specifically says FQDN. 

 

I bring this up because I thought we permitted Authorization Domain in more places.  Just making sure it was intentionally to exclude it in several places.

 

From: Doug Beattie [ <mailto:doug.beattie at globalsign.com> mailto:doug.beattie at globalsign.com] 
Sent: Thursday, May 4, 2017 2:11 PM
To: CA/Browser Forum Validation WG List < <mailto:validation at cabforum.org> validation at cabforum.org>
Cc: Jeremy Rowley < <mailto:jeremy.rowley at digicert.com> jeremy.rowley at digicert.com>
Subject: RE: Ballot 190

 

Why do you have FQDN checked for 1-3?  I think you’d only do FQDN level validation if you also allow Authorization domain.

 

Can a DAD be used for Authorization domain and base domain?  Not sure.


See comments below.


Doug

 

 


Method

FQDN

Authorization Domain

Base Domain


1. Domain Contact – This method relies on the definition of Domain Contact which specifies the WHOIS person either at the FQDN or base domain. 

X

 

X


2. WHOIS Email – Only permits email to domain contact, but one of the sentences mentions Authorization Domain? 

X

 

X


3. WHOIS Phone – Same as Email

X

 

X


4. Constructed Email – sending the email to authorization domain

X

X

X


5. Domain Document 

X

X?

X?


6. Agreed-Upon Change – Authorization domain specifically mentioned

X

X

X


7. DNS Change – Authorization domain name is mentioned but also permits underscore

X

X

X


8. IP Address – No Authorization domain mentioned

X

 

 


9. Test Cert – Authorization domain mentioned

X

X

X


10. TLS Using a Random Number – Authorization Domain mentioned

X

X

X

 

Doug

 

From: Validation [ <mailto:validation-bounces at cabforum.org> mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Validation
Sent: Thursday, May 4, 2017 3:46 PM
To: CA/Browser Forum Validation WG List < <mailto:validation at cabforum.org> validation at cabforum.org>
Cc: Jeremy Rowley < <mailto:jeremy.rowley at digicert.com> jeremy.rowley at digicert.com>
Subject: [cabf_validation] Ballot 190

 

I wanted to make sure that I’m implementing the methods correctly. For each FQDN you can verify the FQDN using the FQDN, an Authorization Domain, or Base Domain, as specified in the method. Going through the methods, it looks like the verification listed in the table below is permitted. Is this everyone else’s understanding? 

 


Method

FQDN

Authorization Domain

Base Domain


1. Domain Contact – This method relies on the definition of Domain Contact which specifies the WHOIS person either at the FQDN or base domain. 

X

 

X


2. WHOIS Email – Only permits email to domain contact, but one of the sentences mentions Authorization Domain? 

X

 

X


3. WHOIS Phone – Same as Email

X

 

X


4. Constructed Email – sending the email to authorization domain

X

X

X


5. Domain Document 

X

 

 


6. Agreed-Upon Change – Authorization domain specifically mentioned

X

X

X


7. DNS Change – Authorization domain name is mentioned but also permits underscore

X

X

X


8. IP Address – No Authorization domain mentioned

X

 

 


9. Test Cert – Authorization domain mentioned

X

X

X


10. TLS Using a Random Number – Authorization Domain mentioned

X

X

X

 

 

Example, 

 

FQDN:  <http://secure.mail.example.com/> Secure.mail.example.com


Method

Permitted Validation Domains


1. Domain Contact 

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://example.com/> Example.com


2. WHOIS Email

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://example.com/> Example.com


3. WHOIS Phone

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://example.com/> Example.com


4. Constructed Email

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://mail.example.com/> mail.example.com;  <http://example.com/> Example.com


5. Domain Document

 <http://secure.mail.example.com/> Secure.mail.example.com


6. Agreed-Upon Change

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://mail.example.com/> mail.example.com;  <http://example.com/> Example.com


7. DNS Change

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://mail.example.com/> mail.example.com;  <http://example.com/> Example.com _{value}. <http://secure.mail.example.com/> Secure.mail.example.com; _{value}. <http://mail.example.com/> mail.example.com; _{value}. <http://example.com/> Example.com


8. IP Address

 <http://secure.mail.example.com/> Secure.mail.example.com


9. Test Certificate

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://mail.example.com/> mail.example.com;  <http://example.com/> Example.com


10. TLS w/ Random Number

 <http://secure.mail.example.com/> Secure.mail.example.com;  <http://mail.example.com/> mail.example.com;  <http://example.com/> Example.com


 

 

 

_______________________________________________
Validation mailing list
 <mailto:Validation at cabforum.org> Validation at cabforum.org
 <https://cabforum.org/mailman/listinfo/validation> https://cabforum.org/mailman/listinfo/validation

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170508/ce0c3822/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170508/ce0c3822/attachment-0001.bin>


More information about the Validation mailing list