IETF Logo Mail Archive

Re: [dane] CAA: Isn't this completely backwards?

Stephen Schultze <sjs@princeton.edu> Wed, 01 June 2011 17:45 UTC

Return-Path: <sjs@princeton.edu>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F7BE0949 for <dane@ietfa.amsl.com>; Wed, 1 Jun 2011 10:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Upb4gTyhjX for <dane@ietfa.amsl.com>; Wed, 1 Jun 2011 10:45:50 -0700 (PDT)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EDE0678 for <dane@ietf.org>; Wed, 1 Jun 2011 10:45:49 -0700 (PDT)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa04.Princeton.EDU (8.14.4/8.14.4) with ESMTP id p51HjmSo022998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <dane@ietf.org>; Wed, 1 Jun 2011 13:45:48 -0400
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p51HjmZO029610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <dane@ietf.org>; Wed, 1 Jun 2011 13:45:48 -0400
Message-Id: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu>
From: Stephen Schultze <sjs@princeton.edu>
To: dane@ietf.org
In-Reply-To: <E1QR1tS-0004e5-2X@login01.fos.auckland.ac.nz>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 01 Jun 2011 13:45:47 -0400
References: <E1QR1tS-0004e5-2X@login01.fos.auckland.ac.nz>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-06-01_09:2011-06-01, 2011-06-01, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1106010093
Subject: Re: [dane] CAA: Isn't this completely backwards?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 17:45:51 -0000

On May 30, 2011, at 8:48 AM, Peter Gutmann wrote:
> When I first heard of CAA I thought it was great, a web site owner  
> could
> indicate that only certificates from CA X should be trusted for  
> their site:
>
>  The Certification Authority Authorization (CAA) DNS Resource Record  
> allows a
>  DNS domain name holder to specify the certificate signing  
> certificate(s)
>  authorized to issue certificates for that domain.
> [...]

Right, and the following sentence is:
"Publication of CAA resource records allow a public Certification  
Authority (CA) to implement additional controls to reduce the risk of  
unintended certificate mis-issue."

So the obvious primary purpose is for communication between  
participating CAs, rather than to end users, which you observed...

> Then I saw things like:
>
>  Thus Relying Applications MUST NOT use failure to conform to  
> currently
>  published CAA records as a rejection criteria for certificates  
> unless [...]
>
> OK, so that's not a good start.  What's the intended use for this  
> then?  Let's
> see...
>
>  Examples of Use.
>
>  The following example informs CAs that certificates must not be  
> issued
>  except under [...]

So yes, it's backwards if what you're assuming it is intended to  
indicate anything to end users.  The current draft confuses things,  
because it *does* include discussion of relying parties... although  
seemingly as an afterthought.  I think the CAA authors should drop  
their section 2.3 and any other reference to relying party  
applications and instead focus their relying party energies on DANE --  
in particular the current draft's section 2.3 cert type 2.  That way  
we can all clearly address the issues together.  Paul suggested the  
same thingsix months ago:

http://www.ietf.org/mail-archive/web/dane/current/msg01316.html

v2.23.0 | Report a Bug | By Email