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

Yoav Nir <> Thu, 09 June 2011 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D93B11E80A6; Wed, 8 Jun 2011 23:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.073
X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SIqb6+dJ0n1O; Wed, 8 Jun 2011 23:02:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7640211E8074; Wed, 8 Jun 2011 23:02:37 -0700 (PDT)
X-CheckPoint: {4DF06FFC-F-1B221DC2-FFFF}
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p5962Prd000751; Thu, 9 Jun 2011 09:02:25 +0300
Received: from ([]) by ([]) with mapi; Thu, 9 Jun 2011 09:02:25 +0300
From: Yoav Nir <>
To: Marsh Ray <>
Date: Thu, 9 Jun 2011 09:02:24 +0300
Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
Thread-Index: Acwmas3vqVa1+wROSeCVYqt8EJtOAw==
Message-ID: <>
References: <> <> <>
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: "" <>, "" <>, "" <>
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, 09 Jun 2011 06:02:39 -0000

On Jun 8, 2011, at 7:58 PM, Marsh Ray wrote:

> On 06/08/2011 03:37 AM, Yoav Nir wrote:
>> 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.

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, what are they going to do to check?

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

> Registrant:
>    Yoav Nir
>    Registered through:, Inc. (
>    Domain Name: YOAVNIR.COM
>    Domain servers in listed order:
>    For complete domain details go to:

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:, Inc. (
> Domain Name: YOAVNIR.COM
> Created on: 14-Sep-08
> Expires on: 14-Sep-12
> Last Updated on: 25-Jun-10
> Administrative Contact:
> Nir, Yoav
> Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329 
> Tel. +972.46954329
> Technical Contact:
> Ltd., Interspace
> 19 Yad Harutzim St. Netanya null,42505 Tel. +972.732224444 

This gives some new information. We have an administrative contact: "" and a technical contact: ""

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.