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

        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