Re: [TLS] Proposing CAA as PKIX Working Group Item
Phillip Hallam-Baker <hallam <at> gmail.com>
2011-06-02 13:45:58 GMT
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 <ynir <at> checkpoint.com>
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.
On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote:
> 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.
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.
TLS mailing list
TLS <at> ietf.org
pkix mailing list
pkix <at> ietf.org