Re: Object names
Richard Levitte - VMS Whacker wrote: michael Again: The only reference to an attribute type is the OID! I know that. Unfortunately, there are applications out there that attempt to use the textual representation of a DN. One perfect example is LDAP anytime you search for anything (at least, I'm told there are implementations that do not know how to handle DNs with OIDs for names). A correct LDAP implementation should be able to convert RFC2253 DN-strings (e.g. user's input) to an ASN.1 structure representing attribute types with OIDs. If the strings used for an attribute type (a matter of local configuration) are not unique it should simply fail. If the DN is displayed the ASN.1 structure is displayed according to RFC2253. I do not claim that there is currently any LDAP implementation out there really doing it correctly... ;-) Ciao, Michael. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OCSP and issuerNameHash (was: Object names)
From: Michael **UNKNOWN CHARSET** [EMAIL PROTECTED] michael Have you read RFC2560 properly? You can have responders that answer michael for other CA's. Multiple CA's even. michael michael I know that. But is the DER-encoding of the issuerName always michael the same? It's supposed to be encoded in ascending lexicographic order, at least according to the Layman's Guid to a Subset of ASN.1, BER and DER. michael IMHO at least this type definition containing SET OF might michael lead to different DER-encodings (and therefore different michael issuerNameHash values) of equivalent issuer names if the michael RelativeDistinguishedName is reordered. You know, if we couldn't assume that the order would be maintained, we'd be in a lot of trouble, since the full verification of a certificate is done by matching one cert's issuer with another cert's subject. Unless we can assume that the same order will be preserved, verification would be impossible. Think about it, a DN can have multiple RDNs of the same type. Does DC ring a bell? -- 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]
RE: OCSP and issuerNameHash (was: Object names)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: den 26 september 2000 13:58 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OCSP and issuerNameHash (was: Object names) Unless we can assume that the same order will be preserved, verification would be impossible. Think about it, a DN can have multiple RDNs of the same type. Does DC ring a bell? Multiple RDNs aren't the problem, as they are encoded as a SEQUENCE, if I understood the question correctly; rather that the individual RelativeDistinguishedNames themselves contain a SET OF AttributeTypeAndValue in order to facilitate multi-value RDNs. A quick snip from RFC 2253 to illustrate this: quote First is a name containing three relative distinguished names (RDNs): CN=Steve Kille,O=Isode Limited,C=GB Here is an example name containing three RDNs, in which the first RDN is multi-valued: OU=Sales+CN=J. Smith,O=Widget Inc.,C=US /quote DCs are IIRC encoded as separate RelativeDistinguishedNames, at least that's how my directories have been designed. Please set me right if I'm wrong about this. //oscar smime.p7s
Re: OCSP and issuerNameHash (was: Object names)
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] levitte Unless we can assume that the same order will be preserved, levitte verification would be impossible. Think about it, a DN can have levitte multiple RDNs of the same type. Does DC ring a bell? Bleah. I wasn't reading things properly. My appologies... -- 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]
Re: OCSP and issuerNameHash (was: Object names)
Oscar Jacobsson wrote: RelativeDistinguishedNames themselves contain a SET OF AttributeTypeAndValue in order to facilitate multi-value RDNs. [..] OU=Sales+CN=J. Smith,O=Widget Inc.,C=US ^ That's exactly what I meant. I'm currently in the process of writing a Python class for X.500 names. And for several reasons doing proper comparison of X.500 names is pretty complex. Multi-attribute RDNs are one of the reasons. Ciao, Michael. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OCSP and issuerNameHash (was: Object names)
The 6th draft of X.509 2000 (which was all I had handy) has the following to say about the encoding of SETs OF: quote In order to enable the validation of SIGNED and SIGNATURE types in a distributed environment, a distinguished encoding is required. A distinguished encoding of a SIGNED or SIGNATURE data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (1997) | ISO/IEC 8825 :1998, with the following restrictions: [...] e) the components of a Set-of type shall be encoded in ascending order of their octet value; [...] /quote //oscar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Stroder Sent: den 26 september 2000 14:45 To: [EMAIL PROTECTED] Subject: Re: OCSP and issuerNameHash (was: Object names) I'm currently in the process of writing a Python class for X.500 names. And for several reasons doing proper comparison of X.500 names is pretty complex. Multi-attribute RDNs are one of the reasons. smime.p7s
Re: OCSP and issuerNameHash (was: Object names)
IMHO at least this type definition containing SET OF might lead to different DER-encodings Nope. As others have pointed out DER defines a unique encoding for "SET OF" You might want to look at i2d_ASN1_SET in crypto/a_set.c Can somebody with real OCSP experience say anything about this? I believe we found this the hard way at my old employer, but details are fuzzy. :) The CVS log for a_set.c shows: revision 1.2 date: 1998/12/29 21:43:40; author: ben; state: Exp; lines: +91 -10 Fix incorrect DER encoding of SETs and all knock-ons from that. hope this helps. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Object names
I wonder, is there any document somewhere that can tell us how the different objects should really be named? As it currently looks, most names are created ad-hoc. I've just been hit with a problem where the naming of OID 1.2.840.113549.1.9.1 varies. When that is part of the CN rdn using X509_NAME_oneline(), it's displayed as "/Email=...". Other products, like the JDK, seem to name it "/EmailAddress=...". As you can see, that will create a problem when you try to use the representation used by one system in another system. In a more general sense, this has hit me as a problem when I hacked crypto/objects/objects.txt, because the same name was used for several objects or arcs. This tells me that this kind of flat namespace doesn't really work, and with time this will only get worse. Comments? -- 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]
Re: Object names
I just found RFC2253, so that one doesn't have to be pointed out to me :-). -- 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]
SV: Object names
Hi I think it's a great idea to give the OID's the correct names in objects.h. I don't know if a document with the names exist, but when I want to know the name associated to an OID, I always go to: http://www.alvestrand.no/objectid/ I think you can find most of the OpenSSL predefined OID's there (including the names). Just my 2c. Best regards Kim Hellan KMD / KMD-CA http://www.kmd-ca.dk Mailto:[EMAIL PROTECTED] -Oprindelig meddelelse- Fra: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sendt: 25. september 2000 13:50 Til: [EMAIL PROTECTED] Emne: Object names I wonder, is there any document somewhere that can tell us how the different objects should really be named? As it currently looks, most names are created ad-hoc. I've just been hit with a problem where the naming of OID 1.2.840.113549.1.9.1 varies. When that is part of the CN rdn using X509_NAME_oneline(), it's displayed as "/Email=...". Other products, like the JDK, seem to name it "/EmailAddress=...". As you can see, that will create a problem when you try to use the representation used by one system in another system. In a more general sense, this has hit me as a problem when I hacked crypto/objects/objects.txt, because the same name was used for several objects or arcs. This tells me that this kind of flat namespace doesn't really work, and with time this will only get worse. Comments? -- 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]
Re: Object names
Richard Levitte - VMS Whacker wrote:
I wonder, is there any document somewhere that can tell us how the
different objects should really be named?
Currently there is no such central document since everybody is free
to define OIDs after getting a OID arc. Not even a central registry
exists. For registering OIDs it's sufficient that the owner of the
parent OID publishes it and holds at least a table of his defined
OIDs.
As it currently looks, most names are created ad-hoc.
Yes, naming of attribute types is somewhat a mess in OpenSSL.
I've just been hit with a problem where the naming of OID
1.2.840.113549.1.9.1 varies.
dumpasn1.cfg says "emailAddress".
RFC2459 appendix A says:
-
pkcs-9 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
emailAddress AttributeType ::= { pkcs-9 1 }
-
In openssl.cnf emailAdress is used in the request and policy
sections.
For certificates I'm currently using Peter Gutmann's dumpasn1.cfg.
Would be nice to have support for this file in OpenSSL.
Another problem: I would like to map emailAdress
(1.2.840.113549.1.9.1) to the mail attribute commonly used in
inetOrgPerson entries on LDAP servers. But it's defined like this
e.g. in OpenLDAP:
attributetype ( 0.9.2342.19200300.100.1.3
NAME ( 'mail' 'rfc822Mailbox' )
DESC 'RFC1274: RFC822 Mailbox'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
Another thing you can see in this example is the fact that you can
have several name aliases for an attribute type. AFAIK it's
completely up to the implementation to maintain a local name
registry for OIDs.
X509_NAME_oneline(), it's displayed as "/Email=...". Other products,
like the JDK, seem to name it "/EmailAddress=...". As you can see,
that will create a problem when you try to use the representation used
by one system in another system.
The /ATTR= writing should be abandoned anyway since it's not a
proper string representation (no proper escaping of special chars).
In a more general sense, this has hit me as a problem when I hacked
crypto/objects/objects.txt, because the same name was used for several
objects or arcs. This tells me that this kind of flat namespace
doesn't really work, and with time this will only get worse.
Comments?
IMHO it's up to the application to maintain a OID registry
(eventually with name aliases). Names of attribute types should only
be used when displaying or processing user's input.
Ciao, Michael.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SV: Object names
From: "Hellan,Kim KHE" [EMAIL PROTECTED] khe http://www.alvestrand.no/objectid/ khe khe I think you can find most of the OpenSSL predefined OID's there khe (including the names). I know about alvestrand. Guess what? 1.2.840.113549.1.9.1 is named "e-mailAddress" there. Also, anyone can basically send anything to alvestrand. I was rather looking for something a little bit authoritative... -- 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]
Re: Object names
Richard Levitte - VMS Whacker wrote: I just found RFC2253, so that one doesn't have to be pointed out to me :-). But this does not help much with attribute type naming. It only says: - If the AttributeType is in a published table of attribute types associated with LDAP [4], then the type name string from that table is used, otherwise it is encoded as the dotted-decimal encoding of the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is described in [3]. As an example, strings for a few of the attribute types frequently seen in RDNs include: - The term "published table" tells us that you have to keep up with any attribute type OID/naming a vendor or an individual might have defined. Ciao, Michael. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SV: Object names
My experience has been that you need to consult each standard separately. RFC 2459 is good in that it includes object identifiers from a bunch of standards, including the PKCS standards, and the X.5 standards (e.g., X.509 and X.520). Frank -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Monday, September 25, 2000 10:24 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: SV: Object names From: "Hellan,Kim KHE" [EMAIL PROTECTED] khe http://www.alvestrand.no/objectid/ khe khe I think you can find most of the OpenSSL predefined OID's there khe (including the names). I know about alvestrand. Guess what? 1.2.840.113549.1.9.1 is named "e-mailAddress" there. Also, anyone can basically send anything to alvestrand. I was rather looking for something a little bit authoritative... -- 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]
Re: Object names
From: Michael **UNKNOWN CHARSET** [EMAIL PROTECTED] michael Currently there is no such central document since everybody is free michael to define OIDs after getting a OID arc. Not even a central registry michael exists. For registering OIDs it's sufficient that the owner of the michael parent OID publishes it and holds at least a table of his defined michael OIDs. I know about there being no central repository. But for example, the "legal" shortnames for the DN attributes should be available somewhere. I did find some in RFC2253, and I'm pretty sure there are more in some X.500 or X.400 document, since they're used there. What I'd like to know is which ones that we have are actually documented elsewhere and which ones are invented by Eric Young or other SSLeay/OpenSSL hackers... michael For certificates I'm currently using Peter Gutmann's dumpasn1.cfg. michael Would be nice to have support for this file in OpenSSL. Yup, but then we must resolve the problem of name clashes. If you look at the latest incarnation of dumpasn1.cfg (available through the IETF PKIX WG page), you'll see that there are two "emailAddress". The other one is 0.2.262.1.10.7.28, which is apparently a Telesec (some operator) attribute. michael The /ATTR= writing should be abandoned anyway since it's not michael a proper string representation (no proper escaping of special michael chars). That's true, but that's currently a different issue for me. michael IMHO it's up to the application to maintain a OID registry michael (eventually with name aliases). Names of attribute types michael should only be used when displaying or processing user's michael input. The problem is, again, when you try to use the subject DN or the issuer DN that is returned from X509_NAME_oneline() with a different application where the OID name is represented differently. For example, one might want to use that string as name in a LDAP catalogue and access the same entries using a different program, written in Java. But I guess that the right way would be to make it less humanly readable and use the hash of the issuer DN, the same way it should be done according to RFC2560... -- 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]
RE: SV: Object names
From: Frank Balluffi [EMAIL PROTECTED] frankb My experience has been that you need to consult each standard frankb separately. RFC 2459 is good in that it includes object frankb identifiers from a bunch of standards, including the PKCS frankb standards, and the X.5 standards (e.g., X.509 and X.520). Unfortunately, I don't have access to the X.509 and X.520. The long names of the attributes are not a problem, they are normally what is defined in the corresponding ASN.1 module. The problem is the short names. A couple of collegues and I spent some time looking through the PKCS documents that seemed relevant (PKCS#9), RFC2459, RFC2253, RFC2252 and the 6th draft of X.509 4th edition and a few other documents that I don't remember, and came up with almost 0. And still, short names have been used for a while, since they do appear in X.400 addresses and in DNs a little here and there. -- 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]
Re: Object names
Michael Ströder wrote: Currently there is no such central document since everybody is free to define OIDs after getting a OID arc. Not even a central registry exists. No official central regitry, yes, but at least there is this non-official one : http://www.alvestrand.no/objectid/ It's quite complete, while sure not comprehensive. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
Jean-Marc Desperrier wrote: Michael Ströder wrote: Currently there is no such central document since everybody is free to define OIDs after getting a OID arc. Not even a central registry exists. No official central regitry, yes, but at least there is this non-official one : http://www.alvestrand.no/objectid/ It's quite complete, while sure not comprehensive. Gulp, just read the messages before. Sorry about that. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
Richard Levitte - VMS Whacker wrote: But for example, the "legal" shortnames for the DN attributes should be available somewhere. Can you list a limited set of attribute types for certificate DNs? I can't. I did find some in RFC2253, and I'm pretty sure there are more in some X.500 or X.400 document, I do not have access to the X.500 documents. But RFC2256 is a good start for getting an idea of the X.500 schema. BTW: You won't find anything there related to e-mail addresses. michael For certificates I'm currently using Peter Gutmann's michael dumpasn1.cfg. michael Would be nice to have support for this file in OpenSSL. Yup, but then we must resolve the problem of name clashes. If you look at the latest incarnation of dumpasn1.cfg (available through the IETF PKIX WG page), you'll see that there are two "emailAddress". The other one is 0.2.262.1.10.7.28, which is apparently a Telesec (some operator) attribute. Again: The only reference to an attribute type is the OID! If you want to parse a string representation (preferrably RFC2253) and you have a name clash the parsing should fail. Simply like that. This only affects parsing user's input or configuration data. Internally only OIDs of attribute types should be used. The problem is, again, when you try to use the subject DN or the issuer DN that is returned from X509_NAME_oneline() with a different application where the OID name is represented differently. For example, one might want to use that string as name in a LDAP catalogue and access the same entries using a different program, written in Java. Again: All programs handling DNs have to handle the complete ASN.1 structure of the X.500 DN or parse an equivalent RFC2253 string encoding to rebuild the ASN.1 structure. Trivial string comparison is not an overall solution anyway. But I guess that the right way would be to make it less humanly readable and use the hash of the issuer DN, NO! A hash is a significant information loss... ;-) If you're ever lucky enough to have a corresponding DN structure in certificates and your directory the certificate-handling LDAP-client has to handle the complete ASN.1 structure of the DN. I'm currently in the process of trying that with web2ldap and it drives me nuts... the same way it should be done according to RFC2560... OCSP does almost nothing with the issuerName. The OCSP server of a CA can reference a cert by serialNumber anyway. IMHO issuerNameHash is in the OCSP request just for input checking. In opposite directory servers do a lot with DNs... Ciao, Michael. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
On Mon, 25 Sep 2000, Michael Ströder wrote:
Jean-Marc Desperrier wrote:
No official central regitry, yes, but at least there is this
non-official one :
http://www.alvestrand.no/objectid/
Thank you. I already knew that one.
It's quite complete, while sure not comprehensive.
The problem is that not the vendors itself add their entries but
normal users enter what they believe is the name and ASN.1 syntax.
Example: Can someone give me the complete ASN.1 syntax of
entrustVersInfo (OID 1.2.840.113533.7.65.0)? E.g. alvestrand.no
says:
entrustVersInfo EXTENSION ::= {
SYNTAX EntrustVersInfoSyntax
IDENTIFIED BY { id-nsn-ext 0}
}
EntrustVersInfoSyntax ::= OCTET STRING
But according to the ASN.1 parser I'm using it seems to be a
SEQUENCE of a string containing the version (e.g. "V4.0") and a BIT
STRING containing some flags.
See output of Peter Gutmann's dumpasn1:
: SEQUENCE {
564 069: OBJECT IDENTIFIER
: entrustVersInfo (1 2 840 113533 7 65 0)
575 04 12: OCTET STRING, encapsulates {
577 30 10: SEQUENCE {
579 1B4: GeneralString 'V4.0'
585 032: BIT STRING 4 unused bits
: '1001'B
: }
: }
: }
: }
: }
: }
Well alvestrand.no is right on this one You can see it in your
dump... The SEQUENCE is encapsulated in an OCTET STRING...
What you would like is the internal format of this OCTET STRING... Just
ask Entrust...
How could you force anyone to describe the internal format of every
structure they use? Don't even think of it...
--
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: SV: Object names
Richard Levitte wrote: And still, short names have been used for a while, since they do appear in X.400 addresses and in DNs a little here and there. Pardon me for butting in to the discussion this late, but is this really an issue of short or long names? I think the core problem at hand seems to be the fact that there appears to be confusion about the relationships between the X.500 attribute type names and their RFC 2256 string representations. 'commonName' and 'cn' are not long and short names for 2.5.4.3, rather ASN.1 and UTF-8 (string) names. commonName is an X.520 AttributeType for use by other ASN.1 modules. Where a string representation of this attribute type is required (when sending a DN via LDAP, or in an e-mail signature for example), RFC 2256 mandates that it be encoded as the string 'cn'. The string 'commonName' is to my knowledge *not* an acknowledged alternative string encoding of the attribute type. I can't find any mention of it in 2256, anyway. //oscar smime.p7s
Re: Object names
Richard Levitte - VMS Whacker wrote: But I guess that the right way would be to make it less humanly readable and use the hash of the issuer DN, the same way it should be done according to RFC2560... RFC2560: "issuerNameHash is the hash of the Issuer's distinguished name. The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked." DER encodings of equivalent DNs are always the same? I don't think so. Ciao, Michael. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
Michael Ströder wrote: Richard Levitte - VMS Whacker wrote: X509_NAME_oneline(), it's displayed as "/Email=...". Other products, like the JDK, seem to name it "/EmailAddress=...". As you can see, that will create a problem when you try to use the representation used by one system in another system. The /ATTR= writing should be abandoned anyway since it's not a proper string representation (no proper escaping of special chars). Yes X509_NAME_oneline() should now be avoided its only there for compatibility. The function X509_NAME_print_ex() should be used, though it hasn't had much "real world" testing yet, but it has loads of options for customising output. Currently only the 'x509' app uses it if selected. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
From: Michael **UNKNOWN CHARSET** [EMAIL PROTECTED] michael Richard Levitte - VMS Whacker wrote: michael michael But for example, the michael "legal" shortnames for the DN attributes should be available michael somewhere. michael michael Can you list a limited set of attribute types for certificate michael DNs? I can't. That's not what I'm asking for. Anything "legal" is, in my book, something defined in an RFC or X.nnn or something like that. I have not said that it has to cover all attributes that exist or may exist, I just want a list of those that have been defined as said in the previous senteence. Please don't make this harder than it has to be. michael I do not have access to the X.500 documents. But RFC2256 is a michael good start for getting an idea of the X.500 schema. BTW: You michael won't find anything there related to e-mail addresses. Thank you, that one, together with 2253, are a great start. michael Again: The only reference to an attribute type is the OID! I know that. Unfortunately, there are applications out there that attempt to use the textual representation of a DN. One perfect example is LDAP anytime you search for anything (at least, I'm told there are implementations that do not know how to handle DNs with OIDs for names). michael But I guess that the right way would be to make it less humanly michael readable and use the hash of the issuer DN, michael michael NO! A hash is a significant information loss... ;-) I don't meant to replace any DN with a hash, just add a hash in the catalogue entry for index and easy retrieval. The real DN of a certificate would still be part of the certificate itself. michael the same way it should be done according to RFC2560... michael michael OCSP does almost nothing with the issuerName. Have you read RFC2560 properly? You can have responders that answer for other CA's. Multiple CA's even. Considering that, you do need an issuer index as well as the serial number of the cert to validate. michael The OCSP server of a CA can reference a cert by serialNumber michael anyway. But that's limiting one responder for each CA. IIRC, Valicert wants to set up a global responder that can handle requests for other CA's as well as their own... -- 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]
RE: SV: Object names
From: "Oscar Jacobsson" [EMAIL PROTECTED] oscar.jacobsson 'commonName' and 'cn' are not long and short names oscar.jacobsson for 2.5.4.3, rather ASN.1 and UTF-8 (string) names. Hmm, that (and the rest of your explanation) made the whole thing a bit more comprehensible. Thanks, buddy. -- 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]
