Subject: RE: New ID on LDAPv3

From: "Salter, Thomas A" <[email-masked]>
Date: Wed, 14 Jul 1999 16:52:18 -0400

My comments below relate only to the BER/DER and ;binary discussions.  

 > -----Original Message-----
 > From: David Chadwick [mailto:[email-masked]]
 > Sent: Wednesday, July 14, 1999 3:39 PM
 > To: Christopher Oliva; Mike Just
 > Cc: [email-masked]
 > Subject: RE: New ID on LDAPv3
 > 
 > 
 > From:           	Christopher Oliva <[email-masked]>
 > To:             	"[email-masked]'" 
 > <[email-masked]>
 > Copies to:      	Mike Just <[email-masked]>
 > Subject:        	RE: New ID on LDAPv3
 > Date sent:      	Thu, 8 Jul 1999 10:45:31 -0400 
 > 
 > > Hi,
 > > 
 > > I have some comments on the ldapv3 profile:
 > > 
 > > 1) Point 2, Paragraph 1 - re BER encodings
 > > 
 > > Interoperability with various vendors has shown that the 
 > industry trend is
 > > set towards using DER encodings in the protocol. The BER encodings
 > > specified by ldapv3 is too liberal which many clients 
 > cannot properly
 > 
 > There are two sets of encodings to consider. 
 > i) the encoding of the LDAP protocol itself - the request, response 
 > and all the parameters. This is specified as a simplified version of 
 > BER (eg. definite length encodings must be used). I presume you 
 > are not referring to this.
 > ii) the encoding of the X.509 attributes, i.e. certificates 
 > and CRLs. 
 > This is an issue for the CA and not for LDAP in my opinion. 
 > It is the 
 > CA that initially puts the signature on the data item and 
 > then passes 
 > it to the directory for storage. In the process of creating the 
 > signature the CA decide to do DER encoding according to X.509 
 > standard. The directory should not in my opinion decode and then 
 > recode the attribute during storage otherwise it could 
 > invalidate the 
 > signature. Rather the directory may decode (in order to extract the 
 > data item for use in indexing and searches) but should store the 
 > encoded attribute as is, ready for retrieval.
 > 
 > By the way, I am perfectly happy with the wording in RFC 2559 as it 
 > stands and can cut and paste this as appropriately into the 
 > ID if you 
 > wish.
 > 
 > > parse. For that reason, the ldapv3 profile should be 
 > aligned with the
 > > current RFC 2559 and mandate DER encodings. In this case 
 > the clients must
 > > use DER encodings when adding new attribute values and the 
 > server must
 > > return the identical encoding which was originally added 
 > by the client.
 > > 
 > 
 > It seems like we are in agreement here. Incidentally, a CA could use 
 > BER to generate a signature and it should  still all work 
 > fine providing 
 > clients can decode BER. Clients other than CAs should never need 
 > to encode in BER.
 > 
 > > Also, this constraint should apply not only to CRLs and 
 > certificate but to
 > > any attribute which has a SIGNED syntax (for example, 
 > caCertificate,
 > > attributeCertificate etc.)
 > 
 > AGREED!!
 > 

Is the confusion here that the ;binary description says to use BER, but
certificates, CRLs, etc. must be in DER?  Perhaps the server should be
required to preserve the encoding of binary attributes as they were added;
that is, the server must not decode and re-encode certificates.  Then
signatures can be validated even if the original attribute was not quite
correct DER.

 > > 
 > > 2) Point 2, Paragraph 1 - re ;binary support
 > > 
 > > In my opinion, support of the ;binary attribute option is somewhat
 > > ambiguous in the ldap specification. 
 > 
 > Agreed, this is why I added some minimal explanatory text in the ID. 
 > It obviously was not enough. However, we really ought to be 
 > updating the base LDAP texts and not fixing it in the PKIX profile. 
 > Dont you agree?
 > 
 > >I would like to include some text in
 > > the profile to clarify exactly what the behaviour of 
 > clients and server
 > > should be with respect to ;binary. My suggestion is:
 > > 
 > >  ".. When a client adds, deletes or modifies values which 
 > are defined to
 > > have the Binary syntax (defined in RFC 2252), the 
 > attribute type name MUST
 > > always be specified with the ;binary attribute option. 
 > 
 > Dont forget the case of a client retrieving a certificate as well. 
 > ;binary is mandatory for this as well.
 > 
 > >When the server
 > > returns such an attribute in a search result, the 
 > attribute type name
 > > SHOULD include the ;binary but it is not necessary 
 > (whether or not the
 > > attribute type was explicitly requested in the search operation). 
 > 
 > Why do you relax this to SHOULD. What is wrong with MUST. Is it 
 > because the client can infer this during parsing.
 > 

Is there a distinction here between attributes with Binary syntax and
others, such as those with Certificate syntax ?  RFC2252 clearly states that
attributes with certificate syntax must always be requested or returned with
;binary.
 
 > 
 > >The
 > > encoding of the attribute value is BER or DER (for 
 > attributes whose ASN.1
 > > syntax is a SIGNED structure).
 > > 
 > >  When a client adds, deletes or modifies values which are 
 > not defined to
 > > have the Binary syntax, the use of ;binary in the 
 > attribute type name is
 > > optional however if ;binary is used, the value MUST be a valid BER
 > > encoding. If the server cannot accept this form of 
 > presentation of the
 > > attribute value, the server MUST respond with an 
 > invalidAttributeSyntax
 > > error. 
 > 
 > I dont think any of the above has anything to do with PKIX since all 
 > the X.509 attributes are binary. I do not propose putting 
 > this text in 
 > at the moment unless other people think I should.
 > 
 > >If the attribute name with ;binary is specified in a modify
 > > (delete) operation (such that no new values are specified 
 > in the client
 > > operation), the server MUST accept the request as if the 
 > ;binary option
 > > was not present. 
 > 
 > This is not PKIX specific but LDAP general. Is there a bug in LDAP 
 > here?
 > 
 > >When the client performs a search operation and the
 > > attribute type is not explicitly requested or is 
 > explicitly requested
 > > without the ;binary option, the server MUST return an 
 > encoding of the
 > > attribute which matches the syntax used in the attribute's schema
 > > definition. If the attribute type is explicitly requested 
 > with the ;binary
 > > option, the server MUST return a BER encoding for the 
 > value and the type
 > > name SHOULD include the ;binary option. In this case, if 
 > the server cannot
 > > return a BER encoding, it must omit the attribute from the 
 > search response
 > > (treat it as if it were an undefined attribute type).
 > 
 > Again this seems to me to be general LDAP text rather than PKIX 
 > specific text.
 > 

The server should be required to specify the ;binary whenever it returns BER
encodings.

 > > 
 > >  If the attribute in question is defined to have an Octet String
 > > syntax, the same octet string encoding is always used by 
 > the client and
 > > returned by the server whether or not the ;binary option 
 > is used in the
 > > client operation (i.e. the transmitted value will not have 
 > an extra OCTET
 > > STRING wrapper). In this case, the attribute may or may 
 > not have a BER
 > > encoding ..."
 > 
 > ditto above.
 > 

Why is OCTET STRING a special case ?  As I read the RFCs, a server can
support ;binary on attributes of any syntax, in which case it returns the
BER encoding of the value.  An OCTET STRING should be handled just like an
INTEGER or a SEQUENCE, so there would be an extra OCTET STRING wrapper.

... rest deleted ...

 > ***************************************************
 > 
 > David Chadwick
 > IT Institute, University of Salford, Salford M5 4WT
 > Tel +44 161 295 5351  Fax +44 161 745 8169
 > *NEW* Mobile +44 790 167 0359 *NEW*
 > Email [email-masked]
 > Home Page  http://www.salford.ac.uk/its024/chadwick.htm
 > Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
 > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
 > Entrust key validation string MLJ9-DU5T-HV8J
 > 
 > ***************************************************
 >

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 14 Jul 1999 22:42:30 +0100

> signatures can be validated even if the original attribute was not quite

You have it in one. I also think some brain dead servers may 
decode and recode the signed attributes :-) (only heresay though, 
dont know of a concrete example)

> others, such as those with Certificate syntax ?  RFC2252 clearly states
> that attributes with certificate syntax must always be requested or
> returned with ;binary.
> 

I think Chris was trying to have separate text for certificates that 
must be sent with binary syntax and any attributes that may be sent 
with binary syntax. But I did not think that this text was appropriate 
for the PKIX profile.

> 
> The server should be required to specify the ;binary whenever it returns
> BER encodings.

I can certainly agree with this

> INTEGER or a SEQUENCE, so there would be an extra OCTET STRING wrapper.

This also seems fine to me
David

David Chadwick