Hi Ayden, These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name. The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser. Best regards, Theo Geurts On 15-8-2016 20:16, Ayden Férdeline wrote:

If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate?

If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money?

The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags?

- Ayden

...

-------- Original Message -------- Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 6:40 PM UTC Time: August 15, 2016 5:40 PM From: Geoffrey_Noakes@symantec.com To: gnso-rds-pdp-wg@icann.org

I’ve attached a use case for WHOIS/RDP.

Thanks…

Geoff

*From:* Lisa Phifer [mailto:lisa@corecom.com] *Sent:* Monday, August 15, 2016 10:37 AM *To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com> *Subject:* RE: Use Case

Hi Geoff, it's <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>>

For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/ <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/>

As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org <mailto:gnso-secs@icann.org> know.

Thanks again Lisa

At 11:19 AM 8/15/2016, Geoffrey Noakes wrote:

Lisa, what is the “WG email list” email address?

*From:* Lisa Phifer [mailto:lisa@corecom.com <mailto:lisa@corecom.com>] *Sent:* Monday, August 15, 2016 10:17 AM *To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com <mailto:Geoffrey_Noakes@symantec.com>> *Subject:* RE: Use Case

Thanks Geoff and welcome back. I hope you had an excellent vacation.

I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda.

In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention.

Best, Lisa

At 11:11 AM 8/15/2016, you wrote:

+Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this

Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS.

I would prefer the August 23 date – I am on jury duty the week of August 29-September 2.

Thanks…

Geoff

From: Gomes, Chuck [ mailto:cgomes@verisign.com <mailto:cgomes@verisign.com>]

Sent: Monday, August 15, 2016 9:53 AM

To: Geoffrey Noakes <Geoffrey_Noakes@symantec.com <mailto:Geoffrey_Noakes@symantec.com>>

Cc: RDS-Leaders-List (gnso-next-gen-rds-lead@icann.org <mailto:gnso-next-gen-rds-lead@icann.org>) <gnso-next-gen-rds-lead@icann.org <mailto:gnso-next-gen-rds-lead@icann.org>>

Subject: Use Case

Geoff,

You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance.

Hope you are having a good vacation.

Chuck

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Hi Ayden, Lets not forget that in terms of protecting user privacy the use of encryption is vital, so I believe this is an important use case. All web server certificates, no matter which flavor of CA is used (from self-signed, to free to high-end) will result in data encryption at the transport layer. While the encryption is the same (assuming properly configured servers/clients) the difference between TLS certs is the level of authentication of the entity the server represents. Its way out of scope to dive deeper into the various CA business models, but search for Domain Validated, Organizational Validated and Extended Validated for more details on some of the various levels of “authentication”. Alex On Aug 15, 2016, at 2:41 PM, Ayden Férdeline <icann@ferdeline.com<mailto:icann@ferdeline.com>> wrote: Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.) - Ayden -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 9:00 PM UTC Time: August 15, 2016 8:00 PM From: gtheo@xs4all.nl<mailto:gtheo@xs4all.nl> To: icann@ferdeline.com<mailto:icann@ferdeline.com>,Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com> gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Hi Ayden, These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name. The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser. Best regards, Theo Geurts On 15-8-2016 20:16, Ayden Férdeline wrote: If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate? If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money? The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags? - Ayden -------- Original Message -------- Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 6:40 PM UTC Time: August 15, 2016 5:40 PM From: Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com> To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> I’ve attached a use case for WHOIS/RDP. Thanks… Geoff From: Lisa Phifer [mailto:lisa@corecom.com] Sent: Monday, August 15, 2016 10:37 AM To: Geoffrey Noakes <Geoffrey_Noakes@symantec.com><mailto:Geoffrey_Noakes@symantec.com> Subject: RE: Use Case Hi Geoff, it's <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/ As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org<mailto:gnso-secs@icann.org> know. Thanks again Lisa At 11:19 AM 8/15/2016, Geoffrey Noakes wrote: Lisa, what is the “WG email list” email address? From: Lisa Phifer [ mailto:lisa@corecom.com] Sent: Monday, August 15, 2016 10:17 AM To: Geoffrey Noakes <Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com>> Subject: RE: Use Case Thanks Geoff and welcome back. I hope you had an excellent vacation. I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda. In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention. Best, Lisa At 11:11 AM 8/15/2016, you wrote: +Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS. I would prefer the August 23 date – I am on jury duty the week of August 29-September 2. Thanks… Geoff From: Gomes, Chuck [ mailto:cgomes@verisign.com] Sent: Monday, August 15, 2016 9:53 AM To: Geoffrey Noakes < Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com>> Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead@icann.org<mailto:gnso-next-gen-rds-lead@icann.org>) < gnso-next-gen-rds-lead@icann.org<mailto:gnso-next-gen-rds-lead@icann.org>> Subject: Use Case Geoff, You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance. Hope you are having a good vacation. Chuck _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

I see that Geoff has provided some actual facts, to replace both your speculation and mine. That should improve everyone's understanding of this use case. I'll let Alex and/or Geoff respond on the difference between various types and levels of certificates, including the difference in value. I don't think anyone but you implied that there's no difference between a free Let's Encrypt certificate and a $399 Symantec certificate, in spite of your attempt to hang that on Alex. A little research shows quite a number of "value added" differences. That said, Let's Encrypt does seem to be quite a disruptive force in the certificate market, but I don't see the relevance of that to our study of this use case. Greg On Mon, Aug 15, 2016 at 6:25 PM, Geoffrey Noakes < Geoffrey_Noakes@symantec.com> wrote:

Ayden, the “types of checks” done for SSL/TLS certs fall into 3 categories:

· DV (domain validation): the most basic form of authentication performed by the CA. It essentially checks to see if the application for a cert has control over the domain for which the cert will be issued.

· OV (organization validation): the CA checks information about the organization (e.g., the company or business entity) that has applied for the cert.

· EV (extra validation): in addition to the OV checks, the CA checks for whether the individual who is applying for the cert is authorized to do so.

The processes for OV and EV authentication is defined by the CA/Browser Forum at https://cabforum.org/extended-validation/.

Netcraft is a third-party organization which monitors the number of publicly-facing SSL/TLS certs. A Netcraft report with data from July 2016 is attached – they saw ~5.5m certificates.

It is good to think of SSL/TLS certs as being like subscriptions – they each have a period of being valid, and they are usually renewed at the end of their periods. I am unaware of any publicly-available data on the variety of periods, but anecdotally, many are annual. Let’s Encrypt uses a 6 month period for theirs, and some are as low as a week (these a unusual).

I am unaware of any report that shows sales data related to SSL/TLS certs – most CAs are either private (and do not report numbers) or are parts of larger organizations (like Symantec, where I work, and do not break out sales numbers at that level). My sense is that the SSL/TLS cert business is less than $1b/year.

Thanks…

Geoff

*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org] *On Behalf Of *Deacon, Alex *Sent:* Monday, August 15, 2016 3:06 PM *To:* Ayden Férdeline <icann@ferdeline.com> *Cc:* gnso-rds-pdp-wg@icann.org

*Subject:* Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP

Hi Ayden,

Lets not forget that in terms of protecting user privacy the use of encryption is vital, so I believe this is an important use case. All web server certificates, no matter which flavor of CA is used (from self-signed, to free to high-end) will result in data encryption at the transport layer. While the encryption is the same (assuming properly configured servers/clients) the difference between TLS certs is the level of authentication of the entity the server represents.

Its way out of scope to dive deeper into the various CA business models, but search for Domain Validated, Organizational Validated and Extended Validated for more details on some of the various levels of “authentication”.

Alex

On Aug 15, 2016, at 2:41 PM, Ayden Férdeline <icann@ferdeline.com> wrote:

Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.)

- Ayden

-------- Original Message --------

Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP

Local Time: August 15, 2016 9:00 PM

UTC Time: August 15, 2016 8:00 PM

From: gtheo@xs4all.nl

To: icann@ferdeline.com,Geoffrey_Noakes@symantec.com

gnso-rds-pdp-wg@icann.org

Hi Ayden,

These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name.

The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser.

Best regards,

Theo Geurts

On 15-8-2016 20:16, Ayden Férdeline wrote:

If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate?

If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money?

The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags?

- Ayden

-------- Original Message --------

Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP

Local Time: August 15, 2016 6:40 PM

UTC Time: August 15, 2016 5:40 PM

From: Geoffrey_Noakes@symantec.com

To: gnso-rds-pdp-wg@icann.org

I’ve attached a use case for WHOIS/RDP.

Thanks…

Geoff

*From:* Lisa Phifer [mailto:lisa@corecom.com <lisa@corecom.com>]

*Sent:* Monday, August 15, 2016 10:37 AM

*To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com> <Geoffrey_Noakes@symantec.com>

*Subject:* RE: Use Case

Hi Geoff, it's <gnso-rds-pdp-wg@icann.org>

For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/

As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org know.

Thanks again

Lisa

At 11:19 AM 8/15/2016, Geoffrey Noakes wrote:

Lisa, what is the “WG email list” email address?

*From:* Lisa Phifer [ mailto:lisa@corecom.com <lisa@corecom.com>]

*Sent:* Monday, August 15, 2016 10:17 AM

*To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com>

*Subject:* RE: Use Case

Thanks Geoff and welcome back. I hope you had an excellent vacation.

I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda.

In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention.

Best, Lisa

At 11:11 AM 8/15/2016, you wrote:

+Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this

Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS.

I would prefer the August 23 date – I am on jury duty the week of August 29-September 2.

Thanks…

Geoff

From: Gomes, Chuck [ mailto:cgomes@verisign.com <cgomes@verisign.com>]

Sent: Monday, August 15, 2016 9:53 AM

To: Geoffrey Noakes < Geoffrey_Noakes@symantec.com>

Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead@icann.org) < gnso-next-gen-rds-lead@icann.org>

Subject: Use Case

Geoff,

You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance.

Hope you are having a good vacation.

Chuck

_______________________________________________

gnso-rds-pdp-wg mailing list

gnso-rds-pdp-wg@icann.org

https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

---------- Forwarded message ---------- From: Mike Prettejohn <mhp@netcraft.com> To: Diana Marin Severino <Diana_Marin_Severino@symantec.com>, Sue Coakley <Sue_Coakley@symantec.com>, Vijay NS <Vijay_NS@symantec.com>, Sonya Perez <Sonya_Perez@symantec.com>, Eric Lipman <Eric_Lipman@symantec.com>, Laura Aviles <Laura_Aviles@symantec.com>, Jeffrey Whale < Jeffrey_Whale@symantec.com>, Alex Wong <Alex_Wong@symantec.com>, Landon Borup <Landon_Borup@symantec.com>, Alain Allen <Alain_Allen@symantec.com>, Frank Agurto-Machado <Frank_Agurto-Machado@symantec.com>, Charlene Mike-Billstrom <Charlene_Mike-Billstrom@symantec.com>, Rick Andrews < Rick_Andrews@symantec.com>, Anna Sampson <Anna_Sampson@symantec.com>, Eiji Yahagi <Eiji_Yahagi@symantec.com>, Tomonori Sato < Tomonori_Sato@symantec.com>, Christiaan De Villiers < Christiaan_DeVilliers@symantec.com>, Dean Coclin <Dean_Coclin@symantec.com>, Hari Veladanda <Hari_Veladanda@symantec.com>, Robert Hoblit < Robert_Hoblit@symantec.com>, Marisa Luke <Marisa_Luke@symantec.com>, Roxane Divol <Roxane_Divol@symantec.com>, Norie Sato < Norie_Sato@symantec.com>, Masato Hayashi <Masato_Hayashi@symantec.com>, DL-VSN-Data Analysis <DL-VSN-DataAnalysis@symantec.com>, Bill Ng < Bill_Ng@symantec.com>, Geoffrey Noakes <Geoffrey_Noakes@symantec.com>, Tracy Chao <Tracy_Chao@symantec.com>, Tri Tang1 <Tri_Tang@symantec.com>, Jeff Barto <Jeff_Barto@symantec.com>, Theresa Garza < Theresa_Garza@symantec.com>, Sven Skerka <Sven_Skerka@symantec.com>, Helen Bates <Helen_Bates@symantec.com>, Jonathan Skinner < Jonathan_Skinner@symantec.com>, Kevin Brown <Kevin_Brown@symantec.com>, Minori Nakanishi <Minori_Nakanishi@symantec.com>, " leeanne_dewit@netcraft.com" <leeanne_dewit@netcraft.com>, " antec.com@netcraft.com" <antec.com@netcraft.com>, " tristan_fourcault@symantec.com" <tristan_fourcault@symantec.com>, Jun Kamimura <Jun_Kamimura@symantec.com>, Shusuke Nakagawa < Shusuke_Nakagawa@symantec.com>, Lisa Low <Lisa_Low@symantec.com>, Alejandro Borgia <Alejandro_Borgia@symantec.com>, Belinda Charleson < Belinda_Charleson@symantec.com>, Timothy Willey < Timothy_Willey@symantec.com>, Wasi Wahid <Wasi_Wahid@symantec.com>, Jo Ann Lambkin <JoAnn_Lambkin@symantec.com>, Abhijit Solanki < Abhijit_Solanki@symantec.com>, Donald Baker <Donald_Baker@symantec.com>, Harbir Singh <Harbir_Singh@symantec.com>, Michael Klieman < Michael_Klieman@symantec.com>, Takashi Abe <Takashi_Abe@symantec.com>, Helen Lew <Helen_Lew@symantec.com>, Jack Kato <Jack_Kato@symantec.com>, Nicolas Popp <Nicolas_Popp@symantec.com>, Bartosz Begej < Bartosz_Begej@symantec.com>, Jon Kerr <Jon_Kerr@symantec.com>, Roxane Jerbi <Roxane_Jerbi@symantec.com>, Tim Gallo <tim_gallo@symantec.com>, Gautam Kanaparthi <Gautam_Kanaparthi@symantec.com>, Thomas La < Thomas_La@symantec.com>, James Duff <James_Duff@symantec.com>, " aidan_calvert@symantec.com" <aidan_calvert@symantec.com>, Ian McShane < Ian_Mcshane@symantec.com>, Yoshimasa Hiraiwa < Yoshimasa_Hiraiwa@symantec.com>, Robert Lin <Robert_Lin@symantec.com>, Albert Cooley <Albert_Cooley@symantec.com>, Mirco Reimann < Mirco_Reimann@symantec.com>, Jessica Crewse <Jessica_Crewse@symantec.com>, Jason Luong <Jason_Luong@symantec.com>, Rory Tavares < Rory_Tavares@symantec.com>, Asad Faruqui <Asad_Faruqui@symantec.com>, Karina Stiller <Karina_Stiller@symantec.com>, Pavan Bhat < Pavan_Bhat@symantec.com>, "jeannette_duong@symantec.c" <jeannette_duong@symantec.c>, "om@netcraft.com" <om@netcraft.com>, Terri Parker <Terri_Parker@symantec.com>, "K.J.Hari Hara Krishnan" < Hari_Krishnan@symantec.com>, Anna Brannan <Anna_Brannan@symantec.com>, Graeme Watts <Graeme_Watts@symantec.com>, Russel Scovel < Russel_Scovel@symantec.com>, Maren Peasley <maren_peasley@symantec.com>, Tiphany Zellers <Tiphany_Zellers@symantec.com>, Randy Clark < randy_clark@symantec.com>, Susanne Lambert <Susanne_Lambert@symantec.com>, Alex Black <Alex_Black@symantec.com>, Davin Pick <Davin_Pick@symantec.com>, Akhil Verma <Akhil_Verma@symantec.com>, Micheal Brown < Micheal_Brown@symantec.com>, Lee-Lin Thye <Lee-Lin_Thye@symantec.com>, Suhasini Anand <Suhasini_Anand@symantec.com>, Victoria Cloutier < Victoria_Cloutier@symantec.com>, Philip Antoniadis < Philip_Antoniadis@symantec.com>, Ruth Singh <Ruth_Singh@symantec.com>, Thiago Lacerda <Thiago_Lacerda@symantec.com>, " nilanjana_majumdar@symantec.com" <nilanjana_majumdar@symantec.com>, "Sarah Mellor (CS)" <Sarah_Mellor@symantec.com>, Valerie Tsai < Valerie_Tsai@symantec.com>, Deepika Chauhan <Deepika_Chauhan@symantec.com>, Angelique Pereira <Angelique_Pereira@symantec.com>, Rachel Yokum < Rachel_Yokum@symantec.com>, Charlotte Pommier < Charlotte_Pommier@symantec.com>, Ramana Murthy <Ramana_Murthy@symantec.com

...

Cc: Date: Thu, 7 Jul 2016 16:27:35 +0000 Subject: Netcraft Secure Server Survey July 2016 Follow us on Twitter <http://www.twitter.com/Netcraft> & Facebook <http://www.facebook.com/Netcraft> [image: Netcraft] <http://www.netcraft.com/> Netcraft Secure Server Survey July 2016

The Netcraft Secure Server Survey for July 2016 is now available.

You can find the data to which you subscribe at:

- https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/ - https://ssl.netcraft.com/clients/iug3ore/symantec// Jul2016domain.csv.gz - https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016.csv.gz

July 2016 Highlights July Trends

Netcraft's July 2016 SSL Server Survey found 5,516,471 distinct valid third-party certificates <https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/glossary#valid_thir...>, representing a monthly gain of 188,016 (+3.5%).

Let's Encrypt gained a further 120,000 certificates in July, making up 64% of the total increase across all certificate authorities this month. This gain was enough to push Let's Encrypt into third place, with a total of 770,000 certificates.

GoDaddy has fallen to fourth place after losing 4,900 certificates since last month, and now has a market share of 13.52%. GoDaddy remains significantly ahead of fifth-placed GlobalSign, leading by 406,000 certificates and 7.35 percentage points of market share.

Comodo also grew significantly this month, increasing its total count of certificates by 56,000. Much of this growth can be attributed to its Western Digital and cPanel, Inc. sub-CAs . Due to the sheer volume of Let's Encrypt's growth, Comodo lost a very small amount of market share, dropping to 30.52%, despite having the second-largest absolute gain of certificates.

GlobalSign lost 4,900 certificates as 12,000 Shopify, Inc. web stores replaced GlobalSign certificates with ones issued by Let's Encrypt.

Within the DV market, Let's Encrypt now has slightly more than half as many DV certificates as the first-placed Comodo. Although Symantec only took second place in the DV market from GoDaddy last month, it has now been relegated to third place despite gaining 6,000 certificates and increasing its lead over GoDaddy to 25,000.

The DV market has seen significant change over the past 12 months: In the July 2015 survey GoDaddy was the largest issuer of DV certificates with a market share of 30.5% followed closely by Symantec and Comodo, and there were no Let's Encrypt certificates. There are now 1.8 million more DV certificates (+73.2%) with a majority of this growth focused in just two CAs: Comodo (+871,000) and Let's Encrypt (+770,000).

The Extended Validation market once again saw Comodo gain the most certificates with an increase of 494. Almost all of the top ten EV certificate issuers gained certificates this month with Network Solutions being the lone exception, losing 23. Symantec maintains its dominant market position at 48.4% market share.

Symantec continues to achieve the most estimated monthly revenue (using list prices <https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/CMatch/pricing/>) from its certificates; it issued 87,000 certificates in March to give estimated monthly revenue of $28.9 million. Comodo issued more than twice as many certificates, 205,000, yet has significantly smaller estimated revenue of $18.9 million. A majority of Symantec's revenue is derived from the much more expensive Organisation Validated and Extended Validation certificates, markets in which Comodo plays a smaller part. Comodo abandons attempt to trademark "Let's Encrypt"

In October 2015 Comodo filed three trademark applications for "Let's Encrypt", "Comodo Let's Encrypt" and "Let's Encrypt with Comodo". All three applications were abandoned on June 24th 2016 after Let's Encrypt publicly pleaded <https://letsencrypt.org//2016/06/23/defending-our-brand.html> for Comodo to abandon its trademark application. Let's Encrypt claimed its lawyers had been requesting Comodo drop its applications since March 2016 without success.

After Let's Encrypt's blog post was published, Comodo's CEO engaged with commentators on Comodo's forum <https://forums.comodo.com/general-discussion-off-topic-anything-and-everythi...> alleging that Let's Encrypt had copied Comodo's 90-day certificate business model. Later in the same thread, Robin Alden confirmed that Comodo was intending to let the trademark application lapse and had no intention of pursuing them after Let's Encrypt became operational. He explained that "Josh [Aas, the ISRG Executive Director] was wrong when he said we'd 'refused to abandon our applications'. We just hadn't told LE we would leave them to lapse."

Let's Encrypt was officially announced in November 2014, almost a year before Comodo's trademark application. It issued its first certificate in September 2015, before it launched in April 2016 after a short public beta period. ChaCha20-Poly1305 Cipher Suites

RFC 7905 <https://tools.ietf.org/html/rfc7905>, published in June 2016, specifies seven new cipher suites for TLS that combine the ChaCha20 variant of the ChaCha stream cipher with the Poly1305 one-time authenticator method. The new cipher suites provide a replacement to the RC4 stream cipher which was prohibited for TLS <https://tools.ietf.org/html/rfc7465> in February 2015 on the grounds that it no longer provided a sufficient level of security.

Both ChaCha20 and Poly1305 are designed with high performance in mind and the combination of the two is reportedly comparable to RC4 in speed.

ChaCha20-Poly1305 isn't new; a draft specification <https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04> written by Google was published in November 2013 which proposed three cipher suites. The Chrome browser has contained support for this older version of the specification since November 2013 and CloudFlare began using it in February 2015. Some changes have been made over the course of the standardisation process which has now been completed and the RFC approved. Apple updates App Transport Security

Apple announced at its Worldwide Developer Conference (WWDC) [slides] <http://devstreaming.apple.com/videos/wwdc/2016/706sgjvzkvg6rrg9icw/706/706_w...> that all App Store apps will be required to use App Transport Security from the start of 2017. ATS is designed to improve the security of apps by specifying minimum requirements <https://developer.apple.com/library/ios/documentation/General/Reference/Info...> for the HTTP connections that they make.

ATS requires that all connections are HTTPS over TLS 1.2, that the cipher suite must support forward secrecy, and that the certificate must be signed using the SHA-2 hashing algorithm.

ATS was introduced with iOS 9 in September 2015 and is enabled by default although it is currently possible to specify that ATS should be disabled for connections to certain domains or disabled globally. After the end of 2016, exceptions to the fundamental aspects of ATS will only be granted to Apps with valid justification – for example if you must communicate with a third-party service that you cannot control. Other exceptions, such as the requirement for perfect forward secrecy may be automatically approved. Apple also announced the introduction of support for Certificate Transparency. In order to enforce CT, the developer must specify a list of domains for which to require CT, and in order for the check to pass Apple require proofs from at least two CT logs. StartCom launch and then retract StartEncrypt

On 6th June, StartCom announced StartEncrypt <https://www.startssl.com/NewsDetails?date=20160606>, a product designed to automatically acquire and install certificates using its StartAPI. On the 4th July, StartCom announced <https://www.startssl.com/NewsDetails?date=20160606> that StartEncrypt would be replaced with a new protocol based on ACME. ACME is undergoing IETF standardisation after being first used by Let's Encrypt.

StartAPI was launched at the end of April 2016 and allowed users to programmatically acquire certificates as well as complete the validation processes required to prove domain ownership. StartEncrypt was the official client application which was released just over a month later. The proprietary software can be used to obtain any class of certificate and install it automatically both on Windows and Linux servers.

A number of serious issues <https://www.computest.nl/blog/startencrypt-considered-harmful-today/> have already been discovered since the release of the initial version of the StartEncrypt client, these allowed a user to gain valid SSL certificates by tampering with the URL used to verify control of a domain. StartCom was quick to respond to this issue, taking the API offline on the same day that the issue was disclosed and issuing an updated client less than a week later.

The issues lay with the way in which ownership of the domain was verified. In order to prove domain ownership the user must upload a file to a specified path on the domain, but the path used could be specified by the user, the check also followed redirects and didn't verify the file type of the response it received. Combined these issues led to users being able to acquire a valid certificate for any website that allowed file uploading or contained an open redirect, examples include sites such as Dropbox, GitHub, Facebook, PayPal and Google. While the vulnerability was demonstrated with a proof of concept, there is no evidence that the API was mis-used or certificates issued for domains which the applicant did not control.

Another bug <https://www.startssl.com/NewsDetails?date=20160323> in the StartEncrypt system meant that certificates issued using the program were not logged to Certificate Transparency servers. StartCom had stated that all of its SSL certificates would be published to CT logs as of 23rd March. Let's Encrypt leak user email addresses

On the 11th June an automated email script designed to alert users of an update to Let's Encrypt's subscriber agreement accidentally also leaked the email addresses of 7,617 users. The script prepended the email addresses of the users it had already emailed to the beginning of the message.

Let's Encrypt were alerted to the mistake 33 minutes after the emails began to send and subsequently stopped the script after it had sent 7,618 emails, 1.9% of the total it was expected to send.

An initial statement <https://community.letsencrypt.org/t/email-address-disclosures-preliminary-re...> by Josh Aas the Executive Director of ISRG was published less than two hours after the incident originally occurred with a longer analysis <https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/1...> following on the 14th June. Symantec acquire Blue Coat

Symantec has agreed to acquire the market leading web security company Blue Coat for $4.65 billion <https://www.symantec.com/en/uk/about/newsroom/press-releases/2016/symantec_0...>. The deal will see Blue Coat CEO Greg Clark appointed as the new CEO of Symantec, the post is currently vacant following Mike Brown's departure in April.

The acquisition will boost Symantec's enterprise security offerings and is expected to mean that 62% of the company's revenue <http://www.reuters.com/article/us-bluecoat-m-a-symantec-idUSKCN0YZ0BM> will be derived from the enterprise security market.

Blue Coat and Symantec recently made headlines <http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/> after Symantec issued an intermediate CA certificate for Blue Coat Public Services. Blue Coat creates security systems that include the capability to man-in-the-middle encrypted traffic, designed for use in corporate networks. Some reports of the use of Blue Coat systems by foreign governments have prompted criticism, although Blue Coat has consistently denied having any direct involvement.

The existence of the sub-CA was incorrectly reported as allowing Blue Coat the ability to create trusted certificates for arbitrary domains; however, Symantec confirmed <http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-i...> that "private keys for the Blue Coat Intermediate CA were in Symantec's control at all times" and "the only certificates that could be issued from this Intermediate CA were limited solely to ones for the bluecoat.com domain.". Other News

- Microsoft update cipher suites <https://support.microsoft.com/en-us/kb/3161639> for IE and Edge. - Mozilla adding support for reading from Windows Cert Stores <https://cabforum.org/2016/05/25/2016-05/> to Firefox. - GitHub Pages officially support HTTPS <https://github.com/blog/2186-https-for-github-pages> and new sites enforce it. - Amazon is now HTTPS site wide. - UK government updates security guidelines <https://gdstechnology.blog.gov.uk/2016/06/28/updating-our-security-guideline...> to enforce HTTPS, HSTS and DMARC by October 2016. - Microsoft Edge adds support for TLS False Start and TCP Fast Open <https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-se...> .

Copyright © Netcraft 2016. All Rights Reserved.

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

I may be wrong, but I think the encryption keys are the same regardless of the certificate -- it's the level of validation that's different. Also only extended validation certificates get you the green padlock.... As to alternatives, your suggestions regarding using contact info on websites won't work in a vast number of cases, because the certificate is often acquired before the website goes live (remember, the certificate is tied to the domain, not to the website (or the existence of a website)). It's my experience that getting the SSL certificate is typically a checklist item before taking a site live. On top of that, there's no support for an assumption that websites will have contact info on them, in those cases (e.g.., renewal) where the site is live. On Mon, Aug 15, 2016 at 6:58 PM, Ayden Férdeline <icann@ferdeline.com> wrote:

The key point I was raising was that there isn’t a difference between the encryption keys of domain-validated certificates, be they issued by Let’s Encrypt or a paid CA. The level of encryption is the same. That being said, I would like to return to my question about the use case itself: how could the CAs accomplish their desired task if, theoretically, the RDS could not accommodate their needs in the same manner that the WHOIS protocol does at present? - Ayden

-------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 11:48 PM UTC Time: August 15, 2016 10:48 PM From: gregshatanipc@gmail.com To: Geoffrey_Noakes@symantec.com Alex_Deacon@mpaa.org,icann@ferdeline.com,Dean_Coclin@symantec.com, gnso-rds-pdp-wg@icann.org

I see that Geoff has provided some actual facts, to replace both your speculation and mine. That should improve everyone's understanding of this use case.

I'll let Alex and/or Geoff respond on the difference between various types and levels of certificates, including the difference in value. I don't think anyone but you implied that there's no difference between a free Let's Encrypt certificate and a $399 Symantec certificate, in spite of your attempt to hang that on Alex. A little research shows quite a number of "value added" differences. That said, Let's Encrypt does seem to be quite a disruptive force in the certificate market, but I don't see the relevance of that to our study of this use case.

Greg

On Mon, Aug 15, 2016 at 6:25 PM, Geoffrey Noakes < Geoffrey_Noakes@symantec.com> wrote:

...

Ayden, the “types of checks” done for SSL/TLS certs fall into 3 categories:

· DV (domain validation): the most basic form of authentication performed by the CA. It essentially checks to see if the application for a cert has control over the domain for which the cert will be issued.

· OV (organization validation): the CA checks information about the organization (e.g., the company or business entity) that has applied for the cert.

· EV (extra validation): in addition to the OV checks, the CA checks for whether the individual who is applying for the cert is authorized to do so.

The processes for OV and EV authentication is defined by the CA/Browser Forum at https://cabforum.org/extended-validation/.

Netcraft is a third-party organization which monitors the number of publicly-facing SSL/TLS certs. A Netcraft report with data from July 2016 is attached – they saw ~5.5m certificates.

It is good to think of SSL/TLS certs as being like subscriptions – they each have a period of being valid, and they are usually renewed at the end of their periods. I am unaware of any publicly-available data on the variety of periods, but anecdotally, many are annual. Let’s Encrypt uses a 6 month period for theirs, and some are as low as a week (these a unusual).

I am unaware of any report that shows sales data related to SSL/TLS certs – most CAs are either private (and do not report numbers) or are parts of larger organizations (like Symantec, where I work, and do not break out sales numbers at that level). My sense is that the SSL/TLS cert business is less than $1b/year.

Thanks…

Geoff

*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounce s@icann.org] *On Behalf Of *Deacon, Alex *Sent:* Monday, August 15, 2016 3:06 PM *To:* Ayden Férdeline <icann@ferdeline.com> *Cc:* gnso-rds-pdp-wg@icann.org

*Subject:* Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP

Hi Ayden,

Lets not forget that in terms of protecting user privacy the use of encryption is vital, so I believe this is an important use case. All web server certificates, no matter which flavor of CA is used (from self-signed, to free to high-end) will result in data encryption at the transport layer. While the encryption is the same (assuming properly configured servers/clients) the difference between TLS certs is the level of authentication of the entity the server represents.

Its way out of scope to dive deeper into the various CA business models, but search for Domain Validated, Organizational Validated and Extended Validated for more details on some of the various levels of “authentication”.

Alex

On Aug 15, 2016, at 2:41 PM, Ayden Férdeline <icann@ferdeline.com> wrote:

Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.)

- Ayden

-------- Original Message --------

Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP

Local Time: August 15, 2016 9:00 PM

UTC Time: August 15, 2016 8:00 PM

From: gtheo@xs4all.nl

To: icann@ferdeline.com,Geoffrey_Noakes@symantec.com

gnso-rds-pdp-wg@icann.org

Hi Ayden,

These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name.

The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser.

Best regards,

Theo Geurts

On 15-8-2016 20:16, Ayden Férdeline wrote:

If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate?

If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money?

The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags?

- Ayden

-------- Original Message --------

Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP

Local Time: August 15, 2016 6:40 PM

UTC Time: August 15, 2016 5:40 PM

From: Geoffrey_Noakes@symantec.com

To: gnso-rds-pdp-wg@icann.org

I’ve attached a use case for WHOIS/RDP.

Thanks…

Geoff

*From:* Lisa Phifer [mailto:lisa@corecom.com <lisa@corecom.com>]

*Sent:* Monday, August 15, 2016 10:37 AM

*To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com> <Geoffrey_Noakes@symantec.com>

*Subject:* RE: Use Case

Hi Geoff, it's <gnso-rds-pdp-wg@icann.org>

For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/

As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org know.

Thanks again

Lisa

At 11:19 AM 8/15/2016, Geoffrey Noakes wrote:

Lisa, what is the “WG email list” email address?

*From:* Lisa Phifer [ mailto:lisa@corecom.com <lisa@corecom.com>]

*Sent:* Monday, August 15, 2016 10:17 AM

*To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com>

*Subject:* RE: Use Case

Thanks Geoff and welcome back. I hope you had an excellent vacation.

I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda.

In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention.

Best, Lisa

At 11:11 AM 8/15/2016, you wrote:

+Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this

Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS.

I would prefer the August 23 date – I am on jury duty the week of August 29-September 2.

Thanks…

Geoff

From: Gomes, Chuck [ mailto:cgomes@verisign.com <cgomes@verisign.com>]

Sent: Monday, August 15, 2016 9:53 AM

To: Geoffrey Noakes < Geoffrey_Noakes@symantec.com>

Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead@icann.org) < gnso-next-gen-rds-lead@icann.org>

Subject: Use Case

Geoff,

You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance.

Hope you are having a good vacation.

Chuck

_______________________________________________

gnso-rds-pdp-wg mailing list

gnso-rds-pdp-wg@icann.org

https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

---------- Forwarded message ---------- From: Mike Prettejohn <mhp@netcraft.com> To: Diana Marin Severino <Diana_Marin_Severino@symantec.com>, Sue Coakley <Sue_Coakley@symantec.com>, Vijay NS <Vijay_NS@symantec.com>, Sonya Perez <Sonya_Perez@symantec.com>, Eric Lipman < Eric_Lipman@symantec.com>, Laura Aviles <Laura_Aviles@symantec.com>, Jeffrey Whale <Jeffrey_Whale@symantec.com>, Alex Wong < Alex_Wong@symantec.com>, Landon Borup <Landon_Borup@symantec.com>, Alain Allen <Alain_Allen@symantec.com>, Frank Agurto-Machado < Frank_Agurto-Machado@symantec.com>, Charlene Mike-Billstrom < Charlene_Mike-Billstrom@symantec.com>, Rick Andrews < Rick_Andrews@symantec.com>, Anna Sampson <Anna_Sampson@symantec.com>, Eiji Yahagi <Eiji_Yahagi@symantec.com>, Tomonori Sato < Tomonori_Sato@symantec.com>, Christiaan De Villiers < Christiaan_DeVilliers@symantec.com>, Dean Coclin < Dean_Coclin@symantec.com>, Hari Veladanda <Hari_Veladanda@symantec.com>, Robert Hoblit <Robert_Hoblit@symantec.com>, Marisa Luke < Marisa_Luke@symantec.com>, Roxane Divol <Roxane_Divol@symantec.com>, Norie Sato <Norie_Sato@symantec.com>, Masato Hayashi < Masato_Hayashi@symantec.com>, DL-VSN-Data Analysis < DL-VSN-DataAnalysis@symantec.com>, Bill Ng <Bill_Ng@symantec.com>, Geoffrey Noakes <Geoffrey_Noakes@symantec.com>, Tracy Chao < Tracy_Chao@symantec.com>, Tri Tang1 <Tri_Tang@symantec.com>, Jeff Barto < Jeff_Barto@symantec.com>, Theresa Garza <Theresa_Garza@symantec.com>, Sven Skerka <Sven_Skerka@symantec.com>, Helen Bates < Helen_Bates@symantec.com>, Jonathan Skinner < Jonathan_Skinner@symantec.com>, Kevin Brown <Kevin_Brown@symantec.com>, Minori Nakanishi <Minori_Nakanishi@symantec.com>, " leeanne_dewit@netcraft.com" <leeanne_dewit@netcraft.com>, " antec.com@netcraft.com" <antec.com@netcraft.com>, " tristan_fourcault@symantec.com" <tristan_fourcault@symantec.com>, Jun Kamimura <Jun_Kamimura@symantec.com>, Shusuke Nakagawa < Shusuke_Nakagawa@symantec.com>, Lisa Low <Lisa_Low@symantec.com>, Alejandro Borgia <Alejandro_Borgia@symantec.com>, Belinda Charleson < Belinda_Charleson@symantec.com>, Timothy Willey < Timothy_Willey@symantec.com>, Wasi Wahid <Wasi_Wahid@symantec.com>, Jo Ann Lambkin <JoAnn_Lambkin@symantec.com>, Abhijit Solanki < Abhijit_Solanki@symantec.com>, Donald Baker <Donald_Baker@symantec.com>, Harbir Singh <Harbir_Singh@symantec.com>, Michael Klieman < Michael_Klieman@symantec.com>, Takashi Abe <Takashi_Abe@symantec.com>, Helen Lew <Helen_Lew@symantec.com>, Jack Kato <Jack_Kato@symantec.com>, Nicolas Popp <Nicolas_Popp@symantec.com>, Bartosz Begej < Bartosz_Begej@symantec.com>, Jon Kerr <Jon_Kerr@symantec.com>, Roxane Jerbi <Roxane_Jerbi@symantec.com>, Tim Gallo <tim_gallo@symantec.com>, Gautam Kanaparthi <Gautam_Kanaparthi@symantec.com>, Thomas La < Thomas_La@symantec.com>, James Duff <James_Duff@symantec.com>, " aidan_calvert@symantec.com" <aidan_calvert@symantec.com>, Ian McShane < Ian_Mcshane@symantec.com>, Yoshimasa Hiraiwa <Yoshimasa_Hiraiwa@symantec. com>, Robert Lin <Robert_Lin@symantec.com>, Albert Cooley < Albert_Cooley@symantec.com>, Mirco Reimann <Mirco_Reimann@symantec.com>, Jessica Crewse <Jessica_Crewse@symantec.com>, Jason Luong < Jason_Luong@symantec.com>, Rory Tavares <Rory_Tavares@symantec.com>, Asad Faruqui <Asad_Faruqui@symantec.com>, Karina Stiller < Karina_Stiller@symantec.com>, Pavan Bhat <Pavan_Bhat@symantec.com>, "jeannette_duong@symantec.c" <jeannette_duong@symantec.c>, " om@netcraft.com" <om@netcraft.com>, Terri Parker < Terri_Parker@symantec.com>, "K.J.Hari Hara Krishnan" < Hari_Krishnan@symantec.com>, Anna Brannan <Anna_Brannan@symantec.com>, Graeme Watts <Graeme_Watts@symantec.com>, Russel Scovel < Russel_Scovel@symantec.com>, Maren Peasley <maren_peasley@symantec.com>, Tiphany Zellers <Tiphany_Zellers@symantec.com>, Randy Clark < randy_clark@symantec.com>, Susanne Lambert <Susanne_Lambert@symantec.com>, Alex Black <Alex_Black@symantec.com>, Davin Pick <Davin_Pick@symantec.com>, Akhil Verma <Akhil_Verma@symantec.com>, Micheal Brown < Micheal_Brown@symantec.com>, Lee-Lin Thye <Lee-Lin_Thye@symantec.com>, Suhasini Anand <Suhasini_Anand@symantec.com>, Victoria Cloutier < Victoria_Cloutier@symantec.com>, Philip Antoniadis < Philip_Antoniadis@symantec.com>, Ruth Singh <Ruth_Singh@symantec.com>, Thiago Lacerda <Thiago_Lacerda@symantec.com>, " nilanjana_majumdar@symantec.com" <nilanjana_majumdar@symantec.com>, "Sarah Mellor (CS)" <Sarah_Mellor@symantec.com>, Valerie Tsai < Valerie_Tsai@symantec.com>, Deepika Chauhan <Deepika_Chauhan@symantec.com

...

, Angelique Pereira <Angelique_Pereira@symantec.com>, Rachel Yokum < Rachel_Yokum@symantec.com>, Charlotte Pommier < Charlotte_Pommier@symantec.com>, Ramana Murthy < Ramana_Murthy@symantec.com> Cc: Date: Thu, 7 Jul 2016 16:27:35 +0000 Subject: Netcraft Secure Server Survey July 2016

Follow us on Twitter <http://www.twitter.com/Netcraft> & Facebook <http://www.facebook.com/Netcraft> [image: Netcraft] <http://www.netcraft.com/> Netcraft Secure Server Survey July 2016

The Netcraft Secure Server Survey for July 2016 is now available.

You can find the data to which you subscribe at:

- https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/ - https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016do main.csv.gz - https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016.csv.gz

July 2016 Highlights July Trends

Netcraft's July 2016 SSL Server Survey found 5,516,471 distinct valid third-party certificates <https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/glossary#valid_thir...>, representing a monthly gain of 188,016 (+3.5%).

Let's Encrypt gained a further 120,000 certificates in July, making up 64% of the total increase across all certificate authorities this month. This gain was enough to push Let's Encrypt into third place, with a total of 770,000 certificates.

GoDaddy has fallen to fourth place after losing 4,900 certificates since last month, and now has a market share of 13.52%. GoDaddy remains significantly ahead of fifth-placed GlobalSign, leading by 406,000 certificates and 7.35 percentage points of market share.

Comodo also grew significantly this month, increasing its total count of certificates by 56,000. Much of this growth can be attributed to its Western Digital and cPanel, Inc. sub-CAs . Due to the sheer volume of Let's Encrypt's growth, Comodo lost a very small amount of market share, dropping to 30.52%, despite having the second-largest absolute gain of certificates.

GlobalSign lost 4,900 certificates as 12,000 Shopify, Inc. web stores replaced GlobalSign certificates with ones issued by Let's Encrypt.

Within the DV market, Let's Encrypt now has slightly more than half as many DV certificates as the first-placed Comodo. Although Symantec only took second place in the DV market from GoDaddy last month, it has now been relegated to third place despite gaining 6,000 certificates and increasing its lead over GoDaddy to 25,000.

The DV market has seen significant change over the past 12 months: In the July 2015 survey GoDaddy was the largest issuer of DV certificates with a market share of 30.5% followed closely by Symantec and Comodo, and there were no Let's Encrypt certificates. There are now 1.8 million more DV certificates (+73.2%) with a majority of this growth focused in just two CAs: Comodo (+871,000) and Let's Encrypt (+770,000).

The Extended Validation market once again saw Comodo gain the most certificates with an increase of 494. Almost all of the top ten EV certificate issuers gained certificates this month with Network Solutions being the lone exception, losing 23. Symantec maintains its dominant market position at 48.4% market share.

Symantec continues to achieve the most estimated monthly revenue (using list prices <https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/CMatch/pricing/>) from its certificates; it issued 87,000 certificates in March to give estimated monthly revenue of $28.9 million. Comodo issued more than twice as many certificates, 205,000, yet has significantly smaller estimated revenue of $18.9 million. A majority of Symantec's revenue is derived from the much more expensive Organisation Validated and Extended Validation certificates, markets in which Comodo plays a smaller part. Comodo abandons attempt to trademark "Let's Encrypt"

In October 2015 Comodo filed three trademark applications for "Let's Encrypt", "Comodo Let's Encrypt" and "Let's Encrypt with Comodo". All three applications were abandoned on June 24th 2016 after Let's Encrypt publicly pleaded <https://letsencrypt.org//2016/06/23/defending-our-brand.html>for Comodo to abandon its trademark application. Let's Encrypt claimed its lawyers had been requesting Comodo drop its applications since March 2016 without success.

After Let's Encrypt's blog post was published, Comodo's CEO engaged with commentators on Comodo's forum <https://forums.comodo.com/general-discussion-off-topic-anything-and-everything/shame-on-you-comodo-t115958.0.html;msg837411#msg837411>alleging that Let's Encrypt had copied Comodo's 90-day certificate business model. Later in the same thread, Robin Alden confirmed that Comodo was intending to let the trademark application lapse and had no intention of pursuing them after Let's Encrypt became operational. He explained that "Josh [Aas, the ISRG Executive Director] was wrong when he said we'd 'refused to abandon our applications'. We just hadn't told LE we would leave them to lapse."

Let's Encrypt was officially announced in November 2014, almost a year before Comodo's trademark application. It issued its first certificate in September 2015, before it launched in April 2016 after a short public beta period. ChaCha20-Poly1305 Cipher Suites

RFC 7905 <https://tools.ietf.org/html/rfc7905>, published in June 2016, specifies seven new cipher suites for TLS that combine the ChaCha20 variant of the ChaCha stream cipher with the Poly1305 one-time authenticator method. The new cipher suites provide a replacement to the RC4 stream cipher which was prohibited for TLS <https://tools.ietf.org/html/rfc7465> in February 2015 on the grounds that it no longer provided a sufficient level of security.

Both ChaCha20 and Poly1305 are designed with high performance in mind and the combination of the two is reportedly comparable to RC4 in speed.

ChaCha20-Poly1305 isn't new; a draft specification <https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04> written by Google was published in November 2013 which proposed three cipher suites. The Chrome browser has contained support for this older version of the specification since November 2013 and CloudFlare began using it in February 2015. Some changes have been made over the course of the standardisation process which has now been completed and the RFC approved. Apple updates App Transport Security

Apple announced at its Worldwide Developer Conference (WWDC) [slides] <http://devstreaming.apple.com/videos/wwdc/2016/706sgjvzkvg6rrg9icw/706/706_w...> that all App Store apps will be required to use App Transport Security from the start of 2017. ATS is designed to improve the security of apps by specifying minimum requirements <https://developer.apple.com/library/ios/documentation/General/Reference/Info...> for the HTTP connections that they make.

ATS requires that all connections are HTTPS over TLS 1.2, that the cipher suite must support forward secrecy, and that the certificate must be signed using the SHA-2 hashing algorithm.

ATS was introduced with iOS 9 in September 2015 and is enabled by default although it is currently possible to specify that ATS should be disabled for connections to certain domains or disabled globally. After the end of 2016, exceptions to the fundamental aspects of ATS will only be granted to Apps with valid justification – for example if you must communicate with a third-party service that you cannot control. Other exceptions, such as the requirement for perfect forward secrecy may be automatically approved. Apple also announced the introduction of support for Certificate Transparency. In order to enforce CT, the developer must specify a list of domains for which to require CT, and in order for the check to pass Apple require proofs from at least two CT logs. StartCom launch and then retract StartEncrypt

On 6th June, StartCom announced StartEncrypt <https://www.startssl.com/NewsDetails?date=20160606>, a product designed to automatically acquire and install certificates using its StartAPI. On the 4th July, StartCom announced <https://www.startssl.com/NewsDetails?date=20160606>that StartEncrypt would be replaced with a new protocol based on ACME. ACME is undergoing IETF standardisation after being first used by Let's Encrypt.

StartAPI was launched at the end of April 2016 and allowed users to programmatically acquire certificates as well as complete the validation processes required to prove domain ownership. StartEncrypt was the official client application which was released just over a month later. The proprietary software can be used to obtain any class of certificate and install it automatically both on Windows and Linux servers.

A number of serious issues <https://www.computest.nl/blog/startencrypt-considered-harmful-today/> have already been discovered since the release of the initial version of the StartEncrypt client, these allowed a user to gain valid SSL certificates by tampering with the URL used to verify control of a domain. StartCom was quick to respond to this issue, taking the API offline on the same day that the issue was disclosed and issuing an updated client less than a week later.

The issues lay with the way in which ownership of the domain was verified. In order to prove domain ownership the user must upload a file to a specified path on the domain, but the path used could be specified by the user, the check also followed redirects and didn't verify the file type of the response it received. Combined these issues led to users being able to acquire a valid certificate for any website that allowed file uploading or contained an open redirect, examples include sites such as Dropbox, GitHub, Facebook, PayPal and Google. While the vulnerability was demonstrated with a proof of concept, there is no evidence that the API was mis-used or certificates issued for domains which the applicant did not control.

Another bug <https://www.startssl.com/NewsDetails?date=20160323>in the StartEncrypt system meant that certificates issued using the program were not logged to Certificate Transparency servers. StartCom had stated that all of its SSL certificates would be published to CT logs as of 23rd March. Let's Encrypt leak user email addresses

On the 11th June an automated email script designed to alert users of an update to Let's Encrypt's subscriber agreement accidentally also leaked the email addresses of 7,617 users. The script prepended the email addresses of the users it had already emailed to the beginning of the message.

Let's Encrypt were alerted to the mistake 33 minutes after the emails began to send and subsequently stopped the script after it had sent 7,618 emails, 1.9% of the total it was expected to send.

An initial statement <https://community.letsencrypt.org/t/email-address-disclosures-preliminary-re...> by Josh Aas the Executive Director of ISRG was published less than two hours after the incident originally occurred with a longer analysis <https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/1...> following on the 14th June. Symantec acquire Blue Coat

Symantec has agreed to acquire the market leading web security company Blue Coat for $4.65 billion <https://www.symantec.com/en/uk/about/newsroom/press-releases/2016/symantec_0...>. The deal will see Blue Coat CEO Greg Clark appointed as the new CEO of Symantec, the post is currently vacant following Mike Brown's departure in April.

The acquisition will boost Symantec's enterprise security offerings and is expected to mean that 62% of the company's revenue <http://www.reuters.com/article/us-bluecoat-m-a-symantec-idUSKCN0YZ0BM> will be derived from the enterprise security market.

Blue Coat and Symantec recently made headlines <http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/> after Symantec issued an intermediate CA certificate for Blue Coat Public Services. Blue Coat creates security systems that include the capability to man-in-the-middle encrypted traffic, designed for use in corporate networks. Some reports of the use of Blue Coat systems by foreign governments have prompted criticism, although Blue Coat has consistently denied having any direct involvement.

The existence of the sub-CA was incorrectly reported as allowing Blue Coat the ability to create trusted certificates for arbitrary domains; however, Symantec confirmed <http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-i...> that "private keys for the Blue Coat Intermediate CA were in Symantec's control at all times" and "the only certificates that could be issued from this Intermediate CA were limited solely to ones for the bluecoat.com domain.". Other News

- Microsoft update cipher suites <https://support.microsoft.com/en-us/kb/3161639> for IE and Edge. - Mozilla adding support for reading from Windows Cert Stores <https://cabforum.org/2016/05/25/2016-05/> to Firefox. - GitHub Pages officially support HTTPS <https://github.com/blog/2186-https-for-github-pages> and new sites enforce it. - Amazon is now HTTPS site wide. - UK government updates security guidelines <https://gdstechnology.blog.gov.uk/2016/06/28/updating-our-security-guideline...> to enforce HTTPS, HSTS and DMARC by October 2016. - Microsoft Edge adds support for TLS False Start and TCP Fast Open <https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-se...> .

Copyright © Netcraft 2016. All Rights Reserved.

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

On Tue, Aug 16, 2016 at 12:02 PM, Rob Golding <rob.golding@astutium.com> wrote:

...

As to alternatives, your suggestions regarding using contact info on websites won't work in a vast number of cases, because the certificate is often acquired before the website goes live

I have never known a CA issue an EV certificate without requiring that there be a website, with the correct (requestors) contact information on it (and that contact information matches a-n-other 3rd party system like the utility)

Internet != Web of course (and we've organised plenty of certificates where there isn't and never is expected to be a website but the encryption is still necessary)

​GS: Agreed, then -- there are some cases where a website needs to be live, and many others where the website is not live first or no website is intended for the use (e.g., an email only use).​

...

On top of that, there's no support for an assumption that websites will have contact info on them, in those cases (e.g.., renewal) where the site is live.

It's a legal requirement in some jurisdictions, and at least 2 CAs I've obtained certificates from check the sites at least at SSL order time (and as they expire does mean periodic rechecks)

​GS: That's consistent with my statement. Since it's only in some jurisdictions, it's nothing we could depend on as a general matter.​

...

I am unaware of any report that shows sales data related to SSL/TLS certs

Ironically, as the expiry date etc in an SSL Cert is "public", certificate holders face growing numbers of targeting phishing scams following the "fake renewal notice" methodology that has plagued domain Registrants for years (due to domain data being "public")

Rob

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

That’s an interesting mental exercise, as what the CA’s basically do is tie a domain name to an entity using an authoritative source - exactly what whois is today and an RDS would be in the future (in theory).

Certificate type dependant - the bulk of certs by the main CA's are validated by one of 4 methods: 1. trust in the people ordering it 2. by sending an email to(admin/administrator/webmaster/postmaster)@(thedomain) with a code/link (i.e. can they get/respond to an email) 3. simple nslookup of a CNAME containing the MD5 of the CSR (i.e. do they have access to edit the dns entries) 4. placement of a code/snippet/file on a website (i.e. do they have some form of file-level access to the hosting) Only for certain certificate types do they do things like look at "official" document sources to try and verify the provided data = some other database (and they don’t use WHOIS for that, they use the phone book !) and/or ask for scans (or faxes) of a utility bill etc Rob --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

This is a problem with a lot of ccTLDs .se and .nu for example doesn’t show any whois data on personal domains when they have a Swedish adress Not even registrars can pull these data. First of all I don’t think this is a problem we are intended to solve, but it certainly will be a problem a lot of us who sell certificates will feel in one way ot the other. No one from the certificate industry in the WG who can be bothered to give some heads up on this use case? -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200

On 16 Aug 2016, at 10:10, gtheo <gtheo@xs4all.nl> wrote:

Hi Ayden,

The discussion about the certain forms of verification and the differences between SSL certificates is out of scope I think.

However, you have a point for sure.

As a Dutch Registrar, we offer .NL and we offer SSL certificates. The public WHOIS operated by the Dutch Registry no longer displays registrant data when it comes to natural persons for .NL. If I had to order an SSL certificate for say, my personal blog then this would not be possible as there is no info about me in the public WHOIS.

Current Registry solution for .NL is that .NL accredited Registrars have full access to what we call here a Registrar WHOIS operated by the Dutch Registry and only available to accredited .NL Registrars. One could say we have purpose based gated access ;)

With this setup, we are still able to pull the required info through this WHOIS so our customers are able to order SSL certificates.

So at some point, we might need to tackle this for RDS when it comes up.

Best regards,

Theo Geurts

Ayden Férdeline schreef op 2016-08-16 12:58 AM:

...

The key point I was raising was that there isn’t a difference between the encryption keys of domain-validated certificates, be they issued by Let’s Encrypt or a paid CA. The level of encryption is the same. That being said, I would like to return to my question about the use case itself: how could the CAs accomplish their desired task if, theoretically, the RDS could not accommodate their needs in the same manner that the WHOIS protocol does at present? - Ayden

...

-------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 11:48 PM UTC Time: August 15, 2016 10:48 PM From: gregshatanipc@gmail.com To: Geoffrey_Noakes@symantec.com Alex_Deacon@mpaa.org,icann@ferdeline.com,Dean_Coclin@symantec.com,gnso-rds-pdp-wg@icann.org I see that Geoff has provided some actual facts, to replace both your speculation and mine. That should improve everyone's understanding of this use case. I'll let Alex and/or Geoff respond on the difference between various types and levels of certificates, including the difference in value. I don't think anyone but you implied that there's no difference between a free Let's Encrypt certificate and a $399 Symantec certificate, in spite of your attempt to hang that on Alex. A little research shows quite a number of "value added" differences. That said, Let's Encrypt does seem to be quite a disruptive force in the certificate market, but I don't see the relevance of that to our study of this use case. Greg On Mon, Aug 15, 2016 at 6:25 PM, Geoffrey Noakes <Geoffrey_Noakes@symantec.com> wrote: Ayden, the “types of checks” done for SSL/TLS certs fall into 3 categories: · DV (domain validation): the most basic form of authentication performed by the CA. It essentially checks to see if the application for a cert has control over the domain for which the cert will be issued. · OV (organization validation): the CA checks information about the organization (e.g., the company or business entity) that has applied for the cert. · EV (extra validation): in addition to the OV checks, the CA checks for whether the individual who is applying for the cert is authorized to do so. The processes for OV and EV authentication is defined by the CA/Browser Forum at https://cabforum.org/extended-validation/ [2]. Netcraft is a third-party organization which monitors the number of publicly-facing SSL/TLS certs. A Netcraft report with data from July 2016 is attached – they saw ~5.5m certificates. It is good to think of SSL/TLS certs as being like subscriptions – they each have a period of being valid, and they are usually renewed at the end of their periods. I am unaware of any publicly-available data on the variety of periods, but anecdotally, many are annual. Let’s Encrypt uses a 6 month period for theirs, and some are as low as a week (these a unusual). I am unaware of any report that shows sales data related to SSL/TLS certs – most CAs are either private (and do not report numbers) or are parts of larger organizations (like Symantec, where I work, and do not break out sales numbers at that level). My sense is that the SSL/TLS cert business is less than $1b/year. Thanks… Geoff FROM: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] ON BEHALF OF Deacon, Alex SENT: Monday, August 15, 2016 3:06 PM TO: Ayden Férdeline <icann@ferdeline.com> CC: gnso-rds-pdp-wg@icann.org SUBJECT: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Hi Ayden, Lets not forget that in terms of protecting user privacy the use of encryption is vital, so I believe this is an important use case. All web server certificates, no matter which flavor of CA is used (from self-signed, to free to high-end) will result in data encryption at the transport layer. While the encryption is the same (assuming properly configured servers/clients) the difference between TLS certs is the level of authentication of the entity the server represents. Its way out of scope to dive deeper into the various CA business models, but search for Domain Validated, Organizational Validated and Extended Validated for more details on some of the various levels of “authentication”. Alex On Aug 15, 2016, at 2:41 PM, Ayden Férdeline <icann@ferdeline.com> wrote: Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.) - Ayden -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 9:00 PM UTC Time: August 15, 2016 8:00 PM From: gtheo@xs4all.nl To: icann@ferdeline.com,Geoffrey_Noakes@symantec.com gnso-rds-pdp-wg@icann.org Hi Ayden, These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name. The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser. Best regards, Theo Geurts On 15-8-2016 20:16, Ayden Férdeline wrote: If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate? If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money? The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags? - Ayden -------- Original Message -------- Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 6:40 PM UTC Time: August 15, 2016 5:40 PM From: Geoffrey_Noakes@symantec.com To: gnso-rds-pdp-wg@icann.org I’ve attached a use case for WHOIS/RDP. Thanks… Geoff FROM: Lisa Phifer [mailto:lisa@corecom.com] SENT: Monday, August 15, 2016 10:37 AM TO: Geoffrey Noakes <Geoffrey_Noakes@symantec.com> SUBJECT: RE: Use Case Hi Geoff, it's <gnso-rds-pdp-wg@icann.org> For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/ [3] As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org know. Thanks again Lisa At 11:19 AM 8/15/2016, Geoffrey Noakes wrote: Lisa, what is the “WG email list” email address? FROM: Lisa Phifer [ mailto:lisa@corecom.com] SENT: Monday, August 15, 2016 10:17 AM TO: Geoffrey Noakes <Geoffrey_Noakes@symantec.com> SUBJECT: RE: Use Case Thanks Geoff and welcome back. I hope you had an excellent vacation. I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda. In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention. Best, Lisa At 11:11 AM 8/15/2016, you wrote: +Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS. I would prefer the August 23 date – I am on jury duty the week of August 29-September 2. Thanks… Geoff From: Gomes, Chuck [ mailto:cgomes@verisign.com] Sent: Monday, August 15, 2016 9:53 AM To: Geoffrey Noakes < Geoffrey_Noakes@symantec.com> Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead@icann.org) < gnso-next-gen-rds-lead@icann.org> Subject: Use Case Geoff, You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance. Hope you are having a good vacation. Chuck _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [1]

---

gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [1] ---------- Forwarded message ---------- From: Mike Prettejohn <mhp@netcraft.com> To: Diana Marin Severino <Diana_Marin_Severino@symantec.com>, Sue Coakley <Sue_Coakley@symantec.com>, Vijay NS <Vijay_NS@symantec.com>, Sonya Perez <Sonya_Perez@symantec.com>, Eric Lipman <Eric_Lipman@symantec.com>, Laura Aviles <Laura_Aviles@symantec.com>, Jeffrey Whale <Jeffrey_Whale@symantec.com>, Alex Wong <Alex_Wong@symantec.com>, Landon Borup <Landon_Borup@symantec.com>, Alain Allen <Alain_Allen@symantec.com>, Frank Agurto-Machado <Frank_Agurto-Machado@symantec.com>, Charlene Mike-Billstrom <Charlene_Mike-Billstrom@symantec.com>, Rick Andrews <Rick_Andrews@symantec.com>, Anna Sampson <Anna_Sampson@symantec.com>, Eiji Yahagi <Eiji_Yahagi@symantec.com>, Tomonori Sato <Tomonori_Sato@symantec.com>, Christiaan De Villiers <Christiaan_DeVilliers@symantec.com>, Dean Coclin <Dean_Coclin@symantec.com>, Hari Veladanda <Hari_Veladanda@symantec.com>, Robert Hoblit <Robert_Hoblit@symantec.com>, Marisa Luke <Marisa_Luke@symantec.com>, Roxane Divol <Roxane_Divol@symantec.com>, Norie Sato <Norie_Sato@symantec.com>, Masato Hayashi <Masato_Hayashi@symantec.com>, DL-VSN-Data Analysis <DL-VSN-DataAnalysis@symantec.com>, Bill Ng <Bill_Ng@symantec.com>, Geoffrey Noakes <Geoffrey_Noakes@symantec.com>, Tracy Chao <Tracy_Chao@symantec.com>, Tri Tang1 <Tri_Tang@symantec.com>, Jeff Barto <Jeff_Barto@symantec.com>, Theresa Garza <Theresa_Garza@symantec.com>, Sven Skerka <Sven_Skerka@symantec.com>, Helen Bates <Helen_Bates@symantec.com>, Jonathan Skinner <Jonathan_Skinner@symantec.com>, Kevin Brown <Kevin_Brown@symantec.com>, Minori Nakanishi <Minori_Nakanishi@symantec.com>, "leeanne_dewit@netcraft.com" <leeanne_dewit@netcraft.com>, "antec.com@netcraft.com" <antec.com@netcraft.com>, "tristan_fourcault@symantec.com" <tristan_fourcault@symantec.com>, Jun Kamimura <Jun_Kamimura@symantec.com>, Shusuke Nakagawa <Shusuke_Nakagawa@symantec.com>, Lisa Low <Lisa_Low@symantec.com>, Alejandro Borgia <Alejandro_Borgia@symantec.com>, Belinda Charleson <Belinda_Charleson@symantec.com>, Timothy Willey <Timothy_Willey@symantec.com>, Wasi Wahid <Wasi_Wahid@symantec.com>, Jo Ann Lambkin <JoAnn_Lambkin@symantec.com>, Abhijit Solanki <Abhijit_Solanki@symantec.com>, Donald Baker <Donald_Baker@symantec.com>, Harbir Singh <Harbir_Singh@symantec.com>, Michael Klieman <Michael_Klieman@symantec.com>, Takashi Abe <Takashi_Abe@symantec.com>, Helen Lew <Helen_Lew@symantec.com>, Jack Kato <Jack_Kato@symantec.com>, Nicolas Popp <Nicolas_Popp@symantec.com>, Bartosz Begej <Bartosz_Begej@symantec.com>, Jon Kerr <Jon_Kerr@symantec.com>, Roxane Jerbi <Roxane_Jerbi@symantec.com>, Tim Gallo <tim_gallo@symantec.com>, Gautam Kanaparthi <Gautam_Kanaparthi@symantec.com>, Thomas La <Thomas_La@symantec.com>, James Duff <James_Duff@symantec.com>, "aidan_calvert@symantec.com" <aidan_calvert@symantec.com>, Ian McShane <Ian_Mcshane@symantec.com>, Yoshimasa Hiraiwa <Yoshimasa_Hiraiwa@symantec.com>, Robert Lin <Robert_Lin@symantec.com>, Albert Cooley <Albert_Cooley@symantec.com>, Mirco Reimann <Mirco_Reimann@symantec.com>, Jessica Crewse <Jessica_Crewse@symantec.com>, Jason Luong <Jason_Luong@symantec.com>, Rory Tavares <Rory_Tavares@symantec.com>, Asad Faruqui <Asad_Faruqui@symantec.com>, Karina Stiller <Karina_Stiller@symantec.com>, Pavan Bhat <Pavan_Bhat@symantec.com>, "jeannette_duong@symantec.c" <jeannette_duong@symantec.c>, "om@netcraft.com" <om@netcraft.com>, Terri Parker <Terri_Parker@symantec.com>, "K.J.Hari Hara Krishnan" <Hari_Krishnan@symantec.com>, Anna Brannan <Anna_Brannan@symantec.com>, Graeme Watts <Graeme_Watts@symantec.com>, Russel Scovel <Russel_Scovel@symantec.com>, Maren Peasley <maren_peasley@symantec.com>, Tiphany Zellers <Tiphany_Zellers@symantec.com>, Randy Clark <randy_clark@symantec.com>, Susanne Lambert <Susanne_Lambert@symantec.com>, Alex Black <Alex_Black@symantec.com>, Davin Pick <Davin_Pick@symantec.com>, Akhil Verma <Akhil_Verma@symantec.com>, Micheal Brown <Micheal_Brown@symantec.com>, Lee-Lin Thye <Lee-Lin_Thye@symantec.com>, Suhasini Anand <Suhasini_Anand@symantec.com>, Victoria Cloutier <Victoria_Cloutier@symantec.com>, Philip Antoniadis <Philip_Antoniadis@symantec.com>, Ruth Singh <Ruth_Singh@symantec.com>, Thiago Lacerda <Thiago_Lacerda@symantec.com>, "nilanjana_majumdar@symantec.com" <nilanjana_majumdar@symantec.com>, "Sarah Mellor (CS)" <Sarah_Mellor@symantec.com>, Valerie Tsai <Valerie_Tsai@symantec.com>, Deepika Chauhan <Deepika_Chauhan@symantec.com>, Angelique Pereira <Angelique_Pereira@symantec.com>, Rachel Yokum <Rachel_Yokum@symantec.com>, Charlotte Pommier <Charlotte_Pommier@symantec.com>, Ramana Murthy <Ramana_Murthy@symantec.com> Cc: Date: Thu, 7 Jul 2016 16:27:35 +0000 Subject: Netcraft Secure Server Survey July 2016 Follow us on Twitter [4] & Facebook [5] Netcraft Secure Server Survey July 2016 The Netcraft Secure Server Survey for July 2016 is now available. You can find the data to which you subscribe at: * https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/ [6] * https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016domain.csv.gz [7] * https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016.csv.gz [8] July 2016 Highlights July Trends Netcraft's July 2016 SSL Server Survey found 5,516,471 distinct valid third-party certificates [9], representing a monthly gain of 188,016 (+3.5%). Let's Encrypt gained a further 120,000 certificates in July, making up 64% of the total increase across all certificate authorities this month. This gain was enough to push Let's Encrypt into third place, with a total of 770,000 certificates. GoDaddy has fallen to fourth place after losing 4,900 certificates since last month, and now has a market share of 13.52%. GoDaddy remains significantly ahead of fifth-placed GlobalSign, leading by 406,000 certificates and 7.35 percentage points of market share. Comodo also grew significantly this month, increasing its total count of certificates by 56,000. Much of this growth can be attributed to its Western Digital and cPanel, Inc. sub-CAs . Due to the sheer volume of Let's Encrypt's growth, Comodo lost a very small amount of market share, dropping to 30.52%, despite having the second-largest absolute gain of certificates. GlobalSign lost 4,900 certificates as 12,000 Shopify, Inc. web stores replaced GlobalSign certificates with ones issued by Let's Encrypt. Within the DV market, Let's Encrypt now has slightly more than half as many DV certificates as the first-placed Comodo. Although Symantec only took second place in the DV market from GoDaddy last month, it has now been relegated to third place despite gaining 6,000 certificates and increasing its lead over GoDaddy to 25,000. The DV market has seen significant change over the past 12 months: In the July 2015 survey GoDaddy was the largest issuer of DV certificates with a market share of 30.5% followed closely by Symantec and Comodo, and there were no Let's Encrypt certificates. There are now 1.8 million more DV certificates (+73.2%) with a majority of this growth focused in just two CAs: Comodo (+871,000) and Let's Encrypt (+770,000). The Extended Validation market once again saw Comodo gain the most certificates with an increase of 494. Almost all of the top ten EV certificate issuers gained certificates this month with Network Solutions being the lone exception, losing 23. Symantec maintains its dominant market position at 48.4% market share. Symantec continues to achieve the most estimated monthly revenue (using list prices [10]) from its certificates; it issued 87,000 certificates in March to give estimated monthly revenue of $28.9 million. Comodo issued more than twice as many certificates, 205,000, yet has significantly smaller estimated revenue of $18.9 million. A majority of Symantec's revenue is derived from the much more expensive Organisation Validated and Extended Validation certificates, markets in which Comodo plays a smaller part. Comodo abandons attempt to trademark "Let's Encrypt" In October 2015 Comodo filed three trademark applications for "Let's Encrypt", "Comodo Let's Encrypt" and "Let's Encrypt with Comodo". All three applications were abandoned on June 24th 2016 after Let's Encrypt publicly pleaded [11]for Comodo to abandon its trademark application. Let's Encrypt claimed its lawyers had been requesting Comodo drop its applications since March 2016 without success. After Let's Encrypt's blog post was published, Comodo's CEO engaged with commentators on Comodo's forum [12]alleging that Let's Encrypt had copied Comodo's 90-day certificate business model. Later in the same thread, Robin Alden confirmed that Comodo was intending to let the trademark application lapse and had no intention of pursuing them after Let's Encrypt became operational. He explained that "Josh [Aas, the ISRG Executive Director] was wrong when he said we'd 'refused to abandon our applications'. We just hadn't told LE we would leave them to lapse." Let's Encrypt was officially announced in November 2014, almost a year before Comodo's trademark application. It issued its first certificate in September 2015, before it launched in April 2016 after a short public beta period. ChaCha20-Poly1305 Cipher Suites RFC 7905 [13], published in June 2016, specifies seven new cipher suites for TLS that combine the ChaCha20 variant of the ChaCha stream cipher with the Poly1305 one-time authenticator method. The new cipher suites provide a replacement to the RC4 stream cipher which was prohibited for TLS [14] in February 2015 on the grounds that it no longer provided a sufficient level of security. Both ChaCha20 and Poly1305 are designed with high performance in mind and the combination of the two is reportedly comparable to RC4 in speed. ChaCha20-Poly1305 isn't new; a draft specification [15] written by Google was published in November 2013 which proposed three cipher suites. The Chrome browser has contained support for this older version of the specification since November 2013 and CloudFlare began using it in February 2015. Some changes have been made over the course of the standardisation process which has now been completed and the RFC approved. Apple updates App Transport Security Apple announced at its Worldwide Developer Conference (WWDC) [slides] [16] that all App Store apps will be required to use App Transport Security from the start of 2017. ATS is designed to improve the security of apps by specifying minimum requirements [17] for the HTTP connections that they make. ATS requires that all connections are HTTPS over TLS 1.2, that the cipher suite must support forward secrecy, and that the certificate must be signed using the SHA-2 hashing algorithm. ATS was introduced with iOS 9 in September 2015 and is enabled by default although it is currently possible to specify that ATS should be disabled for connections to certain domains or disabled globally. After the end of 2016, exceptions to the fundamental aspects of ATS will only be granted to Apps with valid justification – for example if you must communicate with a third-party service that you cannot control. Other exceptions, such as the requirement for perfect forward secrecy may be automatically approved. Apple also announced the introduction of support for Certificate Transparency. In order to enforce CT, the developer must specify a list of domains for which to require CT, and in order for the check to pass Apple require proofs from at least two CT logs. StartCom launch and then retract StartEncrypt On 6th June, StartCom announced StartEncrypt [18], a product designed to automatically acquire and install certificates using its StartAPI. On the 4th July, StartCom announced [18]that StartEncrypt would be replaced with a new protocol based on ACME. ACME is undergoing IETF standardisation after being first used by Let's Encrypt. StartAPI was launched at the end of April 2016 and allowed users to programmatically acquire certificates as well as complete the validation processes required to prove domain ownership. StartEncrypt was the official client application which was released just over a month later. The proprietary software can be used to obtain any class of certificate and install it automatically both on Windows and Linux servers. A number of serious issues [19] have already been discovered since the release of the initial version of the StartEncrypt client, these allowed a user to gain valid SSL certificates by tampering with the URL used to verify control of a domain. StartCom was quick to respond to this issue, taking the API offline on the same day that the issue was disclosed and issuing an updated client less than a week later. The issues lay with the way in which ownership of the domain was verified. In order to prove domain ownership the user must upload a file to a specified path on the domain, but the path used could be specified by the user, the check also followed redirects and didn't verify the file type of the response it received. Combined these issues led to users being able to acquire a valid certificate for any website that allowed file uploading or contained an open redirect, examples include sites such as Dropbox, GitHub, Facebook, PayPal and Google. While the vulnerability was demonstrated with a proof of concept, there is no evidence that the API was mis-used or certificates issued for domains which the applicant did not control. Another bug [20]in the StartEncrypt system meant that certificates issued using the program were not logged to Certificate Transparency servers. StartCom had stated that all of its SSL certificates would be published to CT logs as of 23rd March. Let's Encrypt leak user email addresses On the 11th June an automated email script designed to alert users of an update to Let's Encrypt's subscriber agreement accidentally also leaked the email addresses of 7,617 users. The script prepended the email addresses of the users it had already emailed to the beginning of the message. Let's Encrypt were alerted to the mistake 33 minutes after the emails began to send and subsequently stopped the script after it had sent 7,618 emails, 1.9% of the total it was expected to send. An initial statement [21] by Josh Aas the Executive Director of ISRG was published less than two hours after the incident originally occurred with a longer analysis [22] following on the 14th June. Symantec acquire Blue Coat Symantec has agreed to acquire the market leading web security company Blue Coat for $4.65 billion [23]. The deal will see Blue Coat CEO Greg Clark appointed as the new CEO of Symantec, the post is currently vacant following Mike Brown's departure in April. The acquisition will boost Symantec's enterprise security offerings and is expected to mean that 62% of the company's revenue [24] will be derived from the enterprise security market. Blue Coat and Symantec recently made headlines [25] after Symantec issued an intermediate CA certificate for Blue Coat Public Services. Blue Coat creates security systems that include the capability to man-in-the-middle encrypted traffic, designed for use in corporate networks. Some reports of the use of Blue Coat systems by foreign governments have prompted criticism, although Blue Coat has consistently denied having any direct involvement. The existence of the sub-CA was incorrectly reported as allowing Blue Coat the ability to create trusted certificates for arbitrary domains; however, Symantec confirmed [26] that "private keys for the Blue Coat Intermediate CA were in Symantec's control at all times" and "the only certificates that could be issued from this Intermediate CA were limited solely to ones for the bluecoat.com [27] domain.". Other News * Microsoft update cipher suites [28] for IE and Edge. * Mozilla adding support for reading from Windows Cert Stores [29] to Firefox. * GitHub Pages officially support HTTPS [30] and new sites enforce it. * Amazon is now HTTPS site wide. * UK government updates security guidelines [31] to enforce HTTPS, HSTS and DMARC by October 2016. * Microsoft Edge adds support for TLS False Start and TCP Fast Open [32]. Copyright © Netcraft 2016. All Rights Reserved. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [1] Links: ------ [1] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [2] https://cabforum.org/extended-validation/ [3] http://mm.icann.org/pipermail/gnso-rds-pdp-wg/ [4] http://www.twitter.com/Netcraft [5] http://www.facebook.com/Netcraft [6] https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/ [7] https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016domain.csv.gz [8] https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016.csv.gz [9] https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/glossary#valid_thir... [10] https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/CMatch/pricing/ [11] https://letsencrypt.org//2016/06/23/defending-our-brand.html [12] https://forums.comodo.com/general-discussion-off-topic-anything-and-everythi... [13] https://tools.ietf.org/html/rfc7905 [14] https://tools.ietf.org/html/rfc7465 [15] https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 [16] http://devstreaming.apple.com/videos/wwdc/2016/706sgjvzkvg6rrg9icw/706/706_w... [17] https://developer.apple.com/library/ios/documentation/General/Reference/Info... [18] https://www.startssl.com/NewsDetails?date=20160606 [19] https://www.computest.nl/blog/startencrypt-considered-harmful-today/ [20] https://www.startssl.com/NewsDetails?date=20160323 [21] https://community.letsencrypt.org/t/email-address-disclosures-preliminary-re... [22] https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/1... [23] https://www.symantec.com/en/uk/about/newsroom/press-releases/2016/symantec_0... [24] http://www.reuters.com/article/us-bluecoat-m-a-symantec-idUSKCN0YZ0BM [25] http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ [26] http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-i... [27] http://bluecoat.com [28] https://support.microsoft.com/en-us/kb/3161639 [29] https://cabforum.org/2016/05/25/2016-05/ [30] https://github.com/blog/2186-https-for-github-pages [31] https://gdstechnology.blog.gov.uk/2016/06/28/updating-our-security-guideline... [32] https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-se... _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

My key point was that this is a very important use case to add to our list and that we should always be encouraging the use of encryption - no matter what the mechanisms may be. Also I specifically avoided getting into the details of the varying CA authentication mechanisms and business models. While the recent email on potential innovation of the CA biz has been interesting its clearly out of scope for this WG. Alex On Aug 15, 2016, at 3:58 PM, Ayden Férdeline <icann@ferdeline.com<mailto:icann@ferdeline.com>> wrote: The key point I was raising was that there isn’t a difference between the encryption keys of domain-validated certificates, be they issued by Let’s Encrypt or a paid CA. The level of encryption is the same. That being said, I would like to return to my question about the use case itself: how could the CAs accomplish their desired task if, theoretically, the RDS could not accommodate their needs in the same manner that the WHOIS protocol does at present? - Ayden -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 11:48 PM UTC Time: August 15, 2016 10:48 PM From: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> To: Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com> Alex_Deacon@mpaa.org<mailto:Alex_Deacon@mpaa.org>,icann@ferdeline.com<mailto:icann@ferdeline.com>,Dean_Coclin@symantec.com<mailto:Dean_Coclin@symantec.com>,gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> I see that Geoff has provided some actual facts, to replace both your speculation and mine. That should improve everyone's understanding of this use case. I'll let Alex and/or Geoff respond on the difference between various types and levels of certificates, including the difference in value. I don't think anyone but you implied that there's no difference between a free Let's Encrypt certificate and a $399 Symantec certificate, in spite of your attempt to hang that on Alex. A little research shows quite a number of "value added" differences. That said, Let's Encrypt does seem to be quite a disruptive force in the certificate market, but I don't see the relevance of that to our study of this use case. Greg On Mon, Aug 15, 2016 at 6:25 PM, Geoffrey Noakes <Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com>> wrote: Ayden, the “types of checks” done for SSL/TLS certs fall into 3 categories: · DV (domain validation): the most basic form of authentication performed by the CA. It essentially checks to see if the application for a cert has control over the domain for which the cert will be issued. · OV (organization validation): the CA checks information about the organization (e.g., the company or business entity) that has applied for the cert. · EV (extra validation): in addition to the OV checks, the CA checks for whether the individual who is applying for the cert is authorized to do so. The processes for OV and EV authentication is defined by the CA/Browser Forum at https://cabforum.org/extended-validation/. Netcraft is a third-party organization which monitors the number of publicly-facing SSL/TLS certs. A Netcraft report with data from July 2016 is attached – they saw ~5.5m certificates. It is good to think of SSL/TLS certs as being like subscriptions – they each have a period of being valid, and they are usually renewed at the end of their periods. I am unaware of any publicly-available data on the variety of periods, but anecdotally, many are annual. Let’s Encrypt uses a 6 month period for theirs, and some are as low as a week (these a unusual). I am unaware of any report that shows sales data related to SSL/TLS certs – most CAs are either private (and do not report numbers) or are parts of larger organizations (like Symantec, where I work, and do not break out sales numbers at that level). My sense is that the SSL/TLS cert business is less than $1b/year. Thanks… Geoff From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org>] On Behalf Of Deacon, Alex Sent: Monday, August 15, 2016 3:06 PM To: Ayden Férdeline <icann@ferdeline.com<mailto:icann@ferdeline.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Hi Ayden, Lets not forget that in terms of protecting user privacy the use of encryption is vital, so I believe this is an important use case. All web server certificates, no matter which flavor of CA is used (from self-signed, to free to high-end) will result in data encryption at the transport layer. While the encryption is the same (assuming properly configured servers/clients) the difference between TLS certs is the level of authentication of the entity the server represents. Its way out of scope to dive deeper into the various CA business models, but search for Domain Validated, Organizational Validated and Extended Validated for more details on some of the various levels of “authentication”. Alex On Aug 15, 2016, at 2:41 PM, Ayden Férdeline <icann@ferdeline.com<mailto:icann@ferdeline.com>> wrote: Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.) - Ayden -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 9:00 PM UTC Time: August 15, 2016 8:00 PM From: gtheo@xs4all.nl<mailto:gtheo@xs4all.nl> To: icann@ferdeline.com<mailto:icann@ferdeline.com>,Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com> gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Hi Ayden, These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name. The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser. Best regards, Theo Geurts On 15-8-2016 20:16, Ayden Férdeline wrote: If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate? If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money? The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags? - Ayden -------- Original Message -------- Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 6:40 PM UTC Time: August 15, 2016 5:40 PM From: Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com> To: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> I’ve attached a use case for WHOIS/RDP. Thanks… Geoff From: Lisa Phifer [mailto:lisa@corecom.com] Sent: Monday, August 15, 2016 10:37 AM To: Geoffrey Noakes <Geoffrey_Noakes@symantec.com><mailto:Geoffrey_Noakes@symantec.com> Subject: RE: Use Case Hi Geoff, it's <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/ As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org<mailto:gnso-secs@icann.org> know. Thanks again Lisa At 11:19 AM 8/15/2016, Geoffrey Noakes wrote: Lisa, what is the “WG email list” email address? From: Lisa Phifer [ mailto:lisa@corecom.com] Sent: Monday, August 15, 2016 10:17 AM To: Geoffrey Noakes <Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com>> Subject: RE: Use Case Thanks Geoff and welcome back. I hope you had an excellent vacation. I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda. In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention. Best, Lisa At 11:11 AM 8/15/2016, you wrote: +Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS. I would prefer the August 23 date – I am on jury duty the week of August 29-September 2. Thanks… Geoff From: Gomes, Chuck [ mailto:cgomes@verisign.com] Sent: Monday, August 15, 2016 9:53 AM To: Geoffrey Noakes < Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com>> Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead@icann.org<mailto:gnso-next-gen-rds-lead@icann.org>) < gnso-next-gen-rds-lead@icann.org<mailto:gnso-next-gen-rds-lead@icann.org>> Subject: Use Case Geoff, You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance. Hope you are having a good vacation. Chuck _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg ---------- Forwarded message ---------- From: Mike Prettejohn <mhp@netcraft.com<mailto:mhp@netcraft.com>> To: Diana Marin Severino <Diana_Marin_Severino@symantec.com<mailto:Diana_Marin_Severino@symantec.com>>, Sue Coakley <Sue_Coakley@symantec.com<mailto:Sue_Coakley@symantec.com>>, Vijay NS <Vijay_NS@symantec.com<mailto:Vijay_NS@symantec.com>>, Sonya Perez <Sonya_Perez@symantec.com<mailto:Sonya_Perez@symantec.com>>, Eric Lipman <Eric_Lipman@symantec.com<mailto:Eric_Lipman@symantec.com>>, Laura Aviles <Laura_Aviles@symantec.com<mailto:Laura_Aviles@symantec.com>>, Jeffrey Whale <Jeffrey_Whale@symantec.com<mailto:Jeffrey_Whale@symantec.com>>, Alex Wong <Alex_Wong@symantec.com<mailto:Alex_Wong@symantec.com>>, Landon Borup <Landon_Borup@symantec.com<mailto:Landon_Borup@symantec.com>>, Alain Allen <Alain_Allen@symantec.com<mailto:Alain_Allen@symantec.com>>, Frank Agurto-Machado <Frank_Agurto-Machado@symantec.com<mailto:Frank_Agurto-Machado@symantec.com>>, Charlene Mike-Billstrom <Charlene_Mike-Billstrom@symantec.com<mailto:Charlene_Mike-Billstrom@symantec.com>>, Rick Andrews <Rick_Andrews@symantec.com<mailto:Rick_Andrews@symantec.com>>, Anna Sampson <Anna_Sampson@symantec.com<mailto:Anna_Sampson@symantec.com>>, Eiji Yahagi <Eiji_Yahagi@symantec.com<mailto:Eiji_Yahagi@symantec.com>>, Tomonori Sato <Tomonori_Sato@symantec.com<mailto:Tomonori_Sato@symantec.com>>, Christiaan De Villiers <Christiaan_DeVilliers@symantec.com<mailto:Christiaan_DeVilliers@symantec.com>>, Dean Coclin <Dean_Coclin@symantec.com<mailto:Dean_Coclin@symantec.com>>, Hari Veladanda <Hari_Veladanda@symantec.com<mailto:Hari_Veladanda@symantec.com>>, Robert Hoblit <Robert_Hoblit@symantec.com<mailto:Robert_Hoblit@symantec.com>>, Marisa Luke <Marisa_Luke@symantec.com<mailto:Marisa_Luke@symantec.com>>, Roxane Divol <Roxane_Divol@symantec.com<mailto:Roxane_Divol@symantec.com>>, Norie Sato <Norie_Sato@symantec.com<mailto:Norie_Sato@symantec.com>>, Masato Hayashi <Masato_Hayashi@symantec.com<mailto:Masato_Hayashi@symantec.com>>, DL-VSN-Data Analysis <DL-VSN-DataAnalysis@symantec.com<mailto:DL-VSN-DataAnalysis@symantec.com>>, Bill Ng <Bill_Ng@symantec.com<mailto:Bill_Ng@symantec.com>>, Geoffrey Noakes <Geoffrey_Noakes@symantec.com<mailto:Geoffrey_Noakes@symantec.com>>, Tracy Chao <Tracy_Chao@symantec.com<mailto:Tracy_Chao@symantec.com>>, Tri Tang1 <Tri_Tang@symantec.com<mailto:Tri_Tang@symantec.com>>, Jeff Barto <Jeff_Barto@symantec.com<mailto:Jeff_Barto@symantec.com>>, Theresa Garza <Theresa_Garza@symantec.com<mailto:Theresa_Garza@symantec.com>>, Sven Skerka <Sven_Skerka@symantec.com<mailto:Sven_Skerka@symantec.com>>, Helen Bates <Helen_Bates@symantec.com<mailto:Helen_Bates@symantec.com>>, Jonathan Skinner <Jonathan_Skinner@symantec.com<mailto:Jonathan_Skinner@symantec.com>>, Kevin Brown <Kevin_Brown@symantec.com<mailto:Kevin_Brown@symantec.com>>, Minori Nakanishi <Minori_Nakanishi@symantec.com<mailto:Minori_Nakanishi@symantec.com>>, "leeanne_dewit@netcraft.com<mailto:leeanne_dewit@netcraft.com>" <leeanne_dewit@netcraft.com<mailto:leeanne_dewit@netcraft.com>>, "antec.com@netcraft.com<mailto:antec.com@netcraft.com>" <antec.com@netcraft.com<mailto:antec.com@netcraft.com>>, "tristan_fourcault@symantec.com<mailto:tristan_fourcault@symantec.com>" <tristan_fourcault@symantec.com<mailto:tristan_fourcault@symantec.com>>, Jun Kamimura <Jun_Kamimura@symantec.com<mailto:Jun_Kamimura@symantec.com>>, Shusuke Nakagawa <Shusuke_Nakagawa@symantec.com<mailto:Shusuke_Nakagawa@symantec.com>>, Lisa Low <Lisa_Low@symantec.com<mailto:Lisa_Low@symantec.com>>, Alejandro Borgia <Alejandro_Borgia@symantec.com<mailto:Alejandro_Borgia@symantec.com>>, Belinda Charleson <Belinda_Charleson@symantec.com<mailto:Belinda_Charleson@symantec.com>>, Timothy Willey <Timothy_Willey@symantec.com<mailto:Timothy_Willey@symantec.com>>, Wasi Wahid <Wasi_Wahid@symantec.com<mailto:Wasi_Wahid@symantec.com>>, Jo Ann Lambkin <JoAnn_Lambkin@symantec.com<mailto:JoAnn_Lambkin@symantec.com>>, Abhijit Solanki <Abhijit_Solanki@symantec.com<mailto:Abhijit_Solanki@symantec.com>>, Donald Baker <Donald_Baker@symantec.com<mailto:Donald_Baker@symantec.com>>, Harbir Singh <Harbir_Singh@symantec.com<mailto:Harbir_Singh@symantec.com>>, Michael Klieman <Michael_Klieman@symantec.com<mailto:Michael_Klieman@symantec.com>>, Takashi Abe <Takashi_Abe@symantec.com<mailto:Takashi_Abe@symantec.com>>, Helen Lew <Helen_Lew@symantec.com<mailto:Helen_Lew@symantec.com>>, Jack Kato <Jack_Kato@symantec.com<mailto:Jack_Kato@symantec.com>>, Nicolas Popp <Nicolas_Popp@symantec.com<mailto:Nicolas_Popp@symantec.com>>, Bartosz Begej <Bartosz_Begej@symantec.com<mailto:Bartosz_Begej@symantec.com>>, Jon Kerr <Jon_Kerr@symantec.com<mailto:Jon_Kerr@symantec.com>>, Roxane Jerbi <Roxane_Jerbi@symantec.com<mailto:Roxane_Jerbi@symantec.com>>, Tim Gallo <tim_gallo@symantec.com<mailto:tim_gallo@symantec.com>>, Gautam Kanaparthi <Gautam_Kanaparthi@symantec.com<mailto:Gautam_Kanaparthi@symantec.com>>, Thomas La <Thomas_La@symantec.com<mailto:Thomas_La@symantec.com>>, James Duff <James_Duff@symantec.com<mailto:James_Duff@symantec.com>>, "aidan_calvert@symantec.com<mailto:aidan_calvert@symantec.com>" <aidan_calvert@symantec.com<mailto:aidan_calvert@symantec.com>>, Ian McShane <Ian_Mcshane@symantec.com<mailto:Ian_Mcshane@symantec.com>>, Yoshimasa Hiraiwa <Yoshimasa_Hiraiwa@symantec.com<mailto:Yoshimasa_Hiraiwa@symantec.com>>, Robert Lin <Robert_Lin@symantec.com<mailto:Robert_Lin@symantec.com>>, Albert Cooley <Albert_Cooley@symantec.com<mailto:Albert_Cooley@symantec.com>>, Mirco Reimann <Mirco_Reimann@symantec.com<mailto:Mirco_Reimann@symantec.com>>, Jessica Crewse <Jessica_Crewse@symantec.com<mailto:Jessica_Crewse@symantec.com>>, Jason Luong <Jason_Luong@symantec.com<mailto:Jason_Luong@symantec.com>>, Rory Tavares <Rory_Tavares@symantec.com<mailto:Rory_Tavares@symantec.com>>, Asad Faruqui <Asad_Faruqui@symantec.com<mailto:Asad_Faruqui@symantec.com>>, Karina Stiller <Karina_Stiller@symantec.com<mailto:Karina_Stiller@symantec.com>>, Pavan Bhat <Pavan_Bhat@symantec.com<mailto:Pavan_Bhat@symantec.com>>, "jeannette_duong@symantec.c<mailto:jeannette_duong@symantec.c>" <jeannette_duong@symantec.c<mailto:jeannette_duong@symantec.c>>, "om@netcraft.com<mailto:om@netcraft.com>" <om@netcraft.com<mailto:om@netcraft.com>>, Terri Parker <Terri_Parker@symantec.com<mailto:Terri_Parker@symantec.com>>, "K.J.Hari Hara Krishnan" <Hari_Krishnan@symantec.com<mailto:Hari_Krishnan@symantec.com>>, Anna Brannan <Anna_Brannan@symantec.com<mailto:Anna_Brannan@symantec.com>>, Graeme Watts <Graeme_Watts@symantec.com<mailto:Graeme_Watts@symantec.com>>, Russel Scovel <Russel_Scovel@symantec.com<mailto:Russel_Scovel@symantec.com>>, Maren Peasley <maren_peasley@symantec.com<mailto:maren_peasley@symantec.com>>, Tiphany Zellers <Tiphany_Zellers@symantec.com<mailto:Tiphany_Zellers@symantec.com>>, Randy Clark <randy_clark@symantec.com<mailto:randy_clark@symantec.com>>, Susanne Lambert <Susanne_Lambert@symantec.com<mailto:Susanne_Lambert@symantec.com>>, Alex Black <Alex_Black@symantec.com<mailto:Alex_Black@symantec.com>>, Davin Pick <Davin_Pick@symantec.com<mailto:Davin_Pick@symantec.com>>, Akhil Verma <Akhil_Verma@symantec.com<mailto:Akhil_Verma@symantec.com>>, Micheal Brown <Micheal_Brown@symantec.com<mailto:Micheal_Brown@symantec.com>>, Lee-Lin Thye <Lee-Lin_Thye@symantec.com<mailto:Lee-Lin_Thye@symantec.com>>, Suhasini Anand <Suhasini_Anand@symantec.com<mailto:Suhasini_Anand@symantec.com>>, Victoria Cloutier <Victoria_Cloutier@symantec.com<mailto:Victoria_Cloutier@symantec.com>>, Philip Antoniadis <Philip_Antoniadis@symantec.com<mailto:Philip_Antoniadis@symantec.com>>, Ruth Singh <Ruth_Singh@symantec.com<mailto:Ruth_Singh@symantec.com>>, Thiago Lacerda <Thiago_Lacerda@symantec.com<mailto:Thiago_Lacerda@symantec.com>>, "nilanjana_majumdar@symantec.com<mailto:nilanjana_majumdar@symantec.com>" <nilanjana_majumdar@symantec.com<mailto:nilanjana_majumdar@symantec.com>>, "Sarah Mellor (CS)" <Sarah_Mellor@symantec.com<mailto:Sarah_Mellor@symantec.com>>, Valerie Tsai <Valerie_Tsai@symantec.com<mailto:Valerie_Tsai@symantec.com>>, Deepika Chauhan <Deepika_Chauhan@symantec.com<mailto:Deepika_Chauhan@symantec.com>>, Angelique Pereira <Angelique_Pereira@symantec.com<mailto:Angelique_Pereira@symantec.com>>, Rachel Yokum <Rachel_Yokum@symantec.com<mailto:Rachel_Yokum@symantec.com>>, Charlotte Pommier <Charlotte_Pommier@symantec.com<mailto:Charlotte_Pommier@symantec.com>>, Ramana Murthy <Ramana_Murthy@symantec.com<mailto:Ramana_Murthy@symantec.com>> Cc: Date: Thu, 7 Jul 2016 16:27:35 +0000 Subject: Netcraft Secure Server Survey July 2016 Follow us on Twitter<http://www.twitter.com/Netcraft> & Facebook<http://www.facebook.com/Netcraft> <http://www.netcraft.com/> <ATT00001.png> Netcraft Secure Server Survey July 2016 The Netcraft Secure Server Survey for July 2016 is now available. You can find the data to which you subscribe at: * https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/ * https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016domain.csv.gz * https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016.csv.gz July 2016 Highlights July Trends Netcraft's July 2016 SSL Server Survey found 5,516,471 distinct valid third-party certificates<https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/glossary#valid_thir...>, representing a monthly gain of 188,016 (+3.5%). Let's Encrypt gained a further 120,000 certificates in July, making up 64% of the total increase across all certificate authorities this month. This gain was enough to push Let's Encrypt into third place, with a total of 770,000 certificates. GoDaddy has fallen to fourth place after losing 4,900 certificates since last month, and now has a market share of 13.52%. GoDaddy remains significantly ahead of fifth-placed GlobalSign, leading by 406,000 certificates and 7.35 percentage points of market share. Comodo also grew significantly this month, increasing its total count of certificates by 56,000. Much of this growth can be attributed to its Western Digital and cPanel, Inc. sub-CAs . Due to the sheer volume of Let's Encrypt's growth, Comodo lost a very small amount of market share, dropping to 30.52%, despite having the second-largest absolute gain of certificates. GlobalSign lost 4,900 certificates as 12,000 Shopify, Inc. web stores replaced GlobalSign certificates with ones issued by Let's Encrypt. Within the DV market, Let's Encrypt now has slightly more than half as many DV certificates as the first-placed Comodo. Although Symantec only took second place in the DV market from GoDaddy last month, it has now been relegated to third place despite gaining 6,000 certificates and increasing its lead over GoDaddy to 25,000. The DV market has seen significant change over the past 12 months: In the July 2015 survey GoDaddy was the largest issuer of DV certificates with a market share of 30.5% followed closely by Symantec and Comodo, and there were no Let's Encrypt certificates. There are now 1.8 million more DV certificates (+73.2%) with a majority of this growth focused in just two CAs: Comodo (+871,000) and Let's Encrypt (+770,000). The Extended Validation market once again saw Comodo gain the most certificates with an increase of 494. Almost all of the top ten EV certificate issuers gained certificates this month with Network Solutions being the lone exception, losing 23. Symantec maintains its dominant market position at 48.4% market share. Symantec continues to achieve the most estimated monthly revenue (using list prices<https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/CMatch/pricing/>) from its certificates; it issued 87,000 certificates in March to give estimated monthly revenue of $28.9 million. Comodo issued more than twice as many certificates, 205,000, yet has significantly smaller estimated revenue of $18.9 million. A majority of Symantec's revenue is derived from the much more expensive Organisation Validated and Extended Validation certificates, markets in which Comodo plays a smaller part. Comodo abandons attempt to trademark "Let's Encrypt" In October 2015 Comodo filed three trademark applications for "Let's Encrypt", "Comodo Let's Encrypt" and "Let's Encrypt with Comodo". All three applications were abandoned on June 24th 2016 after Let's Encrypt publicly pleaded<https://letsencrypt.org//2016/06/23/defending-our-brand.html>for Comodo to abandon its trademark application. Let's Encrypt claimed its lawyers had been requesting Comodo drop its applications since March 2016 without success. After Let's Encrypt's blog post was published, Comodo's CEO engaged with commentators on Comodo's forum<https://forums.comodo.com/general-discussion-off-topic-anything-and-everything/shame-on-you-comodo-t115958.0.html;msg837411#msg837411>alleging that Let's Encrypt had copied Comodo's 90-day certificate business model. Later in the same thread, Robin Alden confirmed that Comodo was intending to let the trademark application lapse and had no intention of pursuing them after Let's Encrypt became operational. He explained that "Josh [Aas, the ISRG Executive Director] was wrong when he said we'd 'refused to abandon our applications'. We just hadn't told LE we would leave them to lapse." Let's Encrypt was officially announced in November 2014, almost a year before Comodo's trademark application. It issued its first certificate in September 2015, before it launched in April 2016 after a short public beta period. ChaCha20-Poly1305 Cipher Suites RFC 7905<https://tools.ietf.org/html/rfc7905>, published in June 2016, specifies seven new cipher suites for TLS that combine the ChaCha20 variant of the ChaCha stream cipher with the Poly1305 one-time authenticator method. The new cipher suites provide a replacement to the RC4 stream cipher which was prohibited for TLS<https://tools.ietf.org/html/rfc7465> in February 2015 on the grounds that it no longer provided a sufficient level of security. Both ChaCha20 and Poly1305 are designed with high performance in mind and the combination of the two is reportedly comparable to RC4 in speed. ChaCha20-Poly1305 isn't new; a draft specification<https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04> written by Google was published in November 2013 which proposed three cipher suites. The Chrome browser has contained support for this older version of the specification since November 2013 and CloudFlare began using it in February 2015. Some changes have been made over the course of the standardisation process which has now been completed and the RFC approved. Apple updates App Transport Security Apple announced at its Worldwide Developer Conference (WWDC) [slides]<http://devstreaming.apple.com/videos/wwdc/2016/706sgjvzkvg6rrg9icw/706/706_w...> that all App Store apps will be required to use App Transport Security from the start of 2017. ATS is designed to improve the security of apps by specifying minimum requirements<https://developer.apple.com/library/ios/documentation/General/Reference/Info...> for the HTTP connections that they make. ATS requires that all connections are HTTPS over TLS 1.2, that the cipher suite must support forward secrecy, and that the certificate must be signed using the SHA-2 hashing algorithm. ATS was introduced with iOS 9 in September 2015 and is enabled by default although it is currently possible to specify that ATS should be disabled for connections to certain domains or disabled globally. After the end of 2016, exceptions to the fundamental aspects of ATS will only be granted to Apps with valid justification – for example if you must communicate with a third-party service that you cannot control. Other exceptions, such as the requirement for perfect forward secrecy may be automatically approved. Apple also announced the introduction of support for Certificate Transparency. In order to enforce CT, the developer must specify a list of domains for which to require CT, and in order for the check to pass Apple require proofs from at least two CT logs. StartCom launch and then retract StartEncrypt On 6th June, StartCom announced StartEncrypt<https://www.startssl.com/NewsDetails?date=20160606>, a product designed to automatically acquire and install certificates using its StartAPI. On the 4th July, StartCom announced<https://www.startssl.com/NewsDetails?date=20160606>that StartEncrypt would be replaced with a new protocol based on ACME. ACME is undergoing IETF standardisation after being first used by Let's Encrypt. StartAPI was launched at the end of April 2016 and allowed users to programmatically acquire certificates as well as complete the validation processes required to prove domain ownership. StartEncrypt was the official client application which was released just over a month later. The proprietary software can be used to obtain any class of certificate and install it automatically both on Windows and Linux servers. A number of serious issues<https://www.computest.nl/blog/startencrypt-considered-harmful-today/> have already been discovered since the release of the initial version of the StartEncrypt client, these allowed a user to gain valid SSL certificates by tampering with the URL used to verify control of a domain. StartCom was quick to respond to this issue, taking the API offline on the same day that the issue was disclosed and issuing an updated client less than a week later. The issues lay with the way in which ownership of the domain was verified. In order to prove domain ownership the user must upload a file to a specified path on the domain, but the path used could be specified by the user, the check also followed redirects and didn't verify the file type of the response it received. Combined these issues led to users being able to acquire a valid certificate for any website that allowed file uploading or contained an open redirect, examples include sites such as Dropbox, GitHub, Facebook, PayPal and Google. While the vulnerability was demonstrated with a proof of concept, there is no evidence that the API was mis-used or certificates issued for domains which the applicant did not control. Another bug<https://www.startssl.com/NewsDetails?date=20160323>in the StartEncrypt system meant that certificates issued using the program were not logged to Certificate Transparency servers. StartCom had stated that all of its SSL certificates would be published to CT logs as of 23rd March. Let's Encrypt leak user email addresses On the 11th June an automated email script designed to alert users of an update to Let's Encrypt's subscriber agreement accidentally also leaked the email addresses of 7,617 users. The script prepended the email addresses of the users it had already emailed to the beginning of the message. Let's Encrypt were alerted to the mistake 33 minutes after the emails began to send and subsequently stopped the script after it had sent 7,618 emails, 1.9% of the total it was expected to send. An initial statement<https://community.letsencrypt.org/t/email-address-disclosures-preliminary-re...> by Josh Aas the Executive Director of ISRG was published less than two hours after the incident originally occurred with a longer analysis<https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/1...> following on the 14th June. Symantec acquire Blue Coat Symantec has agreed to acquire the market leading web security company Blue Coat for $4.65 billion<https://www.symantec.com/en/uk/about/newsroom/press-releases/2016/symantec_0...>. The deal will see Blue Coat CEO Greg Clark appointed as the new CEO of Symantec, the post is currently vacant following Mike Brown's departure in April. The acquisition will boost Symantec's enterprise security offerings and is expected to mean that 62% of the company's revenue<http://www.reuters.com/article/us-bluecoat-m-a-symantec-idUSKCN0YZ0BM> will be derived from the enterprise security market. Blue Coat and Symantec recently made headlines<http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/> after Symantec issued an intermediate CA certificate for Blue Coat Public Services. Blue Coat creates security systems that include the capability to man-in-the-middle encrypted traffic, designed for use in corporate networks. Some reports of the use of Blue Coat systems by foreign governments have prompted criticism, although Blue Coat has consistently denied having any direct involvement. The existence of the sub-CA was incorrectly reported as allowing Blue Coat the ability to create trusted certificates for arbitrary domains; however, Symantec confirmed<http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-i...> that "private keys for the Blue Coat Intermediate CA were in Symantec's control at all times" and "the only certificates that could be issued from this Intermediate CA were limited solely to ones for the bluecoat.com<http://bluecoat.com/> domain.". Other News * Microsoft update cipher suites<https://support.microsoft.com/en-us/kb/3161639> for IE and Edge. * Mozilla adding support for reading from Windows Cert Stores<https://cabforum.org/2016/05/25/2016-05/> to Firefox. * GitHub Pages officially support HTTPS<https://github.com/blog/2186-https-for-github-pages> and new sites enforce it. * Amazon is now HTTPS site wide. * UK government updates security guidelines<https://gdstechnology.blog.gov.uk/2016/06/28/updating-our-security-guideline...> to enforce HTTPS, HSTS and DMARC by October 2016. * Microsoft Edge adds support for TLS False Start and TCP Fast Open<https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-se...>. Copyright © Netcraft 2016. All Rights Reserved. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Some information on the SSL industry and certificate types can be found here: https://www.netcraft.com/internet-data-mining/ssl-survey/. I'm not sure I understand your reference to "basic SSL certificates." It appears there are several types of SSL certificates (according to the page above, at least the following: "*domain-validated* certificates simply validate control over a domain name; *organisation-validated* certificates include the identity of the organisation; and *Extended Validation* certificates increase the level of identity checking"), and that Let's Encrypt is offering only domain-validated certificates, the most basic type (but that's not entirely clear). The distinction between Let's Encrypt and commercial Certificate Authorities seems to be (a) it's free and (b) its process is automated. There doesn't appear to be any difference in the certificate itself. Indeed, Let's Encrypt appears to rely on a commercial CA to cross-sign its certificates, since Let's Encrypt certificates are not yet trusted by most browsers. I'm also not sure I understand your thought " I cannot imagine a significant volume of these certificates are purchased on a daily basis, " I would tend to imagine the opposite. I see that Let's Encrypt, which is not by any means a major CA, issued over a million certificates in 16 months. I assume the major certificate authorities each have numbers that are a multiple of that, although it appears there are different ways to count certificates. As for whether this applies to a "handful of businesses worldwide." I've seen reference to a 2012 EFF study that said there were over 650 Certificate Authorities. The study first referenced above does show that a much smaller number have a significant share of the market, but that still doesn't jibe with your assumption. I'm also not sure that any of this really matters. It's not up to us to change real-world use cases. If Certificate Authorities use WHOIS data in their validation process, that's a fact. Whether you think they should use something else doesn't really matter. I also find it quite odd that you are attempting to minimize this use case. This is clearly both an important and widespread use case. Greg On Mon, Aug 15, 2016 at 5:41 PM, Ayden Férdeline <icann@ferdeline.com> wrote:

Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.)

- Ayden

-------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 9:00 PM UTC Time: August 15, 2016 8:00 PM From: gtheo@xs4all.nl To: icann@ferdeline.com,Geoffrey_Noakes@symantec.com gnso-rds-pdp-wg@icann.org

Hi Ayden,

These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name.

The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser.

Best regards,

Theo Geurts

On 15-8-2016 20:16, Ayden Férdeline wrote:

If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate?

If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money?

The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags?

- Ayden

-------- Original Message -------- Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP Local Time: August 15, 2016 6:40 PM UTC Time: August 15, 2016 5:40 PM From: Geoffrey_Noakes@symantec.com To: gnso-rds-pdp-wg@icann.org

I’ve attached a use case for WHOIS/RDP.

Thanks…

Geoff

*From:* Lisa Phifer [mailto:lisa@corecom.com <lisa@corecom.com>] *Sent:* Monday, August 15, 2016 10:37 AM *To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com> <Geoffrey_Noakes@symantec.com> *Subject:* RE: Use Case

Hi Geoff, it's <gnso-rds-pdp-wg@icann.org>

For further info, see mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/

As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs@icann.org know.

Thanks again Lisa

At 11:19 AM 8/15/2016, Geoffrey Noakes wrote:

Lisa, what is the “WG email list” email address?

*From:* Lisa Phifer [ mailto:lisa@corecom.com <lisa@corecom.com>] *Sent:* Monday, August 15, 2016 10:17 AM *To:* Geoffrey Noakes <Geoffrey_Noakes@symantec.com> *Subject:* RE: Use Case

Thanks Geoff and welcome back. I hope you had an excellent vacation.

I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda.

In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention.

Best, Lisa

At 11:11 AM 8/15/2016, you wrote:

+Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this

Chuck, I am just back from a week of PTO. I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS.

I would prefer the August 23 date – I am on jury duty the week of August 29-September 2.

Thanks…

Geoff

From: Gomes, Chuck [ mailto:cgomes@verisign.com <cgomes@verisign.com>]

Sent: Monday, August 15, 2016 9:53 AM

To: Geoffrey Noakes < Geoffrey_Noakes@symantec.com>

Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead@icann.org) < gnso-next-gen-rds-lead@icann.org>

Subject: Use Case

Geoff,

You volunteered to prepare a use case for Certificate Authorities. We hope to discuss that use case in the WG meeting on either August 23 or August 30? Which date would work better for you? In either case, we would need the use case to be submitted to the WG list 24 hours in advance.

Hope you are having a good vacation.

Chuck

_______________________________________________ gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg