From kirk_hall at trendmicro.com  Tue Sep  1 08:43:22 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Tue, 1 Sep 2015 15:43:22 +0000
Subject: [cabf_validation] Question on cert validity period for EV certs
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC23A2B@SJDCEXMBX03.us.trendnet.org>

Here is an excerpt from the minutes of the last full Forum con call on Aug. 20 when we discussed possible changes to cert validity periods.  I think it would be fair to say that CAs either supported or did not oppose allowing EV certs to be issued for 3 years (the same as DV and OV certs today), but that there could be resistance from one or more browsers.

There are also potential questions about data validity periods for DV, OV, and EV certs, but I'm not sure that would arise with a ballot to extend EV cert validity periods from 2 years to 3 years.

Question for the Validation Working Group: Do we want to propose a ballot to extend the possible maximum validity period for EV certs to 3 years?

Here are the minutes:


Cert validity periods: Kirk sent out a matrix of the different options that came out of the F2F meeting in Zurich. This was discussed in the validation working group where many different opinions were presented. A consensus which seemed to emerge is that it didn't make sense to reduce EV validity timeframe further and perhaps we should increase it to 3 years to match DV and OV. The WG will finalize their recommendation shortly. Eddy said there are much less EV certificates used so it's easier to switch them out if there were a problem. Hence there shouldn't be objections to raising to 3 years. Ben said Digicert would like to see all the validity periods to be the same, no matter what the length. Bruce also said they prefer 3 year EV. He also asked about the re-validation timeframe. Wayne said we need to attack one piece at a time but also said the validity period of the data is more important than the validity period of the cert. Kirk asked if there were any objections from those on the call about changing EV to 3 years. Mat from Apple said his colleague Geoff may have some issues with that. Kirk said the Validation WG will put something out on the mailing list for discussion.


<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/20150901/1e074185/attachment.html 

From doug.beattie at globalsign.com  Tue Sep  1 08:48:37 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Tue, 1 Sep 2015 15:48:37 +0000
Subject: [cabf_validation] Question on cert validity period for EV certs
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC23A2B@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC23A2B@SJDCEXMBX03.us.trendnet.org>
Message-ID: <SG2PR03MB0666C44FCB332CCC1FEA7695F06A0@SG2PR03MB0666.apcprd03.prod.outlook.com>

It?s only worth it if we think there is a chance of it passing.  Google will say no, do we understand the other Brower views on the topic?  If they are all going to reject it, let?s spend the time doing something else?.

Doug

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Tuesday, September 1, 2015 11:43 AM
To: validation at cabforum.org
Subject: [cabf_validation] Question on cert validity period for EV certs

Here is an excerpt from the minutes of the last full Forum con call on Aug. 20 when we discussed possible changes to cert validity periods.  I think it would be fair to say that CAs either supported or did not oppose allowing EV certs to be issued for 3 years (the same as DV and OV certs today), but that there could be resistance from one or more browsers.

There are also potential questions about data validity periods for DV, OV, and EV certs, but I?m not sure that would arise with a ballot to extend EV cert validity periods from 2 years to 3 years.

Question for the Validation Working Group: Do we want to propose a ballot to extend the possible maximum validity period for EV certs to 3 years?

Here are the minutes:


Cert validity periods: Kirk sent out a matrix of the different options that came out of the F2F meeting in Zurich. This was discussed in the validation working group where many different opinions were presented. A consensus which seemed to emerge is that it didn?t make sense to reduce EV validity timeframe further and perhaps we should increase it to 3 years to match DV and OV. The WG will finalize their recommendation shortly. Eddy said there are much less EV certificates used so it?s easier to switch them out if there were a problem. Hence there shouldn?t be objections to raising to 3 years. Ben said Digicert would like to see all the validity periods to be the same, no matter what the length. Bruce also said they prefer 3 year EV. He also asked about the re-validation timeframe. Wayne said we need to attack one piece at a time but also said the validity period of the data is more important than the validity period of the cert. Kirk asked if there were any objections from those on the call about changing EV to 3 years. Mat from Apple said his colleague Geoff may have some issues with that. Kirk said the Validation WG will put something out on the mailing list for discussion.




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/20150901/0b8cf7c6/attachment-0001.html 

From bruce.morton at entrust.com  Thu Sep  3 08:56:41 2015
From: bruce.morton at entrust.com (Bruce Morton)
Date: Thu, 3 Sep 2015 15:56:41 +0000
Subject: [cabf_validation] Question on cert validity period for EV certs
In-Reply-To: <SG2PR03MB0666C44FCB332CCC1FEA7695F06A0@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC23A2B@SJDCEXMBX03.us.trendnet.org>
	<SG2PR03MB0666C44FCB332CCC1FEA7695F06A0@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <452C99D20750E74083DBA441FF932385E80192B6@SOTTEXCH10.corp.ad.entrust.com>

My observation is the ballot would be the majority of the browsers would vote No.

Another suggestion would to increase the EV 13 month re-validate period to 27 months, which would be the same as the maximum validity period. This would make this requirement consistent with DV/OV where both the maximum validity period and the re-validate period are the same at 39 months.

The benefit would be to reduce cost of EV certificates.

Bruce.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Tuesday, September 1, 2015 11:49 AM
To: kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Question on cert validity period for EV certs

It?s only worth it if we think there is a chance of it passing.  Google will say no, do we understand the other Brower views on the topic?  If they are all going to reject it, let?s spend the time doing something else?.

Doug

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: Tuesday, September 1, 2015 11:43 AM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Question on cert validity period for EV certs

Here is an excerpt from the minutes of the last full Forum con call on Aug. 20 when we discussed possible changes to cert validity periods.  I think it would be fair to say that CAs either supported or did not oppose allowing EV certs to be issued for 3 years (the same as DV and OV certs today), but that there could be resistance from one or more browsers.

There are also potential questions about data validity periods for DV, OV, and EV certs, but I?m not sure that would arise with a ballot to extend EV cert validity periods from 2 years to 3 years.

Question for the Validation Working Group: Do we want to propose a ballot to extend the possible maximum validity period for EV certs to 3 years?

Here are the minutes:


Cert validity periods: Kirk sent out a matrix of the different options that came out of the F2F meeting in Zurich. This was discussed in the validation working group where many different opinions were presented. A consensus which seemed to emerge is that it didn?t make sense to reduce EV validity timeframe further and perhaps we should increase it to 3 years to match DV and OV. The WG will finalize their recommendation shortly. Eddy said there are much less EV certificates used so it?s easier to switch them out if there were a problem. Hence there shouldn?t be objections to raising to 3 years. Ben said Digicert would like to see all the validity periods to be the same, no matter what the length. Bruce also said they prefer 3 year EV. He also asked about the re-validation timeframe. Wayne said we need to attack one piece at a time but also said the validity period of the data is more important than the validity period of the cert. Kirk asked if there were any objections from those on the call about changing EV to 3 years. Mat from Apple said his colleague Geoff may have some issues with that. Kirk said the Validation WG will put something out on the mailing list for discussion.




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/20150903/e2e2a34c/attachment.html 

From kirk_hall at trendmicro.com  Wed Sep  9 14:28:28 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Wed, 9 Sep 2015 21:28:28 +0000
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept. 10
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC34E0F@SJDCEXMBX03.us.trendnet.org>

For our VWG call tomorrow, I'm circulating the most recent draft of our domain validation ballot.  There is no change from the draft circulated for our Forum call last week.

I pasted in the draft Minutes on this issue from last week's call.  At this point, it appears the only remaining work relates to the definition of Authorized Ports.  We asked everyone on the call to forward their ideas.

Ben re-posted his original list - see attachment.  Tim H. suggested removeing TelNet as obsolete and insecure.  Ryan suggested any port greater than 1024 be prohibited, and had other comments.  See attached.  Gerv agreed with the 1024 limit, and suggested approvals for an SSL certificate should not be through a port which was well-known for not being SSL.  That's all the feedback we got.

So if I read this all correctly, here is what is left of Ben's 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


Our current placeholder definition for Authorized Domains is as follows - which of these do we keep?

Authorized Port: One of the following ports:  80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

Can we try to finish this issue on our call tomorrow?

*****

DRAFT CABF CALL MINUTES

8.            Domain Validation Ballot - Discussion of Draft

Kirk noted that the Validation Working Group had completed a draft ballot with changes to BR 3.2.2.4 concerning domain validation methods, and wanted initial input from Forum members.  He started by asking for a response to the open issues noted in the draft that was circulated.

The first open issue was the question of Authorized Ports.  The working group recognized that allowing use of any and all ports for a practical demonstration method of domain validation presented security risks, and was looking to limit the number of ports that could be used.  The draft ballot includes a definition of Authorized Ports, with a short list of off the possible ports to be used.  However, the working group was not certain that this list was correct.

Jeremy stated that he initially liked the idea of restricting CAs to specific ports, but changed his mind.  He noted that the draft ballot imposed other safeguards for domain validation by practical demonstrations, such as limiting web pages to the well-known directory location and requiring a random value unknown to the customer, so he now believed that there was no need to limit methods to Authorized Ports.  If we are going to limit to Authorized Ports, we need a more comprehensive list, and should get data from all CAs - the current list is too short.

Ryan noted that he was one of the original proponents of limiting Authorized Ports, and stated that some CAs are allowing any ports to be used and that successful hacks have occurred.  He did not feel that the other limitations, such as use of a well-known directory and random value, were sufficient to avoid the security risks if any port is allowed for a practical demonstration.

Ben stated he previously posted a list of 30 to 40 ports to the Validation Working Group, but the group had not reached any consensus.  Kirk asked Ben to repost his list to the Public list for comments and suggestions, and Ben agreed.

Kirk stated the Validation Working Group would take this information into consideration at its meeting next week, then bring the draft ballot back as a real ballot for voting.



<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/20150909/60db4292/attachment-0001.html 
-------------- next part --------------
An embedded message was scrubbed...
From: Ben Wilson <ben.wilson at digicert.com>
Subject: [cabfpub] "Authorized Port"
Date: Thu, 3 Sep 2015 17:06:08 +0000
Size: 45942
Url: https://cabforum.org/pipermail/validation/attachments/20150909/60db4292/attachment-0002.mht 
-------------- next part --------------
An embedded message was scrubbed...
From: Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] "Authorized Port"
Date: Thu, 3 Sep 2015 18:11:05 +0000
Size: 54067
Url: https://cabforum.org/pipermail/validation/attachments/20150909/60db4292/attachment-0003.mht 

From kirk_hall at trendmicro.com  Wed Sep  9 14:29:42 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Wed, 9 Sep 2015 21:29:42 +0000
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept.
	10
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC34E63@SJDCEXMBX03.us.trendnet.org>

This time with most recent draft of ballot.
From: Kirk Hall (RD-US)
Sent: Wednesday, September 09, 2015 2:28 PM
To: validation at cabforum.org
Subject: Validation Working Group call - Thurs. Sept. 10
Importance: High

For our VWG call tomorrow, I'm circulating the most recent draft of our domain validation ballot.  There is no change from the draft circulated for our Forum call last week.

I pasted in the draft Minutes on this issue from last week's call.  At this point, it appears the only remaining work relates to the definition of Authorized Ports.  We asked everyone on the call to forward their ideas.

Ben re-posted his original list - see attachment.  Tim H. suggested removeing TelNet as obsolete and insecure.  Ryan suggested any port greater than 1024 be prohibited, and had other comments.  See attached.  Gerv agreed with the 1024 limit, and suggested approvals for an SSL certificate should not be through a port which was well-known for not being SSL.  That's all the feedback we got.

So if I read this all correctly, here is what is left of Ben's 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


Our current placeholder definition for Authorized Domains is as follows - which of these do we keep?

Authorized Port: One of the following ports:  80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

Can we try to finish this issue on our call tomorrow?

*****

DRAFT CABF CALL MINUTES

8.            Domain Validation Ballot - Discussion of Draft

Kirk noted that the Validation Working Group had completed a draft ballot with changes to BR 3.2.2.4 concerning domain validation methods, and wanted initial input from Forum members.  He started by asking for a response to the open issues noted in the draft that was circulated.

The first open issue was the question of Authorized Ports.  The working group recognized that allowing use of any and all ports for a practical demonstration method of domain validation presented security risks, and was looking to limit the number of ports that could be used.  The draft ballot includes a definition of Authorized Ports, with a short list of off the possible ports to be used.  However, the working group was not certain that this list was correct.

Jeremy stated that he initially liked the idea of restricting CAs to specific ports, but changed his mind.  He noted that the draft ballot imposed other safeguards for domain validation by practical demonstrations, such as limiting web pages to the well-known directory location and requiring a random value unknown to the customer, so he now believed that there was no need to limit methods to Authorized Ports.  If we are going to limit to Authorized Ports, we need a more comprehensive list, and should get data from all CAs - the current list is too short.

Ryan noted that he was one of the original proponents of limiting Authorized Ports, and stated that some CAs are allowing any ports to be used and that successful hacks have occurred.  He did not feel that the other limitations, such as use of a well-known directory and random value, were sufficient to avoid the security risks if any port is allowed for a practical demonstration.

Ben stated he previously posted a list of 30 to 40 ports to the Validation Working Group, but the group had not reached any consensus.  Kirk asked Ben to repost his list to the Public list for comments and suggestions, and Ben agreed.

Kirk stated the Validation Working Group would take this information into consideration at its meeting next week, then bring the draft ballot back as a real ballot for voting.



<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/20150909/f8e18751/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 9-1-2015 (for CABF consideration).pdf
Type: application/pdf
Size: 383278 bytes
Desc: New Domain Validation Draft 9-1-2015 (for CABF
 consideration).pdf
Url : https://cabforum.org/pipermail/validation/attachments/20150909/f8e18751/attachment-0001.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 9-1-2015 (for CABF consideration).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 34986 bytes
Desc: New Domain Validation Draft 9-1-2015 (for CABF
 consideration).docx
Url : https://cabforum.org/pipermail/validation/attachments/20150909/f8e18751/attachment-0001.bin 

From doug.beattie at globalsign.com  Thu Sep 10 04:06:40 2015
From: doug.beattie at globalsign.com (Doug Beattie)
Date: Thu, 10 Sep 2015 11:06:40 +0000
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept.
	10
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC34E0F@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC34E0F@SJDCEXMBX03.us.trendnet.org>
Message-ID: <SG2PR03MB06669C6518A761190D45A9F2F0510@SG2PR03MB0666.apcprd03.prod.outlook.com>

Kirk,
Gerv said this regarding the current option 7:

?        Speaking for us, even if I thought these changes were good, I don't think I'd want to vote in favour of removing that option until the patent process had completed.
How does this impact our strategy, if at all?
From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Wednesday, September 9, 2015 5:28 PM
To: validation at cabforum.org
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept. 10
Importance: High

For our VWG call tomorrow, I?m circulating the most recent draft of our domain validation ballot.  There is no change from the draft circulated for our Forum call last week.

I pasted in the draft Minutes on this issue from last week?s call.  At this point, it appears the only remaining work relates to the definition of Authorized Ports.  We asked everyone on the call to forward their ideas.

Ben re-posted his original list ? see attachment.  Tim H. suggested removeing TelNet as obsolete and insecure.  Ryan suggested any port greater than 1024 be prohibited, and had other comments.  See attached.  Gerv agreed with the 1024 limit, and suggested approvals for an SSL certificate should not be through a port which was well-known for not being SSL.  That?s all the feedback we got.

So if I read this all correctly, here is what is left of Ben?s 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


Our current placeholder definition for Authorized Domains is as follows ? which of these do we keep?

Authorized Port: One of the following ports:  80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

Can we try to finish this issue on our call tomorrow?

*****

DRAFT CABF CALL MINUTES

8.            Domain Validation Ballot - Discussion of Draft

Kirk noted that the Validation Working Group had completed a draft ballot with changes to BR 3.2.2.4 concerning domain validation methods, and wanted initial input from Forum members.  He started by asking for a response to the open issues noted in the draft that was circulated.

The first open issue was the question of Authorized Ports.  The working group recognized that allowing use of any and all ports for a practical demonstration method of domain validation presented security risks, and was looking to limit the number of ports that could be used.  The draft ballot includes a definition of Authorized Ports, with a short list of off the possible ports to be used.  However, the working group was not certain that this list was correct.

Jeremy stated that he initially liked the idea of restricting CAs to specific ports, but changed his mind.  He noted that the draft ballot imposed other safeguards for domain validation by practical demonstrations, such as limiting web pages to the well-known directory location and requiring a random value unknown to the customer, so he now believed that there was no need to limit methods to Authorized Ports.  If we are going to limit to Authorized Ports, we need a more comprehensive list, and should get data from all CAs ? the current list is too short.

Ryan noted that he was one of the original proponents of limiting Authorized Ports, and stated that some CAs are allowing any ports to be used and that successful hacks have occurred.  He did not feel that the other limitations, such as use of a well-known directory and random value, were sufficient to avoid the security risks if any port is allowed for a practical demonstration.

Ben stated he previously posted a list of 30 to 40 ports to the Validation Working Group, but the group had not reached any consensus.  Kirk asked Ben to repost his list to the Public list for comments and suggestions, and Ben agreed.

Kirk stated the Validation Working Group would take this information into consideration at its meeting next week, then bring the draft ballot back as a real ballot for voting.





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/20150910/8f1ea247/attachment-0001.html 

From ben.wilson at digicert.com  Thu Sep 10 04:12:40 2015
From: ben.wilson at digicert.com (Ben Wilson)
Date: Thu, 10 Sep 2015 11:12:40 +0000
Subject: [cabf_validation] Validation Working Group call - Thurs.
	Sept.	10
In-Reply-To: <SG2PR03MB06669C6518A761190D45A9F2F0510@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC34E0F@SJDCEXMBX03.us.trendnet.org>
	<SG2PR03MB06669C6518A761190D45A9F2F0510@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <162124c58f064a0ca9974599a6b3c77a@EX2.corp.digicert.com>

>From what I took away from the last PAG call, we should proceed on multiple parallel paths without waiting for one solution or letting one course of action derail progress.  Not sure I have a specific answer for you, though.

 

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Thursday, September 10, 2015 5:07 AM
To: kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Validation Working Group call - Thurs. Sept. 10

 

Kirk,

Gerv said this regarding the current option 7:

*        Speaking for us, even if I thought these changes were good, I don't think I'd want to vote in favour of removing that option until the patent process had completed.

How does this impact our strategy, if at all?

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, September 9, 2015 5:28 PM
To: validation at cabforum.org <mailto:validation at cabforum.org> 
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept. 10
Importance: High

 

For our VWG call tomorrow, I?m circulating the most recent draft of our domain validation ballot.  There is no change from the draft circulated for our Forum call last week.

 

I pasted in the draft Minutes on this issue from last week?s call.  At this point, it appears the only remaining work relates to the definition of Authorized Ports.  We asked everyone on the call to forward their ideas.

 

Ben re-posted his original list ? see attachment.  Tim H. suggested removeing TelNet as obsolete and insecure.  Ryan suggested any port greater than 1024 be prohibited, and had other comments.  See attached.  Gerv agreed with the 1024 limit, and suggested approvals for an SSL certificate should not be through a port which was well-known for not being SSL.  That?s all the feedback we got.

 

So if I read this all correctly, here is what is left of Ben?s 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

 

Our current placeholder definition for Authorized Domains is as follows ? which of these do we keep?

 

Authorized Port: One of the following ports:  80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

 

Can we try to finish this issue on our call tomorrow?

 

*****

 

DRAFT CABF CALL MINUTES

 

8.            Domain Validation Ballot - Discussion of Draft

 

Kirk noted that the Validation Working Group had completed a draft ballot with changes to BR 3.2.2.4 concerning domain validation methods, and wanted initial input from Forum members.  He started by asking for a response to the open issues noted in the draft that was circulated.

 

The first open issue was the question of Authorized Ports.  The working group recognized that allowing use of any and all ports for a practical demonstration method of domain validation presented security risks, and was looking to limit the number of ports that could be used.  The draft ballot includes a definition of Authorized Ports, with a short list of off the possible ports to be used.  However, the working group was not certain that this list was correct.

 

Jeremy stated that he initially liked the idea of restricting CAs to specific ports, but changed his mind.  He noted that the draft ballot imposed other safeguards for domain validation by practical demonstrations, such as limiting web pages to the well-known directory location and requiring a random value unknown to the customer, so he now believed that there was no need to limit methods to Authorized Ports.  If we are going to limit to Authorized Ports, we need a more comprehensive list, and should get data from all CAs ? the current list is too short.

 

Ryan noted that he was one of the original proponents of limiting Authorized Ports, and stated that some CAs are allowing any ports to be used and that successful hacks have occurred.  He did not feel that the other limitations, such as use of a well-known directory and random value, were sufficient to avoid the security risks if any port is allowed for a practical demonstration.

 

Ben stated he previously posted a list of 30 to 40 ports to the Validation Working Group, but the group had not reached any consensus.  Kirk asked Ben to repost his list to the Public list for comments and suggestions, and Ben agreed.

 

Kirk stated the Validation Working Group would take this information into consideration at its meeting next week, then bring the draft ballot back as a real ballot for voting.

 

 



 
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/20150910/1ce2f343/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/20150910/1ce2f343/attachment-0001.bin 

From kirk_hall at trendmicro.com  Thu Sep 10 06:51:05 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Thu, 10 Sep 2015 13:51:05 +0000
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept.
	10
In-Reply-To: <SG2PR03MB06669C6518A761190D45A9F2F0510@SG2PR03MB0666.apcprd03.prod.outlook.com>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC34E0F@SJDCEXMBX03.us.trendnet.org>
	<SG2PR03MB06669C6518A761190D45A9F2F0510@SG2PR03MB0666.apcprd03.prod.outlook.com>
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC35C9E@SJDCEXMBX03.us.trendnet.org>

While the PAG group is working on a proposal, it won?t necessarily solve all the problems with our current IPR agreement, and it could take months to develop a broader solution to that.  In fact, we may never have a broader solution.  So my own feeling is we just keep going with our work on this.  I suppose the full Forum can choose not to adopt this ballot when we come to a vote.

From: Doug Beattie [mailto:doug.beattie at globalsign.com]
Sent: Thursday, September 10, 2015 4:07 AM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: Validation Working Group call - Thurs. Sept. 10

Kirk,
Gerv said this regarding the current option 7:

?        Speaking for us, even if I thought these changes were good, I don't think I'd want to vote in favour of removing that option until the patent process had completed.
How does this impact our strategy, if at all?
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, September 9, 2015 5:28 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Validation Working Group call - Thurs. Sept. 10
Importance: High

For our VWG call tomorrow, I?m circulating the most recent draft of our domain validation ballot.  There is no change from the draft circulated for our Forum call last week.

I pasted in the draft Minutes on this issue from last week?s call.  At this point, it appears the only remaining work relates to the definition of Authorized Ports.  We asked everyone on the call to forward their ideas.

Ben re-posted his original list ? see attachment.  Tim H. suggested removeing TelNet as obsolete and insecure.  Ryan suggested any port greater than 1024 be prohibited, and had other comments.  See attached.  Gerv agreed with the 1024 limit, and suggested approvals for an SSL certificate should not be through a port which was well-known for not being SSL.  That?s all the feedback we got.

So if I read this all correctly, here is what is left of Ben?s 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


Our current placeholder definition for Authorized Domains is as follows ? which of these do we keep?

Authorized Port: One of the following ports:  80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

Can we try to finish this issue on our call tomorrow?

*****

DRAFT CABF CALL MINUTES

8.            Domain Validation Ballot - Discussion of Draft

Kirk noted that the Validation Working Group had completed a draft ballot with changes to BR 3.2.2.4 concerning domain validation methods, and wanted initial input from Forum members.  He started by asking for a response to the open issues noted in the draft that was circulated.

The first open issue was the question of Authorized Ports.  The working group recognized that allowing use of any and all ports for a practical demonstration method of domain validation presented security risks, and was looking to limit the number of ports that could be used.  The draft ballot includes a definition of Authorized Ports, with a short list of off the possible ports to be used.  However, the working group was not certain that this list was correct.

Jeremy stated that he initially liked the idea of restricting CAs to specific ports, but changed his mind.  He noted that the draft ballot imposed other safeguards for domain validation by practical demonstrations, such as limiting web pages to the well-known directory location and requiring a random value unknown to the customer, so he now believed that there was no need to limit methods to Authorized Ports.  If we are going to limit to Authorized Ports, we need a more comprehensive list, and should get data from all CAs ? the current list is too short.

Ryan noted that he was one of the original proponents of limiting Authorized Ports, and stated that some CAs are allowing any ports to be used and that successful hacks have occurred.  He did not feel that the other limitations, such as use of a well-known directory and random value, were sufficient to avoid the security risks if any port is allowed for a practical demonstration.

Ben stated he previously posted a list of 30 to 40 ports to the Validation Working Group, but the group had not reached any consensus.  Kirk asked Ben to repost his list to the Public list for comments and suggestions, and Ben agreed.

Kirk stated the Validation Working Group would take this information into consideration at its meeting next week, then bring the draft ballot back as a real ballot for voting.





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/20150910/2808f31e/attachment-0001.html 

From kirk_hall at trendmicro.com  Wed Sep 23 09:27:47 2015
From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com)
Date: Wed, 23 Sep 2015 16:27:47 +0000
Subject: [cabf_validation] Domain Validation Ballot discussion
Message-ID: <EF70381B2D29784EA4FC66042BE81EAF5AC60E8F@SJDCEXMBX03.us.trendnet.org>

I was able to listen to the domain validation ballot discussion from the CABF meeting last week.  Jeremy, you were in favor of delaying further action until after the PAG meeting last Friday.  How did the PAG meeting affect your point of view?  Should we move forward with the ballot now?  (I saw the revised PAG memo that will go to the Members, and it looks good to me.)

You made one point on the CABF call - you were concerned that if we proceed with the ballot now (and eliminate "any other method"), and then it turns out that all validation methods are covered by (currently undisclosed) patents, we could be in trouble.  I don't think that's a realistic threat for a couple of reasons.

First, Methods 1-6 remain virtually unchanged, and have been used for years without anyone claiming IP on them.  It's pretty unlikely IP claims will pop up after "any other method" is dropped.

Second, even if Methods 7-9 are covered by IP, no one has to use those methods - we can stick with Methods 1-6 as in the past.  We may get voluntary disclosure based on the PAG, and maybe IP holders will tell the Forum they will not block use by others - we will see.

As to Methods 7 and 8 in particular - it's hard to see how anyone could have enforceable IP that relates to adding a Random Value to a DNS record, or controlling an IP address for an A or AAAA record...

Finally, suppose one or more companies do assert broad IP rights over one or many validation methods?  If it's truly a crisis for CAs, the Forum can respond very quickly (a ballot can be completed in about two weeks) either to add back "any other method" so CAs can make changes to avoid infringement, or even better, can modify the validation method where IP is asserted to be broader and allow non-infringing workarounds by CAs to avoid the problem.  (That's the function that some people have assigned to current Method 7 - any other method - something that allows a CA to modify a method to avoid infringement if an infringement claim pops up.  I don't think that situation has ever arisen.)  We can also add other validation methods by future ballot as well.

There seems to be no real opposition to the ballot as drafted, and we won't really have a complete and binding solution to our IPR situation for months - so I'd say let's proceed with the ballot in the near future.

We can discuss on our call tomorrow.

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/20150923/4970ff81/attachment.html 

From jeremy.rowley at digicert.com  Wed Sep 23 09:54:31 2015
From: jeremy.rowley at digicert.com (Jeremy Rowley)
Date: Wed, 23 Sep 2015 16:54:31 +0000
Subject: [cabf_validation] Domain Validation Ballot discussion
In-Reply-To: <EF70381B2D29784EA4FC66042BE81EAF5AC60E8F@SJDCEXMBX03.us.trendnet.org>
References: <EF70381B2D29784EA4FC66042BE81EAF5AC60E8F@SJDCEXMBX03.us.trendnet.org>
Message-ID: <bbe9f4a2be004df78d667ca2810356de@EX2.corp.digicert.com>

Sounds good. I?m not opposed to proceeding with the ballot. I am opposed to proceeding with the ballot with the ?any other method? language included.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Wednesday, September 23, 2015 10:28 AM
To: validation at cabforum.org
Subject: [cabf_validation] Domain Validation Ballot discussion

I was able to listen to the domain validation ballot discussion from the CABF meeting last week.  Jeremy, you were in favor of delaying further action until after the PAG meeting last Friday.  How did the PAG meeting affect your point of view?  Should we move forward with the ballot now?  (I saw the revised PAG memo that will go to the Members, and it looks good to me.)

You made one point on the CABF call ? you were concerned that if we proceed with the ballot now (and eliminate ?any other method?), and then it turns out that all validation methods are covered by (currently undisclosed) patents, we could be in trouble.  I don?t think that?s a realistic threat for a couple of reasons.

First, Methods 1-6 remain virtually unchanged, and have been used for years without anyone claiming IP on them.  It?s pretty unlikely IP claims will pop up after ?any other method? is dropped.

Second, even if Methods 7-9 are covered by IP, no one has to use those methods ? we can stick with Methods 1-6 as in the past.  We may get voluntary disclosure based on the PAG, and maybe IP holders will tell the Forum they will not block use by others ? we will see.

As to Methods 7 and 8 in particular ? it?s hard to see how anyone could have enforceable IP that relates to adding a Random Value to a DNS record, or controlling an IP address for an A or AAAA record?

Finally, suppose one or more companies do assert broad IP rights over one or many validation methods?  If it?s truly a crisis for CAs, the Forum can respond very quickly (a ballot can be completed in about two weeks) either to add back ?any other method? so CAs can make changes to avoid infringement, or even better, can modify the validation method where IP is asserted to be broader and allow non-infringing workarounds by CAs to avoid the problem.  (That?s the function that some people have assigned to current Method 7 ? any other method ? something that allows a CA to modify a method to avoid infringement if an infringement claim pops up.  I don?t think that situation has ever arisen.)  We can also add other validation methods by future ballot as well.

There seems to be no real opposition to the ballot as drafted, and we won?t really have a complete and binding solution to our IPR situation for months ? so I?d say let?s proceed with the ballot in the near future.

We can discuss on our call tomorrow.

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/20150923/400eedae/attachment.html 

From rbarnes at mozilla.com  Thu Sep 24 07:59:20 2015
From: rbarnes at mozilla.com (Richard Barnes)
Date: Thu, 24 Sep 2015 07:59:20 -0700
Subject: [cabf_validation] Two minor changes
Message-ID: <CAOAcki9CVzmYFB1eCSuRzacBsqdP-N2qybY7kQMvfU24gWw-Sg@mail.gmail.com>

Hey all,

After a read-through of the ballot with the IETF ACME work in mind, I would
like to propose two minor changes to the current draft text:

Proposal 1: In part L
OLD: "by the Applicant requesting and then installing a Test Certificate
issued by the CA"
NEW: "by the Applicant requesting and then installing a Test Certificate
issued by the CA, or installing a Test Certificate containing a Random
Value or Request Token"

This liberalization would cover the DVSNI proposal being considered in
ACME, and seems to offer equivalent protection to the other option.
(Either way the cert contains something specified by the CA.)

Proposal 2: In part H
OLD: "under "/.well-known/validation" directory on an Authorized Domain
Name"
NEW: "under "/.well-known/validation" directory on an Authorized Domain
Name, or any other path under .well-known registered by IANA for this
purpose"

For automated systems like ACME, they're going to want a much more precise
definition of the validation process than what's in this document, and they
may want to use different .well-known paths to indicate different methods
that are all compliant with this section.  Requiring the IANA registration
allows these differences to exist, but in a controlled way.

I think if we can make these two small liberalizations, it will save us
some revision effort down the road as ACME gets its work done.

Thanks,
--Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150924/db749d06/attachment.html