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

Tom Gindin <tgindin@us.ibm.com> Thu, 09 June 2011 12:11 UTC

Return-Path: <tgindin@us.ibm.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 9852311E809A; Thu, 9 Jun 2011 05:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 nHJ7IDvoDkNe; Thu, 9 Jun 2011 05:11:07 -0700 (PDT)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 637BA11E807C; Thu, 9 Jun 2011 05:11:05 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p59BeVEH006700; Thu, 9 Jun 2011 07:40:31 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p59CAuxu105006; Thu, 9 Jun 2011 08:10:56 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p598Aiph006468; Thu, 9 Jun 2011 05:10:44 -0300
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p598AicL006465; Thu, 9 Jun 2011 05:10:44 -0300
In-Reply-To: <BANLkTikp5P1WhvA2ms58KxS+8ohSBv-FWQ@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> <BANLkTikp5P1WhvA2ms58KxS+8ohSBv-FWQ@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
MIME-Version: 1.0
X-KeepSent: B299299E:1FCA02D8-852578A9:0052F9E2; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
From: Tom Gindin <tgindin@us.ibm.com>
Message-ID: <OFB299299E.1FCA02D8-ON852578A9.0052F9E2-852578AA.0042ECF4@us.ibm.com>
Date: Thu, 9 Jun 2011 08:10:54 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/09/2011 08:10:55, Serialize complete at 06/09/2011 08:10:55
Content-Type: text/plain; charset="US-ASCII"
X-Mailman-Approved-At: Wed, 15 Jun 2011 09:04:12 -0700
Cc: pkix <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: Thu, 09 Jun 2011 12:11:09 -0000

        This check seems to be primarily useful when the CA gives high 
(arguably too high) levels of trust to multiple RA's, and the CA is more 
carefully operated than some and perhaps all of its RA's.  Is that 
situation unique to Comodo, or are they the extreme case of a common 
arrangement when there are independent RA's?  This is a reasonable 
suggestion if there are other CA's half as vulnerable as Comodo.

                Tom Gindin
P.S. - The opinions above are mine, and not necessarily those of my 
employer



From:   Phillip Hallam-Baker <hallam@gmail.com>
To:     Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc:     pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org
Date:   06/08/2011 08:58 AM
Subject:        Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item
Sent by:        pkix-bounces@ietf.org



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:
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/
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix