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

Phillip Hallam-Baker <> Wed, 08 June 2011 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1A5721F852C; Wed, 8 Jun 2011 05:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dybddd2mWtha; Wed, 8 Jun 2011 05:57:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B0F1221F8558; Wed, 8 Jun 2011 05:56:51 -0700 (PDT)
Received: by gxk19 with SMTP id 19so243199gxk.31 for <multiple recipients>; Wed, 08 Jun 2011 05:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0vNTszsGe9xsKRxpYvhryin3rETsB0+1GZaEtf32eyw=; b=c7flDXWbqoo0TMwBPOkHnMVVpaA9PSqAfFD2jEZkXZh1hVrxv7uJmAcRW3NK61Mr9L TQT118dMVuK4GmbK/yjhwPoNYKkn2YDztlC2s/lP72Z00i8U0XJUmQSGIP5HTNIkQGBX ZlGDvk4rZ/DIzkQnzuoBohuyvWIhEEb7CH1Qc=
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=hHtbxP1bgl+tusyg1HM1C0XvL5AXnqnoMgTFpwoYjHauRwIjoH2ZiuBNQkg9uNVY3g LV71lk0lAi98WDqFueXyLrBle/aA8qsI5LHF/7ybHifChNPQ2NUwoDcN4U0dHPyQZHJD cQgGUccKnxGKK2ONtvNSWbwMlT/b4ATWI4nz8=
MIME-Version: 1.0
Received: by with SMTP id b10mr5965109anl.107.1307537811157; Wed, 08 Jun 2011 05:56:51 -0700 (PDT)
Received: by with HTTP; Wed, 8 Jun 2011 05:56:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 8 Jun 2011 08:56:51 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Peter Gutmann <>
Content-Type: multipart/alternative; boundary=0016368e1f85c3b3ab04a532de03
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: Wed, 08 Jun 2011 12:57:33 -0000

sorry, that should have been, the previous year. CAA was developed in the
fall of 2010.

On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker <>wrote;wrote:

> First off, I think that people need to stop using the -gate suffix. Just
> because a competitor decided that they would attempt to apply it does not
> mean it is justified. That is an old game and a rather silly one in our
> industry. The relevant cautionary text here being John 8:7.
> What differentiates companies in our industry is not whether they are
> breached, it is whether they give prompt, voluntary notice of breaches that
> occur or not. The market leaders in the CA industry have a track record of
> having done so.
> As for CAA being a response to the Iranian attack, Ben, Rob and I developed
> it a year earlier.
> The point of proposals like CAA is not whether they are 'necessary' or not,
> it is whether they mitigate risk. I have never seen a security control
> involving a human element that is guaranteed to be operated with 100%
> accuracy every time. So whenever there are humans involved I like to have
> strength in depth.
> There would be no problem here if browsers actually implemented revocation
> checking either. But we have had that in PKIX specs for 15 years and it
> still isn't deployed in hard fail mode. Which is rather sad when you
> consider that about 70% of the complexity of PKI comes from the need for
> revocation.