RE: Long Name Requirements
Ersin Gülaçtı <ersin.gulacti@kamusm.gov.tr> Tue, 24 February 2009 08:58 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 A09273A6942 for <ietfarch-pkix-archive@core3.amsl.com>; Tue, 24 Feb 2009 00:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.561
X-Spam-Level:
X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TR=0.935, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803]
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 5oNM+TOi5Sfn for <ietfarch-pkix-archive@core3.amsl.com>; Tue, 24 Feb 2009 00:58:58 -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 A766A3A6A73 for <pkix-archive@ietf.org>; Tue, 24 Feb 2009 00:58:57 -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 n1O8ZmOE047512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 01:35:48 -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 n1O8ZmC2047509; Tue, 24 Feb 2009 01:35:48 -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 mail.kamusm.gov.tr (ns1.kamusm.gov.tr [193.140.71.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O8ZjYW047493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Tue, 24 Feb 2009 01:35:47 -0700 (MST) (envelope-from ersin.gulacti@kamusm.gov.tr)
Message-Id: <200902240835.n1O8ZjYW047493@balder-227.proper.com>
Received: (qmail 27125 invoked by uid 89); 24 Feb 2009 08:35:43 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=private; d=kamusm.gov.tr; b=wcyhhofAiScwdzRXnv0L9JTdhzkk+L9xdm75o2xpKEWT9Xm22TOg/k4yRKLZqqf6fjkgDULaGSFgh+4vvCnmtg==;
Received: by simscan 1.3.1 ppid: 27117, pid: 27120, t: 0.0173s scanners: regex: 1.3.1 attach: 1.3.1 clamav: 0.94.2/m:49
Received: from unknown (HELO LENOVO2DE2357D) (ersin.gulacti@10.1.8.20) by mail.kamusm.gov.tr with ESMTPA; 24 Feb 2009 08:35:43 -0000
Reply-To: ersin.gulacti@kamusm.gov.tr
From: Ersin Gülaçtı <ersin.gulacti@kamusm.gov.tr>
To: ietf-pkix@imc.org
Subject: RE: Long Name Requirements
Date: Tue, 24 Feb 2009 10:35:46 +0200
Organization: TUBITAK UEKAE
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-9"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
thread-index: AcmVxPmSRdg/2yWETEq5nGDMIFyj9AAAMVgQAAKeFDAAIaBfkA==
In-Reply-To: <20090223182955.BEC7B225800C@postaci.uekae.tubitak.gov.tr>
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>
First, I like to clarify some points. What I am trying is to put a legal person's name (i.e Company Title) in the Subject field of the certificate (CN=ACME Company ...). The company will be the owner of the certificate. Since company names are longer than 64 characters in nature, I have to devise a solution for creating standards compatible certificates. I have reviewed the discussions between the PKIX and ITU on upper bounds. I wish and hope that RFC 5280 bis will follow X.509's lead on handling longer names. In practice our CA software and verification API had strict enforcement of the 64 characters based on RFC 3280, 4 years ago. At that time we encountered some root certificates that had longer CN and OU components than 64 characters. To make our API compatible with those certificates we relaxed our upper bounds limit to 128 characters for the decoding of certificates. Our CA software still creates certificates according to the 64 characters upper bound limitation. I think it would be better to modify our CA software and create certificates with no upper bound limits on name structures. -----Original Message----- From: Kemp, David P. [mailto:DPKemp@missi.ncsc.mil] Sent: Monday, February 23, 2009 8:29 PM To: egulacti@uekae.tubitak.gov.tr; ietf-pkix@imc.org Subject: RE: Long Name Requirements 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
- Long Name Requirements egulacti
- RE: Long Name Requirements Erik Andersen
- Re: Long Name Requirements Russ Housley
- RE: Long Name Requirements Paul Hoffman
- RE: Long Name Requirements Erik Andersen
- RE: Long Name Requirements Kemp, David P.
- Re: Long Name Requirements Stefan Santesson
- Re: Long Name Requirements Nelson B Bolyard
- Re: Long Name Requirements Stefan Santesson
- RE: Long Name Requirements Ersin Gülaçtı
- Re: Long Name Requirements Stephen Farrell