[cabf_validation] Validation proposal edits

[Ben Wilson]

All,

I’ve redlined https://docs.google.com/document/d/1_myTluMpMD7vaBkjVEIFiI1Q8u7tWuzlvEvLF3oDCZ8/edit .

Also, here is the cleaned version.  I’ve left a few gaps that need to be filled in, or if someone has an alternative approach, then maybe the gaps will disappear.   I’ve also highlighted a few of my changes.

Ben

 

Proposed Revisions to Domain Validation Requirements

 

Amendment to Section 3.2.2.4 of CA/Browser Forum Baseline Requirements to clarify acceptable methods of validating domain control:

 

1)         Add the following definitions to Section 1.6:

 

Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for a given FQDN.  By default, this is the Registered Domain for the FQDN or the FQDN itself.  The CA may derive an alternative Authorization Domain Name in the following ways:

●      Removing the “*” label from a wildcard FQDN (see Section 3.2.2.6), or

●      Using the name returned from a DNS CNAME request, or a chain of CNAME redirects

 

Random Value: A value specified by a CA to the Applicant that exhibits at least 128 bits of entropy.

 

Request Token: A value derived in a method specified by the CA, which uniquely identifies the  Applicant.  For example, the CA may use as a Request Token a Random Value provided to the Applicant in a session where the Applicant is authenticated or the CA may derive the Request Token from the public key to be certified.

 

Secure Location:  A directory with a unique name [define] located within a well-known directory [define] and accessible at port 80 or 443 at an Authorization Domain Name in which an Applicant may post a Request Token. 

 

Test Certificate: A Certificate which includes data that renders the Certificate unusable for use by an application software vendor or publicly trusted TLS server such as the inclusion of a critical extension that is not recognized by any known application software vendor or a certificate issued under a root certificate not subject to these Requirements.

2)         Section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements is amended as follows:

…

3.2.2.4   Authorization by Domain Name Registrant

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 and that certificate issuance is authorized.  The CA’s method of obtaining confirmation or authorization of certificate issuance SHALL include security measures sufficient to prevent a third party (i.e. who is not the Domain Name Registrant or who does not have control over the FQDN) from obtaining a certificate.   Where confirmation is sought by email and an automated process for recording the successful response is used, such as the provision of a hyper-link in an email, the CA MUST use a value that is unpredictable and previously unknown to the applicant  in the email and verify that the value is also present in the response. The CA MUST NOT rely on a Random Value, Request Token or Test Certificate generated more than 14 days prior to completion of the verification under this section.

Acceptable methods for a CA to confirm domain registration (or control) and authorization are as follows:

(1) Communicate with the Domain Name Registrant or Domain Name Registrar (or private, anonymous, or proxy registration service) for the FQDN, as listed in WHOIS, and confirm authorization of certificate issuance for the FQDN:

a.   through an email communication to an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by an Authorization Domain Name; or

b.   with the contact listed as the “registrant”, “technical”, or “administrative” contact in the WHOIS record for the Registered Domain Name; or

Note:  A Domain Authorization Document, which the CA previously obtained through a Reliable Method of Communication under a. or b., which establishes that the Domain Name Registrant has authorized the Applicant to obtain a certificate for the FQDN may be used to demonstrate authorization provided that the CA verifies that the WHOIS record still shows the same Domain Name Registrant as when the CA obtained the Domain Authorization Document;

OR

(2)   Having the Applicant demonstrate practical control over the requested FQDN by:

a. adding a file, filename, or directory containing a Random Value or a Request Token provided by the CA, provided that the Random Value or Request Token is posted to a Secure Location at an Authorization Domain Name for the FQDN in accordance with RFC 5785; or

b.   making a change to information in a DNS record for the Authorization Domain Name where the change is to insert a Random Value or Request Token; or

c.  requesting and then installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via https by the CA at one of the following ports: 443, ….

OR

(3)   Having the CA perform a DNS lookup for:

a. CNAME records for the requested FQDN at _______ , provided that the CA performs one of subsections 1 through 6 above (or also this subsection 7, iteratively if necessary), and uses the ____ that is determined thereby, yada yada; or

b.   A or AAAA records for the requested IP address, provided that the CA confirms control in accordance with procedures stated in section 3.2.2.5.  

 

Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension.

 

 

 

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Saturday, July 25, 2015 2:56 PM
To: Richard Barnes <rbarnes at mozilla.com>; validation at cabforum.org
Subject: Re: [cabf_validation] Validation proposal edits

 

Hi Richard,

 

I agree that it would be a good thing to adjust our approach to express security requirements for validation mechanisms.

 

Also, in your proposal you define the Authorization Domain Name as derived either by:

 

Removing the “*” label from a wildcard FQDN (see Section 3.2.2.6)

Using the name returned from a DNS CNAME request, or a chain of CNAME redirects

 

But we still haven’t fully addressed the ambiguity between a requested FQDN and the Domain Name that is registered with a Registrar.  

 

On the one hand, we could define an ADN to include the latter.  (Previously we’ve attempted to describe how to derive the registered domain name from the requested FQDN without running afoul of second-level domains.)

 

If we want to distinguish Authorization Domain Name from the Domain Name registered with a Registrar (and use the ADN only for some of the validation methods), then I think we need to be explicit.    

 

I’ll work on this a bit today, see what I can do in both areas, and circulate another draft.

 

Thanks,

 

Ben

 

From: validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org>  [mailto:validation-bounces at cabforum.org] On Behalf Of Richard Barnes
Sent: Thursday, July 23, 2015 10:50 AM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Validation proposal edits

 

Hey guys,

Last week, I promised edits on the validation proposal in about a week.  I pulled the proposal into a Google doc, and started making some edits.  I haven't done anything with the specific validation methods, but I've done some stuff with the preamble that I would appreciate the group's feedback on.

https://docs.google.com/document/d/1_myTluMpMD7vaBkjVEIFiI1Q8u7tWuzlvEvLF3oDCZ8/edit

Allow me to riff for a moment about the specific validation mechanisms:

I'm concerned about the descriptions of the more technical mechanisms (3, 5, 6, 7, 8, 9).  On the one hand, they're general enough that one could implement them insecurely, and on the other hand, they're specific enough that they rule out some valid techniques.

It seems like what we really need for this document to do is express the security requirements for validation mechanisms, in a specific enough way that it's difficult for CAs to do bad things.  If we only do that, though, I'm worried that we won't be giving auditors enough tools to evaluate CAs; we'll be requiring them to do technical analysis on CAs' validation mechanisms to determine whether they meet the security requirements.  So it would be good to provide specific examples of acceptable techniques.

 

It seems like if we do those two things (security requirements + specific examples), we will strike a better balance between enhancing security and allowing flexibility.  It basically gives CAs a choice between a fast path and a slow path -- either use one of the approved methods, or do a lot of work to convince your auditor that your custom thing is OK.

Does that seem like a sensible direction?

--Richard

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150725/d3d1b238/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150725/d3d1b238/attachment-0001.bin