[Date Prev][Date Next]
Re: About userSMIMECertificate&userPKCS12 attributes
One should use ldap_get_values_len() regardless.
At 06:03 PM 8/1/2004, ZhangPu wrote:
>Thanks for your answer. > Kurt & Ciao, Michael
>In confirmation of ldap api additionally, native ldap string can be gotten by ldap_get_values()
>although attributes syntax is "binary". ldap_get_values_len() only can be used to get ";binary"
>an unnative ldap string. <--- Is this right?
>On Fri, 30 Jul 2004 08:00:48 -0700
>"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:
>> At 01:13 AM 7/30/2004, ZhangPu wrote:
>> >There is a question about the attributes userSMIMECertificate and userPKCS12.
>> >Currently, OpenLDAP does not support the ";binary" transferring method for the two
>> >attributes above although this had been defined in RFC2798.
>> >Because the syntax of these two attributes was defined with "184.108.40.206.4.1.14220.127.116.11.5"
>> >(also this syntax was defined as meaning "BINARY" in RFC2252), I'm not sure, are these
>> >two attributes always transferred by BINARY mode in any case from client to server or from
>> >server to client?
>> Don't confuse the Binary (18.104.22.168.4.1.1422.214.171.124.5) syntax with the
>> ;binary transfer option (and with the LDIF :: format). Also note
>> that for both Binary and ;binary, the name doesn't imply "binary data"
>> (all LDAP data are 0s and 1s). (The Binary syntax likely should have
>> been called Any syntax and the ;binary transfer option should likely
>> have been called the transfer-BER option. Oh well.)
>> Anyways, slapd(8) requires that all values of a syntax be transferred in
>> the native LDAP string encoding if defined. ;binary transfer option is only
>> to be used where no native LDAP string encoding has been defined. For instance,
>> values of CN attribute (DirectoryString) are to be transferred as UTF-8
>> encoded Unicode strings (e.g., 'CN') and not the BER-encoded DirectoryStrings
>> (e.g., 'CN;binary'). Values of userCertificate are to be transferred using
>> ;binary as the Certificate syntax has no defined native LDAP string encoding.
>> The Binary syntax has a defined (in RFC 2252) native LDAP string encoding
>> and hence is expected to be transferred in that string encoding.
>> RFC 2798 is odd in that suggests use of ;binary for a syntax which has
>> a native LDAP string encoding. slapd(8) cannot support that without
>> always using ;binary for that syntax, and doing that would cause
>> interoperability problems for other attributes of the Binary syntax.
>Zhang Pu email@example.com