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

Yoav Nir <> Thu, 02 June 2011 15:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 573B8E07CC; Thu, 2 Jun 2011 08:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.53
X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z4Zq6YCy7-K3; Thu, 2 Jun 2011 08:40:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C1F95E06FD; Thu, 2 Jun 2011 08:40:14 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p52FeBKR008989; Thu, 2 Jun 2011 18:40:11 +0300
X-CheckPoint: {4DE7BB74-17-1B221DC2-FFFF}
Received: from ([]) by ([]) with mapi; Thu, 2 Jun 2011 18:40:11 +0300
From: Yoav Nir <>
To: Phillip Hallam-Baker <>
Date: Thu, 2 Jun 2011 18:37:36 +0300
Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
Thread-Index: AcwhO1t+ULi0hC8VSoeVpXSIgYhHIw==
Message-ID: <>
References: <> <> <> <p06240814ca0c32f70867@> <> <p0624081bca0c624c205a@> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, Paul Hoffman <>, TLS Mailing List <>
Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Jun 2011 15:40:16 -0000

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:
> 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. 

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.