This was all actually changed intentionally a while back as there was a
conflict between id-at-uniqueIdentifier and { 0 9 2342 19200300 100 1 1
} (henceforth simply reffered to as Userid.)
The reason for the conflict is that both claimed the short name "uid".
Userid, having formally had the attribute type name "uid" assigned to it
in RFC 2798 was given precedence over id-at-uniqueIdentifier, which to
my knowledge doesn't have a defined attribute type name, and should thus
be represented as "2.5.4.45".
This might seem like nit-picking, but the central problem at hand is
that the short name form is what gets used when constructing the string
encoding of distinguished names, as specified in RFC 2253. And since the
string "UID" should not, unless I've got it all wrong, translate either
to or from any attribute type save Userid that short name got
re-assigned.
Hope that clears things up a bit. This did mess with backwards
compatibility, granted, and I thought this was actually mentioned in
CHANGES. Maybe it fell out during a branch or a merge?
There's more information about this in the thread "UID is usually
RFC1274 user id, not X500 unique id" from late November last year if you
care to search the archives.
Best regards,
//oscar
Dan Lanz wrote:
>
> The patch below fixes a bug in the objects list
> where the UID object shortname is incorrectly
> specified to be identical to its longname
> ("uniqueIdentifier"). This evidences itself,
> for example, when using OBJ_sn2nid() to convert
> the UID rdn of a dn (i.e., "uid=test,o=myorg")
> to an object. The following two files were
> modified:
>
> crypto/objects/objects.txt
> crypto/objects/obj_dat.h
>
> This was fine in 0.9.6b, but is incorrect in
> 0.9.6c and 0.9.7.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
