IETF Logo Mail Archive

Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan

Wayne Thayer <wthayer@godaddy.com> Wed, 05 February 2014 03:12 UTC

Return-Path: <wthayer@godaddy.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65651A0012 for <therightkey@ietfa.amsl.com>; Tue, 4 Feb 2014 19:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja3DfEWD-lYo for <therightkey@ietfa.amsl.com>; Tue, 4 Feb 2014 19:12:12 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id DB9FE1A000C for <therightkey@ietf.org>; Tue, 4 Feb 2014 19:12:11 -0800 (PST)
Received: from CO1PR02MB064.namprd02.prod.outlook.com (10.242.163.16) by CO1PR02MB062.namprd02.prod.outlook.com (10.242.163.12) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 03:12:09 +0000
Received: from CO1PR02MB064.namprd02.prod.outlook.com ([169.254.5.65]) by CO1PR02MB064.namprd02.prod.outlook.com ([169.254.5.16]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 03:12:09 +0000
From: Wayne Thayer <wthayer@godaddy.com>
To: Ryan Sleevi <sleevi@google.com>, Jeremy Rowley <jeremy.rowley@digicert.com>
Thread-Topic: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan
Thread-Index: AQHPIhtL+WmzA48PxEuQCqmiz/uBapql9VYA//+RLgA=
Date: Wed, 05 Feb 2014 03:12:08 +0000
Message-ID: <CF16F6CD.678E6%wthayer@godaddy.com>
References: <CABrd9STwBDxwB1vtmS9Ozb5e_7D=zfOqkOBeAaT2HG7X-cw5gw@mail.gmail.com> <647dad549e3047e4a94c721a616f1dee@CO1PR02MB064.namprd02.prod.outlook.com> <CACvaWvYb-anrri8rzxNDee_UW4AKM7uNC7j7UwHqPRnK4oQiFw@mail.gmail.com> <CF16EFDA.678DA%wthayer@godaddy.com> <08b001cf221b$4cd7b4a0$e6871de0$@digicert.com> <CACvaWvbyUpWK2ODOzsUKWshdzdwK_=cXe5nLjkOHUSK_VmAAWg@mail.gmail.com>
In-Reply-To: <CACvaWvbyUpWK2ODOzsUKWshdzdwK_=cXe5nLjkOHUSK_VmAAWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [68.231.156.37]
x-forefront-prvs: 01136D2D90
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(24454002)(189002)(199002)(19580405001)(87936001)(81686001)(80976001)(85852003)(92566001)(92726001)(83072002)(76786001)(46102001)(54356001)(2656002)(16236675002)(77096001)(51856001)(53806001)(4396001)(76796001)(81816001)(19580395003)(66066001)(83322001)(90146001)(50986001)(47976001)(49866001)(36756003)(81342001)(94316002)(47446002)(80022001)(65816001)(74876001)(74502001)(93516002)(93136001)(56816005)(74662001)(81542001)(86362001)(74366001)(47736001)(85306002)(56776001)(87266001)(54316002)(69226001)(94946001)(77982001)(79102001)(59766001)(31966008)(74706001)(63696002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB062; H:CO1PR02MB064.namprd02.prod.outlook.com; CLIP:68.231.156.37; FPR:1E58F0F5.A7D6C7C2.E1D3370B.88E9E15C.203AA; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CF16F6CD678E6wthayergodaddycom_"
MIME-Version: 1.0
X-OriginatorOrg: godaddy.com
Cc: therightkey <therightkey@ietf.org>, Ben Laurie <benl@google.com>, certificate-transparency <certificate-transparency@googlegroups.com>, CABFPub <public@cabforum.org>
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 03:12:21 -0000

On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <jeremy.rowley@digicert.com<mailto:jeremy.rowley@digicert.com>> wrote:
I'm confused as well.  Does that mean Android will start showing an EV indicator?

From: therightkey [mailto:therightkey-bounces@ietf.org<mailto:therightkey-bounces@ietf.org>] On Behalf Of Wayne Thayer
Sent: Tuesday, February 04, 2014 7:33 PM
To: Ryan Sleevi
Cc: therightkey@ietf.org<mailto:therightkey@ietf.org>; Ben Laurie; certificate-transparency@googlegroups.com<mailto:certificate-transparency@googlegroups.com>; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan


Hi Wayne,

Considering we already do not indicate EV on Android, nor have we ever, I don't think this perceived loss of functionality is as significant as you may believe.

Further, considering the very real and distinct performance characteristics of mobile (radio warmups, RTTs, initcwnds), the idea of fetching OCSP, or, worse, CRLs - especially when some CAs have CRLs that are quite large (20+ MB) - in order to assure the EV display is... non-ideal. So again, the EV indicator on mobile is not as strong or as present as it may be on desktop platforms.

In that case, what does this statement mean?


Chrome for mobile platforms will cease to show EV indicators for certificates that are not CT qualified according to the criteria below.

It means that for any CAs that hope to be recognized as EV on Chrome for mobile platforms (which include iOS), implementing CT by the dates outlined is seen as a requirement for such treatment. We wanted to specifically call attention to this - the whitelist is seen as a temporary measure for Desktop, but given the unique characteristics of mobile platforms, we're pursuing this requirement at a more aggressive pace.

While Chrome for Android - and the Chrome-based WebView, as the WebView preceding it - do not provide special treatment for EV, any future plans for EV indications on these platforms have incorporated the above requirements and dates.

In that case, my original objection stands - this policy retroactively downgrades existing EV certificates if and when a mobile platform chooses to implement an EV indicator. There are certainly times when it's necessary to apply a new policy to existing certificates to protect relying parties, but IMO this isn't one of them.

v2.23.0 | Report a Bug | By Email