RE: interoperability of ;binary

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

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).

Ron.

-----Original Message-----
From: Leif Johansson [mailto:leifj@it.su.se]
Sent: Tuesday, 10 April 2001 16:47
To: Ramsay, Ron
Cc: Kurt D. Zeilenga; Jim Sermersheim; ietf-ldapbis@OpenLDAP.org
Subject: Re: interoperability of ;binary 



Another spin on this: transfer-options like ;binary can just as easily
be implemented as an ldap control (i.e "gimme all values encoded using X").
Language tags seem to be different. That was my though when raising the
issue.

	Cheers Leif

PS Everybody is talking about ;binary = BER but I assume that in the case
of userCertificate at least, DER encoding is what you need. Right? DS