Re: [certid] CN fallback
"RL 'Bob' Morgan" <rlmorgan@washington.edu> Tue, 06 April 2010 16:20 UTC
Return-Path: <rlmorgan@washington.edu>
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 CC6C53A6987 for <certid@core3.amsl.com>;
Tue, 6 Apr 2010 09:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level:
X-Spam-Status: No,
score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11,
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 Dqq-P9kqlZSM for
<certid@core3.amsl.com>; Tue, 6 Apr 2010 09:20:20 -0700 (PDT)
Received: from mxout13.cac.washington.edu (mxout13.cac.washington.edu
[140.142.32.202]) by core3.amsl.com (Postfix) with ESMTP id 18C003A687B for
<certid@ietf.org>; Tue, 6 Apr 2010 09:20:04 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be
forged)) by mxout13.cac.washington.edu (8.14.3+UW09.11/8.14.3+UW09.11) with
ESMTP id o36GIN6p031317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
bits=256 verify=OK) for <certid@ietf.org>; Tue, 6 Apr 2010 09:18:23 -0700
X-Auth-Received: from lil-red-x.local (c-71-231-138-233.hsd1.wa.comcast.net
[71.231.138.233]) (authenticated authid=rlmorgan) by smtp.washington.edu
(8.14.3+UW09.11/8.14.3+UW09.11) with ESMTP id o36GIMlL014779
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for
<certid@ietf.org>; Tue, 6 Apr 2010 09:18:23 -0700
Date: Tue, 6 Apr 2010 09:18:22 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@lil-red-x
To: certid@ietf.org
In-Reply-To: <00d401cad517$7ee680c0$7cb38240$@2@osu.edu>
Message-ID: <alpine.DEB.2.00.1004060908370.2761@lil-red-x>
References: <201003231544.05651.ludwig.nussel@suse.de>
<4BB3C21E.90502@stpeter.im> <4BBA5673.7020403@isode.com>
<00d401cad517$7ee680c0$7cb38240$@2@osu.edu>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2010.4.6.160052
X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5,
BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, INVALID_MSGID_NO_FQDN 0, TO_NO_NAME 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CANPHARM_COPYRIGHT 0,
__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0,
__USER_AGENT 0'
Subject: Re: [certid] CN fallback
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, 06 Apr 2010 16:20:23 -0000
> Since nothing's referencing this specification yet anyway, why not > outline what people should do, rather than what they are doing? Because this isn't a brand new subject area. This doc is intended (IMHO) to clarify (lots and lots of) existing practice and nudge it in the right direction, not start with a clean sheet. > A previous note mentioned the fact that DNs are hierarchical paths into > a directory. This, of course, is not true; X.500 does not exist as a > global/going concern, so DNs are in fact misleading in this context. > Let's stop pretending otherwise. Indeed use of DNs in certs is disconnected from directory usage in practice. Indeed people treat DNs as what they are syntactically, a sequence of attribute-value assertions (sometimes "OU=(c) XYZ Corp 2010, all rights reserved"). This doesn't change the fact that CAs almost always, in my experience, put the intended subject name in the leaf RDN of the Subject DN, just because doing otherwise is far less likely to work with deployed software. So it seems to me the doc should say: * Use subjectAlt in all its wonderfulness. * Use of Subject DN is traditional and not recommended and being phased out, but if you do it you should put the element in a CN that is the leaf RDN. People will be looking to this spec to clarify this naming mystery. Leaving out traditional practice because it's icky just leaves the mystery to be documented in alleyways instead. - RL "Bob"
- [certid] CN fallback Ludwig Nussel
- Re: [certid] CN fallback Peter Saint-Andre
- Re: [certid] CN fallback Alexey Melnikov
- Re: [certid] CN fallback Scott Cantor
- Re: [certid] CN fallback Alexey Melnikov
- Re: [certid] CN fallback Scott Cantor
- Re: [certid] CN fallback RL 'Bob' Morgan
- Re: [certid] CN fallback Scott Cantor
- Re: [certid] CN fallback Ludwig Nussel
- [certid] open issue: iPAddress Peter Saint-Andre
- Re: [certid] CN fallback Michael Ströder
- Re: [certid] open issue: iPAddress Michael Ströder
- Re: [certid] CN fallback Michael Ströder