[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: About userSMIMECertificate&userPKCS12 attributes
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 "1.3.6.1.4.1.1466.115.121.1.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 (1.3.6.1.4.1.1466.115.121.1.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.
Kurt