Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item

Yoav Nir <> Thu, 02 June 2011 04:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DE6AE068F; Wed, 1 Jun 2011 21:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.979
X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nYv4ApGYkawW; Wed, 1 Jun 2011 21:10:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98CC1E0676; Wed, 1 Jun 2011 21:10:56 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p524AriS024146; Thu, 2 Jun 2011 07:10:53 +0300
X-CheckPoint: {4DE719E9-0-1B221DC2-FFFF}
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 2 Jun 2011 07:10:53 +0300
Received: from ([]) by ([]) with mapi; Thu, 2 Jun 2011 07:10:53 +0300
From: Yoav Nir <>
To: "Michael D'Errico" <>
Date: Thu, 2 Jun 2011 07:10:52 +0300
Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
Thread-Index: Acwg2w/ucXVWFeMOTFGqsb86yZzLiQ==
Message-ID: <>
References: <> <> <> <p06240814ca0c32f70867@> <> <p0624081bca0c624c205a@> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, Paul Hoffman <>, TLS Mailing List <>
Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
X-Mailman-Version: 2.1.12
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: Thu, 02 Jun 2011 04:10:59 -0000

On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote:

> Paul Hoffman wrote:
>> I support the PKIX WG adopting as a work item (wording taken from the CAA draft's text) "DNS Resource Records that allow a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain".
> I haven't read the draft, but from the quote it appears that
> this could improve the weakest part of TLS (as it is used
> today in browsers) where any of the hundreds of preinstalled
> root CAs is trusted to issue a certificate to any possible
> domain name.

I'm not opposed to this draft, but I don't think it solves this problem. The issue is not even the dozens of pre-installed root CAs, but that those root CAs can have many many affiliates, whether they're sub-CAs or registration authorities. 

The two famous attacks of the last two years have not been about Verisign or Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the "Verisign trust network" but not Verisign itself. In the recent case it was a small Italian RA. In both cases the problem was an affiliate with not quite best practices that caused the mis-issue.

CAA works if all root CAs and affiliates follow it. That's hundreds or thousands of entities. Any one of them that fails to comply might ignore the CAA record.

PHB says that having the CAA record may aid in assigning blame, and thus perhaps at some point, liability. Remains to be seen, but at least in the short term, CAA is not a panacea.

That's why I believe that the DANE record that is aimed at relying parties is a necessary complement to this work. I know I've said the opposite on the DANE list, but I've changed my mind since then.