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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 08 June 2011 12:57 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5721F852C; Wed, 8 Jun 2011 05:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dybddd2mWtha; Wed, 8 Jun 2011 05:57:32 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (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; d=gmail.com; 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; d=gmail.com; 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 10.101.74.10 with SMTP id b10mr5965109anl.107.1307537811157; Wed, 08 Jun 2011 05:56:51 -0700 (PDT)
Received: by 10.100.41.5 with HTTP; Wed, 8 Jun 2011 05:56:51 -0700 (PDT)
In-Reply-To: <BANLkTikO4W_voMQkoo-gsXAYkMfi09GQyg@mail.gmail.com>
References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> <E1QUEVy-0002cB-JN@login01.fos.auckland.ac.nz> <BANLkTikO4W_voMQkoo-gsXAYkMfi09GQyg@mail.gmail.com>
Date: Wed, 8 Jun 2011 08:56:51 -0400
Message-ID: <BANLkTikp5P1WhvA2ms58KxS+8ohSBv-FWQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=0016368e1f85c3b3ab04a532de03
Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: 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 <hallam@gmail.com>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.
>



-- 
Website: http://hallambaker.com/