[keyassure] dane-04 trust anchors

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 11 February 2011 07:26 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2EB3A6B19 for <keyassure@core3.amsl.com>; Thu, 10 Feb 2011 23:26:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNLXvWFi9OLh for <keyassure@core3.amsl.com>; Thu, 10 Feb 2011 23:26:22 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DB6443A6AFC for <keyassure@ietf.org>; Thu, 10 Feb 2011 23:26:21 -0800 (PST)
Received: by fxm9 with SMTP id 9so2775789fxm.31 for <keyassure@ietf.org>; Thu, 10 Feb 2011 23:26:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=uLjEpOvO5AWhGDttlEIrXFBEnHrBa5MDCFCjZzv8iwI=; b=bxGzOet7IbnpQqXGC3U6RrT3h5PRbs1EAc0tPc7KP3S4bTc+iY4B4liy9ejBhAgIxI XBycA/aCKLyi7+//fsciw/qRHcYFNyI5wSZLU+hioeMTEYwl/n2Gk542q83oqeYAD+Mm aIJW9Us07tOaAoz8/QGTRkkwCAfE1BU2HzvKI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=IbYkJd/D2LVyouH+cLvcfIjJVzuT2pq23zTRch/yQPtPGId7jxmqipjRZQ+xkPDSTN IYPDcEEXDta4/z1+qWsIFiH6oeSNxvP/tTrtVTaTAUNlEDjegXfY1U5rICPEZZFqiW83 FsmxbIHK3Cf8tv6Z+2L+O19cDWd8Az0Wbilz8=
Received: by 10.223.107.133 with SMTP id b5mr168880fap.87.1297409195273; Thu, 10 Feb 2011 23:26:35 -0800 (PST)
Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id 17sm180571far.19.2011.02.10.23.26.34 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 23:26:34 -0800 (PST)
Message-ID: <4D54E4A9.1020104@gmail.com>
Date: Fri, 11 Feb 2011 09:26:33 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: keyassure@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [keyassure] dane-04 trust anchors
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2011 07:26:23 -0000

Hi,

the new text is a major improvement over the previous version. But it is 
still missing some necessary guidance.

My reference scenario is this: I am a phisher. I'd like to trick 
BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now 
I can get a certificate that they will use as a trust anchor, and 
include whatever I want in it, such as the Subject field, "Your trusted 
BigBank".

Moreover, even if I am the rightful owner, the current text does not 
allow me to restrict the certificate's use.

So I propose the following text added:

Client treatment of any non-key information included in the trust anchor 
is a matter of local policy. It is noted that this specification does 
not mandate that such information be inspected or validated by the 
domain registrar.

The client MUST obey any constraints included in the trust anchor, 
including but not limited to:
- Validity period.
- Key usage fields.
- Path length constraints.
- Name constraints.
The normal rules of RFC 5280 apply.

Thanks,
	Yaron