RE: interoperability of ;binary

[Chris Ridd <chris.ridd@messagingdirect.com>]

"Ramsay, Ron" <Ron.Ramsay@ca.com> wrote:
> Leif,
> 
> This looks good to me for the return of attributes.
> 
> The problem it doesn't address is the current usage of ;binary for
> returning certificate-related attributes. If (only) this could be
> dropped, certificate syntax could be defined to be binary, meaning that
> it could only be transferred BER-encoded.
> 
> PS: DER is a stricter form of BER. It is often not clear when DER takes
> over. Certificate extensions needn't be DER (they are mapped to octet
> strings) and it is not clear if the certificate itself should be encoded
> as DER, only the toBeSigned part technically has to be DER. I would have
> thought that 'binary' syntax objects would be sent to the server as
> BER/DER, stored in this form and subsequently retrieved, all without
> decoding the value. If a server chooses to decode the value then it would
> have to handle the consequences, noting that not all binary values would
> be DER (eg photo from inetOrgPerson).

Actually this is a good source of interop problems. Lots of CA/security
vendors *require* the server to return things like certificates to be
returned DER encoded, and of course LDAP does not require this.

There's also nothing in the LDAP RFCs to prevent a server from re-encoding
a certificate it receives from a DUA. As long as what comes out is BER, the
server is behaving correctly according to the RFCs.

There should be some way of properly requesting DER - either changing
";binary" to mean DER, or adding another transfer option, or adding a
control (probably critical), just to clean all this nastiness up.

Cheers,

Chris