Re: [keyassure] The draft and subj alt names

Martin Rex <mrex@sap.com> Fri, 01 April 2011 13:55 UTC

Return-Path: <mrex@sap.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 28E673A681C for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 06:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.221
X-Spam-Level:
X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 vip1uJXsaP2Z for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 06:55:12 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 85FBB3A67FC for <keyassure@ietf.org>; Fri, 1 Apr 2011 06:55:11 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p31DuRvp003620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 15:56:27 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201104011356.p31DuRUK014555@fs4113.wdf.sap.corp>
To: jay@nzrs.net.nz (Jay Daley)
Date: Fri, 1 Apr 2011 15:56:27 +0200 (MEST)
In-Reply-To: <EB7DE8E2-B40F-4C3B-AB21-B27BF053E4C0@nzrs.net.nz> from "Jay Daley" at Apr 1, 11 09:41:24 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: keyassure@ietf.org
Subject: Re: [keyassure] The draft and subj alt names
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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 13:55:13 -0000

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.

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.

Today's browsers show a very intimidating warning page when they
receive a server cert that doesn't match their expectations.
But once you have convinced your browser that you want to connect,
and to make this decision persistent (cert pinning), then there
are no more warnings on further connects about mismatches on
name attributes of the certificate.


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, [...]
  

-Martin