Subject: RE: interoperability of ;binary

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 10 Apr 2001 17:43:02 +1000

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:[email-masked]]
Sent: Tuesday, 10 April 2001 16:47
To: Ramsay, Ron
Cc: Kurt D. Zeilenga; Jim Sermersheim; [email-masked]
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

---

From: Chris Ridd <[email-masked]>
Date: Tue, 10 Apr 2001 10:03:46 +0100

"Ramsay, Ron" <[email-masked]> wrote:
> 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.
> 
> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Apr 2001 07:39:20 -0700

At 05:43 PM 4/10/01 +1000, Ramsay, Ron wrote:
>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.

The technical specification only defines the information
representation within the protocol.  The server is free to
store any attribute value, regardless of how it was transferred,
in any form it chooses so long as it does not violate the
LDAP interface.

>If a server chooses to decode the value then it would have to handle

It could be argued that every LDAP syntax is described
by some ASN.1 data type definition and hence could be
encoded using any ASN.1 encoding rules.

Kurt