Re: [wpkops] draft-housley-web-pki-problems-00

Rick Andrews <Rick_Andrews@symantec.com> Wed, 08 July 2015 19:47 UTC

Return-Path: <Rick_Andrews@symantec.com>
X-Original-To: wpkops@ietfa.amsl.com
Delivered-To: wpkops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096FA1A8716 for <wpkops@ietfa.amsl.com>; Wed, 8 Jul 2015 12:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 zmiP9UrKW98H for <wpkops@ietfa.amsl.com>; Wed, 8 Jul 2015 12:47:17 -0700 (PDT)
Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5AD1A8702 for <wpkops@ietf.org>; Wed, 8 Jul 2015 12:47:16 -0700 (PDT)
X-AuditID: a66201d2-f79716d000002214-1a-559d7e438caf
Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 0D.F9.08724.34E7D955; Wed, 8 Jul 2015 19:47:15 +0000 (GMT)
Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from <Rick_Andrews@symantec.com>) id 1ZCvJL-0007TI-3i; Wed, 08 Jul 2015 19:47:15 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Wed, 8 Jul 2015 12:47:20 -0700
From: Rick Andrews <Rick_Andrews@symantec.com>
To: Gervase Markham <gerv@mozilla.org>, "wpkops@ietf.org" <wpkops@ietf.org>
Date: Wed, 08 Jul 2015 12:47:13 -0700
Thread-Topic: [wpkops] draft-housley-web-pki-problems-00
Thread-Index: AdC5b2jP+SBwUIrTTsSM5/mk+eEYMwAQdHog
Message-ID: <544B0DD62A64C1448B2DA253C01141461922CEB934@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <28D7CC3C-E21C-4D01-8F13-F2D661D82D71@vigilsec.com> <559D0644.2060701@mozilla.org>
In-Reply-To: <559D0644.2060701@mozilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0125_01D0B97C.35D725C0"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsVyYMU1bV3nurmhBmt/qFrs2XGNyeLmqe2s DkweS5b8ZPJYfekKawBTFJdNSmpOZllqkb5dAlfG6faNrAWzAivaWvoYGxhn+nQxcnJICJhI fF/7jQnCFpO4cG89WxcjF4eQwAdGidO7JrBAOK8YJe6tPsYM4axklDjRsxOshU1AT2LL4yvs ILaIgLfEt7avrCA2i4CKxOHXC9hAbGEBc4n1s2exQNRYSDy7/ZUJwjaSOPtnF1g9r0CUxO/p lxhBbCGBBIkTc36C1XAKaEscnfgdLM4IdN73U2vA4swC4hK3nsyHOltE4uHF02wQtqjEy8f/ WCHqRSXutK9nBDmaWaCXUeLxxC0sEMsEJU7OfMIygVF0FpJZs5DVzUJSN4uRAyihJ9G2kRGi Xl5i+9s5zBC2tcSMXwfZIGxFiSndD9khbFOJ10c/Mi5g5FjFKJOanGOYW5KYX1pSkFphYKRX XJmbCIzLZL3k/NxNjMDYXJbEeGkH4/3DuocYBTgYlXh410fODRViTSwDqjzEqAI07tGG1RcY pVjy8vNSlUR465KA0rwpiZVVqUX58UWlOanFhxilOViUxHm3P2kMFRJITyxJzU5NLUgtgsky cXBKNTBGTrm1/KVWp6Su751EaamiVTM0OPg49vs/Kzrq9OVO0JRNEnsPqhVWG3ZwSjzXuPWj LLkp3PrMN+mgNm7FGVycrDzrhaujzBnsW1+UdLMty5y77/1F8de3Iz+au+uofzlw9+ofY6td B0M4PGuOSFbcm5vP/X3JpwbxR14bVtWreATbXjNbulWJpTgj0VCLuag4EQDFH+eQ1QIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/wpkops/PAD8vTmqILNxJRo2JkGxjvMJIvI>
Subject: Re: [wpkops] draft-housley-web-pki-problems-00
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wpkops/>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2015 19:47:20 -0000

3.1 It's true that many browsers don't do certificate status checks by
default, but only Firefox (AFAIK) gives the user the option to enable those
checks.

3.4 " Despite this situation, at least one major browser does not support
name constraints, and as a result, CAs are reluctant to use name
constraints." That's true, but it's only part of the story. Symantec (as an
example) issues certificates to FQDNs in practically all TLDs, ccTLDs, gTLDs
including many of the newly-approved ones. It's simply not practical for us
to use name constraints on our issuing CAs. And in the small number of cases
where we issued an issuing CA to an external third party, every single one
has rejected the idea of name constraints because they all wanted the
ability to issue to newly-acquired domain names. 

4.1.  Determination of the Trusted Certificate Authorities
" The browser vendors and the CAs determine what should and should not be
trusted by default." Not true; only the browser vendors determine what
should and should not be trusted. CAs have no control over their decisions.

Under " 5.  Emerging Technical Improvements" you might add the use of
Content Delivery Networks. Most major CAs today use CDNs to deliver CRLs and
OCSP responses, resulting in high availability and low latency for clients.
However, browser vendors still eschew status checking. 

5.1.1 " Sadly, few CAs take advantage of the CRLDP certificate extension." I
don't agree. Most of the CAs I'm aware of still add CRLDP extensions, even
though they're not required by the CABF Baseline Requirements and largely
ignored by browsers.

5.2.1 DANE
" DNSSEC has a single root domain as opposed to a multiplicity of trusted
CAs" It's true that DNSSEC has a single root domain, but if fully deployed,
every domain owner would also have to manage their own PKI. It's not
trivial, and there are no audit or compliance standards for this. 

I would suggest that you mention the multiple DANE modes of operation. In
two of the modes, no PKIX chain validation is needed; hence a self-signed
cert might appear as trustworthy as a CA-signed cert.