Re: Long Name Requirements

Stefan Santesson <stefans@exmsft.com> Mon, 23 February 2009 23:05 UTC

Return-Path: <owner-ietf-pkix@mail.imc.org>
X-Original-To: ietfarch-pkix-archive@core3.amsl.com
Delivered-To: ietfarch-pkix-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D585328C209 for <ietfarch-pkix-archive@core3.amsl.com>; Mon, 23 Feb 2009 15:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.416
X-Spam-Level:
X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 8Qrv2qkEFFEw for <ietfarch-pkix-archive@core3.amsl.com>; Mon, 23 Feb 2009 15:05:53 -0800 (PST)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 02E5A28C243 for <pkix-archive@ietf.org>; Mon, 23 Feb 2009 15:05:49 -0800 (PST)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NManCj020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 15:36:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NManqC020721; Mon, 23 Feb 2009 15:36:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NMaa3r020705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Mon, 23 Feb 2009 15:36:48 -0700 (MST) (envelope-from stefans@exmsft.com)
Received: (qmail 90722 invoked from network); 23 Feb 2009 22:36:43 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <stefans@exmsft.com>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <ietf-pkix@imc.org>; 23 Feb 2009 22:36:43 -0000
Received: (qmail 49052 invoked from network); 23 Feb 2009 22:36:33 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender <stefans@exmsft.com>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <DPKemp@missi.ncsc.mil>; 23 Feb 2009 22:36:33 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Mon, 23 Feb 2009 23:36:32 +0100
Subject: Re: Long Name Requirements
From: Stefan Santesson <stefans@exmsft.com>
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>, egulacti@uekae.tubitak.gov.tr, ietf-pkix@imc.org
Message-ID: <C5C8E380.53E%stefans@exmsft.com>
Thread-Topic: Long Name Requirements
Thread-Index: AcmVxPmSRdg/2yWETEq5nGDMIFyj9AAAMVgQAAKeFDAADb1sZQ==
In-Reply-To: <200902231829.n1NITfVP003323@stingray.missi.ncsc.mil>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

While RFC 5280 has retained upper bounds for backwards compatibility I would
not expect products on the market to enforce them. Microsoft for one does
not.

If you are applying this in a controlled environment, you could simply test
with the OS versions and applications that are being used to see if there is
any problem.

However, eventhough your description is brief, it strikes me whether it
would be more suitable to define a subjectAltName for your "long" name form
instead of throwing it into a subject attribute. It appears to me as you are
building a unique alternative identifier through this long string rather
than an attribute of a relative distinguished name structure.

/stefan


On 2/23/09 7:28 PM, "Kemp, David P." <DPKemp@missi.ncsc.mil> wrote:

> 
> Ersin,
> 
> While X.509 permits unlimited-length strings in the Subject field, it
> may be worth considering usability before making a decision to exercise
> that freedom.
> 
> From a practical perspective, applications may handle long names with
> varying degrees of grace - some may have hard-coded upper bounds based
> on 5280 and will refuse to accept longer strings; others may have user
> interface layouts based on length assumptions and may truncate or wrap
> for display purposes without rejecting the certificate.  If you buy or
> develop applications designed to handle long strings, then no problem as
> long as every application that touches your certificates can handle them
> properly.
> 
> From a theoretical perspective, title (regardless of length) probably
> doesn't belong in the Subject field.  The Subject name is an identifier
> that tells "who" the certificate applies to.  Other information about
> the user, such as height, weight, date of birth, fax number, or
> title/role/position within the organization can be included in
> certificates but are not semantically identifiers.  Contact information
> can go either way - at the office a fax number is probably shared but
> you have a private voice line that uniquely refers to you, while at home
> the voice line may be shared with the wife and kids but the only fax
> machine is in your home office.  If your purpose is to issue a "role
> certificate" to a position without regard to who occupies the position,
> then title is an identifier and does belong in the Subject name.  But in
> most cases, title is an attribute of the user, not part of the user's
> name.  The X.520 title attribute is most appropriately placed in the
> Subject Directory Attributes extension, with the same implementation
> considerations as above.
> 
> As Eric says, defining a new attribute type is not necessary because it
> would be at least as difficult to get applications to support a new type
> as it would be to support the new syntax of the existing attribute.
> Hopefully RFC 5280 bis will follow X.509's lead, making upper bounds
> minima that implementations MUST support, not maxima that
> implementations MUST NOT exceed.
> 
> I'm sure someone will point out that there is precedent for putting
> almost anything you want in the Subject name, including certificate
> policy statements and mpeg videos of cats.  But don't be persuaded that
> everything that is syntactically valid is necessarily wise.
> 
> 
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Erik Andersen
> Sent: Monday, February 23, 2009 9:57 AM
> To: egulacti@uekae.tubitak.gov.tr; ietf-pkix@imc.org
> Subject: RE: Long Name Requirements
> 
> 
> Hi Ersin,
> 
> In the latest edition of X.509, we removed the length restrictions on
> attribute types. The PKIX group did not follow suit, but retained the
> length
> restriction. A field of 500 characters will not comply with RFC 5280,
> but it
> will comply with the X.509 itself, and that is what is important.
> 
> You can find links to the lasted documents on
> http://www.x500standard.com/index.php?n=Extension.Ed6.
> 
> You do not need to define own attribute types.
> 
> Erik Andersen
> Andersen's L-Service
> Elsevej 48, DK-3500 Vaerloese
> Denmark
> Mobile: +45 2097 1490
> email: era@x500.eu
> www.x500.eu
> www.x500standard.com
>  
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
> On
> Behalf Of egulacti@uekae.tubitak.gov.tr
> Sent: 23. februar 2009 14:42
> To: ietf-pkix@imc.org
> Subject: Long Name Requirements
> 
> 
> Hi,
> 
> I have read through the PKIX mailing list archives to find a method for
> using name components longer than 64 characters in the Subject field of
> an
> X.509 v3 certificate. Unfortunately I could not find a solution which
> satisfies RFC 5280 (3280) by using standard CN, Title, O or OU
> components.
> 
> Now I plan to use a custom attribute-value pair in the Subject field. Is
> there any widely used OID for really long names in the Subject field? I
> need to put full company titles, up to 500 characters long, in the
> Subject
> field.
> 
> Regards,
> 
> Ersin
> 
> 
> 
>