Richard Levitte wrote:
> frankb> 3. RFC 2253's "short names" identify attribute types (i.e.,
> frankb> attributeType = (ALPHA 1*keychar) / oid), not object
> identifiers.
> frankb> I am not aware of any standard for short object identifier
> frankb> names, nor do I see a whole lot of value in them.
>
> I'm not sure I understand in what way an attribute types are very
> different from other object identifiers from a technical point of
> view. I can fully understand the difference from a conceptual or
> semantic point of view, but I see that as a different viewpoint.
I agree. An object identifier identifies something (e.g., an algorithm
identifier, attribute, attribute type and value, object class, etc.).
After further thinking, I do see value in short names. For example, "CN" (or
"cn") is understood by most people because it is a standard (RFC 2253). The
real problem is the lack of standard short names for identifying objects
like algorithm identifiers, etc. For example, RSA with SHA-1 could mean
either of the following (from objects.h):
#define SN_sha1WithRSAEncryption "RSA-SHA1"
#define LN_sha1WithRSAEncryption "sha1WithRSAEncryption"
#define NID_sha1WithRSAEncryption 65
#define OBJ_sha1WithRSAEncryption OBJ_pkcs,1L,5L
#define SN_sha1WithRSA "RSA-SHA1-2"
#define LN_sha1WithRSA "sha1WithRSA"
#define NID_sha1WithRSA 115
#define OBJ_sha1WithRSA OBJ_algorithm,29L
Whereas, 1.2.840.113549.1.1.5 (i.e., sha1WithRSAEncryption) is pretty darn
clear, but not very user friendly. An informational RFC defining short names
for algorithm identifiers would actually be valuable.
Frank
> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 25, 2000 11:42 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Objects and a configuration file
>
>
> From: Frank Balluffi <[EMAIL PROTECTED]>
>
> frankb> 1. I can see lots of value in using a file (that maps an
> frankb> object identifier's numeric representation to and from its
> frankb> string representation) when decoding. I can't see much use
> frankb> when encoding. Perhaps someone else can?
>
> Depends on what you mean, but ciphers are identified through names
> like "DES-EDE3-CBC3". Those are "short names" for the algorithm
> OIDs. There are most probably other examples. I'd look for OBJ_sn2
> and OBJ_txt2 throughout the source to see how and where it's used.
>
> frankb> 2. When possible, use an existing standard. RFC 2253's oid =
> frankb> 1*DIGIT *("." 1*DIGIT) is probably the most common numeric
> frankb> representation of an object identifier.
>
> In objects.txt, what's been used is a part of the ASN.1 syntax:
>
>
> id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
> ^^^^^^^^^^^^^^
>
> frankb> 3. RFC 2253's "short names" identify attribute types (i.e.,
> frankb> attributeType = (ALPHA 1*keychar) / oid), not object
> identifiers.
> frankb> I am not aware of any standard for short object identifier
> frankb> names, nor do I see a whole lot of value in them.
>
> I'm not sure I understand in what way an attribute types are very
> different from other object identifiers from a technical point of
> view. I can fully understand the difference from a conceptual or
> semantic point of view, but I see that as a different viewpoint.
>
> --
> Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
> Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
> Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
> Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
> Software Engineer, Celo Communications: http://www.celocom.com/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
