RE: New ID on LDAPv3

["David Chadwick" <[e-mail]>]

From:           	Christopher Oliva <[e-mail]>
To:             	"'[e-mail]'" 
<[e-mail]>
Copies to:      	Mike Just <[e-mail]>
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!!

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


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

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

> 
> 3) Point 2, Paragraph 1 - re other attribute options
> 
> I feel that the statement that other attribute options should not be
> supported is unnecessary and should be removed. Otherwise a valid reason
> for this should be provided.

As a result of this and Mark Wahl's comments, this has now been 
changed to

"Other attribute description options SHOULD NOT 
be generated by clients. Servers MAY choose to 
support them at their discretion."

The rationale is to simply implemenations since this feature is not 
required for PKIX operation.

> 
> 4) Point 2, Paragraph 2 - re UTF8 encodings
> 
> Support for UTF8 should include a statement which specifies that raw,
> binary UTF8 should be used in the protocol and the escaped hex-ascii
> mechanism of RFC 2253 should not be used in the protocol.
> 

I dont agree with this from reading the LDAP specs. This will need to 
be discussed by a wider audience, including the LDAP group 
before I make a change.

> 5) Point 2, Paragraph 2 - re distinguished names
> 
> From experiences with some directory vendors, I feel it is necessary to
> state that DN support MUST include support for multiple AVAs within RDN
> components and that the ordering of the AVAs is non-deterministic. For
> example cn=John + uid=123 is the same as uid=123 + cn=John.
> 

Good Point.Agreed. The inserted text reads as follows:

Multiple attribute value assertions (AVAs) within 
RDN components of distinguished names MUST be 
supported and the ordering of the AVAs is non-
deterministic. For example cn=John + uid=123 is 
the same as uid=123 + cn=John.


> 6) Point 2 - Additional recommendation - common schema
> 
> I'm sure that a common ldapv3 schema is planned to support the protocol

I had not planned to do this, I dont know if you want to start?

> profile but it would be important to reference it and perhaps note that
> only the standard attribute names MUST be used by the client and server.

SHOULD is probably better here, since orgs could change it if they 
had a really good reason to.

> For example, legacy names such as rfc822Mailbox should not be used. the
> attribute name is more commonly defined as "mail". Since that is not
> actually standardized anywhere I think a common schema for this type of
> thing would be useful.

The closest it has got to standardisation is the InetOrgPerson draft 
from Mark Smith

> 
> I would also like to recommend that the common schema should include a
> mechanism to identify what CAs have authority within a given subtree of
> the DIT. This could take the form of a collective attribute which applies
> to specific users or as a multi valued root DSE operational attribute
> which applies to subtrees.

I had not thought about this before. You seem to be suggesting that I 
can search the DIT to find out which CA is in charge, is that correct.
What purpose does this serve? Since I can get this anyway from 
the issuer field of the retrieved cert.

> 
> 7) Point 3 - re referrals and search continuations
> 
> RFC 2255 allows ldap URLs to identify new search filters, and list of
> attributes to return as well as new bind credentials. This MUST not be
> supported in the PKI environment since integrity of the operations require
> consistency in these parameters.
> 

I have inserted the following text

However, the returned referrals SHOULD NOT 
specify new search filters, attributes to be 
returned or user credentials. Servers SHOULD only 
return the hostport, and DN components and MAY 
return the scope component.

(Scope is needed for a onelevel search that hits an alias in another 
server)

> I would like to propose a new extension for URLs: a minimal authentication
> level. This would specify the minimal authentication level which is
> necessary to bind to the server. This would never be critical so the
> client is free to use a stronger form of authentication if so desired.

This ID is not the correct place to add updates to the URL. THis 
should be referred to the LDAPExt group. However, if you are 
suggesting returning authentication level information, why not accept 
new credentials as well?


> 
> 8) Point 4 - Paragraph 1 - re modifyDN, compare and abandon operations
> 
> I see no reason that these operations should be omitted. Perhaps in the
> case of modifyDN there may be concern with respect to making sure that the
> DN in the certificate subject is the same as the DN in the entry name
> however this is dependent on the organization's CPS and other
> implementation factors. Generally, I believe that leaving the statement in
> the current draft will lead to confusion and degraded functionality and
> should be removed (vendors should not be discouraged from supporting
> ModifyDN which is an extremely useful operation).

After discussion with Mark Wahl, the text currently reads:
"A client following this profile need not send 
the ModifyDN, Compare and Abandon operations. The 
server MAY choose to support these operations at 
its discretion."

I appreciate that Entrust does support change of 
DN, and I can see its use. Does the above satisfy 
you or not?


> 
> 9) Point 4 - Paragraph 4 - re schema publication
> 
> I don't see why vendors would be discouraged from publishing the schema.
> Indeed it is conceivable that a server's support of schema may affect how
> revocation information is published or how user entries are created. There
> are also other useful reasons to retrieve schema information such as
> constructing a list of attribute which have opaque binary syntaxes and
> cannot be displayed to users. The statement should be removed unless there
> is a strong argument for discouraging vendors from implementing schema
> publication.

This was not the rationale for excluding it.I am generally in favour of 
schema publishing. I thought (perhaps incorrectly) that it was not 
needed by PKIX. Mark Wahl pointed out one use for it, and I am 
happy to have schema publishing in the ID. The text currenly has 
matching rules added as follows:

"LDAPv3 allows the subschema supported by the 
server to be published in a subschema subentry. 
Clients following this profile which support
invoking a search containing an extensible 
matching rule MAY use the
subschemaSubentry attribute in the root DSE and 
retrieve the subschema to determine whether the 
server supports the certificateMatch matching 
rule described below."


If this is not sufficient for you please advise.

> 
> 10) Point 5 - Paragraph 4 - re certificate matching rules
> 
> I think that vendors should be encouraged to implement certificate
> matching rules as much as possible. For that reason, I would recommend
> that support of this feature should be upgraded to SHOULD rather than MAY.
> 

The text currently reads

"If the server supports flexible matching, then 
the extensibleMatch filter item MUST be 
supported. Clients MAY support the 
extensibleMatch filter item."

Is this enough for you or not?

David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
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

***************************************************