Thank you for your reply. The 64-char limit imposed by the RFC makes sense now, thank you. As for my goal, it is simply to encode extra data in the DN. I do not care exactly how this is done, as long as my string is present somehow.
When you say "You can legally have multiple CN fields", I interpret this to mean the CN can look like: CN=name/XX=y/XY=z Of course this is still restricted by the 64 character limit. Is there an easy method to add my fields to the DN, even in an unstructured way? -Federico On Wed, Jun 30, 2004, Federico Sacerdoti wrote: > Hello, > > Perhaps I do not understand the concept, but I need to create a cert > with a DN containing some custom fields: > > /C=US/ST=California/L=San Diego/O=San Diego Supercomputer > Center/OU=Quartz/CN=compute-0-0/RocksMembership=NAS > Appliance/RocksAddress=198.202.74.254 > > I need one of the following abilities: > > 1. A CN field that allows more than 64 characters. If I try to > "piggyback" the new fields on the CN, I see: > > problems making Certificate Request > 12489:error:0D07A097:asn1 encoding routines:ASN1_mbstring_copy:string > too long:a_mbstr.c:154:maxsize=64 > The 64 character limit is imposed by various standards including RFC3280, so that can't be changed without OpenSSL being non-compliant and would need recompilation anyway. You can legally have multiple CN fields though... > 2. A way to define new OIDs. I have searched the docs and web, but when > I add this to my cfg file: > > [ oid_section ] > RocksMembership=1.2.3.4 > RocksAddess=69.69.1.3 > > I see: > Subject Attribute RocksMembership has no known NID, skipped > Subject Attribute RocksAddress has no known NID, skipped > -----BEGIN CERTIFICATE REQUEST----- > MIIBxzCCATACAQAwgYYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh > MRIwEAYDVQQHEwlTYW4gRGllZ28xJzAlBgNVBAoTHlNhbiBEaWVnbyBTdXBlcmNv > > I cannot find how to define new NIDs. Recompiling openssl is not an > option, so I may be out of luck. I hope there is something I am > missing. > > Well you've probably not added the new fields correctly to the config file. There are several ways, the new approved way is via a config module (see the config manual page in a recent snapshot for docs). However you shouldn't just invent random numbers for OIDs, you can obtain a subtree for your organization assuming you don't already have one. What actually appears in a certificate is an encoding of the numerical form (1.2.3.4 above) its down to an individual application to recognize the value in its tables and convert into a human readable form. So if you did define "RockeMembership" to be "1.2.3.4" you'd get the encoded form of "1.2.3.4" in the certificate which would not be recognized by any software which didn't include the new OID in its tables (and some software doesn't allow you to add new OIDs). I suspect however that none of this really suits what you want to do... Perhaps you could explain what you want to do in detail, then a more appropriate way might be apparent. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
