From kirk_hall at trendmicro.com  Tue Aug 11 14:17:17 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Tue, 11 Aug 2015 21:17:17 +0000
Subject: [cabf_validation] Matrix for comparing possible changes to cert
	validity period
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5ABECB82@SJDCEXMBX03.us.trendnet.org>

For our discussion.  These are the options for change that were offered at the Zurich face to face meeting.  I tried to present possible pros and cons in a neutral way for each option; no doubt there are more arguments for each.

<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/validation/attachments/20150811/ee1d1ff1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Validity Period Matrix (8-11-2015).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 17165 bytes
Desc: Validity Period Matrix (8-11-2015).docx
Url : https://cabforum.org/pipermail/validation/attachments/20150811/ee1d1ff1/attachment-0001.bin 

From kirk_hall at trendmicro.com  Wed Aug 12 09:17:13 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Wed, 12 Aug 2015 16:17:13 +0000
Subject: [cabf_validation] Updated draft on domain validation methods
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5ABEDBD1@SJDCEXMBX03.us.trendnet.org>

Doug Beattie and I took on responsibility for creating an updated draft on revisions to domain validation methods.  Because this conversation has gone on so many months, I think the working group has lost track so where some proposed changes came from, what they are supposed to mean, etc.  Some changes have meant that particular Definitions are no longer used, etc.  We really want to track all this and make sure all proposed changes are explained clearly and consistent.  We are also trying to research things like appropriate (secure) ports to be used in practical demonstration methods, and are waiting for recommendations on that.  Once we have a new draft (with comments and recommendations), we want the VWG to have enough time to evaluate before we discuss on a call.

What this means is, we won't have a new draft ready for tomorrow's call, but should have a new draft ready for the call on August 27.

Kirk

<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/validation/attachments/20150812/65acff25/attachment.html 

From jeremy.rowley at digicert.com  Thu Aug 13 08:20:20 2015
From: jeremy.rowley at digicert.com (Jeremy Rowley)
Date: Thu, 13 Aug 2015 15:20:20 +0000
Subject: [cabf_validation] Validation Working Group
Message-ID: <e037ec14b7444c7085e91de02724b021@EX2.corp.digicert.com>

The details of this event have been changed for: Aug 13, 2015

When: August 13, 9:00?10:00 AM
-----------------------------------
Update call information for the Validation WG

Access Code: 373-2280
Toll: +1 (805) 309-2350
Toll-Free: +1 (800) 309-2350
sip:bridge at turbobridge.com
https://turbobridge.com/skype.html
https://turbobridge.com/international.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2984 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150813/a0e9c2c5/attachment.bin 

From ben.wilson at digicert.com  Thu Aug 13 08:58:39 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Thu, 13 Aug 2015 15:58:39 +0000
Subject: [cabf_validation] Domain Authorization Documents
Message-ID: <d8dcf7981512433da93b2e1533616622@EX2.corp.digicert.com>

As I said on the call, the concept of the Domain Authorization Document is a
stop-gap measure needed to close that last mile in some limited situations.
It isn't something that should be used regularly, but it's needed to enable
SSL issuance when you have performed domain validation, yet the name in
WHOIS does not match the name of the entity in the certificate.  

 

This concept has been through the EVG sausage grinder multiple times-so it
doesn't make sense to go through its entire history.  Suffice it to say that
at one point the Attorney Letter was seen as satisfactory, (section
10.6.2(2)(A)(i),  of v. 1.2 of the EV Guidelines (2010)), and then at some
point in the development of the EV Guidelines, the Domain Authorization
Document was coined as the suggested way of handling private/anonymous
registrations.  In Draft 04, of v. 1.4 (March 2012), the following
definition was proposed, "Domain Authorization Document: Documentation
provided by, or a CA's documentation of a communication with, the domain
name registrar or the person or entity listed in WHOIS as registering the
domain name (including any private, anonymous, or proxy registration
service)  Correspondence or other documentation provided by a Domain Name
Registrant attesting that the Applicant has the exclusive right to use the
specified domain name."  

 

This concept needs to be retained somewhere in the CABF guidelines-not as an
alternative validation method, but as a way to supplement other methods. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150813/05e0f321/attachment.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/20150813/05e0f321/attachment.bin 

From kirk_hall at trendmicro.com  Thu Aug 13 11:16:36 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Thu, 13 Aug 2015 18:16:36 +0000
Subject: [cabf_validation] Question on use of Domain Authorization Document
	for domain vetting
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5ABEFDBA@SJDCEXMBX03.us.trendnet.org>

On the VWG call this morning, I mentioned that the current language for the domain validation method using a Domain Authorization Document (DAD) is extremely hard to understand, and suggested people let us know how they are using DADs so we can improve the language.  There is no intention of eliminating this method, just making the language better.

Here is current domain validation method #5 in BR 3.2.2.4:

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 by: ***

5. Relying upon a Domain Authorization Document;

Here is the definition of a DAD, parsed to show why it?s confusing today:



TEXT

COMMENTS



Domain Authorization Document:



A

Documentation provided by,

Documents the CA receives from someone else, or

B

or a CA?s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably phone, maybe email or fax?) with a party listed in the next three rows

C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar

D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does this imply it can only come a party that is listed as the Registrant in the WhoIs registry for the domain?  It seems to say that.
I guess this might be used if the Registrant in WhoIs is Company A, and the Applicant for the domain is Company B, and you get a letter from Company A saying ?I have licensed Company B to use my domain - it?s ok?.  Any other uses?

E

or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service)

What?s the difference between ?the Domain Name Registrant? in the prior row, and ?the person or entity listed in WHOIS as the Domain Name Registrant? in this row?  Aren?t they the same?
Is the prior row trying to include the Applicant, even if the Applicant isn?t listed as the Registrant in WhoIs?  It doesn?t read that way.

F

attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

So the ?documentation? is only a DAD if it attests to the authority of the Applicant to use the domain.


Early in the call we discussed that a DAD has often been used when an Applicant wants to show ownership or control of a long list of its domains, and submits an attorney/accountant letter attesting that the Applicant owns or controls the domains (which sufficient for vetting purposes).  The attorney/accountant letter would be a DAD, and under method #5, that would be sufficient to authenticate the domains.  But attorney/accountant letters are probably going away.  So how else are CAs using DADs for domain authentication?

I would mention that BR 3.3.1 allows vetting data to be used for 39 months before revetting is required:

The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty?nine (39) months prior to issuing the Certificate.

So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given date (and has a record of that in the file), the CA can reuse the same data for the customer for later cert requests for the same domain - in my opinion, there is no need to call the record of the first vetting a ?DAD? and then say ?I?m relying on the DAD as method #5? the next time the same customer asks for another cert for the same domain - the vetting has already been done and is good for 39 months (and subsequent cert requests) under BR 3.3.1, and the CA does not need to pretend the vetting was repeated by reference to a DAD containing results of the earlier vetting.

Does anyone have a specific use-case of current method #5 requiring a DAD they can share (and where the DAD by itself is sufficient to complete the vetting)?  If we can gather these use-cases, maybe we can improve the language of this current vetting method so it can be understood.


<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/validation/attachments/20150813/08eecf21/attachment-0001.html 

From kirk_hall at trendmicro.com  Thu Aug 13 12:46:24 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Thu, 13 Aug 2015 19:46:24 +0000
Subject: [cabf_validation] Question on use of Domain Authorization
 Document for domain vetting
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5ABEFF40@SJDCEXMBX03.us.trendnet.org>

Sorry - to clarify me request below about use of DADs:
Can you list some use cases for relying solely on a DAD for domain authorization that are not already covered by validation methods 1-4 and 6, which are:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;

2. Communicating directly with the Domain Name Registrant using an address, email, or telephone
number provided by the Domain Name Registrar;

3. Communicating directly with the Domain Name Registrant using the contact information listed in the
WHOIS record?s ?registrant?, ?technical?, or ?administrative? field;
4. Communicating with the Domain?s administrator using an email address created by pre?pending
?admin?, ?administrator?, ?webmaster?, ?hostmaster?, or ?postmaster? in the local part, followed by the
at?sign (?@?), followed by the Domain Name, which may be formed by pruning zero or more
components from the requested FQDN;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed?upon
change to information found on an online Web page identified by a uniform resource identifier
containing the FQDN; or

From: Kirk Hall (RD-US)
Sent: Thursday, August 13, 2015 11:17 AM
To: validation at cabforum.org
Subject: Question on use of Domain Authorization Document for domain vetting

On the VWG call this morning, I mentioned that the current language for the domain validation method using a Domain Authorization Document (DAD) is extremely hard to understand, and suggested people let us know how they are using DADs so we can improve the language.  There is no intention of eliminating this method, just making the language better.

Here is current domain validation method #5 in BR 3.2.2.4:

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 by: ***

5. Relying upon a Domain Authorization Document;

Here is the definition of a DAD, parsed to show why it?s confusing today:



TEXT

COMMENTS



Domain Authorization Document:



A

Documentation provided by,

Documents the CA receives from someone else, or

B

or a CA?s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably phone, maybe email or fax?) with a party listed in the next three rows

C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar

D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does this imply it can only come a party that is listed as the Registrant in the WhoIs registry for the domain?  It seems to say that.
I guess this might be used if the Registrant in WhoIs is Company A, and the Applicant for the domain is Company B, and you get a letter from Company A saying ?I have licensed Company B to use my domain - it?s ok?.  Any other uses?

E

or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service)

What?s the difference between ?the Domain Name Registrant? in the prior row, and ?the person or entity listed in WHOIS as the Domain Name Registrant? in this row?  Aren?t they the same?
Is the prior row trying to include the Applicant, even if the Applicant isn?t listed as the Registrant in WhoIs?  It doesn?t read that way.

F

attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

So the ?documentation? is only a DAD if it attests to the authority of the Applicant to use the domain.


Early in the call we discussed that a DAD has often been used when an Applicant wants to show ownership or control of a long list of its domains, and submits an attorney/accountant letter attesting that the Applicant owns or controls the domains (which sufficient for vetting purposes).  The attorney/accountant letter would be a DAD, and under method #5, that would be sufficient to authenticate the domains.  But attorney/accountant letters are probably going away.  So how else are CAs using DADs for domain authentication?

I would mention that BR 3.3.1 allows vetting data to be used for 39 months before revetting is required:

The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty?nine (39) months prior to issuing the Certificate.

So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given date (and has a record of that in the file), the CA can reuse the same data for the customer for later cert requests for the same domain - in my opinion, there is no need to call the record of the first vetting a ?DAD? and then say ?I?m relying on the DAD as method #5? the next time the same customer asks for another cert for the same domain - the vetting has already been done and is good for 39 months (and subsequent cert requests) under BR 3.3.1, and the CA does not need to pretend the vetting was repeated by reference to a DAD containing results of the earlier vetting.

Does anyone have a specific use-case of current method #5 requiring a DAD they can share (and where the DAD by itself is sufficient to complete the vetting)?  If we can gather these use-cases, maybe we can improve the language of this current vetting method so it can be understood.


<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/validation/attachments/20150813/b909af18/attachment-0001.html 

From ben.wilson at digicert.com  Fri Aug 14 06:27:09 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Fri, 14 Aug 2015 13:27:09 +0000
Subject: [cabf_validation] Question on use of Domain Authorization
 Document for domain vetting
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5ABEFF40@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5ABEFF40@SJDCEXMBX03.us.trendnet.org>
Message-ID: <b30dd8f06b224c6fbff0c3c6c2b0967a@EX2.corp.digicert.com>

We don?t rely ?solely? on a Domain Authorization Document, because in
nearly all cases you have to at least check with WHOIS to see who has
control over the domain.  I suppose that if you were trying to establish
control over one of the new gTLDs you might need to do it without checking
WHOIS and instead you?d need to rely on the agreements found here -
https://www.icann.org/resources/pages/registries/registries-agreements-en.
I don?t know if anyone has used that, but even in that case, you?re not
relying ?solely?  on the DAD, because there is a public list of registry
agreements that you?re checking.



From: validation-bounces at cabforum.org
[mailto:validation-bounces at cabforum.org] On Behalf Of
kirk_hall at trendmicro.com
Sent: Thursday, August 13, 2015 1:46 PM
To: validation at cabforum.org
Subject: Re: [cabf_validation] Question on use of Domain Authorization
Document for domain vetting



Sorry - to clarify me request below about use of DADs:

Can you list some use cases for relying solely on a DAD for domain
authorization that are not already covered by validation methods 1-4 and 6,
which are:

1. Confirming the Applicant as the Domain Name Registrant directly with the
Domain Name Registrar;



2. Communicating directly with the Domain Name Registrant using an address,
email, or telephone

number provided by the Domain Name Registrar;



3. Communicating directly with the Domain Name Registrant using the contact
information listed in the

WHOIS record?s ?registrant?, ?technical?, or ?administrative? field;

4. Communicating with the Domain?s administrator using an email address
created by pre?pending

?admin?, ?administrator?, ?webmaster?, ?hostmaster?, or
?postmaster? in the local part, followed by the

at?sign (?@?), followed by the Domain Name, which may be formed by
pruning zero or more

components from the requested FQDN;

6. Having the Applicant demonstrate practical control over the FQDN by
making an agreed?upon

change to information found on an online Web page identified by a uniform
resource identifier

containing the FQDN; or



From: Kirk Hall (RD-US)
Sent: Thursday, August 13, 2015 11:17 AM
To: validation at cabforum.org <mailto:validation at cabforum.org>
Subject: Question on use of Domain Authorization Document for domain vetting



On the VWG call this morning, I mentioned that the current language for the
domain validation method using a Domain Authorization Document (DAD) is
extremely hard to understand, and suggested people let us know how they are
using DADs so we can improve the language.  There is no intention of
eliminating this method, just making the language better.



Here is current domain validation method #5 in BR 3.2.2.4:



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 by: ***



5. Relying upon a Domain Authorization Document;



Here is the definition of a DAD, parsed to show why it?s confusing today:






TEXT

COMMENTS




Domain Authorization Document:




A

Documentation provided by,

Documents the CA receives from someone else, or


B

or a CA?s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably
phone, maybe email or fax?) with a party listed in the next three rows


C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar


D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does
this imply it can only come a party that is listed as the Registrant in the
WhoIs registry for the domain?  It seems to say that.

I guess this might be used if the Registrant in WhoIs is Company A, and the
Applicant for the domain is Company B, and you get a letter from Company A
saying ?I have licensed Company B to use my domain - it?s ok?.  Any other
uses?


E

or the person or entity listed in WHOIS as the Domain Name Registrant
(including any private, anonymous, or proxy registration service)

What?s the difference between ?the Domain Name Registrant? in the prior
row, and ?the person or entity listed in WHOIS as the Domain Name
Registrant? in this row?  Aren?t they the same?

Is the prior row trying to include the Applicant, even if the Applicant
isn?t listed as the Registrant in WhoIs?  It doesn?t read that way.


F

attesting to the authority of an Applicant to request a Certificate for a
specific Domain Namespace.

So the ?documentation? is only a DAD if it attests to the authority of the
Applicant to use the domain.



Early in the call we discussed that a DAD has often been used when an
Applicant wants to show ownership or control of a long list of its domains,
and submits an attorney/accountant letter attesting that the Applicant owns
or controls the domains (which sufficient for vetting purposes).  The
attorney/accountant letter would be a DAD, and under method #5, that would
be sufficient to authenticate the domains.  But attorney/accountant letters
are probably going away.  So how else are CAs using DADs for domain
authentication?



I would mention that BR 3.3.1 allows vetting data to be used for 39 months
before revetting is required:



The CA MAY use the documents and data provided in Section 3.2 to verify
certificate information, provided that the CA obtained the data or document
from a source specified under Section 3.2 no more than thirty?nine (39)
months prior to issuing the Certificate.



So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given
date (and has a record of that in the file), the CA can reuse the same data
for the customer for later cert requests for the same domain - in my
opinion, there is no need to call the record of the first vetting a ?DAD?
and then say ?I?m relying on the DAD as method #5? the next time the same
customer asks for another cert for the same domain - the vetting has already
been done and is good for 39 months (and subsequent cert requests) under BR
3.3.1, and the CA does not need to pretend the vetting was repeated by
reference to a DAD containing results of the earlier vetting.



Does anyone have a specific use-case of current method #5 requiring a DAD
they can share (and where the DAD by itself is sufficient to complete the
vetting)?  If we can gather these use-cases, maybe we can improve the
language of this current vetting method so it can be understood.






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...
URL: https://cabforum.org/pipermail/validation/attachments/20150814/9dd3b14d/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/20150814/9dd3b14d/attachment-0001.bin 

From Cecilia_Kam at symantec.com  Fri Aug 14 11:27:33 2015
From: Cecilia_Kam at symantec.com (Cecilia Kam)
Date: Fri, 14 Aug 2015 11:27:33 -0700
Subject: [cabf_validation] Question on use of Domain Authorization
 Document for domain vetting
In-Reply-To: <b30dd8f06b224c6fbff0c3c6c2b0967a@EX2.corp.digicert.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5ABEFF40@SJDCEXMBX03.us.trendnet.org>
	<b30dd8f06b224c6fbff0c3c6c2b0967a@EX2.corp.digicert.com>
Message-ID: <571602E8CBF2CE4B8D025AD126A299632D4F50E3DB@TUS1XCHEVSPIN32.SYMC.SYMANTEC.COM>

Along with what Ben is saying the Domain Authorization Document is not solely used but is for documenting our process of communication with the Registrar or Registrant until authorization is received.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 14, 2015 06:27
To: kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

We don?t rely ?solely? on a Domain Authorization Document, because in nearly all cases you have to at least check with WHOIS to see who has control over the domain.  I suppose that if you were trying to establish control over one of the new gTLDs you might need to do it without checking WHOIS and instead you?d need to rely on the agreements found here - https://www.icann.org/resources/pages/registries/registries-agreements-en.  I don?t know if anyone has used that, but even in that case, you?re not relying ?solely?  on the DAD, because there is a public list of registry agreements that you?re checking.

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, August 13, 2015 1:46 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

Sorry - to clarify me request below about use of DADs:
Can you list some use cases for relying solely on a DAD for domain authorization that are not already covered by validation methods 1-4 and 6, which are:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;

2. Communicating directly with the Domain Name Registrant using an address, email, or telephone
number provided by the Domain Name Registrar;

3. Communicating directly with the Domain Name Registrant using the contact information listed in the
WHOIS record?s ?registrant?, ?technical?, or ?administrative? field;
4. Communicating with the Domain?s administrator using an email address created by pre?pending
?admin?, ?administrator?, ?webmaster?, ?hostmaster?, or ?postmaster? in the local part, followed by the
at?sign (?@?), followed by the Domain Name, which may be formed by pruning zero or more
components from the requested FQDN;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed?upon
change to information found on an online Web page identified by a uniform resource identifier
containing the FQDN; or

From: Kirk Hall (RD-US)
Sent: Thursday, August 13, 2015 11:17 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Question on use of Domain Authorization Document for domain vetting

On the VWG call this morning, I mentioned that the current language for the domain validation method using a Domain Authorization Document (DAD) is extremely hard to understand, and suggested people let us know how they are using DADs so we can improve the language.  There is no intention of eliminating this method, just making the language better.

Here is current domain validation method #5 in BR 3.2.2.4:

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 by: ***

5. Relying upon a Domain Authorization Document;

Here is the definition of a DAD, parsed to show why it?s confusing today:



TEXT

COMMENTS



Domain Authorization Document:



A

Documentation provided by,

Documents the CA receives from someone else, or

B

or a CA?s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably phone, maybe email or fax?) with a party listed in the next three rows

C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar

D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does this imply it can only come a party that is listed as the Registrant in the WhoIs registry for the domain?  It seems to say that.
I guess this might be used if the Registrant in WhoIs is Company A, and the Applicant for the domain is Company B, and you get a letter from Company A saying ?I have licensed Company B to use my domain - it?s ok?.  Any other uses?

E

or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service)

What?s the difference between ?the Domain Name Registrant? in the prior row, and ?the person or entity listed in WHOIS as the Domain Name Registrant? in this row?  Aren?t they the same?
Is the prior row trying to include the Applicant, even if the Applicant isn?t listed as the Registrant in WhoIs?  It doesn?t read that way.

F

attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

So the ?documentation? is only a DAD if it attests to the authority of the Applicant to use the domain.


Early in the call we discussed that a DAD has often been used when an Applicant wants to show ownership or control of a long list of its domains, and submits an attorney/accountant letter attesting that the Applicant owns or controls the domains (which sufficient for vetting purposes).  The attorney/accountant letter would be a DAD, and under method #5, that would be sufficient to authenticate the domains.  But attorney/accountant letters are probably going away.  So how else are CAs using DADs for domain authentication?

I would mention that BR 3.3.1 allows vetting data to be used for 39 months before revetting is required:

The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty?nine (39) months prior to issuing the Certificate.

So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given date (and has a record of that in the file), the CA can reuse the same data for the customer for later cert requests for the same domain - in my opinion, there is no need to call the record of the first vetting a ?DAD? and then say ?I?m relying on the DAD as method #5? the next time the same customer asks for another cert for the same domain - the vetting has already been done and is good for 39 months (and subsequent cert requests) under BR 3.3.1, and the CA does not need to pretend the vetting was repeated by reference to a DAD containing results of the earlier vetting.

Does anyone have a specific use-case of current method #5 requiring a DAD they can share (and where the DAD by itself is sufficient to complete the vetting)?  If we can gather these use-cases, maybe we can improve the language of this current vetting method so it can be understood.




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...
URL: https://cabforum.org/pipermail/validation/attachments/20150814/31def161/attachment-0001.html 

From doug.beattie at globalsign.com  Mon Aug 17 07:50:56 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Mon, 17 Aug 2015 14:50:56 +0000
Subject: [cabf_validation] Definition of Base Domain Name
Message-ID: <SG2PR03MB06665A46D00CFAFE4C067D02F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>

We haven't discussed the accuracy of the current definition:

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" or "example.com").

For reference, the definition of Authorization Domain Name says: The CA may prune zero or more labels from left to right until encountering a Base Domain Name.

If the value of the first domain name node left of the registry controlled or psl is "www", should we allow the cert to be issued?  There are cases where certs need to be issued, for example: https://www.gov.uk/ .  New tlds might also need this, www.walmart<http://www.walmart>, www.visa<http://www.visa>, etc.  We can validate FQDNs like this when doing domain control technically via email approval, DNS or file as long as we use the www variant and haven't pruned any labels (www in this case) from the left.  Authorized domain name says to leave one node to the left of the Base Domain name, and www technically is one node.  It sounds like this is supported.

If we allow this, then we  should consider updating the definition of Base Domain Name to include some additional examples like www.co.example<http://www.co.example> and www.example<http://www.example> as valid Base Domain Names.  However, calling these Base Domain Names does not seem accurate, thus my question.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150817/dfb30d8c/attachment.html 

From ben.wilson at digicert.com  Mon Aug 17 07:58:28 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Mon, 17 Aug 2015 14:58:28 +0000
Subject: [cabf_validation] Definition of Base Domain Name
In-Reply-To: <SG2PR03MB06665A46D00CFAFE4C067D02F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <SG2PR03MB06665A46D00CFAFE4C067D02F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <06256a0a28c74ebea276b0998309553d@EX2.corp.digicert.com>

Doug,

You make a good point about these two definitions.  FQDN is another concept
that we also need to integrate into this analysis.  It makes me think we
need to create the concept of the "Requested FQDN", which isn't currently
used or defined.  

 

An applicant requests either a wildcard for a Base Domain Name or a
particular FQDN ("requested FQDN") for a certificate?  So I would argue that
we need to consider two scenarios - one is the wildcard for a base domain
and the other is an FQDN.  Question- is there a different process for
determining an Authorization Domain Name for each alternatives, or is it the
same?

 

Ben

 

From: validation-bounces at cabforum.org
[mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Monday, August 17, 2015 8:51 AM
To: validation at cabforum.org
Subject: [cabf_validation] Definition of Base Domain Name

 

We haven't discussed the accuracy of the current definition:

 

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" or
"example.com").

 

For reference, the definition of Authorization Domain Name says: The CA may
prune zero or more labels from left to right until encountering a Base
Domain Name.

 

If the value of the first domain name node left of the registry controlled
or psl is "www", should we allow the cert to be issued?  There are cases
where certs need to be issued, for example: https://www.gov.uk/ .  New tlds
might also need this, www.walmart <http://www.walmart> , www.visa
<http://www.visa> , etc.  We can validate FQDNs like this when doing domain
control technically via email approval, DNS or file as long as we use the
www variant and haven't pruned any labels (www in this case) from the left.
Authorized domain name says to leave one node to the left of the Base Domain
name, and www technically is one node.  It sounds like this is supported.

 

If we allow this, then we  should consider updating the definition of Base
Domain Name to include some additional examples like www.co.example
<http://www.co.example>  and www.example <http://www.example>  as valid Base
Domain Names.  However, calling these Base Domain Names does not seem
accurate, thus my question.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150817/cb87ae8e/attachment.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/20150817/cb87ae8e/attachment.bin 

From jeremy.rowley at digicert.com  Mon Aug 17 14:05:18 2015
From: jeremy.rowley at digicert.com (Jeremy Rowley)
Date: Mon, 17 Aug 2015 21:05:18 +0000
Subject: [cabf_validation] Question on use of Domain Authorization
 Document for domain vetting
In-Reply-To: <b30dd8f06b224c6fbff0c3c6c2b0967a@EX2.corp.digicert.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5ABEFF40@SJDCEXMBX03.us.trendnet.org>
	<b30dd8f06b224c6fbff0c3c6c2b0967a@EX2.corp.digicert.com>
Message-ID: <f5717f8d3b9149bd834a2bc706fda6f3@EX2.corp.digicert.com>

True - I don?t think you should be able to rely on a sole WHOIS lookup either. I?m not sure that tells you anything without some time to the organization vetted (for OV and EV) or some technical association with the requester (for all cert types). The DAL works as that tie for OV and EV.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 14, 2015 7:27 AM
To: kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

We don?t rely ?solely? on a Domain Authorization Document, because in nearly all cases you have to at least check with WHOIS to see who has control over the domain.  I suppose that if you were trying to establish control over one of the new gTLDs you might need to do it without checking WHOIS and instead you?d need to rely on the agreements found here - https://www.icann.org/resources/pages/registries/registries-agreements-en.  I don?t know if anyone has used that, but even in that case, you?re not relying ?solely?  on the DAD, because there is a public list of registry agreements that you?re checking.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, August 13, 2015 1:46 PM
To: validation at cabforum.org
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

Sorry - to clarify me request below about use of DADs:
Can you list some use cases for relying solely on a DAD for domain authorization that are not already covered by validation methods 1-4 and 6, which are:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;

2. Communicating directly with the Domain Name Registrant using an address, email, or telephone
number provided by the Domain Name Registrar;

3. Communicating directly with the Domain Name Registrant using the contact information listed in the
WHOIS record?s ?registrant?, ?technical?, or ?administrative? field;
4. Communicating with the Domain?s administrator using an email address created by pre?pending
?admin?, ?administrator?, ?webmaster?, ?hostmaster?, or ?postmaster? in the local part, followed by the
at?sign (?@?), followed by the Domain Name, which may be formed by pruning zero or more
components from the requested FQDN;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed?upon
change to information found on an online Web page identified by a uniform resource identifier
containing the FQDN; or

From: Kirk Hall (RD-US)
Sent: Thursday, August 13, 2015 11:17 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Question on use of Domain Authorization Document for domain vetting

On the VWG call this morning, I mentioned that the current language for the domain validation method using a Domain Authorization Document (DAD) is extremely hard to understand, and suggested people let us know how they are using DADs so we can improve the language.  There is no intention of eliminating this method, just making the language better.

Here is current domain validation method #5 in BR 3.2.2.4:

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 by: ***

5. Relying upon a Domain Authorization Document;

Here is the definition of a DAD, parsed to show why it?s confusing today:



TEXT

COMMENTS



Domain Authorization Document:



A

Documentation provided by,

Documents the CA receives from someone else, or

B

or a CA?s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably phone, maybe email or fax?) with a party listed in the next three rows

C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar

D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does this imply it can only come a party that is listed as the Registrant in the WhoIs registry for the domain?  It seems to say that.
I guess this might be used if the Registrant in WhoIs is Company A, and the Applicant for the domain is Company B, and you get a letter from Company A saying ?I have licensed Company B to use my domain - it?s ok?.  Any other uses?

E

or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service)

What?s the difference between ?the Domain Name Registrant? in the prior row, and ?the person or entity listed in WHOIS as the Domain Name Registrant? in this row?  Aren?t they the same?
Is the prior row trying to include the Applicant, even if the Applicant isn?t listed as the Registrant in WhoIs?  It doesn?t read that way.

F

attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

So the ?documentation? is only a DAD if it attests to the authority of the Applicant to use the domain.


Early in the call we discussed that a DAD has often been used when an Applicant wants to show ownership or control of a long list of its domains, and submits an attorney/accountant letter attesting that the Applicant owns or controls the domains (which sufficient for vetting purposes).  The attorney/accountant letter would be a DAD, and under method #5, that would be sufficient to authenticate the domains.  But attorney/accountant letters are probably going away.  So how else are CAs using DADs for domain authentication?

I would mention that BR 3.3.1 allows vetting data to be used for 39 months before revetting is required:

The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty?nine (39) months prior to issuing the Certificate.

So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given date (and has a record of that in the file), the CA can reuse the same data for the customer for later cert requests for the same domain - in my opinion, there is no need to call the record of the first vetting a ?DAD? and then say ?I?m relying on the DAD as method #5? the next time the same customer asks for another cert for the same domain - the vetting has already been done and is good for 39 months (and subsequent cert requests) under BR 3.3.1, and the CA does not need to pretend the vetting was repeated by reference to a DAD containing results of the earlier vetting.

Does anyone have a specific use-case of current method #5 requiring a DAD they can share (and where the DAD by itself is sufficient to complete the vetting)?  If we can gather these use-cases, maybe we can improve the language of this current vetting method so it can be understood.




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...
URL: https://cabforum.org/pipermail/validation/attachments/20150817/d59b5a76/attachment-0001.html 

From doug.beattie at globalsign.com  Mon Aug 17 14:16:15 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Mon, 17 Aug 2015 21:16:15 +0000
Subject: [cabf_validation] Definition of Base Domain Name
In-Reply-To: <06256a0a28c74ebea276b0998309553d@EX2.corp.digicert.com>
References: <SG2PR03MB06665A46D00CFAFE4C067D02F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<06256a0a28c74ebea276b0998309553d@EX2.corp.digicert.com>
Message-ID: <SG2PR03MB0666967770E488F3F6043E13F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>

Hi Ben,

 

At this point the applicant requests an FQDN that they want in the cert, we
compute a list of allowed Authorization Domain Names which they can use (for
some methods) to help approve the FQDN.  The Authorization Domain Name
defines how to handle wildcard and how to trim from the left, so that should
be OK also.

 

A base domain is of the format example.com, and a wildcard for a base domain
would be *.example.com, so I think that is describes accurately.


We don't contemplate wildcards for gTLDs, *.co.uk, and that's good - let's
not get into how to do that (certainly one could envision allowing that for
some brand gTLDs, but manual processes would be good for that.)

 

So it comes back to the original question, do we treat www.gTLD as a Base
Domain, or is it something different?

 

 

 

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Monday, August 17, 2015 10:58 AM
To: Doug Beattie <doug.beattie at globalsign.com>; validation at cabforum.org
Subject: RE: Definition of Base Domain Name

 

Doug,

You make a good point about these two definitions.  FQDN is another concept
that we also need to integrate into this analysis.  It makes me think we
need to create the concept of the "Requested FQDN", which isn't currently
used or defined.  

 

An applicant requests either a wildcard for a Base Domain Name or a
particular FQDN ("requested FQDN") for a certificate?  So I would argue that
we need to consider two scenarios - one is the wildcard for a base domain
and the other is an FQDN.  Question- is there a different process for
determining an Authorization Domain Name for each alternatives, or is it the
same?

 

Ben

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Monday, August 17, 2015 8:51 AM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Definition of Base Domain Name

 

We haven't discussed the accuracy of the current definition:

 

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" or
"example.com").

 

For reference, the definition of Authorization Domain Name says: The CA may
prune zero or more labels from left to right until encountering a Base
Domain Name.

 

If the value of the first domain name node left of the registry controlled
or psl is "www", should we allow the cert to be issued?  There are cases
where certs need to be issued, for example: https://www.gov.uk/ .  New tlds
might also need this, www.walmart <http://www.walmart> , www.visa
<http://www.visa> , etc.  We can validate FQDNs like this when doing domain
control technically via email approval, DNS or file as long as we use the
www variant and haven't pruned any labels (www in this case) from the left.
Authorized domain name says to leave one node to the left of the Base Domain
name, and www technically is one node.  It sounds like this is supported.

 

If we allow this, then we  should consider updating the definition of Base
Domain Name to include some additional examples like www.co.example
<http://www.co.example>  and www.example <http://www.example>  as valid Base
Domain Names.  However, calling these Base Domain Names does not seem
accurate, thus my question.

 

 

 

 

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

From kirk_hall at trendmicro.com  Mon Aug 17 17:55:55 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Tue, 18 Aug 2015 00:55:55 +0000
Subject: [cabf_validation] Definition of Base Domain Name
In-Reply-To: <SG2PR03MB0666967770E488F3F6043E13F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <SG2PR03MB06665A46D00CFAFE4C067D02F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<06256a0a28c74ebea276b0998309553d@EX2.corp.digicert.com>
	<SG2PR03MB0666967770E488F3F6043E13F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5ABF6816@SJDCEXMBX03.us.trendnet.org>

Doug - is the case of www the only situation we are considering?

If yes, would we solve the problem by adding the following sentence at the end of the definition of Base Domain?  "For gTLDs, the domain www.[gTLD<http://www.[gTLD>] will be considered to be a Base Domain."

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Monday, August 17, 2015 2:16 PM
To: Ben Wilson; validation at cabforum.org
Subject: Re: [cabf_validation] Definition of Base Domain Name

Hi Ben,

At this point the applicant requests an FQDN that they want in the cert, we compute a list of allowed Authorization Domain Names which they can use (for some methods) to help approve the FQDN.  The Authorization Domain Name defines how to handle wildcard and how to trim from the left, so that should be OK also.

A base domain is of the format example.com, and a wildcard for a base domain would be *.example.com, so I think that is describes accurately.

We don't contemplate wildcards for gTLDs, *.co.uk, and that's good - let's not get into how to do that (certainly one could envision allowing that for some brand gTLDs, but manual processes would be good for that.)

So it comes back to the original question, do we treat www.gTLD<http://www.gTLD> as a Base Domain, or is it something different?




From: Ben Wilson [mailto:ben.wilson at digicert.com]
Sent: Monday, August 17, 2015 10:58 AM
To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: Definition of Base Domain Name

Doug,
You make a good point about these two definitions.  FQDN is another concept that we also need to integrate into this analysis.  It makes me think we need to create the concept of the "Requested FQDN", which isn't currently used or defined.

An applicant requests either a wildcard for a Base Domain Name or a particular FQDN ("requested FQDN") for a certificate?  So I would argue that we need to consider two scenarios - one is the wildcard for a base domain and the other is an FQDN.  Question- is there a different process for determining an Authorization Domain Name for each alternatives, or is it the same?

Ben

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Monday, August 17, 2015 8:51 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Definition of Base Domain Name

We haven't discussed the accuracy of the current definition:

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" or "example.com").

For reference, the definition of Authorization Domain Name says: The CA may prune zero or more labels from left to right until encountering a Base Domain Name.

If the value of the first domain name node left of the registry controlled or psl is "www", should we allow the cert to be issued?  There are cases where certs need to be issued, for example: https://www.gov.uk/ .  New tlds might also need this, www.walmart<http://www.walmart>, www.visa<http://www.visa>, etc.  We can validate FQDNs like this when doing domain control technically via email approval, DNS or file as long as we use the www variant and haven't pruned any labels (www in this case) from the left.  Authorized domain name says to leave one node to the left of the Base Domain name, and www technically is one node.  It sounds like this is supported.

If we allow this, then we  should consider updating the definition of Base Domain Name to include some additional examples like www.co.example<http://www.co.example> and www.example<http://www.example> as valid Base Domain Names.  However, calling these Base Domain Names does not seem accurate, thus my question.





<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/validation/attachments/20150818/4005b34b/attachment-0001.html 

From kirk_hall at trendmicro.com  Mon Aug 17 19:12:28 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Tue, 18 Aug 2015 02:12:28 +0000
Subject: [cabf_validation] Question on use of Domain Authorization
 Document for domain vetting
In-Reply-To: <571602E8CBF2CE4B8D025AD126A299632D4F50E3DB@TUS1XCHEVSPIN32.SYMC.SYMANTEC.COM>
References: <EF70381B2D29784EA4FC66042BE81EAF5ABEFF40@SJDCEXMBX03.us.trendnet.org>
	<b30dd8f06b224c6fbff0c3c6c2b0967a@EX2.corp.digicert.com>
	<571602E8CBF2CE4B8D025AD126A299632D4F50E3DB@TUS1XCHEVSPIN32.SYMC.SYMANTEC.COM>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5ABF693E@SJDCEXMBX03.us.trendnet.org>

OK, you guys have educated me, and convinced me that current method #5 with Domain Authorization Documents does not need revision.  Thanks.
From: Cecilia Kam [mailto:Cecilia_Kam at symantec.com]
Sent: Friday, August 14, 2015 11:28 AM
To: Ben Wilson; Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

Along with what Ben is saying the Domain Authorization Document is not solely used but is for documenting our process of communication with the Registrar or Registrant until authorization is received.

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 14, 2015 06:27
To: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

We don?t rely ?solely? on a Domain Authorization Document, because in nearly all cases you have to at least check with WHOIS to see who has control over the domain.  I suppose that if you were trying to establish control over one of the new gTLDs you might need to do it without checking WHOIS and instead you?d need to rely on the agreements found here - https://www.icann.org/resources/pages/registries/registries-agreements-en.  I don?t know if anyone has used that, but even in that case, you?re not relying ?solely?  on the DAD, because there is a public list of registry agreements that you?re checking.

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, August 13, 2015 1:46 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

Sorry - to clarify me request below about use of DADs:
Can you list some use cases for relying solely on a DAD for domain authorization that are not already covered by validation methods 1-4 and 6, which are:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;

2. Communicating directly with the Domain Name Registrant using an address, email, or telephone
number provided by the Domain Name Registrar;

3. Communicating directly with the Domain Name Registrant using the contact information listed in the
WHOIS record?s ?registrant?, ?technical?, or ?administrative? field;
4. Communicating with the Domain?s administrator using an email address created by pre?pending
?admin?, ?administrator?, ?webmaster?, ?hostmaster?, or ?postmaster? in the local part, followed by the
at?sign (?@?), followed by the Domain Name, which may be formed by pruning zero or more
components from the requested FQDN;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed?upon
change to information found on an online Web page identified by a uniform resource identifier
containing the FQDN; or

From: Kirk Hall (RD-US)
Sent: Thursday, August 13, 2015 11:17 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Question on use of Domain Authorization Document for domain vetting

On the VWG call this morning, I mentioned that the current language for the domain validation method using a Domain Authorization Document (DAD) is extremely hard to understand, and suggested people let us know how they are using DADs so we can improve the language.  There is no intention of eliminating this method, just making the language better.

Here is current domain validation method #5 in BR 3.2.2.4:

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 by: ***

5. Relying upon a Domain Authorization Document;

Here is the definition of a DAD, parsed to show why it?s confusing today:



TEXT

COMMENTS



Domain Authorization Document:



A

Documentation provided by,

Documents the CA receives from someone else, or

B

or a CA?s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably phone, maybe email or fax?) with a party listed in the next three rows

C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar

D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does this imply it can only come a party that is listed as the Registrant in the WhoIs registry for the domain?  It seems to say that.
I guess this might be used if the Registrant in WhoIs is Company A, and the Applicant for the domain is Company B, and you get a letter from Company A saying ?I have licensed Company B to use my domain - it?s ok?.  Any other uses?

E

or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service)

What?s the difference between ?the Domain Name Registrant? in the prior row, and ?the person or entity listed in WHOIS as the Domain Name Registrant? in this row?  Aren?t they the same?
Is the prior row trying to include the Applicant, even if the Applicant isn?t listed as the Registrant in WhoIs?  It doesn?t read that way.

F

attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

So the ?documentation? is only a DAD if it attests to the authority of the Applicant to use the domain.


Early in the call we discussed that a DAD has often been used when an Applicant wants to show ownership or control of a long list of its domains, and submits an attorney/accountant letter attesting that the Applicant owns or controls the domains (which sufficient for vetting purposes).  The attorney/accountant letter would be a DAD, and under method #5, that would be sufficient to authenticate the domains.  But attorney/accountant letters are probably going away.  So how else are CAs using DADs for domain authentication?

I would mention that BR 3.3.1 allows vetting data to be used for 39 months before revetting is required:

The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty?nine (39) months prior to issuing the Certificate.

So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given date (and has a record of that in the file), the CA can reuse the same data for the customer for later cert requests for the same domain - in my opinion, there is no need to call the record of the first vetting a ?DAD? and then say ?I?m relying on the DAD as method #5? the next time the same customer asks for another cert for the same domain - the vetting has already been done and is good for 39 months (and subsequent cert requests) under BR 3.3.1, and the CA does not need to pretend the vetting was repeated by reference to a DAD containing results of the earlier vetting.

Does anyone have a specific use-case of current method #5 requiring a DAD they can share (and where the DAD by itself is sufficient to complete the vetting)?  If we can gather these use-cases, maybe we can improve the language of this current vetting method so it can be understood.




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/validation/attachments/20150818/81cce180/attachment-0001.html 

From bruce.morton at entrust.com  Tue Aug 18 05:56:45 2015
From: bruce.morton at entrust.com (Bruce Morton)
Date: Tue, 18 Aug 2015 12:56:45 +0000
Subject: [cabf_validation] Definition of Base Domain Name
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5ABF6816@SJDCEXMBX03.us.trendnet.org>
References: <SG2PR03MB06665A46D00CFAFE4C067D02F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<06256a0a28c74ebea276b0998309553d@EX2.corp.digicert.com>
	<SG2PR03MB0666967770E488F3F6043E13F0790@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<EF70381B2D29784EA4FC66042BE81EAF5ABF6816@SJDCEXMBX03.us.trendnet.org>
Message-ID: <452C99D20750E74083DBA441FF932385E7F97954@SOTTEXCH10.corp.ad.entrust.com>

I?m not understanding the issue. Is www reserved?

www.com<http://www.com> has been registered, so I would consider this a base domain.

Would we not treat www.com<http://www.com> the same way as www.visa<http://www.visa>? They both look like Base Domains to me.

Bruce.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Monday, August 17, 2015 8:56 PM
To: Doug Beattie <doug.beattie at globalsign.com>; Ben Wilson <ben.wilson at digicert.com>; validation at cabforum.org
Subject: Re: [cabf_validation] Definition of Base Domain Name

Doug ? is the case of www the only situation we are considering?

If yes, would we solve the problem by adding the following sentence at the end of the definition of Base Domain?  ?For gTLDs, the domain www.[gTLD<http://www.[gTLD>] will be considered to be a Base Domain.?

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Monday, August 17, 2015 2:16 PM
To: Ben Wilson; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Re: [cabf_validation] Definition of Base Domain Name

Hi Ben,

At this point the applicant requests an FQDN that they want in the cert, we compute a list of allowed Authorization Domain Names which they can use (for some methods) to help approve the FQDN.  The Authorization Domain Name defines how to handle wildcard and how to trim from the left, so that should be OK also.

A base domain is of the format example.com, and a wildcard for a base domain would be *.example.com, so I think that is describes accurately.

We don?t contemplate wildcards for gTLDs, *.co.uk, and that?s good ? let?s not get into how to do that (certainly one could envision allowing that for some brand gTLDs, but manual processes would be good for that.)

So it comes back to the original question, do we treat www.gTLD<http://www.gTLD> as a Base Domain, or is it something different?




From: Ben Wilson [mailto:ben.wilson at digicert.com]
Sent: Monday, August 17, 2015 10:58 AM
To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: Definition of Base Domain Name

Doug,
You make a good point about these two definitions.  FQDN is another concept that we also need to integrate into this analysis.  It makes me think we need to create the concept of the ?Requested FQDN?, which isn?t currently used or defined.

An applicant requests either a wildcard for a Base Domain Name or a particular FQDN (?requested FQDN?) for a certificate?  So I would argue that we need to consider two scenarios ? one is the wildcard for a base domain and the other is an FQDN.  Question- is there a different process for determining an Authorization Domain Name for each alternatives, or is it the same?

Ben

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Monday, August 17, 2015 8:51 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Definition of Base Domain Name

We haven?t discussed the accuracy of the current definition:

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? or ?example.com?).

For reference, the definition of Authorization Domain Name says: The CA may prune zero or more labels from left to right until encountering a Base Domain Name.

If the value of the first domain name node left of the registry controlled or psl is ?www?, should we allow the cert to be issued?  There are cases where certs need to be issued, for example: https://www.gov.uk/ .  New tlds might also need this, www.walmart<http://www.walmart>, www.visa<http://www.visa>, etc.  We can validate FQDNs like this when doing domain control technically via email approval, DNS or file as long as we use the www variant and haven?t pruned any labels (www in this case) from the left.  Authorized domain name says to leave one node to the left of the Base Domain name, and www technically is one node.  It sounds like this is supported.

If we allow this, then we  should consider updating the definition of Base Domain Name to include some additional examples like www.co.example<http://www.co.example> and www.example<http://www.example> as valid Base Domain Names.  However, calling these Base Domain Names does not seem accurate, thus my question.







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...
URL: https://cabforum.org/pipermail/validation/attachments/20150818/fa085b90/attachment.html 

From kirk_hall at trendmicro.com  Tue Aug 25 16:39:37 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Tue, 25 Aug 2015 23:39:37 +0000
Subject: [cabf_validation] New draft domain validation ballot for discussion
	on Thursday's call
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC1BADE@SJDCEXMBX03.us.trendnet.org>

Doug Beattie, Jeremy Rowley, and I worked on a new draft of a domain validation ballot dated Aug. 25 - see attached.  Let's work from this re-draft for our call this Thursday.

I tried to go back to some of the earlier draft ballots from some months ago - over time, we got more changes and complexity, and I think people lost track of what we were trying to do, or even what some of the new language meant or was intended to do.

I would strongly recommend we try to stick to old language if possible - we are creating guidelines that CAs around the world will follow, and (in my opinion) shouldn't make changes to the wording of current methods 1-6 unless really necessary.

This draft drops current method 7 ("any other method") and adds three new methods (new 7, 8, and 9) proposed by different parties.  That was the main goal for this ballot in the first place - so let's keep it simple, and get it done.

<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/validation/attachments/20150825/cac6bb06/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 8-25-2015.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 32005 bytes
Desc: New Domain Validation Draft 8-25-2015.docx
Url : https://cabforum.org/pipermail/validation/attachments/20150825/cac6bb06/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 8-25-2015.pdf
Type: application/pdf
Size: 385703 bytes
Desc: New Domain Validation Draft 8-25-2015.pdf
Url : https://cabforum.org/pipermail/validation/attachments/20150825/cac6bb06/attachment-0001.pdf 

From kirk_hall at trendmicro.com  Wed Aug 26 14:34:29 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Wed, 26 Aug 2015 21:34:29 +0000
Subject: [cabf_validation] Updated draft domain validation ballot for
 discussion on Thursday's call
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC1CBC2@SJDCEXMBX03.us.trendnet.org>

I incorporated some additional comments and suggestions in the attached draft domain validation ballot (dated 8/26/2015) for discussion on Thursday's call - changes from the prior draft are shown in red.

Let's work from this on our call tomorrow morning.

Kirk

<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/validation/attachments/20150826/f50e501a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 8-26-2015.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 32684 bytes
Desc: New Domain Validation Draft 8-26-2015.docx
Url : https://cabforum.org/pipermail/validation/attachments/20150826/f50e501a/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 8-26-2015.pdf
Type: application/pdf
Size: 387467 bytes
Desc: New Domain Validation Draft 8-26-2015.pdf
Url : https://cabforum.org/pipermail/validation/attachments/20150826/f50e501a/attachment-0001.pdf 

From jeremy.rowley at digicert.com  Wed Aug 26 22:34:03 2015
From: jeremy.rowley at digicert.com (Jeremy Rowley)
Date: Thu, 27 Aug 2015 05:34:03 +0000
Subject: [cabf_validation] Updated draft domain validation ballot for
 discussion on Thursday's call
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC1CBC2@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1CBC2@SJDCEXMBX03.us.trendnet.org>
Message-ID: <487bc1b3e3df453f9a7429cfc88a8bdc@EX2.corp.digicert.com>

I don?t think you should have to use ?a value that is unpredictable and previously unknown to the applicant? on D, E, and F. You?re communicating directly with the registrar or applicant.  How would you even do this by phone? Plus unpredictable is not well-defined at this point.

I also have issues with Authorized Port, which is not defined, and requiring a Random Value for H. The point is that the information is being placed into the .well-known directory, not that the value is random. I don?t think we should call it ?DV? either as that causes confusion between the type of validation and the three different types of certificates.  It should be ?validation? or something similar.

The change in J omits that a CNAME record could point to the DNS record.  This is not Random Value or Request Token but is (imo) better than a random value in a TXT record. CNAME validation appears inadvertently omitted and should be reinserted.

On H, methods 2, 3, and 4 do not necessarily require an email challenge. A telephone one is acceptable.

Jeremy

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Wednesday, August 26, 2015 3:34 PM
To: validation at cabforum.org
Subject: [cabf_validation] Updated draft domain validation ballot for discussion on Thursday's call

I incorporated some additional comments and suggestions in the attached draft domain validation ballot (dated 8/26/2015) for discussion on Thursday's call ? changes from the prior draft are shown in red.

Let?s work from this on our call tomorrow morning.

Kirk



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...
URL: https://cabforum.org/pipermail/validation/attachments/20150827/0d39ff47/attachment.html 

From kirk_hall at trendmicro.com  Thu Aug 27 07:11:19 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Thu, 27 Aug 2015 14:11:19 +0000
Subject: [cabf_validation] Updated draft domain validation ballot for
 discussion on Thursday's call
In-Reply-To: <487bc1b3e3df453f9a7429cfc88a8bdc@EX2.corp.digicert.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1CBC2@SJDCEXMBX03.us.trendnet.org>
	<487bc1b3e3df453f9a7429cfc88a8bdc@EX2.corp.digicert.com>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC1E435@SJDCEXMBX03.us.trendnet.org>

Let?s go through each method one by one on the call today and discuss.

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Wednesday, August 26, 2015 10:34 PM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] Updated draft domain validation ballot for discussion on Thursday's call

I don?t think you should have to use ?a value that is unpredictable and previously unknown to the applicant? on D, E, and F. You?re communicating directly with the registrar or applicant.  How would you even do this by phone? Plus unpredictable is not well-defined at this point.

I also have issues with Authorized Port, which is not defined, and requiring a Random Value for H. The point is that the information is being placed into the .well-known directory, not that the value is random. I don?t think we should call it ?DV? either as that causes confusion between the type of validation and the three different types of certificates.  It should be ?validation? or something similar.

The change in J omits that a CNAME record could point to the DNS record.  This is not Random Value or Request Token but is (imo) better than a random value in a TXT record. CNAME validation appears inadvertently omitted and should be reinserted.

On H, methods 2, 3, and 4 do not necessarily require an email challenge. A telephone one is acceptable.

Jeremy

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Wednesday, August 26, 2015 3:34 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Updated draft domain validation ballot for discussion on Thursday's call

I incorporated some additional comments and suggestions in the attached draft domain validation ballot (dated 8/26/2015) for discussion on Thursday's call ? changes from the prior draft are shown in red.

Let?s work from this on our call tomorrow morning.

Kirk



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/validation/attachments/20150827/4c6b7a25/attachment-0001.html 

From kirk_hall at trendmicro.com  Thu Aug 27 11:49:15 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Thu, 27 Aug 2015 18:49:15 +0000
Subject: [cabf_validation] *Please review ASAP* Updated domain validation
	draft
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

Jeremy, you said you had additional Authorized Ports to propose - please send to this list today if possible.

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases - automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn't that what we decided?

For everyone else - please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.

<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/validation/attachments/20150827/926fec2c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 8-27-2015.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 35021 bytes
Desc: New Domain Validation Draft 8-27-2015.docx
Url : https://cabforum.org/pipermail/validation/attachments/20150827/926fec2c/attachment-0001.bin 

From doug.beattie at globalsign.com  Thu Aug 27 12:33:52 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Thu, 27 Aug 2015 19:33:52 +0000
Subject: [cabf_validation] *Please review ASAP* Updated domain
	validation	draft
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
Message-ID: <SG2PR03MB0666A86AAD1C7AA38519DDF8F06F0@SG2PR03MB0666.apcprd03.prod.outlook.com>

Hi Kirk,

Good updates.

Should #4 also be updated to use Random Value?

Z) the use of Random Value is now used in more places than just 6 and 7, so the info in the right column needs to be updated

Nit-pick: If the FQDN starts with a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN, if any.

If you want to send out a version with tracking, that?s OK, but I think you should definitely send out a clean version for people to review and comment on.


From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, August 27, 2015 2:49 PM
To: validation at cabforum.org
Subject: [cabf_validation] *Please review ASAP* Updated domain validation draft
Importance: High

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

Jeremy, you said you had additional Authorized Ports to propose ? please send to this list today if possible.

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases ? automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn?t that what we decided?

For everyone else ? please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.



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...
URL: https://cabforum.org/pipermail/validation/attachments/20150827/82bbb534/attachment.html 

From Rick_Andrews at symantec.com  Thu Aug 27 14:53:51 2015
From: Rick_Andrews at symantec.com (Rick Andrews)
Date: Thu, 27 Aug 2015 14:53:51 -0700
Subject: [cabf_validation] *Please review ASAP* Updated domain
 validation	draft
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
Message-ID: <544B0DD62A64C1448B2DA253C01141461924F1704D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>

Thanks for pulling this together, Kirk (and whoever helped you, if you had help). I added a couple of comments/questions.

 

-Rick

 

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, August 27, 2015 11:49 AM
To: validation at cabforum.org
Subject: [cabf_validation] *Please review ASAP* Updated domain validation draft
Importance: High

 

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

 

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

 

Jeremy, you said you had additional Authorized Ports to propose ? please send to this list today if possible.

 

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases ? automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn?t that what we decided?

 

For everyone else ? please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.



 
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...
URL: https://cabforum.org/pipermail/validation/attachments/20150827/0b9c2ae4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 8-27-2015_Rick.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 43577 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150827/0b9c2ae4/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150827/0b9c2ae4/attachment-0003.bin 

From kirk_hall at trendmicro.com  Thu Aug 27 17:13:17 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Fri, 28 Aug 2015 00:13:17 +0000
Subject: [cabf_validation] *Please review ASAP* Updated domain
 validation	draft
In-Reply-To: <SG2PR03MB0666A86AAD1C7AA38519DDF8F06F0@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
	<SG2PR03MB0666A86AAD1C7AA38519DDF8F06F0@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC1F82E@SJDCEXMBX03.us.trendnet.org>

Thanks, Doug, I made all the changes.  And yes, I will send out only a clean version to the Public list, probably tomorrow.

From: Doug Beattie [mailto:doug.beattie at globalsign.com]
Sent: Thursday, August 27, 2015 12:34 PM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

Hi Kirk,

Good updates.

Should #4 also be updated to use Random Value?

Z) the use of Random Value is now used in more places than just 6 and 7, so the info in the right column needs to be updated

Nit-pick: If the FQDN starts with a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN, if any.

If you want to send out a version with tracking, that?s OK, but I think you should definitely send out a clean version for people to review and comment on.


From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, August 27, 2015 2:49 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] *Please review ASAP* Updated domain validation draft
Importance: High

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

Jeremy, you said you had additional Authorized Ports to propose ? please send to this list today if possible.

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases ? automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn?t that what we decided?

For everyone else ? please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.



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/validation/attachments/20150828/c52bfbd7/attachment.html 

From kirk_hall at trendmicro.com  Thu Aug 27 17:29:57 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Fri, 28 Aug 2015 00:29:57 +0000
Subject: [cabf_validation] *Please review ASAP* Updated domain
 validation	draft
In-Reply-To: <544B0DD62A64C1448B2DA253C01141461924F1704D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
	<544B0DD62A64C1448B2DA253C01141461924F1704D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC1F9C2@SJDCEXMBX03.us.trendnet.org>

Rick, I think I saw only two comments or changes.

I will change ?Domain Validation? to ?Validation of Domain Ownership or Control? for the new title of 3.2.2.4 as you suggest.

The other comment I saw was about CNAME for Method 8.  On the call today, CNAME was raised, and someone said the issue is ?covered? by the new definition of Authorization Domain Name (see below).  Do you agree?

Were there any other issues you raised?

Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for 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.

From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Thursday, August 27, 2015 2:54 PM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

Thanks for pulling this together, Kirk (and whoever helped you, if you had help). I added a couple of comments/questions.

-Rick

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, August 27, 2015 11:49 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] *Please review ASAP* Updated domain validation draft
Importance: High

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

Jeremy, you said you had additional Authorized Ports to propose ? please send to this list today if possible.

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases ? automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn?t that what we decided?

For everyone else ? please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.



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/validation/attachments/20150828/c26a34b8/attachment-0001.html 

From Rick_Andrews at symantec.com  Fri Aug 28 09:41:57 2015
From: Rick_Andrews at symantec.com (Rick Andrews)
Date: Fri, 28 Aug 2015 09:41:57 -0700
Subject: [cabf_validation] *Please review ASAP* Updated domain
 validation	draft
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC1F9C2@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
	<544B0DD62A64C1448B2DA253C01141461924F1704D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
	<EF70381B2D29784EA4FC66042BE81EAF5AC1F9C2@SJDCEXMBX03.us.trendnet.org>
Message-ID: <544B0DD62A64C1448B2DA253C01141461924F173D8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>

Kirk, I saw that mention of CNAME, but I didn?t think it covered my concern. The new method 8 (K) says ?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 requested FQDN in accordance with section 3.2.2.5;  or?. So the new method isn?t tied to the definition of Authorization Domain Name.

 

How about if method 8 said ?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 3.2.2.5;  or?

 

That would make it similar to the other uses of Authorization Domain Name in the doc.

 

-Rick

 

From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] 
Sent: Thursday, August 27, 2015 5:30 PM
To: Rick Andrews; validation at cabforum.org
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

 

Rick, I think I saw only two comments or changes.

 

I will change ?Domain Validation? to ?Validation of Domain Ownership or Control? for the new title of 3.2.2.4 as you suggest.

 

The other comment I saw was about CNAME for Method 8.  On the call today, CNAME was raised, and someone said the issue is ?covered? by the new definition of Authorization Domain Name (see below).  Do you agree?

 

Were there any other issues you raised?

 

Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for 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.

 

From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
Sent: Thursday, August 27, 2015 2:54 PM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

 

Thanks for pulling this together, Kirk (and whoever helped you, if you had help). I added a couple of comments/questions.

 

-Rick

 

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, August 27, 2015 11:49 AM
To: validation at cabforum.org
Subject: [cabf_validation] *Please review ASAP* Updated domain validation draft
Importance: High

 

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

 

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

 

Jeremy, you said you had additional Authorized Ports to propose ? please send to this list today if possible.

 

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases ? automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn?t that what we decided?

 

For everyone else ? please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.



 
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.

 

  _____  

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

From kirk_hall at trendmicro.com  Fri Aug 28 10:05:45 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Fri, 28 Aug 2015 17:05:45 +0000
Subject: [cabf_validation] *Please review ASAP* Updated domain
 validation	draft
In-Reply-To: <544B0DD62A64C1448B2DA253C01141461924F173D8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC1EF0E@SJDCEXMBX03.us.trendnet.org>
	<544B0DD62A64C1448B2DA253C01141461924F1704D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
	<EF70381B2D29784EA4FC66042BE81EAF5AC1F9C2@SJDCEXMBX03.us.trendnet.org>
	<544B0DD62A64C1448B2DA253C01141461924F173D8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC20AA5@SJDCEXMBX03.us.trendnet.org>

I like it and will add now.  Thanks.

From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Friday, August 28, 2015 9:42 AM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

Kirk, I saw that mention of CNAME, but I didn?t think it covered my concern. The new method 8 (K) says ?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 requested FQDN in accordance with section 3.2.2.5;  or?. So the new method isn?t tied to the definition of Authorization Domain Name.

How about if method 8 said ?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 3.2.2.5;  or?

That would make it similar to the other uses of Authorization Domain Name in the doc.

-Rick

From: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> [mailto:kirk_hall at trendmicro.com]
Sent: Thursday, August 27, 2015 5:30 PM
To: Rick Andrews; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

Rick, I think I saw only two comments or changes.

I will change ?Domain Validation? to ?Validation of Domain Ownership or Control? for the new title of 3.2.2.4 as you suggest.

The other comment I saw was about CNAME for Method 8.  On the call today, CNAME was raised, and someone said the issue is ?covered? by the new definition of Authorization Domain Name (see below).  Do you agree?

Were there any other issues you raised?

Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for 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.

From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Thursday, August 27, 2015 2:54 PM
To: Kirk Hall (RD-US); validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: [cabf_validation] *Please review ASAP* Updated domain validation draft

Thanks for pulling this together, Kirk (and whoever helped you, if you had help). I added a couple of comments/questions.

-Rick

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, August 27, 2015 11:49 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] *Please review ASAP* Updated domain validation draft
Importance: High

I attach an updated Domain Validation draft revision, dated today (Aug. 27) in track changes mode from the Aug. 26 draft we discussed this morning.

I added a new Method 10 (line M) to cover the cases where the CA is also the Registrar.  Wayne, can you edit?

Jeremy, you said you had additional Authorized Ports to propose ? please send to this list today if possible.

The definition for Random Value (line Z) has changed as we discussed, so we can use the term everywhere.  Per our discussion, we only specify minimum entropy for two cases ? automated processes, and practical demonstration in the DNS record.  Otherwise, the Random Value can be a value specified by the CA that is unknown to the Applicant.  Isn?t that what we decided?

For everyone else ? please review and see if this is ready to forward to the Forum members TOMORROW for first discussion next Thursday.  Meaning, please provide your comments today or tomorrow morning at the latest.



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/validation/attachments/20150828/bc3362f0/attachment-0001.html 

From ben.wilson at digicert.com  Fri Aug 28 11:10:54 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Fri, 28 Aug 2015 18:10:54 +0000
Subject: [cabf_validation] Authorized Port List
Message-ID: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>

What about this list as something to review?  It's pulled from a review of
this:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 

 

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465
(smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593
(rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos),
898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992
(telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel),
2087 (webhost), 2096 (cpanel), 5060-5061 (sip)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150828/0c0392d1/attachment.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/20150828/0c0392d1/attachment.bin 

From doug.beattie at globalsign.com  Fri Aug 28 11:26:44 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Fri, 28 Aug 2015 18:26:44 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>
Message-ID: <SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>

Ben,

Do you think a CA needs to use all of these ports when attempting to validate a Random value in the .well-known directory on an Authorized Domain?  It seems unlikely Kerberos, sip and many others would be used for that purpose.

I suggest CAs add to the short list in Kirk's proposal with ones they use and need to be present.  If others need to be added in the future that can be another ballot (i.e., start small and add as needed).

Doug

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org
Subject: [cabf_validation] Authorized Port List

What about this list as something to review?  It's pulled from a review of this:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465 (smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593 (rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos), 898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992 (telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel), 2087 (webhost), 2096 (cpanel), 5060-5061 (sip)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150828/e0983cb5/attachment.html 

From ben.wilson at digicert.com  Fri Aug 28 11:45:22 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Fri, 28 Aug 2015 18:45:22 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <de888f44b75241089b727715867677f9@EX2.corp.digicert.com>

It's not about what CAs want.  It's about what a customer might want.
________________________________
From: Doug Beattie<mailto:doug.beattie at globalsign.com>
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson<mailto:ben.wilson at digicert.com>; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: Authorized Port List

Ben,

Do you think a CA needs to use all of these ports when attempting to validate a Random value in the .well-known directory on an Authorized Domain?  It seems unlikely Kerberos, sip and many others would be used for that purpose.

I suggest CAs add to the short list in Kirk?s proposal with ones they use and need to be present.  If others need to be added in the future that can be another ballot (i.e., start small and add as needed).

Doug

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org
Subject: [cabf_validation] Authorized Port List

What about this list as something to review?  It?s pulled from a review of this:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465 (smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593 (rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos), 898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992 (telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel), 2087 (webhost), 2096 (cpanel), 5060-5061 (sip)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150828/10ef87d3/attachment-0001.html 

From doug.beattie at globalsign.com  Fri Aug 28 12:06:43 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Fri, 28 Aug 2015 19:06:43 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
Message-ID: <SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>

Some CAs have very strict rules about where the random number can go and they request the customer to place it there.  If others put it anywhere, then I guess they will need to provide a long list like you did or recommend that we not restrict this to a specific set of ports.

Doug

From: Ben Wilson [mailto:ben.wilson at digicert.com]
Sent: Friday, August 28, 2015 2:45 PM
To: Doug Beattie <doug.beattie at globalsign.com>; validation at cabforum.org
Subject: RE: Authorized Port List

It's not about what CAs want.  It's about what a customer might want.
________________________________
From: Doug Beattie<mailto:doug.beattie at globalsign.com>
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson<mailto:ben.wilson at digicert.com>; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: Authorized Port List
Ben,

Do you think a CA needs to use all of these ports when attempting to validate a Random value in the .well-known directory on an Authorized Domain?  It seems unlikely Kerberos, sip and many others would be used for that purpose.

I suggest CAs add to the short list in Kirk?s proposal with ones they use and need to be present.  If others need to be added in the future that can be another ballot (i.e., start small and add as needed).

Doug

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Authorized Port List

What about this list as something to review?  It?s pulled from a review of this:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465 (smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593 (rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos), 898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992 (telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel), 2087 (webhost), 2096 (cpanel), 5060-5061 (sip)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150828/333a2645/attachment.html 

From ben.wilson at digicert.com  Mon Aug 31 04:06:36 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Mon, 31 Aug 2015 11:06:36 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
	<SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <44d3445e10f145bd8c9cc892fbad7dd6@EX2.corp.digicert.com>

My thought is that if an SSL certificate can be installed for the services
listed below, then the proper way to configure the server (from a security
perspective) is to lock down all other ports and only allow the correct type
of traffic through.  For example, an IMAP server would have ports 143 and
993 open and then once the certificate is installed port 143 would forward
to port 993.  I agree that the list can be pared down (but other ports may
need to be added ? I didn?t include port 143 in my list), but I?m waiting to
hear from someone more knowledgeable than I on this.  I think we need to
reach outside the Validation Working Group for an answer.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Friday, August 28, 2015 1:07 PM
To: Ben Wilson <ben.wilson at digicert.com>; validation at cabforum.org
Subject: RE: Authorized Port List

 

Some CAs have very strict rules about where the random number can go and
they request the customer to place it there.  If others put it anywhere,
then I guess they will need to provide a long list like you did or recommend
that we not restrict this to a specific set of ports.

 

Doug

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Friday, August 28, 2015 2:45 PM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

It's not about what CAs want.  It's about what a customer might want.

  _____  

From: Doug Beattie <mailto:doug.beattie at globalsign.com> 
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson <mailto:ben.wilson at digicert.com> ; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

Ben,

 

Do you think a CA needs to use all of these ports when attempting to
validate a Random value in the .well-known directory on an Authorized
Domain?  It seems unlikely Kerberos, sip and many others would be used for
that purpose.

 

I suggest CAs add to the short list in Kirk?s proposal with ones they use
and need to be present.  If others need to be added in the future that can
be another ballot (i.e., start small and add as needed).

 

Doug

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Authorized Port List

 

What about this list as something to review?  It?s pulled from a review of
this:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 

 

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465
(smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593
(rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos),
898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992
(telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel),
2087 (webhost), 2096 (cpanel), 5060-5061 (sip)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150831/9a0ebc94/attachment.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/20150831/9a0ebc94/attachment.bin 

From ben.wilson at digicert.com  Mon Aug 31 04:30:32 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Mon, 31 Aug 2015 11:30:32 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <44d3445e10f145bd8c9cc892fbad7dd6@EX2.corp.digicert.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
	<SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<44d3445e10f145bd8c9cc892fbad7dd6@EX2.corp.digicert.com>
Message-ID: <8fc03e0e681c41fc983e4d5d88311e11@EX2.corp.digicert.com>

What about this reduced list?

 


Authorized Ports

Not SSL/TLS

SSL/TLS

	

 

 

 

	

ftp

20-21

989-990

	

ssh

22

 

	

telnet

23

992

	

smtp

25, 587

465

	

http

80

443

	

pop

110

995

	

nntp

119

563

	

imap

143

993

	

irc

194

994

	

ldap

389

636

	

sip

5060

5061

	
				

Ports that won't be included

 

		

sftp

115

		

active-directory

445

		

rfs

556

		

filemaker

591

		

rpc-over-http

593

		

ieee-mms-ssl

695

		

kerberos

749-752

		

brocade-ssl

898

		

vmware

901-904

		

ibm

1364

		

c-panel

2083

		
				

 

 

From: validation-bounces at cabforum.org
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Monday, August 31, 2015 5:07 AM
To: Doug Beattie <doug.beattie at globalsign.com>; validation at cabforum.org
Subject: Re: [cabf_validation] Authorized Port List

 

My thought is that if an SSL certificate can be installed for the services
listed below, then the proper way to configure the server (from a security
perspective) is to lock down all other ports and only allow the correct type
of traffic through.  For example, an IMAP server would have ports 143 and
993 open and then once the certificate is installed port 143 would forward
to port 993.  I agree that the list can be pared down (but other ports may
need to be added ? I didn?t include port 143 in my list), but I?m waiting to
hear from someone more knowledgeable than I on this.  I think we need to
reach outside the Validation Working Group for an answer.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Friday, August 28, 2015 1:07 PM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

Some CAs have very strict rules about where the random number can go and
they request the customer to place it there.  If others put it anywhere,
then I guess they will need to provide a long list like you did or recommend
that we not restrict this to a specific set of ports.

 

Doug

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Friday, August 28, 2015 2:45 PM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

It's not about what CAs want.  It's about what a customer might want.

  _____  

From: Doug Beattie <mailto:doug.beattie at globalsign.com> 
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson <mailto:ben.wilson at digicert.com> ; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

Ben,

 

Do you think a CA needs to use all of these ports when attempting to
validate a Random value in the .well-known directory on an Authorized
Domain?  It seems unlikely Kerberos, sip and many others would be used for
that purpose.

 

I suggest CAs add to the short list in Kirk?s proposal with ones they use
and need to be present.  If others need to be added in the future that can
be another ballot (i.e., start small and add as needed).

 

Doug

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Authorized Port List

 

What about this list as something to review?  It?s pulled from a review of
this:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 

 

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465
(smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593
(rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos),
898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992
(telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel),
2087 (webhost), 2096 (cpanel), 5060-5061 (sip)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150831/6cd9b856/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/20150831/6cd9b856/attachment-0001.bin 

From doug.beattie at globalsign.com  Mon Aug 31 04:34:56 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Mon, 31 Aug 2015 11:34:56 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <8fc03e0e681c41fc983e4d5d88311e11@EX2.corp.digicert.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
	<SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<44d3445e10f145bd8c9cc892fbad7dd6@EX2.corp.digicert.com>
	<8fc03e0e681c41fc983e4d5d88311e11@EX2.corp.digicert.com>
Message-ID: <SG2PR03MB06663BED9AE978B343324F2BF06B0@SG2PR03MB0666.apcprd03.prod.outlook.com>

sip is above 1000, is that one necessary or could we omit that and let a
strong proponent that uses it today request that it be added?

 

Other than that, sure, it?s a short list and we can let the public list
discuss the pros/cons of the entries.

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Monday, August 31, 2015 7:31 AM
To: Ben Wilson <ben.wilson at digicert.com>; Doug Beattie
<doug.beattie at globalsign.com>; validation at cabforum.org
Subject: RE: Authorized Port List

 

What about this reduced list?

 


Authorized Ports

Not SSL/TLS

SSL/TLS

	

 

 

 

	

ftp

20-21

989-990

	

ssh

22

 

	

telnet

23

992

	

smtp

25, 587

465

	

http

80

443

	

pop

110

995

	

nntp

119

563

	

imap

143

993

	

irc

194

994

	

ldap

389

636

	

sip

5060

5061

	
				

Ports that won't be included

 

		

sftp

115

		

active-directory

445

		

rfs

556

		

filemaker

591

		

rpc-over-http

593

		

ieee-mms-ssl

695

		

kerberos

749-752

		

brocade-ssl

898

		

vmware

901-904

		

ibm

1364

		

c-panel

2083

		
				

 

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Monday, August 31, 2015 5:07 AM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: Re: [cabf_validation] Authorized Port List

 

My thought is that if an SSL certificate can be installed for the services
listed below, then the proper way to configure the server (from a security
perspective) is to lock down all other ports and only allow the correct type
of traffic through.  For example, an IMAP server would have ports 143 and
993 open and then once the certificate is installed port 143 would forward
to port 993.  I agree that the list can be pared down (but other ports may
need to be added ? I didn?t include port 143 in my list), but I?m waiting to
hear from someone more knowledgeable than I on this.  I think we need to
reach outside the Validation Working Group for an answer.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Friday, August 28, 2015 1:07 PM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

Some CAs have very strict rules about where the random number can go and
they request the customer to place it there.  If others put it anywhere,
then I guess they will need to provide a long list like you did or recommend
that we not restrict this to a specific set of ports.

 

Doug

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Friday, August 28, 2015 2:45 PM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

It's not about what CAs want.  It's about what a customer might want.

  _____  

From: Doug Beattie <mailto:doug.beattie at globalsign.com> 
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson <mailto:ben.wilson at digicert.com> ; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

Ben,

 

Do you think a CA needs to use all of these ports when attempting to
validate a Random value in the .well-known directory on an Authorized
Domain?  It seems unlikely Kerberos, sip and many others would be used for
that purpose.

 

I suggest CAs add to the short list in Kirk?s proposal with ones they use
and need to be present.  If others need to be added in the future that can
be another ballot (i.e., start small and add as needed).

 

Doug

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Authorized Port List

 

What about this list as something to review?  It?s pulled from a review of
this:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 

 

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465
(smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593
(rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos),
898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992
(telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel),
2087 (webhost), 2096 (cpanel), 5060-5061 (sip)

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

From ben.wilson at digicert.com  Mon Aug 31 04:37:05 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Mon, 31 Aug 2015 11:37:05 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <SG2PR03MB06663BED9AE978B343324F2BF06B0@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
	<SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<44d3445e10f145bd8c9cc892fbad7dd6@EX2.corp.digicert.com>
	<8fc03e0e681c41fc983e4d5d88311e11@EX2.corp.digicert.com>
	<SG2PR03MB06663BED9AE978B343324F2BF06B0@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <4713e22a0b22445597c373b47f766be5@EX2.corp.digicert.com>

I?m fine with leaving it off.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Monday, August 31, 2015 5:35 AM
To: Ben Wilson <ben.wilson at digicert.com>; validation at cabforum.org
Subject: RE: Authorized Port List

 

sip is above 1000, is that one necessary or could we omit that and let a
strong proponent that uses it today request that it be added?

 

Other than that, sure, it?s a short list and we can let the public list
discuss the pros/cons of the entries.

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Monday, August 31, 2015 7:31 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

What about this reduced list?

 


Authorized Ports

Not SSL/TLS

SSL/TLS

	

 

 

 

	

ftp

20-21

989-990

	

ssh

22

 

	

telnet

23

992

	

smtp

25, 587

465

	

http

80

443

	

pop

110

995

	

nntp

119

563

	

imap

143

993

	

irc

194

994

	

ldap

389

636

	

sip

5060

5061

	
				

Ports that won't be included

 

		

sftp

115

		

active-directory

445

		

rfs

556

		

filemaker

591

		

rpc-over-http

593

		

ieee-mms-ssl

695

		

kerberos

749-752

		

brocade-ssl

898

		

vmware

901-904

		

ibm

1364

		

c-panel

2083

		
				

 

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Monday, August 31, 2015 5:07 AM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: Re: [cabf_validation] Authorized Port List

 

My thought is that if an SSL certificate can be installed for the services
listed below, then the proper way to configure the server (from a security
perspective) is to lock down all other ports and only allow the correct type
of traffic through.  For example, an IMAP server would have ports 143 and
993 open and then once the certificate is installed port 143 would forward
to port 993.  I agree that the list can be pared down (but other ports may
need to be added ? I didn?t include port 143 in my list), but I?m waiting to
hear from someone more knowledgeable than I on this.  I think we need to
reach outside the Validation Working Group for an answer.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Friday, August 28, 2015 1:07 PM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

Some CAs have very strict rules about where the random number can go and
they request the customer to place it there.  If others put it anywhere,
then I guess they will need to provide a long list like you did or recommend
that we not restrict this to a specific set of ports.

 

Doug

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Friday, August 28, 2015 2:45 PM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

It's not about what CAs want.  It's about what a customer might want.

  _____  

From: Doug Beattie <mailto:doug.beattie at globalsign.com> 
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson <mailto:ben.wilson at digicert.com> ; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

Ben,

 

Do you think a CA needs to use all of these ports when attempting to
validate a Random value in the .well-known directory on an Authorized
Domain?  It seems unlikely Kerberos, sip and many others would be used for
that purpose.

 

I suggest CAs add to the short list in Kirk?s proposal with ones they use
and need to be present.  If others need to be added in the future that can
be another ballot (i.e., start small and add as needed).

 

Doug

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Authorized Port List

 

What about this list as something to review?  It?s pulled from a review of
this:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 

 

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465
(smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593
(rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos),
898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992
(telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel),
2087 (webhost), 2096 (cpanel), 5060-5061 (sip)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150831/d50e0231/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/20150831/d50e0231/attachment-0001.bin 

From ben.wilson at digicert.com  Mon Aug 31 04:47:00 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Mon, 31 Aug 2015 11:47:00 +0000
Subject: [cabf_validation] Authorized Port List
In-Reply-To: <4713e22a0b22445597c373b47f766be5@EX2.corp.digicert.com>
References: <ac516ab2262644ea977a550f3ae52c13@EX2.corp.digicert.com>,
	<SG2PR03MB0666B091BB954670764BA999F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<de888f44b75241089b727715867677f9@EX2.corp.digicert.com>
	<SG2PR03MB0666376671EDFE5C6BC3AC65F06E0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<44d3445e10f145bd8c9cc892fbad7dd6@EX2.corp.digicert.com>
	<8fc03e0e681c41fc983e4d5d88311e11@EX2.corp.digicert.com>
	<SG2PR03MB06663BED9AE978B343324F2BF06B0@SG2PR03MB0666.apcprd03.prod.outlook.com>
	<4713e22a0b22445597c373b47f766be5@EX2.corp.digicert.com>
Message-ID: <1bc3d65daccd4407a55a91c67e046fb4@EX2.corp.digicert.com>

I?m not sure what people think about this list, but here is one where I
included port 24 (private mail) and 991 (network news) because they were
consecutive within a series below ? 

?20-25, 80, 110, 119, 143, 194, 389, 443, 465, 563, 587, 636, 989-995?

 

From: validation-bounces at cabforum.org
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Monday, August 31, 2015 5:37 AM
To: Doug Beattie <doug.beattie at globalsign.com>; validation at cabforum.org
Subject: Re: [cabf_validation] Authorized Port List

 

I?m fine with leaving it off.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Monday, August 31, 2015 5:35 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

sip is above 1000, is that one necessary or could we omit that and let a
strong proponent that uses it today request that it be added?

 

Other than that, sure, it?s a short list and we can let the public list
discuss the pros/cons of the entries.

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Monday, August 31, 2015 7:31 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

What about this reduced list?

 


Authorized Ports

Not SSL/TLS

SSL/TLS

	

 

 

 

	

ftp

20-21

989-990

	

ssh

22

 

	

telnet

23

992

	

smtp

25, 587

465

	

http

80

443

	

pop

110

995

	

nntp

119

563

	

imap

143

993

	

irc

194

994

	

ldap

389

636

	

sip

5060

5061

	
				

Ports that won't be included

 

		

sftp

115

		

active-directory

445

		

rfs

556

		

filemaker

591

		

rpc-over-http

593

		

ieee-mms-ssl

695

		

kerberos

749-752

		

brocade-ssl

898

		

vmware

901-904

		

ibm

1364

		

c-panel

2083

		
				

 

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Monday, August 31, 2015 5:07 AM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: Re: [cabf_validation] Authorized Port List

 

My thought is that if an SSL certificate can be installed for the services
listed below, then the proper way to configure the server (from a security
perspective) is to lock down all other ports and only allow the correct type
of traffic through.  For example, an IMAP server would have ports 143 and
993 open and then once the certificate is installed port 143 would forward
to port 993.  I agree that the list can be pared down (but other ports may
need to be added ? I didn?t include port 143 in my list), but I?m waiting to
hear from someone more knowledgeable than I on this.  I think we need to
reach outside the Validation Working Group for an answer.

 

From: Doug Beattie [mailto:doug.beattie at globalsign.com] 
Sent: Friday, August 28, 2015 1:07 PM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >;
validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

Some CAs have very strict rules about where the random number can go and
they request the customer to place it there.  If others put it anywhere,
then I guess they will need to provide a long list like you did or recommend
that we not restrict this to a specific set of ports.

 

Doug

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Friday, August 28, 2015 2:45 PM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

 

It's not about what CAs want.  It's about what a customer might want.

  _____  

From: Doug Beattie <mailto:doug.beattie at globalsign.com> 
Sent: ?8/?28/?2015 11:26 AM
To: Ben Wilson <mailto:ben.wilson at digicert.com> ; validation at cabforum.org
<mailto:validation at cabforum.org> 
Subject: RE: Authorized Port List

Ben,

 

Do you think a CA needs to use all of these ports when attempting to
validate a Random value in the .well-known directory on an Authorized
Domain?  It seems unlikely Kerberos, sip and many others would be used for
that purpose.

 

I suggest CAs add to the short list in Kirk?s proposal with ones they use
and need to be present.  If others need to be added in the future that can
be another ballot (i.e., start small and add as needed).

 

Doug

 

From: validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org>
[mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 28, 2015 2:11 PM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Authorized Port List

 

What about this list as something to review?  It?s pulled from a review of
this:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 

 

22 (ssh), 25 (smtp), 80 (http), 109-110 (pop), 115 (sftp), 443 (https), 465
(smtps), 556 (rfs), 563 (nntps), 587 (smtp), 591 (filemaker), 593
(rpc-over-http), 636 (ldaps), 695 (ieee-mms-ssl), sip, 749-752 (kerberos),
898 (brocade-ssl), 901-904 (vmware), 911 (nca), 989-990 (ftps), 992
(telnets), 993 (imaps), 994 (ircs), 995 (pops), 1364 (ibm), 2083 (cpanel),
2087 (webhost), 2096 (cpanel), 5060-5061 (sip)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150831/6828f769/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/20150831/6828f769/attachment-0001.bin