[cabfpub] FW: Question 3 – Domain Validation pre-ballot

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Sat Nov 21 13:29:30 MST 2015


Peter, I’m having a hard time with this one – I don’t understand.

Can you pull back a bit from specific BR language changes, and start with this:


1.       What problem(s) are you trying to address with a language change?

2.      Are you trying to change or limit how CAs, Applicants, and others (such as web hosters) complete domain authentication today?  If so, how do you want to change or limit the process?

3.      Or are you simply suggesting we change the language of BR 3.2.2.4 to conform to the current practices of CAs, Applicants, and others (such as web hosters), without changing or limiting the current processes?

Thanks.  Kirk

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Kirk Hall (RD-US)
Sent: Saturday, November 21, 2015 11:07 AM
To: CABFPub (public at cabforum.org)
Subject: [cabfpub] FW: Question 3 – Domain Validation pre-ballot

Reposted with permission

From: Peter Bowen [mailto:pzbowen at gmail.com]
Sent: Friday, November 20, 2015 7:10 PM
To: Kirk Hall (RD-US)
Cc: CABFPub (public at cabforum.org<mailto:public at cabforum.org>); Ryan Sleevi
Subject: Re: [cabfpub] Question 3 – Domain Validation pre-ballot

(reposting authorized)

I'm want to reset the discussion.  I've revised my suggested changes to use the language already approved for the Domain Authorization Document (on Line S). As noted on Line S, this language is in the current BRs and is not proposed to change.  I hope that this should be a more acceptable change as it is no broader in scope that the existing and proposed options and does not change the required relationships between Applicant and Registrant.

Thanks,
Peter

On Tue, Nov 17, 2015 at 6:31 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Peter, I have tried to capture the changes you suggested in the attached documents, plus two choices of effective date.  (We will also have to make similar changes to EVGL 11.14.1 and 11.14.3 when we decide what to do about requiring revetting.)

I am not sure I’m comfortable yet with going from the idea that we are confirming “the Applicant’s domain ownership or control” (current language) to “the Applicant’s authorization to obtain and manage certificates for the Domain Namespace”.   I think the current wording limits Applicant to the owner (or in some cases, licensee) of the domain, who can then work through an agent to obtain a certificate.

Your new phrase is kind of circular, and would treat an agent (web hoster or whatever) as the Applicant – but we use Applicant lots of other places, including legal promises from the Applicant, and I am concerned that we are mixing roles – in some cases the Applicant really does own the domain and should be making the legal promises to the CA, browsers, etc., while in other cases the Applicant could be just a third party agent who doesn’t own or control the domain, and the agent can’t and shouldn’t make legal promises as the “Applicant” for the actual domain owner.

Do you really think the new phrase “the Applicant’s authorization to obtain and manage certificates for the Domain Namespace” adds any clarity?  I’m afraid it would add some ambiguity.  If we need to clarify that someone can act as Agent for the Applicant, we can do that, but only the Applicant should really be agreeing to the Subscriber Agreement, etc.

If you want to respond, please email me and I will repost.

From: Peter Bowen [mailto:pzbowen at gmail.com<mailto:pzbowen at gmail.com>]
Sent: Saturday, November 14, 2015 1:31 PM
To: Kirk Hall (RD-US)
Cc: CABFPub (public at cabforum.org<mailto:public at cabforum.org>)
Subject: Re: [cabfpub] Question 3 – Domain Validation pre-ballot

Kirk,
Thank you for the offer to forward comments to the group.  Overall, I think that this is excellent work and I look forward to these becoming final.  I agree that the current language of Line J makes my comment moot.  However, I do think there are a couple of other minor changes that would make the intent of validation clearer.
In Line C, under (b), insert the words “or Affiliate of the CA” after “CA”.  Many companies have different subsidiaries for different functions, so the Registrar and CA Operator might not be the same legal entity, even if customers see them as the same.
In Lines D, E, F, and G, replace "Confirming the Applicant’s domain ownership or control by" with "Confirming the Applicant’s authorization to obtain and manage certificates for the Domain Namespace by”.  This makes it clear that the purpose of the method is to confirm authorization and that Applicant does not have to be the same entity as the Domain Name Registrant.
In Line B, insert “authorization, “ before “ownership” to reflect the change in D/E/F/G.
It would also be good to clarify that the 6 months from ballot approval date is when CAs must cease to use non-compliant methods.  CAs should be able to use any of the methods in the ballot immediately upon approval.  I think the ballot additionally should clarify if existing validations using a newly non-compliant method can be reused for 39 months (as per 3.3.1) or if CAs must cease relying upon the existing validations 6 months from ballot approval.
Thanks,
Peter

On Thu, Nov 12, 2015 at 5:08 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Question 3 – Domain Validation pre-ballot

Peter Bowen Comments

Peter Bowen of Amazon did not submit specific new language, but posed the following comment about new Method No. 7 shown below:

Proposal 3: In line J of current draft (Method No. 7)

“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>.”


Here is the current Ballot language for Method No. 7:



“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 “

I noted we had discussed before the problem of “kirkstore.shopping.com<http://kirkstore.shopping.com>” – Kirk might have control over the third level FQDN, but might not have control over the SLDN (Base Domain) of shopping.com<http://shopping.com>, so even though Kirk could demonstrate control for kirkstore.shopping.com<http://kirkstore.shopping.com>, he should not use that to get a cert for shopping.com<http://shopping.com>.

Doug Beattie thought that Peter might be misreading Authorization Domain Name, which is defined as follows:

“Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance or a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN starts with a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation.“

“Base Domain Name: The portion of an applied-for FQDN that is the first domain name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. “example.co.uk<http://example.co.uk>” or “example.com<http://example.com>”). For gTLDs, the domain www.[gTLD<http://www.%5BgTLD>] will be considered to be a Base Domain. “

Questions for Discussion:

(1) Is Doug correct that the current definition of Authorized Domain Name (see underlined text above) would already satisfy Peter’s suggestion that proving control of any FQDN by making a change to the DNS record for that FQDN is sufficient to get a certificate for any lower level domain it contains, including the SLDN or Base Domain?   If yes, are any changes needed?

(2) More generally, do the members agree with Peter’s statement that “A domain registrant should be able to choose to approve all FQDNs under corp.example.com<http://corp.example.com> by adding a [DNS]record for  corp.example.com<http://corp.example.com>.”  If not, do we need to change the definition of Authorization Domain Name to delete the language underlined above?

To Peter Bowen: If you want to comment on this issue, please email to me and I will post to the Public list.


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<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public


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.






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.




<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151121/ca5f6fb8/attachment-0001.html 


More information about the Public mailing list