[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
- Re: [keyassure] dane-04 trust anchors Paul Hoffman
- Re: [keyassure] dane-04 trust anchors Yaron Sheffer
- [keyassure] dane-04 trust anchors Yaron Sheffer
- Re: [keyassure] dane-04 trust anchors Phillip Hallam-Baker
- Re: [keyassure] dane-04 trust anchors Jim Schaad
- Re: [keyassure] dane-04 trust anchors Paul Hoffman
- Re: [keyassure] dane-04 trust anchors Paul Wouters
- Re: [keyassure] dane-04 trust anchors Yaron Sheffer
- Re: [keyassure] dane-04 trust anchors Yaron Sheffer
- Re: [keyassure] dane-04 trust anchors Stephen Farrell
- Re: [keyassure] dane-04 trust anchors Paul Hoffman
- Re: [keyassure] dane-04 trust anchors Paul Hoffman
- Re: [keyassure] dane-04 trust anchors Scott Schmit
- Re: [keyassure] dane-04 trust anchors Martin Rex
- Re: [keyassure] dane-04 trust anchors Henry Story