[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: About userSMIMECertificate&userPKCS12 attributes

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? 

Best regards

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 "" 
> >(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 ( 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.
> Kurt

Zhang Pu zhang@fjh.fujitsu.com