Subject: RE: Long Name Requirements

From: Ersin Gülaçtı <[email-masked]>
Date: Tue, 24 Feb 2009 10:35:46 +0200

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:[email-masked]] 
Sent: Monday, February 23, 2009 8:29 PM
To: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Erik Andersen
Sent: Monday, February 23, 2009 9:57 AM
To: [email-masked]; [email-masked]
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: [email-masked]
www.x500.eu
www.x500standard.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of [email-masked]
Sent: 23. februar 2009 14:42
To: [email-masked]
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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Feb 2009 09:51:54 +0000

So I reckon if this is a real use-case then we should think
about a change. And while it sounds like it is a real use
case it'd be good to see some example names that are longer
than those allowed by 5280. (And any issued certs that are
in the wild containing those.)

Having said that, I do wonder whether the organisations
actually also have unique shorter names - hard to imagine
people always using such long names - in which case why
not modify the policy to work within the 5280 limits? A
policy change like that is much cheaper than modifying
and deploying new s/w everywhere. If the authors of the
policy are offered the choice between their current
scheme (full long names in subject field) vs. the cost
of doing so (for everyone else), and the lack of benefit
during Internet-scale deployment, and if they are reasonable,
then they may well change the policy. If OTOH, the policy
only covers certs for some particular application then
I don't care too much anyway that they are x.509 but
not 5280 compliant.

E.g. in our case, we like to be called Trinity College
Dublin even though our name in contracts is much longer (*)
and would in fact break the 5280 limit. (A certain
irony there since my affiliation is mentioned in 5280;-)
But I don't see a need for that name to be in any X.509
certs so I don't mind.

Stephen.

(*) In contracts, but essentially nowhere else, TCD is called
"The Provost Fellows and Scholars of the College of the Holy
and Undivided Trinity of Queen Elisabeth Near Dublin" which
is a 5280-unfriendly 113 characters. I guess the short-sighted
folks 400 years ago just didn't plan ahead for x.509:-)