[Date Prev][Date Next]
Re: About userSMIMECertificate&userPKCS12 attributes
On Fri, 30 Jul 2004 10:44:17 +0200
Michael Stroder <email@example.com> wrote:
> 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?
> > They have SYNTAX that it is "BINARY", so I assume maybe these two
> > attributes are handled by a different processing to "jpegphoto" or
> > "audio".
> Yes. But this is only relevant for matching rules and syntax validation.
> In search results you will get back the binary data.
The search results what I meant is not final results, they are the values
which be gotten after ldap_search_st() be down.
> > I think "jpegphoto" and "audio" can be transferred by both
> > BINARY and BASE64 mode. <-- Is my understanding correct?
> There's no such thing like a base64 mode for LDAP search operations.
> > In addition, does Kurt will correct RFC2798 document to restrict
> > transferred method of "userSMIMECertificate" and "userPKCS12" to "::"
> It seems you're mixing the LDIF text file representation of directory data
> and what you get back as a result of LDAP search operation.
No. Because RFC2798 defined the transferring method of "userSMIMECertificate"
and "userPKCS12" as ";binary", but OpenLDAP does not support it, I read some
information from mailing list told me that kurt want to revise this RFC document.
I only want to confirm it.
---------content of that mail-----------
Despite what RFC2798 says (it's just an informational document),
userSMIMECertificate should not be transferred in ;binary mode
and should be revised (as discussed on the IETF LDAPext mailing
Zhang Pu firstname.lastname@example.org