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

From: Michael D'Errico <[email-masked]>
Date: Wed, 01 Jun 2011 17:12:37 -0700

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.

[CC'ed to the TLS working group]

Mike

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jun 2011 07:10:52 +0300

> root CAs is trusted to issue a certificate to any possible

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.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 09:45:58 -0400

That is not quite right.

First off, measurement of the failure rate of CAs is rather difficult
because we only actually know the failure rate for CAs that self-report. It
is not zero but it is close enough to being zero that people can work
themselves up into a lather about it.

At the end of the day buffer over-run exploits will still trump any
deficiencies in the CA infrastructure. But those don't have people running
round suggesting urgent remedies because they are too common to bear notice.
CAs and RAs are definitely not the weakest link in the chain here. Anyone
claiming that is either grandstanding or has failed to pay attention.

But more importantly, an RA does not have issuing power by definition. Only
a CA can issue certificates because that is the definition of a CA. The
intention of CAA is that it be enforced by the CA so that an RA cannot issue
a non compliant cert either.

One area where I could see a possible use case for extending CAA would be to
enable better RA management controls. For example the vast majority of the
'RAs' identified in the EFF study are actually intermediate roots assigned
to RAs at educational institutions. Such RAs only have general issuing
powers in a minority of circumstances.

We had some discussion of this after my SAAG presentation.

Here is the issue: some of these controls will be technical and some will be
policy. Some of these controls will be the type of thing IETF likes to work
on and some will not. That is why we have CABForum.

And then another question that naturally comes up is how much of this we
should do in phase 1 and whether we should attempt to do everything at once
or to do the lowest of the low hanging fruit first, gain some experience and
then add in features to support additional use cases.

The final point made is that some CAs may not want to support CAA. I can't
see why this would be so unless either:

1) The technology is deficient (something PKIX might fix).
2) They really want to be able to issue fraudulent certificates.
3) They resist change for the sake of it.
4) It is not yet an IETF standard

Now I have no idea which of the above might apply if any. But the only way
to find out is going to be to deploy.

This is still a worthwhile exercise if the only effect is to identify CAs
that wish to issue fraudulent certificates. The IETF does not have the power
to police such CAs but others do.

On Thu, Jun 2, 2011 at 12:10 AM, Yoav Nir <[email-masked]> 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'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.
>
> Yoav
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jun 2011 18:37:36 +0300

On Jun 2, 2011, at 4:45 PM, Phillip Hallam-Baker wrote:

> 
> The final point made is that some CAs may not want to support CAA. I can't see why this would be so unless either:
> 
> Now I have no idea which of the above might apply if any. But the only way to find out is going to be to deploy. 

I can offer a couple of others
 5) They're too lazy to care
 6) It's cheaper to not do anything than to do something

In late 2008, when some researchers got RapidSSL to sign a certificate request that collided with their rogue sub-CA certificate, several things came to light:
 - They were using MD5 10 years after RFC 2459 recommended not to
 - They were a ridiculously small company, with the only full-time employee. An accountant
 - They were doing a bunch of other "industry worst practices" - every field in the certificate was predictable

The root problem is that the RapidSSLs of the world issue certificates that are considered by browsers to be just as valid as any DV certificate issued by responsible CAs. So getting a certificate that validates is as easy as getting a rogue certificate from the worst CA or sub-CA. And with so many to choose from, I'm sure it will be possible to find one that didn't implement CAA correctly.

It's still worthwhile, IMO. Because maybe that particular CA that implemented CAA wrong is not using MD5, or maybe they have some other security mechanism done right. It may very well help thwart the next researcher or hacker. I just don't think it's the ultimate solution to the "weakest link" problem.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Thu, 02 Jun 2011 11:07:05 -0500

On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote:
> deficiencies in the CA infrastructure. But those don't have people
> running round suggesting urgent remedies because they are too common to
> bear notice. CAs and RAs are definitely not the weakest link in the
> chain here. Anyone claiming that is either grandstanding or has failed
> to pay attention.

Well that depends entirely on the chain in question doesn't it?

Not everything that uses TLS or certificates is an unpatched web browser 
with Adobe plugins operated by an ignorant user for the purpose of 
securing nothing particularly important.

Over time it becomes increasingly difficult for _any_ distributed 
application to run over ports other than TCP 443 due to the growth of 
egress filtering. So stuff is bundled in with web traffic that may, in 
fact, be implemented for high security requirements.

Perhaps a solution is to implement your own application-specific trust 
root that doesn't rely on the current profusion of CAs. But as an 
application developer I can attest to the fact that it's difficult to 
use standard platform TLS libraries without also trusting everything in 
the system root store, too. Some sites will insist on using their own 
in-house CAs too, which is fine, but it's further pressure on everything 
else to integrate/be vulnerable with the browser trust model.

The net security world has changed dramatically over the last couple of 
years. We have to move past this 
broken-browser-as-least-common-denominator mentality.

- Marsh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 12:31:13 -0400

On Thu, Jun 2, 2011 at 12:07 PM, Marsh Ray <[email-masked]> wrote:

> with Adobe plugins operated by an ignorant user for the purpose of securing
> nothing particularly important.
>

I hear you.

But lets be realistic here, we are currently actually doing worse for non
browser security.

The weakest link in the TLS protocol is actually the end user who is for
some bizarre reason expected to be looking for padlock icons and green bars
and know when to look for which one.

This is even more problematic when applying TLS to Web services as there
isn't even a user to make the decision and no real idea of what should do
that instead.

CAA is not going to solve every problem associated with trust on the
Internet and CA infrastructure. Nor is TLS and nor is strict security. But I
do think that a combination of those three ideas can make a major step
forward.

That is why CAA is designed to be arbitrarily extensible with a tag-value
format even though there are only two property tags currently defined. I
really like the work that Paypal and Jeff Hodges have been doing and would
like to have a way to eventually bring CAA into alignment there.

But for the moment we have to avoid 'crossing the streams' as Stephen F. put
it to me.

Lets work on the part of the problem that we can while the Web Security folk
work on understanding the complexities of what strict security involves.

> Perhaps a solution is to implement your own application-specific trust root
> that doesn't rely on the current profusion of CAs. But as an application
> developer I can attest to the fact that it's difficult to use standard
> platform TLS libraries without also trusting everything in the system root
> store, too. Some sites will insist on using their own in-house CAs too,
> which is fine, but it's further pressure on everything else to integrate/be
> vulnerable with the browser trust model.
>

Yes and that may well end up motivating a mechanism to allow for protocol
specific path properties so that enterprises can have separate CAs
authorized for separate protocols.

Web Services security is a big part of what I am interested in supporting
here. We went into the Web Services world with certain interests promoting
UDDI as the central directory to make it all work. So now we have a protocol
stack predicated on the existence of a directory with no directory to work
with.

I have some ideas there, but again, that would be crossing the streams at
this point. I think the way to get traction there will be to propose a Web
Service application with some pretty severe security requirements and make
that the test application for a framework designed to 'do it right'.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 03 Jun 2011 14:55:34 +1200

Yoav Nir <[email-masked]> writes:

>In late 2008, when some researchers got RapidSSL to sign a certificate
>request that collided with their rogue sub-CA certificate, several things
>came to light:

I wasn't aware of this one, do you have any pointers to info on this?  I guess 
a Webtrust audit doesn't check whether you have more than a single employee :-).

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 02 Jun 2011 22:53:59 -0500

On 06/02/2011 09:55 PM, Peter Gutmann wrote:
> Yoav Nir<[email-masked]>  writes:
>

I think he's referring to Stevens, Sotirov, et al. 2008
http://www.win.tue.nl/hashclash/rogue-ca/
which I'm sure you heard about.

I hadn't heard the part about the single employee though.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 03 Jun 2011 16:03:19 +1200

>I hadn't heard the part about the single employee though.

That's the bit I hadn't heard before.  Sounds a bit minimal for a commercial
CA.  Perhaps the OP confused it with Honest Achmed.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Jun 2011 09:53:41 +0300

> a Webtrust audit doesn't check whether you have more than a single employee :-).

I'm not sure where I've read it. Probably some blog entry about the incident. Not Bruce Schneier's because his entries are still online. 

Anyway, checking the data for now, Business Week has this:
http://investing.businessweek.com/research/stocks/private/people.asp?privcapId=20888814

It lists two "key executives", VP Marketing and VP Sales and no CEO/President. Click their links, and both have other jobs at Globalsign and other companies.

The key issue is the total lack of in-house expertise. Late in 2008, it wasn't RapidSSL that switched to MD5. Verisign did it for them:
http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-RapidSSL-certificates

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Jun 2011 01:44:58 -0700

>> - They were a ridiculously small company, with the only full-time employee.
...
> http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-RapidSSL-certificates

RapidSSL is owned by GeoTrust which at the time was owned by VeriSign
(thus the press release), and now by Symantec.  It wouldn't surprise
me if RapidSSL itself has no employees at all.  I don't think Business
Week's data is reliable in this case.

---

From: koichi sugimoto <[email-masked]>
Date: Tue, 7 Jun 2011 10:31:59 +0900

Dear Sirs,

I've heard the fact was as follows:

-------------------------------------------------------------------------
Paul Tourret and Steve Waite were independent agents assigned the
responsibility of sales and marketing for the RapidSSL brand, acting under
a company called Certification Services Ltd (CSL). Verisign served
termination notice to CSL immediately after the announcement of the
GeoTrust acquisition. CSL then later changed its name to GlobalSign
Limited following successful acquisition of GlobalSign NV. RapidSSL.com
was, and always had been, an SSL brand owned in full by GeoTrust Inc.
GeoTrust elected to represent the brand as a business unit and as
mentioned above, Paul Tourret and Steve Waite were assigned as "agents" to
promote the brand.  All root Certificates and infrastructure was
maintained and operated alongside the GeoTrust branded roots and in
infrastructure operated by GeoTrust Inc.  In 2006 VeriSign acquired
GeoTrust and all its assets, including the RapidSSL brand and root
Certificates.  Paul and Steve ceased their relationship with GeoTrust (now
owned by VeriSign) in late 2006.  At the time of the rogue issuance of
RapidSSL root Certificates, ownership and infrastructure of maintenance
had been under VeriSign's control for over 2 years.  To be clear, VeriSign
did not switch away from MD5 on behalf of RapidSSL, RapidSSL is just a
product brand (not a company) owned in full by VeriSign.
------------------------------------------------------------------------------------------

Regards,
Koichi Sugimoto.

2011/6/5 Yoav Nir <[email-masked]>:
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 08 Jun 2011 18:56:23 +1200

>thousands of entities. Any one of them that fails to comply might ignore the

That was my problem with it, any CA (and/or RA) that's already diligent about 
cert issuance doesn't need CAA, and any one that isn't won't use it anyway, so 
it doesn't address any existing problem.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2011 10:29:35 +0300

> I've heard the fact was as follows:

Thanks for this.

The point remains, that the customers see only the RapidSSL brand, no sign of Verisign on the homepage. And obviously they were running with a very different web application than other Verisign affiliates. Even as just a product brand, some people were assigned to handle the website and the CA, and despite being owned by Verisign, those people apparently weren't doing a very good job.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2011 10:32:48 +0300

> it doesn't address any existing problem.

It would have prevented what has become known as "Comodo-gate". The attacker subverted an RA. If the CA was doing the CAA checking, the attacker would be foiled. If checking the CAA is delegated to the RA, it would not help, but the draft specifically talks about certification authorities.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 08 Jun 2011 19:46:09 +1200

Yoav Nir <[email-masked]> writes:

>It would have prevented what has become known as "Comodo-gate". The attacker
>subverted an RA. If the CA was doing the CAA checking, the attacker would be
>foiled.

> it doesn't address any existing problem.

What makes you class Comodo as a diligent CA?

(Not wanting to re-open the Comodo bashing again, but I'd use "Comodogate" as
a prime example of why CAA won't do much good).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2011 11:37:44 +0300

> What makes you class Comodo as a diligent CA?

What did Comodo fail to do?

The RA is handing contact with the customer, so it's their job to make sure that the customer is in fact the owner of the domain name in the certificate request.

Without CAA, there's nothing left for Comodo to check.

Yoav

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 08 Jun 2011 20:53:26 +1200

>What did Comodo fail to do?

Hmm, this could get back into the Comodo-bashing flamewar, so I'd prefer not
to continue this one... see endless earlier threads on this.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Jun 2011 08:56:10 -0400

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Jun 2011 08:56:51 -0400

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

---

From: Marsh Ray <[email-masked]>
Date: Wed, 08 Jun 2011 11:58:25 -0500

> What did Comodo fail to do?

If this question is seriously being asked by one as knowledgeable as 
Yoav :-), it suggests to me that the problem is being way over-thinked. 
So forgive me, I'm just going to re-state this bluntly:

The entire value proposition of PKI is based on the trusted root CAs 
refusing to issue fraudulent certs and in this case Comodo, a trusted 
root, failed to refuse to issue certain fraudulent certs.

> The RA is handing contact with the customer, so it's their job to
> make sure that the customer is in fact the owner of the domain name
> in the certificate request.

These legal agreements and auditing procedures only amount to one thing: 
after the victim has been (possibly irreparably) harmed by the issuance 
of a fraudulent certificate, then some legal entity is in a technical 
violation of contract with some other legal entity.

In this case, I've heard of no serious repurcussions other than the loss 
of image to the CA and the RAs. Certainly significant for Comodo, but 
most of the press coverage doesn't even mention the names of the hacked RAs.

Is the CA suing any hacked RA for breach of contract? Are they even 
terminating their agreements?

Are browser vendors removing any root CAs or blacklisting any sub-CAs 
due to this?

What are the costs paid for this debacle as perceived by others with the 
authority to cause the immediate issuance of certs?  Most importantly, 
will these costs always be perceived higher than the immediate gain of a 
corrupt transaction? This is not to suggest any corruption in this case 
of course, but it is surely not going unnoticed for the future that the 
CA, the RAs, and the individuals involved all demonstrated effective 
deniability.

This seems like a good test case to either support or refute the 
arguments of those who claim that policies, auditing, and legal 
agreements between CAs/RAs/subCAs are an effective way to produce strong 
security.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 9 Jun 2011 04:44:07 +0200 (MEST)

Peter Gutmann wrote:
> > thousands of entities. Any one of them that fails to comply might ignore
> > the CAA record.
> 
> That was my problem with it, any CA (and/or RA) that's already diligent
> about cert issuance doesn't need CAA, and any one that isn't won't use
> it anyway, so it doesn't address any existing problem.

You're looking at CAA from the wrong angle.

CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...)
It is only another means for a CA to detect attempts to subvert one of
its RAs, so it's primary purpose is CYA for large commercial CAs.

So a Server admin that has a CAA published is not really using it to
_protect_ clients.  It may reduce the likelyhood to get certs
mis-issued, though, and is therefore well in the ballpark of
what businesses are doing to protect against fraud (not protecting
against it, just make it remain under a certain fraud loss threshold).

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jun 2011 09:02:24 +0300

> root, failed to refuse to issue certain fraudulent certs.

Similarly, the value proposition of the DMV is to not issue a driver's license with the name "Marsh Ray" to people who are not Marsh Ray. These days you don't even have to know how to drive.

There is an established "best practice" for how the DMV ascertains who you are: they examine birth certificates, they check street address, etc.

Suppose I go to some RA or CA, and ask for a certificate for www.yoavnir.com, what are they going to do to check?

Obviously, they can check the whois database. This has:

> Registrant:
>    Yoav Nir
> 
>    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
>    Domain Name: YOAVNIR.COM
> 
>    Domain servers in listed order:
>       NS1.GISIGHT.CO.IL
>       NS2.GISIGHT.CO.IL
> 
> 
>    For complete domain details go to:
>    http://who.godaddy.com/whoischeck.aspx?Domain=YOAVNIR.COM

So far, so good. The registrant name is indeed "Yoav Nir". But we're probably doing this through web or email, so how can they know that I'm actually the same "Yoav Nir"?  Or a "Yoav Nir" at all?  We can check through the link to godaddy (I've removed some of the information):

> Registrant:
> Yoav Nir
> Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329 
> 
> Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
> Domain Name: YOAVNIR.COM
> Created on: 14-Sep-08
> Expires on: 14-Sep-12
> Last Updated on: 25-Jun-10
> 
> Administrative Contact:
> Nir, Yoav [email-masked]
> Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329 
> Tel. +972.46954329
> 
> Technical Contact:
> Ltd., Interspace [email-masked]
> 19 Yad Harutzim St. Netanya null,42505 Tel. +972.732224444 

This gives some new information. We have an administrative contact: "[email-masked]" and a technical contact: "[email-masked]"

I have never actually bought an SSL certificate, so I don't know, but I'll have to assume that part of the automated process involves email to one of these addresses. There are also phone numbers, but I can't imagine a DV certificate that costs $10-$40 involving an international phone call by a human.

That's where I would fail. I don't control these email addresses, and the site belongs to another Yoav Nir who's in a totally different line of business.

This is the simple check that a diligent CA can do. But this is as long as the CA is a single entity. 

I don't know of any best practices document that says anything about the division of responsibility between the CA and RA. Is it OK to have only the RA perform the whois check?  Sure, but then what is the added value of the CA?  The reason I like CAA is that it gives an extra layer of security for the CA to perform even assuming that the RA has been subverted.

The way things stand now, I don't see what Comodo could have done differently technically. Sure, we can say that they should not have had a business relationship with an RA that was so easily hackable. Similarly, Verisign should now have allowed rapidssl to use such bad practices. But at the time of the attack, I don't see what check Comodo could have done.

Others (like Peter Gutmann and Bruce Schneier) have written about this before. The model for HTTPS security is what's broken, not a particular CA. There are just too many single points of failure. CAA is an attempt to make the existing model somewhat better, by adding another layer of security - a security check that the CA can do after the RA has already approved the transaction. DANE is a more revolutionary solution that aims to replace or supplement the existing model. I think both have value, with CAA having value much sooner.

Yoav

---

From: Tom Gindin <[email-masked]>
Date: Thu, 9 Jun 2011 08:10:54 -0400

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 <[email-masked]>
To:     Peter Gutmann <[email-masked]>
Cc:     [email-masked], [email-masked], [email-masked]
Date:   06/08/2011 08:58 AM
Subject:        Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item
Sent by:        [email-masked]

On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker <[email-masked]> 
wrote:

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.