[cabfpub] Question 2 – Domain Validation pre-ballot

Richard Barnes rbarnes at mozilla.com
Fri Nov 13 10:32:00 MST 2015


On Thu, Nov 12, 2015 at 8:08 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

> *Question 2 – Domain Validation pre-ballot*
>
>
>
> The second open question for the current Domain Validation ballot also
> comes from Richard Barnes of Mozilla, and is as follows.
>
>
>
> *Proposal 2: In line H *
>
>
>
> CURRENT DRAFT:
>
>
>
> “6. Having the Applicant demonstrate control over the requested FQDN by
> installing a Random Value (contained in the name of the file, the content
> of a file, on a web page in the form of a meta tag, or any other format as
> determined by the CA) under "/.well-known/validation" directory on an
> Authorized Domain Name, that can be validated over an Authorized Port; or”
>
>
>
> Richard proposes to add the following language as shown: "*** or any other
> path under .well-known registered by IANA for this purpose"
>
>
>
> 6. Having the Applicant demonstrate control over the requested FQDN by
> installing a Random Value (contained in the name of the file, the content
> of a file, on a web page in the form of a meta tag, or any other format as
> determined by the CA) under "/.well-known/validation" directory on an
> Authorized Domain Name, *or any other path under .well-known registered
> by IANA for this purpose* that can be validated over an Authorized Port;
> or
>
>
>
> Richard’s reasoning: “For automated systems like ACME, they're going to
> want a much more precise definition of the validation process than what's
> in this document, and they may want to use different .well-known paths to
> indicate different methods that are all compliant with this section.
> Requiring the IANA registration allows these differences to exist, but in a
> controlled way.”
>
>
>
> On the call today, it was noted that only a single path
> "/.well-known/validation" directory on an Authorized Domain Name” was
> chosen intentionally – so that webmasters could be informed to lock down
> this path on their websites to avoid allowing a hacker to post a bogus
> credential (such as a bogus Random Value, etc.) and obtain a cert by
> practical demonstration for a domain they do not really own or control.
> The sentiment on the call was against this change.  One comment was that if
> a different path was needed in the future, it could be discussed and added
> later by a separate ballot if justified.
>
>
>
> *Questions*:  The Validation Working is likely to reject this suggested
> change.  However, we would like to hear from anyone who things the
> suggested change is a good idea.
>

I can actually live with this.  Eric Mill pointed out to me that you can
distinguish between validation types within that directory, so there's
enough flexibility without the liberalization.  So unless anyone else
thinks there's a need to liberalize this requirement, consider the proposal
withdrawn.

I would like to bike-shed the string a little bit.  The word "validation"
is over-broad.  One could certainly imagine other "validation" things going
under .well-known.  (POSH, an existing .well-known user, comes close
http://www.iana.org/go/draft-ietf-xmpp-posh-06)

What would people think about changing from "validation" to something like
"pki-validation"?

--Richard





>
>
> 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.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151113/53c5e764/attachment-0001.html 


More information about the Public mailing list