Subject: LDAP Extension Style Guide, re interaction between controls

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 16 Aug 2000 15:08:45 -0700

Kurt,

A few days ago, you wrote:

>Just one comment on this comment... "when extending an operation though
>definition of one or more controls, the specification SHOULD clearly
>specify interactions with other, previously-defined, extensions
>(using other controls).  The specification MAY NOT restrict further
>extension of the operation by placement of additional, yet to
>be defined, controls."

I suddenly realize that I don't understand your last sentence.  Can you 
please clarify with an example?  Thanks,

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Aug 2000 16:00:31 -0700

At 03:08 PM 8/16/00 -0700, Bruce Greenblatt wrote:
>I suddenly realize that I don't understand your last sentence.  Can you please clarify with an example?  Thanks,

First, let me state that I believe 2251 needs a clarification like
(needs much work, will note this for later LDAPbis discussions):
  "Controls SHOULD NOT be combined unless the semantics of the
  combination has been defined.  A server MAY ignore non-critical
  controls (even those it recognizes) to establish semantics
  of the operation (e.g. if two non-critical controls are combined,
  one or both may be ignored).  A server MUST NOT ignore any
  critical control (e.g. if one or more critical controls are
  combined with zero or more non-critical controls, the server MAY
  ignore any of the non-critical controls, but must perform the
  operation as defined by remaining controls.  If no semantics
  are defined for this remaining combination of controls, the
  server MUST return unavailableCriticalExtension"

Such a clarification would only require extensions to define
control combinations which make sense.  This would be consistent
with common practices.

Anyways, the last sentence was meant to indicate that any extension
may be further extended.  In particular, the specification should not
detail or restrict interactions with yet to defined controls.  If
such interactions are appropriate, the later defined control should
detail the semantics of the interaction.

It should be also noted that any attempt to say "This specification
SHALL NOT be updated by future specifications" is pointless
as the future specification can update that restriction away.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Aug 2000 16:31:50 -0700

>as the future specification can update that restriction away.

But it is quite appropriate for a specification to limit
its scope and to indicate portions of the specifications
meant to be defined in future specifications.

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 18 Aug 2000 17:36:29 +0100

>   controls (even those it recognizes) to establish semantics of the
>   operation 

Note that the Internet2 guys, IETF PKIX group and Middleware 
people have been discussing this issue, as X.500 is ambiguous in 
this case. A defect report has now been issued on X.500, and the 
proposed solution is contrary to the above, i.e. it states that a 
server that understands an extension (control in the case of LDAP) 
MUST obey it even if it is marked non critical. I would like LDAP to 
either take the same stance for compatibility purposes, or to 
persuade the X.500 , PKIX and other groups that the proposed 
solution is wrong and that the server should be free to choose what 
to do. Either way, I think that compatibility should be the target.

David

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

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
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: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 Aug 2000 10:01:00 -0700

At 05:36 PM 8/18/00 +0100, David Chadwick wrote:

>MUST obey it even if it is marked non critical.

The issue is that the extension, as defined by two recognized
controls, is NOT understood because the semantics of the
combination is not defined.

LDAP allows for a non-critical control to be ignored.  This
implies that if a request contains two controls, one critical
and one not, is submitted to a server which recognizes BOTH
controls but does not understand the semantics of the
combination, the server must either:
  a) return unavailableCriticalExtension
  b) perform the operation as if the non-critical extension
  was not specified.

I prefer option a) as it follows from the similar case:
a request contains two controls, a recognized critical
control and a unrecognized non-critical control.

However, I can see the value offered in option b.

>I would like LDAP to 

I concur!

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 23 Aug 2000 17:35:39 +0100

Date sent:      	Fri, 18 Aug 2000 10:01:00 -0700
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>

> combination is not defined.

Sorry, missed that point

> LDAP allows for a non-critical control to be ignored. 

This is the bit that, on its own, would come into conflict with X.500 if 
the aforementioned defect is accepted.

> This

I do too, as this is the same as if both were critical, and would be in 
the spirit of the X.500 defect correction.

> control and a unrecognized non-critical control.

In this case I would suggest option b) is followed, as the server only 
understands one of the controls, and is obeying it.

But what about the case of two controls, both non-critical, both 
understood in isolation, but the combination not. What does the 
server do now - selectively ignore one of them? If so which one?

I think the PKIX and X.509 guys may also hit the above problems, 
given that certificate extensions are object identifiers and can be 
defined by anyone. I will raise this topic on the PKIX list. 

David

P.S. The problem does not (or should not) arise for DAP as all the 
extensions (controls) are specified together as a whole in one 
document, and each extension is identified by an integer. 
Interactions should be fully spelt out in the base standard, and 
private extensions cannot be defined (legally).

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 23 Aug 2000 09:58:11 -0700

>server do now - selectively ignore one of them? If so which one?

I suggest ignore both under the general principle of least
astonishment.  I suggest:

An operation may be extended by one or more controls.  If the
combination of controls is unrecognized, undefined, or the
server is otherwise unwilling to perform the operation as
extended by the sequence of provided controls,
  if any of the controls are marked critical, the server
  SHALL return unavailableCriticalExtension,
  otherwise the server SHALL perform the operation as if
  no controls were provided.

That is, combined control semantics is all or nothing.

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 27 Aug 2000 16:52:19 +0100

Date sent:      	Wed, 23 Aug 2000 09:58:11 -0700
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>

>   SHALL return unavailableCriticalExtension,

I dont like this. Under the principle of "the server should do its best 
to provide a useful service", it should obey the known critical 
extension and ignore the non-critical ones.

This was the suggested text that I sent to PKIX list that 
unfortunately you did not receive (see below)

" A validation engine that does not understand the interaction of a 
non-critical extension with another extension (critical or non-critical),
may ignore the non-critical extension (even if it understands the
semantics of the extension in isolation to the others), and accept the
certificate (unless factors other than this extension cause it to be
rejected).

A validation engine that does not understand the interaction of two 
critical extensions, must reject the certificate (even if it understands
the semantics of both extensions in isolation to each other)."

> That is, combined control semantics is all or nothing.

My messages directly to you are getting bounced as follows:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. The following address(es) failed:

  [email-masked]:
    SMTP error from remote mailer after MAIL
    FROM:<[email-masked]>: host mail.openldap.org
    [204.152.186.51]: 550 5.0.0 Rejected - see
    http://www.mail-abuse.org/rss/

This means that you did NOT get a copy about this topic that I sent 
to the PKIX group. They are now following up on this, and are 
proposing to produce a table of allowed extensions that can be 
used in combinations. Is this something that LDAPExt should do?

David

P.s could the bouncing be due to my newly installed firewall that 
ignores messages from unknown hosts (I am operating in stealth 
mode). I noticed that I received an unidentified message 
immediately after sending an email to you. Are you testing out 
senders to see if they exist?

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 27 Aug 2000 10:30:02 -0700

>extension and ignore the non-critical ones.

I go back and forth on this issue.  I guess if the client wants
to ensure that the server fully recognizes the combination of
controls, the client should mark each the controls as critical.

So, basically, the server must ignore non-critical extensions
which don't make sense in the context of the operation.

If the operation has recognized and supported controls A, B and C.
Where A is critical, B and C are non-critical, the semantics of A+B and
A+C are defined, and the semantics of A+B+C are not defined (or
explicitly defined as invalid), then the server may perform either:
        A, A+B, or A+C.

>unfortunately you did not receive (see below)

I do recall seeing that (directly, I'm not subscribed to the
PKIX list)...  I'll chat with you off line (if our MTAs will
cooperate).
        Kurt