Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
Phillip Hallam-Baker <hallam@gmail.com> Mon, 04 October 2010 20:09 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C893A705D; Mon, 4 Oct 2010 13:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.417
X-Spam-Level:
X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq7RAQj4rgdR; Mon, 4 Oct 2010 13:09:38 -0700 (PDT)
Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by core3.amsl.com (Postfix) with ESMTP id EA3FE3A6E35; Mon, 4 Oct 2010 13:09:37 -0700 (PDT)
Received: by wyb29 with SMTP id 29so5478558wyb.27 for <multiple recipients>; Mon, 04 Oct 2010 13:10:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=d43dvnWy80d5aja03WclzA+bJsy1oDeu4zDkctIokg8=; b=BvVEslOcGytlH0u9xKotUvhLMrd8AYv7OhslCDmej8TfUAxSHHDSMFVmvu/35gFmsE ZC3an32XaWko1JuKPSGrQJE4LV8Oge7qu0X8BvIzald6qP+yTWI5T2xQuFJjWj5+Kqdi s+W4s6A5eqHPncBVlMY2ho1YRKzHXocvLU6MU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wU5jlHhrzAXJYVZJZq0whbASf0ujt/dq+IzIOB1QsoGSAb4Pso2WlGg3GPPRGxc6bk rzV9rA39J9kncSG+cCwViNjqGQuwgXIELx/MeCpF3XL+KIRktQXd3QjxWRnL2uA+bfyW Mvzu5vxj/AV0F0iidJl7fC2fmBvEOnVgZKX1k=
MIME-Version: 1.0
Received: by 10.227.129.84 with SMTP id n20mr7962866wbs.61.1286222664553; Mon, 04 Oct 2010 13:04:24 -0700 (PDT)
Received: by 10.216.166.9 with HTTP; Mon, 4 Oct 2010 13:04:24 -0700 (PDT)
In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
References: <AANLkTik4MeDWDRxXLkPd8k6HPVeKY9_7p4FQWzyXwvFD@mail.gmail.com> <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
Date: Mon, 04 Oct 2010 16:04:24 -0400
Message-ID: <AANLkTinwihQa4qO1a8o=j82Csx6qMgyTGFmS+ccsbvrD@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="0016e65aeaa205d54a0491d00d91"
Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2010 20:09:40 -0000
<Lots of statements concerning how CAs work> For the past five years, CA certificates have been divided into Domain Validated and Extended Validated. As some of you know, I instigated the process that led to the creation of EV certs because I was very worried about the low quality of many DV certificates. Some DV certificates are of very low quality. Which is why I would like to see the padlock icon phased out entirely. Why does the user need to know if encryption is being used at all? Actually the reason the user need to know that encryption is being used is quite an interesting one and has to do with the lack of a security policy layer for the Internet. If we could guarantee that encryption would always be used when visiting a site where there is a certificate, there would be no need for the padlock icon. But that is a digression. The problem raised by many people here is that a site example.com can get an SSL certificate with the highest available assurance level but a MITM attack can be performed with a low assurance certificate obtained from any of the CAs listed in the browser roots. There are two possible means of attacking this problem 1) Provide a means for determining if a certificate is authorized for use 2) Sanction CAs that issue unauthorized certificates The TLSFP approach only allows the first approach to be employed. My approach, publication of the authorized CA roots permits both approaches to be employed. The way I see this working is that each CA would publish a record that customers could publish in their DNS zone to state that other CAs should not issue certs. This would have the Digest of either the root key or an intermediate cert. example.com ESRV "pkix=29823dhd2w3298yf2==" Some sites might have multiple roots advertised for cases where they are switching providers: example.com ESRV "pkix=29823dhd2w3298yf2== pkix=2u2queihwiehiuhe==" And there could also be provision for advertising CERT records and so on. We can fill in those details later. Once the necessary record is allocated, a proposal is made to CABForum to require all member CAs to verify every cert against these DNS records before issue. I believe that there should be a very high degree of voluntary compliance since it is a check that can be automated. After a short interval the mechanism is made mandatory. The browser and platform providers have the necessary tools to achieve this. They can require the checks to be specified in the annual WebTrust audit which means that every cert would have to be in compliance within a year. Non compliant certificates would be detected as a matter of course by the various companies who have reason to crawl the Web and look at SSL certs. Note that my approach does not require client implementation to be effective, but allows for client implementation if this is considered desirable and is equally effective as a means of client side enforcement.
- [TLS] Cert Enumeration and Key Assurance With DNS… Phillip Hallam-Baker
- Re: [TLS] Cert Enumeration and Key Assurance With… Ben Laurie
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Matt McCutchen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ben Laurie
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Peter Gutmann
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Geoffrey Keating
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] Cert Enumeration and Key Assurance With… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Jakob Schlyter
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Andrew Sullivan
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- [TLS] OtherCerts & pinning (Was: Re: [pkix] Cert … Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Kemp, David P.
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Seth David Schoen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Kent
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Paul Hoffman
- Re: [TLS] Cert Enumeration and Key Assurance With… Nicolas Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Peter Gutmann
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Yaron Sheffer
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Henry B. Hotz
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … der Mouse
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Carl Wallace
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [saag] [pkix] Cert Enumeration … Doug Barton
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Bruno Harbulot
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Paul Wouters