Re: [certid] False choice for CN
"Henry B. Hotz" <hotz@jpl.nasa.gov> Tue, 15 June 2010 05:41 UTC
Return-Path: <hotz@jpl.nasa.gov>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 93C373A67E5 for <certid@core3.amsl.com>;
Mon, 14 Jun 2010 22:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level:
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093,
BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
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 zCcFsP+N-4Q8 for
<certid@core3.amsl.com>; Mon, 14 Jun 2010 22:41:16 -0700 (PDT)
Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by
core3.amsl.com (Postfix) with ESMTP id 4F8FD3A6862 for <certid@ietf.org>;
Mon, 14 Jun 2010 22:41:16 -0700 (PDT)
Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov
[128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP
id o5F5fID5024294 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified
FAIL); Mon, 14 Jun 2010 22:41:19 -0700
Received: from [192.168.2.2] (128.149.137.113) by ums-smtp.jpl.nasa.gov
(128.149.137.72) with Microsoft SMTP Server (TLS) id 8.1.393.1;
Mon, 14 Jun 2010 22:41:18 -0700
MIME-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <p0624080dc83c9b9b8066@[10.20.30.158]>
Date: Mon, 14 Jun 2010 22:41:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <9A21C481-00C6-4261-A5E0-157573E838B0@jpl.nasa.gov>
References: <201006141412.o5EECbvx026607@fs4113.wdf.sap.corp>
<p0624080dc83c9b9b8066@[10.20.30.158]>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1078)
X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: "certid@ietf.org" <certid@ietf.org>
Subject: Re: [certid] False choice for CN
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates
<certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2010 05:41:33 -0000
On Jun 14, 2010, at 7:55 PM, Paul Hoffman wrote: > At 4:12 PM +0200 6/14/10, Martin Rex wrote: >> Paul Hoffman wrote: >>> >>>> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >>>> identifier of type dNSName). >>> >>> . . . >>> >>>> Therefore, if and only if the identity set does not include >>>> subjectAltName extensions of type dNSName, SRVName, or >>>> uniformResourceIdentifier (or any application-specific subjectAltName >>>> extensions supported by the client), the client MAY as a fallback >>>> check for a fully-qualified DNS domain name in the last Common Name >>>> RDN in the sequence of RDNs making up the Distinguished Name within >>>> the certificate's subjectName (where the term "last" refers to the >>>> DER order, which is often not the string order presented to a user; >>>> the order that is applied here MUST be the DER order). >>> >>> Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. Please remove it. >> >> I think this needs to stay. >> >> The document under discussion is supposed to be a BCP (Best current practice) >> document, and it will have to describe how clients should deal with >> server certificates that do no have subjectAltNames. It does so by >> describing the common practice that has been in use for certs that >> do not have subjectAltNames. > > That goes counter to the MUST-level statements in the document. You either need to downgrade the MUST-level requirements, or get rid of the sections that say, in essence, "if this MUST-level requirement is not met, then do this". > > The fact that this is a BCP is irrelevant. BCPs are standards-track documents. Being a BCP doesn't make it OK to have conflicting requirements. The section in question describes what one party is supposed to do if the other party does the wrong thing. I see nothing inconsistent or inappropriate about that. It's just sad that the current (actual, not best) practice is to do "the wrong thing" so often that we need to worry about it so much. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
- [certid] False choice for CN Paul Hoffman
- Re: [certid] False choice for CN Martin Rex
- Re: [certid] False choice for CN Paul Hoffman
- Re: [certid] False choice for CN Henry B. Hotz
- Re: [certid] False choice for CN Peter Saint-Andre