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

[benny at nordreg.se]

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 at 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 at gmail.com
>>> To: Geoffrey_Noakes at symantec.com
>> Alex_Deacon at mpaa.org,icann at ferdeline.com,Dean_Coclin at symantec.com,gnso-rds-pdp-wg at 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 at 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 at icann.org
>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] ON BEHALF OF Deacon, Alex
>>> SENT: Monday, August 15, 2016 3:06 PM
>>> TO: Ayden Férdeline <icann at ferdeline.com>
>>> CC: gnso-rds-pdp-wg at 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 at 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 at xs4all.nl
>>> To: icann at ferdeline.com,Geoffrey_Noakes at symantec.com
>>> gnso-rds-pdp-wg at 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 at symantec.com
>>> To: gnso-rds-pdp-wg at icann.org
>>> I’ve attached a use case for WHOIS/RDP.
>>> Thanks…
>>> Geoff
>>> FROM: Lisa Phifer [mailto:lisa at corecom.com]
>>> SENT: Monday, August 15, 2016 10:37 AM
>>> TO: Geoffrey Noakes <Geoffrey_Noakes at symantec.com>
>>> SUBJECT: RE: Use Case
>>> Hi Geoff, it's <gnso-rds-pdp-wg at 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 at 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 at corecom.com]
>>> SENT: Monday, August 15, 2016 10:17 AM
>>> TO: Geoffrey Noakes <Geoffrey_Noakes at 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 at verisign.com]
>>> Sent: Monday, August 15, 2016 9:53 AM
>>> To: Geoffrey Noakes < Geoffrey_Noakes at symantec.com>
>>> Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead at icann.org) <
>>> gnso-next-gen-rds-lead at 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 at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [1]
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [1]
>> ---------- Forwarded message ----------
>> From: Mike Prettejohn <mhp at netcraft.com>
>> To: Diana Marin Severino <Diana_Marin_Severino at symantec.com>, Sue
>> Coakley <Sue_Coakley at symantec.com>, Vijay NS <Vijay_NS at symantec.com>,
>> Sonya Perez <Sonya_Perez at symantec.com>, Eric Lipman
>> <Eric_Lipman at symantec.com>, Laura Aviles <Laura_Aviles at symantec.com>,
>> Jeffrey Whale <Jeffrey_Whale at symantec.com>, Alex Wong
>> <Alex_Wong at symantec.com>, Landon Borup <Landon_Borup at symantec.com>,
>> Alain Allen <Alain_Allen at symantec.com>, Frank Agurto-Machado
>> <Frank_Agurto-Machado at symantec.com>, Charlene Mike-Billstrom
>> <Charlene_Mike-Billstrom at symantec.com>, Rick Andrews
>> <Rick_Andrews at symantec.com>, Anna Sampson <Anna_Sampson at symantec.com>,
>> Eiji Yahagi <Eiji_Yahagi at symantec.com>, Tomonori Sato
>> <Tomonori_Sato at symantec.com>, Christiaan De Villiers
>> <Christiaan_DeVilliers at symantec.com>, Dean Coclin
>> <Dean_Coclin at symantec.com>, Hari Veladanda
>> <Hari_Veladanda at symantec.com>, Robert Hoblit
>> <Robert_Hoblit at symantec.com>, Marisa Luke <Marisa_Luke at symantec.com>,
>> Roxane Divol <Roxane_Divol at symantec.com>, Norie Sato
>> <Norie_Sato at symantec.com>, Masato Hayashi
>> <Masato_Hayashi at symantec.com>, DL-VSN-Data Analysis
>> <DL-VSN-DataAnalysis at symantec.com>, Bill Ng <Bill_Ng at symantec.com>,
>> Geoffrey Noakes <Geoffrey_Noakes at symantec.com>, Tracy Chao
>> <Tracy_Chao at symantec.com>, Tri Tang1 <Tri_Tang at symantec.com>, Jeff
>> Barto <Jeff_Barto at symantec.com>, Theresa Garza
>> <Theresa_Garza at symantec.com>, Sven Skerka <Sven_Skerka at symantec.com>,
>> Helen Bates <Helen_Bates at symantec.com>, Jonathan Skinner
>> <Jonathan_Skinner at symantec.com>, Kevin Brown
>> <Kevin_Brown at symantec.com>, Minori Nakanishi
>> <Minori_Nakanishi at symantec.com>, "leeanne_dewit at netcraft.com"
>> <leeanne_dewit at netcraft.com>, "antec.com at netcraft.com"
>> <antec.com at netcraft.com>, "tristan_fourcault at symantec.com"
>> <tristan_fourcault at symantec.com>, Jun Kamimura
>> <Jun_Kamimura at symantec.com>, Shusuke Nakagawa
>> <Shusuke_Nakagawa at symantec.com>, Lisa Low <Lisa_Low at symantec.com>,
>> Alejandro Borgia <Alejandro_Borgia at symantec.com>, Belinda Charleson
>> <Belinda_Charleson at symantec.com>, Timothy Willey
>> <Timothy_Willey at symantec.com>, Wasi Wahid <Wasi_Wahid at symantec.com>,
>> Jo Ann Lambkin <JoAnn_Lambkin at symantec.com>, Abhijit Solanki
>> <Abhijit_Solanki at symantec.com>, Donald Baker
>> <Donald_Baker at symantec.com>, Harbir Singh <Harbir_Singh at symantec.com>,
>> Michael Klieman <Michael_Klieman at symantec.com>, Takashi Abe
>> <Takashi_Abe at symantec.com>, Helen Lew <Helen_Lew at symantec.com>, Jack
>> Kato <Jack_Kato at symantec.com>, Nicolas Popp
>> <Nicolas_Popp at symantec.com>, Bartosz Begej
>> <Bartosz_Begej at symantec.com>, Jon Kerr <Jon_Kerr at symantec.com>, Roxane
>> Jerbi <Roxane_Jerbi at symantec.com>, Tim Gallo <tim_gallo at symantec.com>,
>> Gautam Kanaparthi <Gautam_Kanaparthi at symantec.com>, Thomas La
>> <Thomas_La at symantec.com>, James Duff <James_Duff at symantec.com>,
>> "aidan_calvert at symantec.com" <aidan_calvert at symantec.com>, Ian McShane
>> <Ian_Mcshane at symantec.com>, Yoshimasa Hiraiwa
>> <Yoshimasa_Hiraiwa at symantec.com>, Robert Lin
>> <Robert_Lin at symantec.com>, Albert Cooley <Albert_Cooley at symantec.com>,
>> Mirco Reimann <Mirco_Reimann at symantec.com>, Jessica Crewse
>> <Jessica_Crewse at symantec.com>, Jason Luong <Jason_Luong at symantec.com>,
>> Rory Tavares <Rory_Tavares at symantec.com>, Asad Faruqui
>> <Asad_Faruqui at symantec.com>, Karina Stiller
>> <Karina_Stiller at symantec.com>, Pavan Bhat <Pavan_Bhat at symantec.com>,
>> "jeannette_duong at symantec.c" <jeannette_duong at symantec.c>,
>> "om at netcraft.com" <om at netcraft.com>, Terri Parker
>> <Terri_Parker at symantec.com>, "K.J.Hari Hara Krishnan"
>> <Hari_Krishnan at symantec.com>, Anna Brannan
>> <Anna_Brannan at symantec.com>, Graeme Watts <Graeme_Watts at symantec.com>,
>> Russel Scovel <Russel_Scovel at symantec.com>, Maren Peasley
>> <maren_peasley at symantec.com>, Tiphany Zellers
>> <Tiphany_Zellers at symantec.com>, Randy Clark
>> <randy_clark at symantec.com>, Susanne Lambert
>> <Susanne_Lambert at symantec.com>, Alex Black <Alex_Black at symantec.com>,
>> Davin Pick <Davin_Pick at symantec.com>, Akhil Verma
>> <Akhil_Verma at symantec.com>, Micheal Brown
>> <Micheal_Brown at symantec.com>, Lee-Lin Thye
>> <Lee-Lin_Thye at symantec.com>, Suhasini Anand
>> <Suhasini_Anand at symantec.com>, Victoria Cloutier
>> <Victoria_Cloutier at symantec.com>, Philip Antoniadis
>> <Philip_Antoniadis at symantec.com>, Ruth Singh
>> <Ruth_Singh at symantec.com>, Thiago Lacerda
>> <Thiago_Lacerda at symantec.com>, "nilanjana_majumdar at symantec.com"
>> <nilanjana_majumdar at symantec.com>, "Sarah Mellor (CS)"
>> <Sarah_Mellor at symantec.com>, Valerie Tsai <Valerie_Tsai at symantec.com>,
>> Deepika Chauhan <Deepika_Chauhan at symantec.com>, Angelique Pereira
>> <Angelique_Pereira at symantec.com>, Rachel Yokum
>> <Rachel_Yokum at symantec.com>, Charlotte Pommier
>> <Charlotte_Pommier at symantec.com>, Ramana Murthy
>> <Ramana_Murthy at 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 at 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_third_party
>> [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-everything/shame-on-you-comodo-t115958.0.html;msg837411#msg837411
>> [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_whats_new_in_security.pdf
>> [17]
>> https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW35
>> [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-report-june-11-2016/16867
>> [22]
>> https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/17025
>> [23]
>> https://www.symantec.com/en/uk/about/newsroom/press-releases/2016/symantec_0612_01
>> [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-its-control
>> [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-guidelines-for-digital-services/
>> [32]
>> https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-secure-web-with-tcp-fast-open-tls-false-start-and-tls-1-3/
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> 
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg