Re: [keyassure] The draft and subj alt names
Ondřej Surý <ondrej.sury@nic.cz> Fri, 01 April 2011 14:36 UTC
Return-Path: <ondrej.sury@nic.cz>
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 838E73A6851 for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 07:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 9MQakqZ9-vgB for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 07:36:49 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 06E623A6850 for <keyassure@ietf.org>; Fri, 1 Apr 2011 07:36:49 -0700 (PDT)
Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 008B22A2ABB for <keyassure@ietf.org>; Fri, 1 Apr 2011 16:38:28 +0200 (CEST)
Message-ID: <4D95E363.4000304@nic.cz>
Date: Fri, 01 Apr 2011 16:38:27 +0200
From: Ondřej Surý <ondrej.sury@nic.cz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9
MIME-Version: 1.0
To: keyassure@ietf.org
References: <201104011356.p31DuRUK014555@fs4113.wdf.sap.corp>
In-Reply-To: <201104011356.p31DuRUK014555@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [keyassure] The draft and subj alt names
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, 01 Apr 2011 14:36:50 -0000
On 1.4.2011 15:56, Martin Rex wrote: > Jay Daley wrote: >> >> 6. Add a flag into TLSA that specifies >> whether name matching is to be done or not > > I think that (6.) would be the most sensible solution. This starts to look like overengineering. Let's not put too many ingreedients into one pot please. > Especially for self-signed X.509 certificates, it doesn't make sense > to look at name attributes of the certificate at all, because these > are all self-asserted attributes, not certified attributes. The > only thing that really matters is the public key. On the other hand it's not that hard to issue a self-signed CA issued cert which matches the domain name, isn't it? The other option would be use the bare keys (see Paul W. proposal in TLS WG). E.g. if you use X.509 do match, if you use bare key, don't match. > TLSv1.2 1. Introduction, last sentence > > http://tools.ietf.org/html/rfc5246#page-5 > > the decisions on how to initiate TLS > handshaking and how to interpret the authentication certificates > exchanged are left to the judgment of the designers and implementors > of protocols that run on top of TLS. > > HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph > > http://tools.ietf.org/html/rfc2818#section-3.1 > > If the client has external information as to the expected identity of > the server, the hostname check MAY be omitted. (For instance, a > client may be connecting to a machine whose address and hostname are > dynamic but the client knows the certificate that the server will > present.) > > > or the new RFC-6125 > > http://tools.ietf.org/html/rfc6125#page-8 > > o Keys or certificates employed outside the context of PKIX-based > systems. > > Some deployed application technologies use a web of trust model > based on or similar to OpenPGP [OPENPGP], or use self-signed > certificates, or are deployed on networks that are not directly > connected to the public Internet and therefore cannot depend on > Certificate Revocation Lists (CRLs) or the Online Certificate > Status Protocol [OCSP] to check CA-issued certificates. However, > the method for binding a public key to an identifier in OpenPGP > differs essentially from the method in X.509, the data in self- > signed certificates has not been certified by a third party in any > way, [...] I think that those paragraphs are exactly the reason why the option "Leave it alone - it's up to the application" is most appropriate for the DANE WG. And there will be interest I think that it could be solved elsewhere or here as BCP RFC. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------
- Re: [keyassure] The draft and subj alt names Ondřej Surý
- [keyassure] The draft and subj alt names Olle E. Johansson
- Re: [keyassure] The draft and subj alt names Richard L. Barnes
- Re: [keyassure] The draft and subj alt names Jay Daley
- Re: [keyassure] The draft and subj alt names Richard L. Barnes
- Re: [keyassure] The draft and subj alt names Jay Daley
- Re: [keyassure] The draft and subj alt names Paul Wouters
- Re: [keyassure] The draft and subj alt names Richard L. Barnes
- Re: [keyassure] The draft and subj alt names Martin Rex
- Re: [keyassure] The draft and subj alt names Jeff Schmidt
- Re: [keyassure] The draft and subj alt names =JeffH