[cabf_validation] Analysis of Ben's latest draft for domain validation methods

Thu Jul 30 08:52:33 MST 2015

For context on .well-known:
  https://tools.ietf.org/html/rfc5785

There do not appear to be any a priori blocks to registering
".well-known/dv".  (I was worried about, say, a minimum length on the
strings.)

On Thu, Jul 30, 2015 at 11:40 AM, Richard Barnes <rbarnes at mozilla.com>
wrote:

> OLD: "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."
>
> NEW: "Secure Location: A directory on a web server that can only be
> written to by the administrator of the web server.  In particular, any
> directory under '/.well-known/pki/' is considered a secure location."
>
> We could also fold this into the HTTP validation thing, if we don't think
> it needs to be stand-alone.
>
> On Thu, Jul 30, 2015 at 12:09 AM, Ben Wilson <ben.wilson at digicert.com>
> wrote:
>
>> Ok- thanks- no warranties or reps as to accuracy, etc.
>> ------------------------------
>> From: kirk_hall at trendmicro.com
>> Sent: ‎7/‎29/‎2015 7:20 PM
>> To: validation at cabforum.org
>> Subject: [cabf_validation] Analysis of Ben's latest draft for domain
>> validation methods
>>
>> Ben, your latest draft of July 25 threw me (it looked so different from
>> the July 2 draft and the current BRs), but I think I can track what you
>> have done.  Maybe on the call tomorrow you can highlight where you have
>> made substantive changes from your draft of July 2 (both attached).
>>
>>
>>
>> Here is how I analyze your latest draft.  *[Comments in red]*  On
>> tomorrow’s call, can you walk us through it, including any changes you made
>> to definitions?
>>
>>
>>
>> *****
>>
>>
>>
>> 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:  *[Shouldn’t this be its own separate confirmation method – WhoIs
>> lookup?  This is old method #1]*
>>
>>
>>
>> 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  *[old method #3)*
>>
>> b.   with the contact listed as the “registrant”, “technical”, or
>> “administrative” contact in the WHOIS record for the Registered Domain
>> Name;  *[old method #2]*
>>
>>
>>
>> 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; *[Shouldn’t this be a separate confirmation method?  It’s old
>> method #4]*
>>
>>
>>
>> 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 *[old method #5]*
>>
>> 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 *[old method #6]*
>>
>> 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, …. *[old method #9]*
>>
>>
>>
>> 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 [old method #7]
>>
>> 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.  *[old
>> method #8]*
>>
>>
>>
>> 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. *[New?]*
>>
>>
>>
>>
>>
>>
>>
>> TREND MICRO EMAIL NOTICE
>> The information contained in this email and any attachments is confidential
>> and may be subject to copyright or other intellectual property protection.
>> If you are not the intended recipient, you are not authorized to use or
>> disclose this information, and we request that you notify us by reply mail or
>> telephone and delete the original message from your mail system.
>>
>>
>> _______________________________________________
>> Validation mailing list
>> Validation at cabforum.org
>> https://cabforum.org/mailman/listinfo/validation
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150730/a904bd44/attachment.html 