Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Phillip Hallam-Baker <> Mon, 04 October 2010 20:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12C893A705D; Mon, 4 Oct 2010 13:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.417
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jq7RAQj4rgdR; Mon, 4 Oct 2010 13:09:38 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id n20mr7962866wbs.61.1286222664553; Mon, 04 Oct 2010 13:04:24 -0700 (PDT)
Received: by with HTTP; Mon, 4 Oct 2010 13:04:24 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 4 Oct 2010 16:04:24 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
Content-Type: multipart/alternative; boundary=0016e65aeaa205d54a0491d00d91
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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.  ESRV "pkix=29823dhd2w3298yf2=="

Some sites might have multiple roots advertised for cases where they are
switching providers:  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.