[cabfpub] Thursday CABF call -- Discussion of Domain Validation Methods (BR 184.108.40.206)
richard at wosign.com
Mon Nov 9 20:06:10 MST 2015
I think the ballot should include some sort of requirement that a Random Value, Request Token, or Test Certificate can only be used once by the CA and customer to validate one domain, and that a new Random Value, Request Token, or Test Certificate must be generated by the CA for the customer for each domain being validated, and each time a domain is validated.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Tuesday, November 10, 2015 9:56 AM
To: CABFPub (public at cabforum.org) <public at cabforum.org>
Subject: [cabfpub] Thursday CABF call -- Discussion of Domain Validation Methods (BR 220.127.116.11)
The Validation Working Group is trying to finish up the Ballot to change BR 18.104.22.168 on domain validation methods. We’ve been at this for over six months, and have previously presented you with the attached draft Ballot dated September 10, 2015. It is ready to go, except we need to consider the comments of Richard Barnes of Mozilla and Peter Bowen of Amazon (attached, and shown below).
[As a separate matter, we delayed further work on this Ballot until early November to wait for any IP disclosures requested by the Patent Assessment Group (PAG) committee had been received. We will see what conclusions the PAG has drawn.]
It will be useful to receive comments and feedback from the Forum Members on this Thursday’s call. The Validation Working Group (VWG) can then discuss the comments next week, and try to finalize the Ballot.
I am repeating the comments from both Richard and Peter here, with a little more context. Please be ready to comment on these four matters so we can complete this Ballot.
Any other comments on the draft Ballot?
Richard Barnes Comments
In September, Richard made the two proposals shown below, and they were discussed in a VWG meeting. I remember there were criticisms of Richard’s proposals – but I don’t remember exactly what they were! (I think the objection to the proposed change in method 6 was allowing any “well-known” path chosen by the CA in addition to the “well-known/validation” directory in the current language – allowing the CA to choose a different past perhaps defeated the purpose of choosing a single path that website owners would know about.) Richard was going to modify and resubmit his proposals, but he has not done so to date. (Richard – if possible, please resubmit before Thursday.) Each proposal is keyed to a line or part in the attached pdf matrix of the ballot
Proposal 1: In part L
OLD: "by the Applicant requesting and then installing a Test Certificate issued by the CA"
NEW: "by the Applicant requesting and then installing a Test Certificate issued by the CA, or installing a Test Certificate containing a Random Value or Request Token"
9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN or installing a Test Certificate containing a Random Value or Request Token which is accessed and then validated via https by the CA over an Authorized Port.
This liberalization would cover the DVSNI proposal being considered in ACME, and seems to offer equivalent protection to the other option. (Either way the cert contains something specified by the CA.)
Proposal 2: In part H
OLD: "under "/.well-known/validation" directory on an Authorized Domain Name"
NEW: "under "/.well-known/validation" directory on an Authorized Domain Name, 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
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.
Peter Bowen Comments (Peter did not submit specific new language)
Proposal 3: In part J
In Item J, it suggests that the random token is only valid for a FQDN validation. I think DNS validation should be allowed for domain hierarchies in addition to specific FQDNs. A domain registrant should be able to choose to approve all FQDNs under corp.example.com <http://corp.example.com> by adding a record for corp.example.com <http://corp.example.com> .
[Current Ballot language]
7. Having the Applicant demonstrate control over the requested FQDN by the Applicant making a change to information in a DNS record for an Authorization Domain Name where the change is to insert a Random Value or Request Token; or
Proposal 4: In part K
Conversely, in item K, using Authorization Domain seems inappropriate. Just because I control the IP address of corp.example.com <http://corp.example.com> doesn't mean I have control payments.corp.example.com <http://payments.corp.example.com> .
[Current Ballot language]
8. Having the Applicant demonstrate control over the requested FQDN by the CA confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the Authorization Domain Name in accordance with section 22.214.171.124; or
Let’s be ready to discuss on Thursday’s call.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5151 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151110/1933b547/attachment-0001.bin
More information about the Public