Subject: Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]

From: Steven Legg <[email-masked]>
Date: Fri, 16 Apr 2010 14:53:37 +1000

Hi Daniel,

Daniel Pluta wrote:
> Dear ldapext,
> 
> we would appreciate your valuable comments and feedback regrading our 
> draft specifying "ldap server side current time matching".

The draft is essentially about enforcing access control policy through
schema mechanisms, which strikes me as inappropriate for two principal
reasons:

(1) Schema is supposed to be immutable, whereas access control policy
is subject to change. If access control policy is reflected in the
attribute syntaxes one chooses, then that policy is permanently locked-in.

(2) Schema is one-size-fits-all. The same rules apply to everyone,
regardless of whether they are anonymous guest users or highly privileged
administrators. Access control policy is rarely that uniform.

Privacy goals should be addressed through access control mechanisms,
but of course you are hampered by the absence of a common, standardized
access control mechanism across all LDAP implementations. With that in
mind I would take a somewhat different approach to a solution.

Basically you want to allow general access to a derived property of
a collection of attributes while simultaneously enforcing restricted
access to that collection of attributes. What I would do is define a
schema mechanism for defining derived attributes, i.e., attributes
whose values are algorithmically derived by the server from the values
of other attributes in the same entry. The derived attributes can then
be subject to different access controls than the source attributes.

In your example with the notValidBefore and notValidAfter attributes,
I imagine having a derived attribute called currentlyValid, with
Boolean Syntax, that is derived from notValidBefore and
notValidAfter according to the following pseudo code:

     if (current time >= notValidBefore and
         current time <= notValidAfter) then
         value = TRUE
     else
         value = FALSE

Privileged users and processes would be given permission to read
and update the notValidBefore and notValidAfter attributes, but
regular users would only be able to read the currentlyValid
attribute. This kind of access control policy can be expressed in
existing LDAP access control schemes even though they differ between
implementations.

That takes care of the nowBefore and nowAfter syntaxes. I don't see
that you achieve anything with the nowBeforeOffset and nowAfterOffset
syntaxes since a user can just use a binary search to determine the
actual values of the target attributes by adjusting the offsets (a
client can guess the time at the server with reasonable accuracy).
Limiting the sign or magnitude of the offset would provide partial
protection, but a derived attribute could also do that. For example,
to allow regular users to determine when a valid account became valid
but not allow them to determine whether or when an account will become
valid at some time in the future I would define a derived attribute
of GeneralizedTime syntax whose values are determined by the following
pseudo code:

     if (current time >= notValidBefore)
         value = notValidBefore
     else
         absent

It becomes a question of how expressive should the derivation rules be
and what form should they take ? I think OpenLDAP might have some
capabilities in that area already.

The nowOffset syntax isn't required if derived attributes are used instead,
but if you want to persist with it I suggest you align it with the existing
ASN.1 DURATION data type (see http://www.itu.int/rec/T-REC-X.680-200606-S!Amd3/en )
rather than rolling your own format, not the least because I already have an
implementation that supports DURATION as an attribute and assertion syntax
for both X.500 and LDAP.

Regards,
Steven

> 
> Please see below for the abstract.
> 
> The full version can be found here: 
> http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-00.txt
> 
> Many thanks in advance!
> 
> Best regards
> Daniel
> 
> 
> -------- Original-Nachricht --------
> Betreff: New Version Notification for 
> draft-pluta-ldap-srv-side-current-time-match-00
> Datum: Thu, 25 Mar 2010 15:51:33 -0700 (PDT)
> Von: IETF I-D Submission Tool <[email-masked]>
> 
> 
> A new version of I-D, 
> draft-pluta-ldap-srv-side-current-time-match-00.txt has been 
> successfully submitted and posted to the IETF repository.
> 
> Filename:     draft-pluta-ldap-srv-side-current-time-match
> Revision:     00
> Title:         Lightweight Directory Access Protocol (LDAP): Server Side 
> Current Time Matching - Matching Rules and Syntaxes
> Creation_date:     2010-03-25
> WG ID:         Independent Submission
> Number_of_pages: 20
> 
> Abstract:
> This document extends the Lightweight Directory Access Protocol
> (LDAP) to support server side current time matching.  Matching of
> attribute values against an LDAP server's current time offers
> additional functionality with regard to authorization and fulfills
> enhanced data privacy requirements for restrictive environments.
> Therefore this specification defines four additional syntaxes and
> related matching rules useful for extensible matching in association
> with these syntaxes.  In addition and for general use the matching
> rules defined in this document are also applicable to any attribute
> type definitions that are using the 'Generalized Time' syntax.  This
> specification also contains restrictive attribute type definitions
> demonstrating the usage of the introduced syntaxes and matching
> rules.
> 
> 
> 
> 
> The IETF Secretariat.
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Daniel Pluta <[email-masked]>
Date: Mon, 19 Apr 2010 14:22:09 +0200

Dear Steven,

many thanks for your feedback! Your suggestion regarding a solution to 
support "entry validity period evaluation" based on simple server 
internal time-stamp delta calculations which result in a derived boolean 
attribute sounds interesting and is surely worth to be discussed in 
detail in the (near) future, but... ;-)

Our primary intention of this draft is to introduce some kind of 
additional not yet available matching possibilities for LDAP: we need to 
implement support for comparison of time-stamp values relative to the 
server's current time and some related requirements, publishing the 
current time and timezone (location) information via the Root-DSE.

Our finally mentioned use case/scenario which combines the matching 
rules with further syntax and schema definition to achieve some kind of 
"entry validity period evaluation" feature is intended as example to 
motivate the need for current time matching. It is a direct result based 
on our experiments with current time matching rules, which probably 
deflects from our primary intention.

Your suggested solution does not need to make use of current time 
matching rules (due to server internal delta calculation which first of 
all seems to be an easy and elegant way) so this solution is strictly 
limited to the scenario where two time-stamps define a rather hard 
validity period (begin and end).
On the other side, what about the possibility to use one of the two 
time-stamps (or any other time-stamp attribute) within scenarios where 
flexible transitions times (e.g. +2 months/days/... after or before a 
given time) need to be supported, too? Therefore the server internal 
calculation suggested by you need to be customizable depending on the 
operations details...

To support these kind of requirements the matching rules are of general 
interest. Based on our current experimental implementation (which 
possibly needs to be reduced to the matching basics) of these matching 
rules in combination with your implementation of the X680 duration 
specification the matching could be of general use for LDAP, too.

In our opinion there is currently nothing to be said against the 
reasonable use of both mechanisms. What do you think about this?

Best Regards,
Daniel

Steven Legg wrote:
> ASN.1 DURATION data type (see 
> http://www.itu.int/rec/T-REC-X.680-200606-S!Amd3/en )
>> Title:         Lightweight Directory Access Protocol (LDAP): Server 
>> Side Current Time Matching - Matching Rules and Syntaxes

---

From: Steven Legg <[email-masked]>
Date: Tue, 20 Apr 2010 12:45:31 +1000

Hi Daniel,

> current time and timezone (location) information via the Root-DSE.

GeneralizedTime values in LDAP are required to be in UTC or in local time
plus timezone (from which UTC can be calculated). The time matching rules
compare values according to their corresponding times in UTC. In reading
your draft I assumed that your time matching rules also operate with respect
to UTC. If that is not the case, then some clarification is needed. If it
is the case, then it boils down to a question of whether a time comparison
involving the current time is performed using the client's idea of UTC or
the server's. In an ideal world the client and server clocks will be
perfectly synchronized. In practice they will still be fairly close. Do
you have a use case where it is important to be using the server's idea
of the current time (which justifies new matching capabilities) rather
than the client's (which is achieved with current matching capabilities) ?
Do you have a specific reason why clients need to know the server's timezone ?

Incidentally, I have implemented operational attributes that expose the
current date and time, current time of day and current day of the week.
They appear in every entry and are created on demand.

> motivate the need for current time matching.

I don't think it helps. Rather, it raises new issues (like questions
about appropriateness) and the need for further justification. If particular
privacy outcomes are not a goal, then all you need is two matching rules
with DURATION assertion syntax that I might call currentTimeMatch and
currentTimeOrderingMatch. The currentTimeMatch rule tests if an attribute
value is equal to the current time plus an offset (i.e., the DURATION
assertion value, which can be positive, negative or zero) and the
currentTimeOrderingMatch tests if an attribute value is less than the
current time plus an offset.

 > It is a direct result based

Yes, that's why I said "it becomes a question of how expressive should
the derivation rules be and what form should they take ?". One way to
express the derivation rule for a boolean attribute is as a search filter,
which could use currentTimeMatch and currentTimeOrderingMatch ! It may
be more appropriate to have different derived attributes and end-points
to reflect "soft" and "hard" validity. Detailed use cases would help
guide such decisions. However, it doesn't matter if privacy outcomes
are not the goal.

> reasonable use of both mechanisms. What do you think about this?

New matching rules and derived attributes both have their uses,
singly or in combination, but using syntaxes to achieve access control
is just wrong to my mind.

Regards,
Steven

---

From: Daniel Pluta <[email-masked]>
Date: Tue, 20 Apr 2010 15:42:56 +0200

Hi Steven,

Steven Legg wrote:
> Daniel Pluta wrote:
>> many thanks for your feedback! Your suggestion regarding a solution 
>> to support "entry validity period evaluation" based on simple server 
>> internal time-stamp delta calculations which result in a derived 
>> boolean attribute sounds interesting and is surely worth to be 
>> discussed in detail in the (near) future, but... ;-)
>>
>> additional not yet available matching possibilities for LDAP: we need 
>> to implement support for comparison of time-stamp values relative to 
>> the server's current time and some related requirements, publishing 
>> the current time and timezone (location) information via the Root-DSE.
> to UTC. If that is not the case, then some clarification is needed. 

UTC is used.

> If it is the case, then it boils down to a question of whether a time 
> comparison
> the server's.

We specifically require the server's idea of UTC.

> In an ideal world the client and server clocks will be

There are various scenarios where this matching feature offer
advantages in addition to the existing ones. Especially in cases 
configuration directives in third party products do not allow to be 
dynamically rewritten to use the client's current time for each request. 
Specifying a search filter (endOfLifeTimeStamp:noOrEarlierMatch:=NOW) 
solves this. A client does not need to replace the assertion value for 
each request any more.

In environments the server does not trust the client side specified 
time-stamps a server can use a filter based ACL statement to enforce the 
filtering (OpenLDAP already support filters within ACLs).

> Do you have a specific reason why clients need to know the server's 

Some clients for example LDAP servers (thinking of global replication
over different timezones) profit from this information:
During replication of special/custom time-stamp attributes' values the
time-stamps can be adapted/transformed according the timezone delta
between source and destination. This ensures that the current time
comparison delivers always the same result independent from which LDAP
server in which timezone the client contacts. E.g. office-hours which
are defined in the user's entry. The comparison result need to be 
independent of the replica (its timezone) a client connects to.

> They appear in every entry and are created on demand.

Ok. We have decided to take the Root-DSE because we are not sure
whether this information is needed for each entry:
- As time flows which time of day is it? The time of the operation's
request or the time of the result set's delivery (constant result set
delivery time or still "drifting" for each result set's entry's delivery)?
- Depending on the first point: how does this impact perfomance?
- Depending on the first and the second point: What's the reason (use
case / scenario) where these information and the possible processing
overhead is worth for?

>> rules with further syntax and schema definition to achieve some kind 
>> of "entry validity period evaluation" feature is intended as example 
>> to motivate the need for current time matching.
> about appropriateness) and the need for further justification.

Please forget the additional syntaxes for now. In the meantime I've
learned that there is no possibility to support binary searching by
using an attribute of generalizedTime syntax within extensibleMatch
filters because ordering rules cannot be handled in extensibleMatching
rules because the specification does not say anything about ":<=" or ":>=".

<off topic>
Please correct me if I'm wrong but I currently do not understand exactly
what's the reason ":<=" or ":>=" is not supported/specified for
extensibleMatch filter expressions? Is it because of an LDAP
technical/design intention or just a specification issue?
Is it fallacious that in some time in the future the extensibleMatch 
filter specification may be gets extended to support ordering matching 
e.g. by ":<=" and ":>="? If an extension is possible then the additional 
syntaxes will be of use. In the meantime just ignore them please.
</off topic>

Independent of the syntax and extensibleMatch filter expression question 
we are nevertheless still focusing on enhanced privacy requirements and 
solutions by using the matching rules. The four matching rules 
(nowOrEarlier|nowOrEarlierOffset and nowOrLater|nowOrLaterOffset) in 
combination with OpenLDAP's powerful ACL definitions do already support 
to hide entries very easy and flexible without major source code 
changes. The same should be true for any other LDAP server that offers 
support for filter statements within ACLs.

In addition to privacy another scenario where the server side time
matching is very useful affects provisioning systems. E.g. identity 
management (IDM) system infrastructures can profit from such matching 
rules. They can be pre-provisioned (pre means timely in advance) and 
entries become available just-in-time (based on a single time-stamp 
attribute for example), without the need for an external event that has 
to trigger the provisioning (results in an entry's visibility). Beside 
the initial provisioning, the provisioning life-cycle becomes 
independent, more flexible, gets simplified and can be consolidated into 
the ldap server itself. Not to mention automatic de-provisioning without 
manual/external just-in-time interventions. De-provisioning is highly 
probable the wrong expression:
In IDM systems former identities need to be removed from core services 
but often also need to stay available for a subset of services (for 
alumna).
Currently this is often controlled by complete entry provisioning or
simple attribute changes (event or timely triggered or both). Although
these changes are known in advance for the majority of the users,
complex interdependent event handling mechanisms and triggers are
externally implemented to manipulate (e.g. hide or disable) entries for 
distinct services...
When using current time matching no events are needed in those 
scenarios. In OpenLDAP for example, by using an appropriate ACL the 
event's can be planned in advance and the partial de-provisioning will 
automatically and immediately take effect when time has come.

> If particular
>> matching rules (due to server internal delta calculation which first 
>> of all seems to be an easy and elegant way) so this solution is 
>> strictly limited to the scenario where two time-stamps define a 
>> rather hard validity period (begin and end).
>> time-stamps (or any other time-stamp attribute) within scenarios 
>> where flexible transitions times (e.g. +2 months/days/... after or 
>> before a given time) need to be supported, too? Therefore the server 
>> internal calculation suggested by you need to be customizable 
>> depending on the operations details...
>

As explained above LDAP servers that support filter statements during
ACL processing can fulfill the privacy goals very easily, because the
matching rules can be used to server-side force a filter via ACLs that
clients cannot overwrite or bypass.

>> To support these kind of requirements the matching rules are of 
>> general interest. Based on our current experimental implementation 
>> (which possibly needs to be reduced to the matching basics) of these 
>> matching rules in combination with your implementation of the X680 
>> duration specification the matching could be of general use for LDAP, 
>> too.
>>
> singly or in combination,

yes, for sure.

> but using syntaxes to achieve access control

yes, at least as long as extensibleMatch filter expression do not 
support ":<=" or ":>=" comparison operations...

Best regards,
Daniel

>> Steven Legg wrote:
>>>
>>> Hi Daniel,
>>>
>>> Daniel Pluta wrote:
>>>> Dear ldapext,
>>>>
>>>> we would appreciate your valuable comments and feedback regrading 
>>>> our draft specifying "ldap server side current time matching".
>>>

---

From: Steven Legg <[email-masked]>
Date: Wed, 21 Apr 2010 12:36:52 +1000

Hi Daniel,

> solves this. A client does not need to replace the assertion value for 

I think this is reasonable justification for new matching rules.

> filtering (OpenLDAP already support filters within ACLs).

The assertion here would be that it would be desirable to be able to express
access controls that depend on the relationship of timestamps in an entry
to the current time. That's something that can't be expressed otherwise.
It isn't about trusting the client's idea of UTC because that doesn't come
into the access control decision.

> between source and destination.

If the special/custom time-stamp attributes use the LDAP Generalized Time
syntax, then all servers will be working in UTC and all the values
will be in UTC or have sufficient information to derive UTC. There is
no need for any server to know the timezone of any other server.

 > This ensures that the current time
> are defined in the user's entry.

If the office hours attributes use the Generalized Time syntax, then
they are effectively expressed in UTC with the timezone already factored
in.

 > The comparison result need to be

It should be already because all comparisons are according to UTC.

> delivery time or still "drifting" for each result set's entry's delivery)?

Currently (for convenience) it is the instant when the entry contents are
composed for final filtering and access control checks. This means that each
entry could have a slightly different time. This is adequate for our current
purposes because the time difference between the first and last entry is
small compared to the precision that the consuming applications actually
need, and small compared to the typical skew between different machines.
If that ever changes we will review how the timestamps are generated.

> - Depending on the first point: how does this impact perfomance?

Barely at all in the great scheme of things. The attributes are only generated
if they are specifically requested or required.

> case / scenario) where these information and the possible processing

The primary motivation was to allow access controls to be set up based on
time of day. The eB2Bcom directory also allows access controls to be
specified using filters. With these operational attributes we can do things
like permit access if:
     (&(currentTimeOfDay>=09:00:00+10:00)(currentTimeOfDay<=17:00:00+10:00)).
N.B., the syntax of currentTimeOfDay uses a constrained ASN.1 TIME type.

> rules because the specification does not say anything about ":<=" or ":>=".

I'm afraid you're under a misapprehension. Although the string representation
of an extensible match contains a equals sign, it is just meaningless syntactic
fluff. The extensible match applies a matching rule, which is a boolean
predicate that may or may not represent a relational operator like "=".
So that the extensible match had the same expressive power as the other
filter items, the X.500 working group defined matching rules for each of
the syntaxes that has an obvious equality or ordering relationship between
values. For each syntax with an ordering relationship they defined two
predicates; an equality or "=" matching rule (e.g., generalizedTimeMatch)
and an ordering or "<" matching rule (e.g., generalizedTimeOrderingMatch).
This is sufficient to construct the other relational operators through an
expression of extensible match filter items. That is,

     "type=value" is (type:generalizedTimeMatch:=value)
     "type<value" is (type:generalizedTimeOrdering:=value)
     "type<=value" is (|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value))
     "type>value" is (!(|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value)))
     "type>=value" is (!(type:generalizedTimeOrdering:=value))

There is nothing magic about the choice of "=" and "<". The X.500 working
group could have chosen any other pair of the relational operators, or more
than two, but this is the convention that has been followed since. Therein
also lies the reason why I suggested that currentTimeMatch and
currentTimeOrderingMatch were sufficient. It's not wrong to define more
rules as you have done, just unconventional and excess to requirements.

So it is possible to perform binary search on a syntax using extensible match
given an ordering matching rule for that syntax, and it is meaningless to talk
about ":<=" or ":>=" with respect to the extensible match filter item.

> automatically and immediately take effect when time has come.

I can see how that works if the services always bind to the directory
and perform operations as themselves but it wouldn't work if the services
proxy the end user or proxy other services.

In all, this feels like a workaround for simple-minded services that
assume the service is available to a user just because the user has an
entry. The ideal solution would be for the service to check that the current
time is in the validity period for that service and user (in which case
the service's idea of UTC is just as good as the LDAP server's). Where
there is some limited ability to configure the service with fixed LDAP
searches then the new matching rules become useful. If that isn't an
option, then the new matching rules could be used to limit the visibility
of the user's entry for different services. Bad luck if the services
proxy other identities.

> clients cannot overwrite or bypass.

In that case you don't need extra syntaxes or all four matching rules.

> support ":<=" or ":>=" comparison operations...

... which they do and always have :-).

Regards,
Steven

---

From: Daniel Pluta <[email-masked]>
Date: Wed, 21 Apr 2010 11:52:44 +0200

Hi Steven,

Steven Legg wrote:
>     "type<=value" is 
> (|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value)) 
>
>     "type>value" is 
> (!(|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value))) 
>

This is just a short intermediate answer details regarding the other 
(main) points will follow later.

Many thanks for your explanation and the clarification that ordering 
matching rules in general are or should be supported, too.

We think we've been misled by a quick look into openldap's source where 
ordering matching rules (e.g. caseIgnoreOrderingMatch, 
generalizedTimeOrderingMatch) don't seem to be supported in combination 
with extensible match filter expressions:

              Processing a filter like: 
(createTimestamp:generalizedTimeOrderingMatch:=2010...Z)
              results in "filter: (?=undefined)"

Sorry for the confusion and thanks again for the clarification.

---

From: Daniel Pluta <[email-masked]>
Date: Thu, 22 Apr 2010 21:28:57 +0200

Hi Steven,

Steven Legg wrote:
> Daniel Pluta wrote:
>> Steven Legg wrote:
>>> Daniel Pluta wrote:
>>> If it is the case, then it boils down to a question of whether a
>>> time comparison involving the current time is performed using
>>> the client's idea of UTC or the server's.
>> 

And you are right, the timezone information in the Root-DSE is not
needed for our mentioned replication scenario in case every time-stamp 
value and the comparison is strictly made using UTC.

At first I've been thinking of using localtime which:
- would justify the transformation but causes major disadvantages at
least in complexity, usability, replication and in other cases e.g. when 
taking a replica's dump to recover the master or another replica in 
other timezones.
- is against common accepted LDAP specifications (everything is UTC)
- should no longer be thought about

Nevertheless we are currently still think that the timezone information
should be published:
- this data "completes" the current time information
- this information can be used to derive a server's timezone position
(at least as long as there is no specification how to publish the global
positioning system information)

>>  dynamically rewritten to use the client's current time for each 
>> request. Specifying a search filter 
>> (endOfLifeTimeStamp:noOrEarlierMatch:=NOW) solves this. A client
>> does not need to replace the assertion value for each request any
>> more.
> 

Fine, thanks.

>> The comparison result need to be independent of the replica (its
>> timezone) a client connects to.
> 

As already said above: that's right.

>>> Incidentally, I have implemented operational attributes that
>>> expose the current date and time, current time of day and current
>>> day of the week. They appear in every entry and are created on
>>> demand.
>> 
>> whether this information is needed for each entry: - As time flows
>> which time of day is it? The time of the operation's request or the
>> time of the result set's delivery (constant result set delivery
>> time or still "drifting" for each result set's entry's delivery)?
> 
> Currently (for convenience) it is the instant when the entry contents
> are composed for final filtering and access control checks. This
> means that each entry could have a slightly different time. This is
> adequate for our current purposes because the time difference between
> the first and last entry is small compared to the precision that the
> consuming applications actually need, and small compared to the
> typical skew between different machines. If that ever changes we will
> review how the timestamps are generated.
> 
> Barely at all in the great scheme of things. The attributes are only
>  generated if they are specifically requested or required.
>> case / scenario) where these information and the possible
>> processing overhead is worth for?
> The primary motivation was to allow access controls to be set up
> based on time of day. The eB2Bcom directory also allows access
> controls to be specified using filters. With these operational
> attributes we can do things like permit access if:
> 

Ah I see, this is exactly the opposite approach of ours - but an 
interesting solution at least for this specialized scenario (and limited 
for a short period of time e.g. a day).

Therefore in our opinion it's not comparable to the draft's matching 
rule approach and rises the following questions (if nevertheless compared):
- the many time determination operations for huge result sets (which can 
be optimized)
- the client side specified filter criteria

The first point can be easily optimized:
In huge result sets the repeating time determination for each
entry does possibly take some time. I would suggest to use an
instantaneous and constant time of the request/operation/etc even
because you already said, that the time deltas are just slightly
different and are to small to be of any great effect (so, why spending
processing time for them?).

Comment regarding the second point:
Instead of using calculated times, when using in backend stored
time-stamp values in combination with our matching rule each entry can
have different period limiting time-stamp pairs. This is an important
difference regarding the use in automatic provisioning scenarios where 
we want to support selection of all currently valid entries (independent 
from the distinct time-stamps, which should not be readable or even 
binary search able) in contrast to your scenario.

Our approach handles huge and tiny result sets using the same matching 
rule mechanisms independent from operating as single userDN (self) or a 
service's DN.

However, I think I understand your scenario and idea. In
regard to "currentTimeOfDay" this seems to be a fine solution in case
your clients and services are trustworthy enough to be allowed to 
define/request the periods on their own. Regardless from our concerns, 
your currentTimeOfDay syntax is very interesting, to extend our matching 
rules to also match these kind of values, too.

Instead of publishing the current time in each entry our approach allows 
us to uses a single, centralized place in the DIT (e.g. Root-DSE) to 
publish the server's current time information. The time information is 
only used seldom in combination with our matching rule approach but is 
useful to offer clients a general chance to determine the server's 
current system time. When using tls/ssl in general the server's system 
time should be ok, but nobody knows. So the clients needs a
chance to query the server (using LDAP) for its current time at least in 
UTC.

Although a concrete scenario where the timezone is needed is currently 
missing, additionally publishing the timezone (in contrast to our draft 
e.g. in an extra attribute) makes this kind of information (the time) 
more complete, at least in our opinion.

>>  management (IDM) system infrastructures can profit from such
>> matching rules. They can be pre-provisioned (pre means timely in
>> advance) and entries become available just-in-time (based on a
>> single time-stamp attribute for example), without the need for an
>> external event that has to trigger the provisioning (results in an
>> entry's visibility). Beside the initial provisioning, the
>> provisioning life-cycle becomes independent, more flexible, gets
>> simplified and can be consolidated into the ldap server itself. Not
>> to mention automatic de-provisioning without manual/external
>> just-in-time interventions. De-provisioning is highly probable the
>> wrong expression: In IDM systems former identities need to be
>> removed from core services but often also need to stay available
>> for a subset of services (for alumna). Currently this is often
>> controlled by complete entry provisioning or simple attribute
>> changes (event or timely triggered or both). Although these changes
>> are known in advance for the majority of the users, complex
>> interdependent event handling mechanisms and triggers are 
>> externally implemented to manipulate (e.g. hide or disable) entries
>>  for distinct services... When using current time matching no
>> events are needed in those scenarios. In OpenLDAP for example, by
>> using an appropriate ACL the event's can be planned in advance and
>> the partial de-provisioning will automatically and immediately take
>> effect when time has come.
> 
>  and perform operations as themselves but it wouldn't work if the
> services proxy the end user or proxy other services. In all, this
> feels like a workaround for simple-minded services that assume the
> service is available to a user just because the user has an entry.
> The ideal solution would be for the service to check that the current
> time is in the validity period for that service and user (in which 
> case the service's idea of UTC is just as good as the LDAP server's).
> 

In our current scenario service proxies are supported as well. They
could also contain time-stamp attributes that are used to determine
whether a service is currently allowed to operate on the directory 
(please see below for details).

> Where there is some limited ability to configure the service with
> fixed LDAP searches then the new matching rules become useful. If
> that isn't an option, then the new matching rules could be used to
> limit the visibility of the user's entry for different services. Bad
> luck if the services proxy other identities.

Probably I cannot follow you in detail. Could you please give me a more 
detailed example? Thanks a lot.

>>> If particular privacy outcomes are not a goal, then all you need
>>> is two matching rules with DURATION assertion syntax that I might
>>> call currentTimeMatch and currentTimeOrderingMatch. The
>>> currentTimeMatch rule tests if an attribute value is equal to the
>>> current time plus an offset (i.e., the DURATION assertion value,
>>> which can be positive, negative or zero) and the 
>>> currentTimeOrderingMatch tests if an attribute value is less than
>>> the current time plus an offset.
>>> 
>>>> It is a direct result based on our experiments with current
>>>> time matching rules, which probably deflects from our primary
>>>> intention.
>>>> 
>>>> Your suggested solution does not need to make use of current
>>>> time matching rules (due to server internal delta calculation
>>>> which first of all seems to be an easy and elegant way) so this
>>>> solution is strictly limited to the scenario where two
>>>> time-stamps define a rather hard validity period (begin and
>>>> end). On the other side, what about the possibility to use one
>>>> of the two time-stamps (or any other time-stamp attribute)
>>>> within scenarios where flexible transitions times (e.g. +2
>>>> months/days/... after or before a given time) need to be
>>>> supported, too? Therefore the server internal calculation
>>>> suggested by you need to be customizable depending on the
>>>> operations details...
>>> 
>>> Yes, that's why I said "it becomes a question of how expressive
>>> should the derivation rules be and what form should they take ?".
>>> One way to express the derivation rule for a boolean attribute is
>>> as a search filter, which could use currentTimeMatch and
>>> currentTimeOrderingMatch ! It may be more appropriate to have
>>> different derived attributes and end-points to reflect "soft" and
>>> "hard" validity. Detailed use cases would help guide such
>>> decisions. However, it doesn't matter if privacy outcomes are not
>>> the goal.
>> 
>> As explained above LDAP servers that support filter statements
>> during ACL processing can fulfill the privacy goals very easily,
>> because the matching rules can be used to server-side force a
>> filter via ACLs that clients cannot overwrite or bypass.
> 
> 

Indeed we need the syntaxes to prevent services to be able to determine
the limiting time-stamp values for example of an user's entry which has 
to be searched by a service before it can be used for authentication via 
a bind operation. We are yet already able to prevent inquisitive 
services to get more information than that are needed just in the moment.

BTW: I could not find an RFC which explicitly says something
about how ordering matching rules may/must/should be supported/processed
in extensible match filters. On the other hand I also have not found a
statement that ordering matching rules should not be supported in
extensible match filters...
Although, OpenLDAP currently does not support ordering matching rules in
extensible match filters it's possibly just a question of time when this
"feature" becomes supported, too (in case the/a specification says so?).
On the other hand, other directory server implementations may be already
support ordering matching rules in extensible match filters (the way
you've explained above) and probably also want to prevent client's to 
determine the exact time-stamps vaules - just by using the new syntaxes 
which we derived from gerneralizedTime.

Now let me please come back to explain the common need for the two extra 
syntaxes (named "nowBefore" and "nowAfter") mentioned in our draft:

Imagine two period limiting time-stamp attributes' values. These
attributes need to be searchable to allow an ACL engine (that supports 
searchfilter) to process the filter statement in the context of the user 
or the context of a service's bindDN. So at least search (ideally 
without read) permission has to be given to self, the service's bindDN 
or both. Search permission for "self" is not as critical as search 
access for the service's bindDN. Snoopy bindDN owners could try to 
gather more detailed information from exntries than originally intended 
(e.g. looking into the future or past using binary search...)

Thus, search access currently cannot be further limited e.g. to 
"generalizedTimeMatch-only" and there's currently no easy or general 
(even standardized) way to handle/extend ACL processing to exclude 
distinct matching rules from search (matching) operations, using 
generalizedTime syntax for the two limiting attributes leads to the 
binary search problem in case ordering matching rules are usable in 
combination with extensible match filters.

By using our two syntaxes, services' bindDNs are able to use the 
time-stamp limits (using our matching rule) right in the moment but they 
are not able to determine any entry's distinct time-stamps (even not 
their own where this is appropriate).

Additionally both attribute value syntaxes are not completely new. They 
are just syntactically derived from generalizedTime syntax. Both are 
explicitly not associated with the generalizedTimeOrdering matching rule 
to prevent binary searching in extensible match filters. In our opinion 
the above mentioned limitation (in regard to privacy protection against 
binary search) justifies their introduction. How these syntaxes are used 
in an userApplication schema or even product specific ACL definition 
(where supported) should of course be left open to the directory 
designers and administrators.

Appendix:
Of course you are right, the other two extra offset-syntaxes (defined in
our draft) are only nice to have but not needed (in regard to privacy) 
because clients can of course specify all kind of offsets to do a binary 
search. Therefore these syntaxes can be removed from the document. 
generalizedTime syntax is completely sufficient in regard to 
Offset/Duration matching.

>>>>  general interest. Based on our current experimental
>>>> implementation (which possibly needs to be reduced to the
>>>> matching basics) of these matching rules in combination with
>>>> your implementation of the X680 duration specification the
>>>> matching could be of general use for LDAP, too.
>>>> 
>>>> In our opinion there is currently nothing to be said against
>>>> the reasonable use of both mechanisms. What do you think about
>>>> this?
>>> 
>>> but using syntaxes to achieve access control is just wrong to my
>>> mind.
>> 

Hmmm, please let me cite BOFH chap. 13: "Yes means No and No means Yes.
Delete all files [Y]?" ;-)

Based on your clarification regarding the possibility to use ordering 
matching rules in extensible match filters our previous position 
regarding the sabove "yes, at least as..." has spontaneously changed 
into the opposite. As explained above we would like to see the 
additional two syntaxes to solve possible privacy concerns (regardless 
of distinct products' ACL processing features), so please let me answer 
your previous statement once again:

> but using syntaxes to achieve access control is just wrong to my
> mind.

Achieving additional access control features is just a side effect 
(which affect varies between different directory server products' features).
The additional syntaxes' limitations are useful in common
privacy related scenarios where time-stamp derived attributes should by 
design only be search able using our matching rules. Preventing snoopy 
service's (proxy?) bindDNs to get more information about an entry than 
actually is needed.

Best regards,
Daniel

> Regards, Steven
> 
>> 
>> Best regards, Daniel
>> 
>> 
>>>> Steven Legg wrote:
>>>>> Daniel Pluta wrote:
>>>>>> Dear ldapext,
>>>>>> 
>>>>>> we would appreciate your valuable comments and feedback
>>>>>> regrading our draft specifying "ldap server side current
>>>>>> time matching".
>>>>> 
>>>>> The draft is essentially about enforcing access control
>>>>> policy through schema mechanisms, which strikes me as
>>>>> inappropriate for two principal reasons:
>>>>> 
>>>>> (1) Schema is supposed to be immutable, whereas access
>>>>> control policy is subject to change. If access control policy
>>>>> is reflected in the attribute syntaxes one chooses, then that
>>>>> policy is permanently locked-in.
>>>>> 
>>>>> (2) Schema is one-size-fits-all. The same rules apply to
>>>>> everyone, regardless of whether they are anonymous guest
>>>>> users or highly privileged administrators. Access control
>>>>> policy is rarely that uniform.
>>>>> 
>>>>> Privacy goals should be addressed through access control
>>>>> mechanisms, but of course you are hampered by the absence of
>>>>> a common, standardized access control mechanism across all
>>>>> LDAP implementations. With that in mind I would take a
>>>>> somewhat different approach to a solution.
>>>>> 
>>>>> Basically you want to allow general access to a derived
>>>>> property of a collection of attributes while simultaneously
>>>>> enforcing restricted access to that collection of attributes.
>>>>> What I would do is define a schema mechanism for defining
>>>>> derived attributes, i.e., attributes whose values are
>>>>> algorithmically derived by the server from the values of
>>>>> other attributes in the same entry. The derived attributes
>>>>> can then be subject to different access controls than the
>>>>> source attributes.
>>>>> 
>>>>> In your example with the notValidBefore and notValidAfter
>>>>> attributes, I imagine having a derived attribute called
>>>>> currentlyValid, with Boolean Syntax, that is derived from
>>>>> notValidBefore and notValidAfter according to the following
>>>>> pseudo code:
>>>>> 
>>>>> if (current time >= notValidBefore and current time <=
>>>>> notValidAfter) then value = TRUE else value = FALSE
>>>>> 
>>>>> Privileged users and processes would be given permission to
>>>>> read and update the notValidBefore and notValidAfter
>>>>> attributes, but regular users would only be able to read the
>>>>> currentlyValid attribute. This kind of access control policy
>>>>> can be expressed in existing LDAP access control schemes even
>>>>> though they differ between implementations.
>>>>> 
>>>>> That takes care of the nowBefore and nowAfter syntaxes. I
>>>>> don't see that you achieve anything with the nowBeforeOffset
>>>>> and nowAfterOffset syntaxes since a user can just use a
>>>>> binary search to determine the actual values of the target
>>>>> attributes by adjusting the offsets (a client can guess the
>>>>> time at the server with reasonable accuracy). Limiting the
>>>>> sign or magnitude of the offset would provide partial 
>>>>> protection, but a derived attribute could also do that. For
>>>>> example, to allow regular users to determine when a valid
>>>>> account became valid but not allow them to determine whether
>>>>> or when an account will become valid at some time in the
>>>>> future I would define a derived attribute of GeneralizedTime
>>>>> syntax whose values are determined by the following pseudo
>>>>> code:
>>>>> 
>>>>> if (current time >= notValidBefore) value = notValidBefore 
>>>>> else absent
>>>>> 
>>>>> It becomes a question of how expressive should the derivation
>>>>>  rules be and what form should they take ? I think OpenLDAP
>>>>> might have some capabilities in that area already.
>>>>> 
>>>>> The nowOffset syntax isn't required if derived attributes are
>>>>> used instead, but if you want to persist with it I suggest
>>>>> you align it with the existing ASN.1 DURATION data type (see
>>>>>  http://www.itu.int/rec/T-REC-X.680-200606-S!Amd3/en ) rather
>>>>> than rolling your own format, not the least because I already
>>>>> have an implementation that supports DURATION as an attribute
>>>>> and assertion syntax for both X.500 and LDAP.
>>>>> 
>>>>> Regards, Steven
>>>>> 
>>>>>> 
>>>>>> Best regards Daniel
>>>>>> -------- Original-Nachricht -------- Betreff: New Version
>>>>>> Notification for 
>>>>>> draft-pluta-ldap-srv-side-current-time-match-00 Datum: Thu,
>>>>>> 25 Mar 2010 15:51:33 -0700 (PDT) Von: IETF I-D Submission
>>>>>> Tool <[email-masked]>
>>>>>> 
>>>>>> 
>>>>>> A new version of I-D, 
>>>>>> draft-pluta-ldap-srv-side-current-time-match-00.txt has
>>>>>> been successfully submitted and posted to the IETF
>>>>>> repository.
>>>>>> 
>>>>>> Revision:     00 Title:         Lightweight Directory
>>>>>> Access Protocol (LDAP): Server Side Current Time Matching -
>>>>>> Matching Rules and Syntaxes Creation_date:     2010-03-25 
>>>>>> WG ID:         Independent Submission Number_of_pages: 20
>>>>>> 
>>>>>> Abstract: This document extends the Lightweight Directory
>>>>>> Access Protocol (LDAP) to support server side current time
>>>>>> matching.  Matching of attribute values against an LDAP
>>>>>> server's current time offers additional functionality with
>>>>>> regard to authorization and fulfills enhanced data privacy
>>>>>> requirements for restrictive environments. Therefore this
>>>>>> specification defines four additional syntaxes and related
>>>>>> matching rules useful for extensible matching in
>>>>>> association with these syntaxes.  In addition and for
>>>>>> general use the matching rules defined in this document are
>>>>>> also applicable to any attribute type definitions that are
>>>>>> using the 'Generalized Time' syntax.  This specification
>>>>>> also contains restrictive attribute type definitions 
>>>>>> demonstrating the usage of the introduced syntaxes and
>>>>>> matching rules.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The IETF Secretariat. 
>>>>>> _______________________________________________ Ldapext
>>>>>> mailing list [email-masked]

---

From: Steven Legg <[email-masked]>
Date: Fri, 23 Apr 2010 16:03:51 +1000

Hi Daniel,

> positioning system information)

I don't have problem with a server publishing its time zone, but the IESG
might take exception to standardizing a feature for which no particular
purpose has been identified.

Incidentally, I can imagine scenarios where an administrator would set up
a server to report and operate as though it is in a time zone other than
the one it is physically in. It's better and easier for the server to nominate
its timezone rather than have to work it out from the server's location.

> for a short period of time e.g. a day).

Not so much an opposite approach as a solution to a different requirement.
I just mentioned it to indicate that I have a use for publishing the server's
current time, not just in the root, but in every entry. I wasn't offering
it as an alternative solution to your specific requirements.

> processing time for them?).

Because it was easier to code it that way. A consistent time would be
better but requires more coding. If I were to standardize this attribute,
then I would specify it as having its value fixed for the duration of an
operation, and change the code accordingly.

> define/request the periods on their own.

The periods are defined by the directory administrators in the access
controls, which are evaluated by the server using the server's current time.
The client's aren't defining anything.

 > Regardless from our concerns,

I don't see what that would achieve. The value of currentTimeOfDay is always
"now" and your matching rules are testing if the value of a timestamp is "now",
so the result would always be true (assuming the implementation determined
"now" only once for the entire operation).

> chance to query the server (using LDAP) for its current time at least in 

The pertinent question is: why? The IESG will probably want to know.

> more complete, at least in our opinion.

My opinion is different. An operational attribute to publish the server's
time and/or timezone isn't significant to the remainder of the draft and
could just as well be in a separate draft, or not mentioned at all.
So I don't see it as being desirable for reasons of completeness.

>>> interdependent event handling mechanisms and triggers are externally 
>>> implemented to manipulate (e.g. hide or disable) entries

In the ideal situation the "foobar" service would test whether it is
currently enabled for a given user by searching the user's entry with a
filter like:

     (&(foobarStartTime<=20100423133800+1000)(foobarEndTime>=20100423133800+1000))

where (for example) the current time is 20100423133800+1000 as far as
the foobar service is concerned.

If the foobar service can only be configured with a fixed LDAP filter,
then that filter would need to be something like this:

     (&(|(foobarStartTime:currentTimeMatch:=P0S)
         (foobarStartTime:currentTimeOrderingMatch:=P0S))
       (!(foobarEndTime:currentTimeOrderingMatch:=P0S)))

Note that "P0S" is a duration of zero seconds.

If the foobar service just assumes that it is enabled for any user whose
entry is visible, then there would need to be an access control in the LDAP
server that only allows the foobar service identity to see a user entry
if the preceding filter applied to that user entry is satisfied.

If the foobar service used the user identity rather than its own to
determine the existence of the user entry, then there would need to be
an access control in the LDAP server that only allows the user identity
to see its own entry if the preceding filter is satisfied. However, it
then isn't possible to have separate start and end times for each service.
There would be one start time and end time that applies to all services
and the user would not even see their own entry outside those times.

> services to get more information than that are needed just in the moment.

I'm not convinced that preventing services from seeing data that are pertinent
to the operation of that service is an important goal. Fair enough that
users shouldn't be able to see the service details of other users, and maybe
there are times when users shouldn't be able to see some of their own service
details, but putting blinkers on the service as well doesn't seem worth it.
For one thing it means that the service can't do things like warn users
that their access will be disabled in one hour, or even determine for itself
which users will soon become disabled so that certain administrative actions
can be put in motion.

> extensible match filters...

I know of no standard specification that explicitly allows or prohibits the use
of any particular matching rule in an extensible match. Yours would be the
first.

> which we derived from gerneralizedTime.

FYI, eB2Bcom's directory allows all of its 110+ supported matching rules to
be used in an extensible match. In fact, an extensible match is the only
way to invoke a significant number of them. I'm not convinced that the
new syntaxes are necessary or desirable.

> or the context of a service's bindDN.

An ACL engine in a directory is not itself subject to access controls.

 > So at least search (ideally

Even if you lock down the timestamps there is still plenty of other,
more useful information that someone with the service's credentials
could access. The new syntaxes would provide only a marginal benefit
in this situation. Not enough to justify their unconventional
quirkiness.

Regards,
Steven

>>>>>> sign or magnitude of the offset would provide partial protection, 
>>>>>> but a derived attribute could also do that. For
>>>>>> if (current time >= notValidBefore) value = notValidBefore else 
>>>>>> absent
>>>>>>
>>>>>>> Notification for draft-pluta-ldap-srv-side-current-time-match-00 
>>>>>>> Datum: Thu,
>>>>>>> Matching Rules and Syntaxes Creation_date:     2010-03-25 WG 
>>>>>>> ID:         Independent Submission Number_of_pages: 20
>>>>>>>

---

From: Daniel Pluta <[email-masked]>
Date: Fri, 23 Apr 2010 23:06:24 +0200

Hi Steven,

Steven Legg wrote:
> Hi Daniel, Daniel Pluta wrote:
>> Hi Steven, Steven Legg wrote:
>>> Daniel Pluta wrote:
>>>> Steven Legg wrote:
>>>>> Daniel Pluta wrote: If it is the case, then it boils down to
>>>>> a question of whether a time comparison involving the current
>>>>> time is performed using the client's idea of UTC or the
>>>>> server's.
>>>> 
>> needed for our mentioned replication scenario in case every 
>> time-stamp value and the comparison is strictly made using UTC.
>> 
>> At first I've been thinking of using localtime which: - would
>> justify the transformation but causes major disadvantages at least
>> in complexity, usability, replication and in other cases e.g. when
>> other timezones. - is against common accepted LDAP specifications
>> (everything is UTC) - should no longer be thought about
>> 
>> Nevertheless we are currently still think that the timezone
>> information should be published: - this data "completes" the
>> current time information - this information can be used to derive a
>> server's timezone position (at least as long as there is no
>> specification how to publish the global positioning system
>> information)
> 
> I don't have problem with a server publishing its time zone, but the
> IESG might take exception to standardizing a feature for which no
> particular purpose has been identified.

Yes we currently share the same concerns but in our opinion it's at 
least worth a try. In case publishing the "time" via the Root-DSE would 
be generally acceptable, we would suggest and vote for also publishing 
the server's timezone to make the common information about the time more 
complete.

> Incidentally, I can imagine scenarios where an administrator would
> set up a server to report and operate as though it is in a time zone
> other than the one it is physically in. It's better and easier for
> the server to nominate its timezone rather than have to work it out
> from the server's location.

Yes that would be the most reliable way.

>>>> configuration directives in third party products do not allow
>>>> to be dynamically rewritten to use the client's current time
>>>> for each request. Specifying a search filter 
>>>> (endOfLifeTimeStamp:noOrEarlierMatch:=NOW) solves this. A
>>>> client does not need to replace the assertion value for each
>>>> request any more.
>>> 
>>>> The comparison result need to be independent of the replica
>>>> (its timezone) a client connects to.
>>> 
>>>>> expose the current date and time, current time of day and
>>>>> current day of the week. They appear in every entry and are
>>>>> created on demand.
>>>> 
>>>> Ok. We have decided to take the Root-DSE because we are not
>>>> sure whether this information is needed for each entry: - As
>>>> time flows which time of day is it? The time of the operation's
>>>> request or the time of the result set's delivery (constant
>>>> result set delivery time or still "drifting" for each result
>>>> set's entry's delivery)?
>>> 
>>> Currently (for convenience) it is the instant when the entry
>>> contents are composed for final filtering and access control
>>> checks. This means that each entry could have a slightly
>>> different time. This is adequate for our current purposes because
>>> the time difference between the first and last entry is small
>>> compared to the precision that the consuming applications
>>> actually need, and small compared to the typical skew between
>>> different machines. If that ever changes we will review how the
>>> timestamps are generated.
>>> 
>>> Barely at all in the great scheme of things. The attributes are
>>> only generated if they are specifically requested or required.
>> interesting solution at least for this specialized scenario (and 
>> limited for a short period of time e.g. a day).
> 
> Not so much an opposite approach as a solution to a different 
> requirement. I just mentioned it to indicate that I have a use for
> publishing the server's current time, not just in the root, but in
> every entry. I wasn't offering it as an alternative solution to your
> specific requirements.
> 
>> 
>> Therefore in our opinion it's not comparable to the draft's
>> matching rule approach and rises the following questions (if
>> nevertheless compared): - the many time determination operations
>> for huge result sets (which can be optimized) - the client side
>> specified filter criteria
>> 
>> The first point can be easily optimized: In huge result sets the
>> repeating time determination for each entry does possibly take some
>> time. I would suggest to use an instantaneous and constant time of
>> the request/operation/etc even because you already said, that the
>> time deltas are just slightly different and are to small to be of
>> any great effect (so, why spending processing time for them?).
> 
>  better but requires more coding. If I were to standardize this
> attribute, then I would specify it as having its value fixed for the
> duration of an operation, and change the code accordingly.
> 
>> 
>> Comment regarding the second point: Instead of using calculated
>> times, when using in backend stored time-stamp values in
>> combination with our matching rule each entry can have different
>> period limiting time-stamp pairs. This is an important difference
>> regarding the use in automatic provisioning scenarios where we want
>> to support selection of all currently valid entries (independent
>> Our approach handles huge and tiny result sets using the same 
>> matching rule mechanisms independent from operating as single
>> userDN (self) or a service's DN.
>> 
>> However, I think I understand your scenario and idea. In regard to
>> "currentTimeOfDay" this seems to be a fine solution in case your
>> clients and services are trustworthy enough to be allowed to 
>  controls, which are evaluated by the server using the server's
> current time. The client's aren't defining anything.
> 
>> Regardless from our concerns, your currentTimeOfDay syntax is very
>> interesting, to extend our matching rules to also match these kind
>> of values, too.
> 
> I don't see what that would achieve. The value of currentTimeOfDay is
>  always "now" and your matching rules are testing if the value of a
> timestamp is "now", so the result would always be true (assuming the
> implementation determined "now" only once for the entire operation).

Sorry that's my fault: I've meant the assertion value's syntax. Which in 
our scenario probably could become useful as attribute value syntax.

>> Instead of publishing the current time in each entry our approach 
>> allows us to uses a single, centralized place in the DIT (e.g. 
>> Root-DSE) to publish the server's current time information. The
>> time information is only used seldom in combination with our
>> matching rule approach but is useful to offer clients a general
>> chance to determine the server's current system time. When using
>> tls/ssl in general the server's system time should be ok, but
>> nobody knows. So the clients needs a chance to query the server
>> (using LDAP) for its current time at least in UTC.
> 

In our opinion and based on our approach the question "Why?" does not
exist. The only open questions would be "where and how?". Please let me
try to explain from the beginning:

Q: Why should the server publish its time in general?
A: The answer is related to the big picture behind our scenario where
both, syntaxes and matching rules are in operation.
The matching rule operates on the server side. The clients do not need
to use a distinct time for example using time-similar assertion values
in filters strings. Clients just use "NOW" as assertion value which the
server internally expands into its current server side time. Based on
this internal (hidden) expansion the client can only *hope* the server
delivers the currently available entries.
Q: But why the client's only can hope?
A: Depending on the scenario which leads to different data-privacy
requirements the clients are not always able to verify the returned
entries time-stamps because permission to access the result set entries'
time-stamp values (in case our specialized syntaxes are in use) by read
may be knowingly (a directory operator'/designer'/administrator's
decision) denied. To give interested clients a chance to determine the
server's time we suggest that the server should publish its current time
to be query able for some kind of verification / debugging possibility.

Let me now come to the still somewhat open question: "Where and how?"
Q: Where should the time be published? Why within the Root-DSE, and not
in each entry?
A: In our opinion clients would ask servers seldom for their current
time but there exist some justifications for clients to do so. The time
information is very helpful especially in case of supposed errors or for
debugging. Imagine replicated environments where one replica system for
example is operating using the wrong system time. This would probably
lead to strongly varying result sets depending on the server that
answers the queries.
Because the time is so seldom queried we prefer its publication within
the "neutral zone" the Root-DSE, instead of attaching it using an extra
attribute for each entry.

And finally the minor important question:
Q: In case the server would already publish its current system time,
what about additionally publishing the server's timezone?
A: We currently do not have an idea why and for what reason to insist of 
publishing the timezone. The only reason is: a timezone generally 
somehow belongs/completes an information about the time (regardless 
whether LDAP internally always uses UTC).

>> Although a concrete scenario where the timezone is needed is 
>> currently missing, additionally publishing the timezone (in
>> contrast to our draft e.g. in an extra attribute) makes this kind
>> of information (the time) more complete, at least in our opinion.
> 
> My opinion is different. An operational attribute to publish the
> server's time and/or timezone isn't significant to the remainder of
> the draft and could just as well be in a separate draft, or not
> mentioned at all. So I don't see it as being desirable for reasons of
> completeness.

Please see above: time is a must-have, timezone is just nice to have

>>>> In addition to privacy another scenario where the server side
>>>> time matching is very useful affects provisioning systems. E.g.
>>>> identity management (IDM) system infrastructures can profit
>>>> from such matching rules. They can be pre-provisioned (pre
>>>> means timely in advance) and entries become available
>>>> just-in-time (based on a single time-stamp attribute for
>>>> example), without the need for an external event that has to
>>>> trigger the provisioning (results in an entry's visibility).
>>>> Beside the initial provisioning, the provisioning life-cycle
>>>> becomes independent, more flexible, gets simplified and can be
>>>> consolidated into the ldap server itself. Not to mention
>>>> automatic de-provisioning without manual/external just-in-time
>>>> interventions. De-provisioning is highly probable the wrong
>>>> expression: In IDM systems former identities need to be removed
>>>> from core services but often also need to stay available for a
>>>> subset of services (for alumna). Currently this is often 
>>>> changes (event or timely triggered or both). Although these
>>>> changes are known in advance for the majority of the users,
>>>> complex interdependent event handling mechanisms and triggers
>>>> are externally implemented to manipulate (e.g. hide or disable)
>>>> entries for distinct services... When using current time
>>>> matching no events are needed in those scenarios. In OpenLDAP
>>>> for example, by using an appropriate ACL the event's can be
>>>> planned in advance and the partial de-provisioning will
>>> I can see how that works if the services always bind to the
>>> directory and perform operations as themselves but it wouldn't
>>> work if the services proxy the end user or proxy other services.
>>> In all, this feels like a workaround for simple-minded services
>>> that assume the service is available to a user just because the
>>> user has an entry. The ideal solution would be for the service to
>>> check that the current time is in the validity period for that
>>> service and user (in which case the service's idea of UTC is just
>>> as good as the LDAP server's).
>>> 
>> 
>>  could also contain time-stamp attributes that are used to
>> determine whether a service is currently allowed to operate on the
>> directory (please see below for details).
>> 
>> 
>>>  fixed LDAP searches then the new matching rules become useful.
>>> If that isn't an option, then the new matching rules could be
>>> used to limit the visibility of the user's entry for different
>>> services. Bad luck if the services proxy other identities.
>> 
>> Probably I cannot follow you in detail. Could you please give me a
>>  more detailed example? Thanks a lot.
> 
> currently enabled for a given user by searching the user's entry with
> a filter like:
> 
> 
> If the foobar service can only be configured with a fixed LDAP
> filter, then that filter would need to be something like this:
> 
> If the foobar service just assumes that it is enabled for any user
> whose entry is visible, then there would need to be an access control
> in the LDAP server that only allows the foobar service identity to
> see a user entry if the preceding filter applied to that user entry
> is satisfied.
> 
> determine the existence of the user entry, then there would need to
> be an access control in the LDAP server that only allows the user
> identity to see its own entry if the preceding filter is satisfied.
> However, it then isn't possible to have separate start and end times
> for each service. There would be one start time and end time that
> applies to all services and the user would not even see their own
> entry outside those times.

This is all fine, at least in case you trust the services. Don't call us 
paranoid, but in our scenario we even do not trust the (even internal) 
services, at least in regard to data privacy concerns. Of course we do 
trust our services regarding their core competence: offering the maximum 
service quality.

Imagine huge organizations where service administrators can very easily 
and lucratively misuse identity information (e.g. contacting the press, 
the business rival, or sell/buy some own/rival shares).

Please see below for one sample scenario's details and the resulting 
requirements.

>>>>> If particular privacy outcomes are not a goal, then all you
>>>>> need is two matching rules with DURATION assertion syntax
>>>>> that I might call currentTimeMatch and
>>>>> currentTimeOrderingMatch. The currentTimeMatch rule tests if
>>>>> an attribute value is equal to the current time plus an
>>>>> offset (i.e., the DURATION assertion value, which can be
>>>>> positive, negative or zero) and the currentTimeOrderingMatch
>>>>> tests if an attribute value is less than the current time
>>>>> plus an offset.
>>>>> 
>>>>>>  time matching rules, which probably deflects from our
>>>>>> primary intention.
>>>>>> 
>>>>>> Your suggested solution does not need to make use of
>>>>>> current time matching rules (due to server internal delta
>>>>>> calculation which first of all seems to be an easy and
>>>>>> elegant way) so this solution is strictly limited to the
>>>>>> scenario where two time-stamps define a rather hard
>>>>>> validity period (begin and end). On the other side, what
>>>>>> about the possibility to use one of the two time-stamps (or
>>>>>> any other time-stamp attribute) within scenarios where
>>>>>> flexible transitions times (e.g. +2 months/days/... after
>>>>>> or before a given time) need to be supported, too?
>>>>>> Therefore the server internal calculation suggested by you
>>>>>> need to be customizable depending on the operations
>>>>>> details...
>>>>> 
>>>>> Yes, that's why I said "it becomes a question of how
>>>>> expressive should the derivation rules be and what form
>>>>> should they take ?". One way to express the derivation rule
>>>>> for a boolean attribute is as a search filter, which could
>>>>> use currentTimeMatch and currentTimeOrderingMatch ! It may be
>>>>> more appropriate to have different derived attributes and
>>>>> end-points to reflect "soft" and "hard" validity. Detailed
>>>>> use cases would help guide such decisions. However, it
>>>>> doesn't matter if privacy outcomes are not the goal.
>>>> 
>>>> during ACL processing can fulfill the privacy goals very
>>>> easily, because the matching rules can be used to server-side
>>>> force a filter via ACLs that clients cannot overwrite or
>>>> bypass.
>>> 
>>> 
>> Indeed we need the syntaxes to prevent services to be able to
>> determine the limiting time-stamp values for example of an user's
>> entry which has to be searched by a service before it can be used
>> for authentication via a bind operation. We are yet already able to
>>  prevent inquisitive services to get more information than that are
>>  needed just in the moment.
> 
> I'm not convinced that preventing services from seeing data that are
>  pertinent to the operation of that service is an important goal.

We are focusing on the optimization of provision process event-handling
related questions, rather than administration and authorization 
requirements. If our syntaxes and matching rules in general (as a 
side-effect) also offer some management advantages in direction to 
administration and authorization that's of course fine, too.

Two important and commonly accepted data privacy requirements are:
- Data minimization
- Data avoidance

In our opinion it's better to centralize (even critical) data as much as
possible instead of distributing these critical data from one system to
another and slightly loosing control. But this in general is an 
architectural/infrastructure question and a discussion topic not related 
to but taken as basis for this draft.

Imagine a new employee who has successfully applied for a timely limited
contract. The contract says the employee should begin in 2 months and 
the employment should end in 14 months. Why waiting for an external 
event which triggers the provisioning (aka partially giving up control 
and spreading sensitive data into remote systems - "data graves") in 
exactly two month,  not later not earlier?

In our scenario a new employee has already provisioned herself e.g. by
self-registration in the career portal (e.g. unprivileged role
"guest" or "applicant"). A contract is usually signed some time in
advance. Right after signing the contract the new employee's dataset is
enriched by HR using the verified data from the CV and some more details
from the distinct contract (e.g. the contract's time-stamps).
As soon as the contract has been signed the new (in this moment future) 
employee often needs instant access to the organization's (internal) 
privileged career portal services to complete some open formalities. The 
HR's LDAP service proxy is allowed to access these entries even before 
the employment gets actually an active member of the organization's 
workforce.

Two months later the entry becomes (automatically without any event)
accessible for other system's service proxies, too - completely without
the need of external event triggering frameworks that need to manipulate
attribute values, move entries and the like.
In between the successful application and the first working day it is 
very important to strictly deny access to employees' data which for good 
reasons are already provisioned but shouldn't generally be usable in 
advance. Not only the user's access to a service has to be denied (to 
avoid misuse by the user from the administration/authorization point of 
view), but also the service must not be permitted to access the future 
employees data (misuse, e.g. insider trading, bullying). That's the 
reason we want to deny read access to the time-stamps at all. Services 
shouldn't be able to notice such entries' existence and they also 
shouldn't be able to determine (binary search) the time-stamps of 
existing entries.
Just for fun, imagine the entry of the new head of the research in the 
chip industry, head of design in automotive industry or head of the 
brokerage department in the finance industry whose employment will 
probably begin in 3 to 6 month. All these information are very sensitive
(for both sides, the user and the organization) and need to be
protected because they are potentially also very lucrative and thus an 
important cause for potential internal misuse through service 
administrators.

Sensitive for the user means (affects her new and old employment), e.g.:
- possibly she still has a current employment elsewhere which could be
affected negatively for her (or for the new organization in case the old 
organization "spontaneously" rises her salary...)
- some other user's contract will end in 2 month which unnecessarily 
causes rumors
- ...

Sensitive for the (new) organization, e.g.:
- current head of department X soon joins, get's replaced or will leave 
the organization (just imagine the value/impact of this pre-information 
if Steve J., Bill G. or Steven B. are affected - OMG).
- ...

For that reason no service (only exceptional trustworthy services like
HR or equivalent) should be allowed to query a distinct object for its 
begin and end of life time-stamp. Additionally a look into the past as 
well as into the future has to be prohibited, too.

Because an user's information is usually needed in advance (e.g. HR
portal self-service right after the contract has been signed) the 
identity data regardlessly has to be existent in the system. The same 
applies regarding the end of life: User accounts do not need to and in 
practice they usually aren't be (completely) removed because they need 
to remain existent for alumna services (for example a retired employment 
still needs access to the organization's services x and a borrowed 
employee want stay a customer or wants to get employed again next year 
etc.pp).

That's the reason we would like to see our two dedicated syntaxes 
specified. Beside the above sample demonstration employment life-cycle 
scenario the draft's principal is of broader general use. Imagine 
entries that represent permissions which get automatically or 
temporarily "deactivated" or entries that represent contracts whose 
lifetime should not be disclosed to most of the services etc. pp.

> Fair enough that users shouldn't be able to see the service details
> of other users, and maybe there are times when users shouldn't be
> able to see some of their own service details, but putting blinkers
> on the service as well doesn't seem worth it. For one thing it means
> that the service can't do things like warn users that their access
> will be disabled in one hour, or even determine for itself which
> users will soon become disabled so that certain administrative 
> actions can be put in motion.

Thus our above provisioning scenario profits from automatic processing
the draft currently does not require to manage these fields during all 
day standard operation (e.g. administration/authorization).
Of course using another (generalizedTime syntax) attribute (in 
contrast/addition to our two extra ones) would more or less support the 
  administration and authorization goals you've mentioned for example above.

>> BTW: I could not find an RFC which explicitly says something about
>> how ordering matching rules may/must/should be supported/processed 
>> in extensible match filters. On the other hand I also have not
>> found a statement that ordering matching rules should not be
>> supported in extensible match filters...
> 
> I know of no standard specification that explicitly allows or 
> prohibits the use of any particular matching rule in an extensible
> match. Yours would be the first.

Disclaimer: it's not our intention and we don't want to introduce a 
major change or any quirky exceptions in LDAP. We try to solve a problem 
making use of the existing standards and when forced to we just aim to 
extend this standard as marginal as possible. We found a solution which 
works for us by just implementing two matching rules and two 
generalizedTime-derived attribute value syntaxes (and the assertion 
syntax we have called "NOW").

All we currently are looking for is to get reliable information how 
ordering matching rules are/should be commonly supported in extensible 
matching rules. Depending from the answer we perhaps need the extra 
syntaxes (when supported) or we perhaps don't need the extra syntaxes 
(when not supported).

Our draft is based on the assumption that ordering matching rules are 
supported in extensible matching rules, as long as the matching rules 
are compatible to the attribute value syntax. That's also the reason for 
our interim confusion regarding a reliable demand for the extra syntaxes 
after we have seen that openldap seems currently not to support ordering 
matching rules in extensible match filters.

Regardless of the temporary confusion we've used the "natural" schema 
definition mechanism (especially using the relation between a syntax and 
its associated/compatible matching rules). We understand this 
association the way that only "assigned/compatible" matching rules 
are/should be applicable to attributes of a distinct syntax (please 
correct me if I'm wrong).

As you've previously explained, ordering matching rules are (at least by
your product) supported in extensible match filters. Sadly we both
are not aware of a detailed specification regarding this specific question.
But for sure I'm with you: personally I do not understand why ordering 
matching rules in common shouldn't be supported in extensible match
filters. I also don't know whether this kind of support/feature is left 
open to each vendor because the specification does not say something 
about it. Therefore I've posted a question on openldap-technical in the 
meantime and I'm currently hoping for an answer (regardless whether 
product specific or not) which hopefully at least slightly enlightens me.

Although, missing support for ordering matching rules in extensible 
match filters (which seems to be the current status of openldap) would 
solve our non-disclosure problem (without the need for additional 
syntaxes), I would prefer the general support of syntactically 
compatible ordering matching rules in extensible matching filters, 
because ordering matching rule support could offer extra functionality 
(e.g. in case two or more different ordering matching rules are 
available for one attribute syntax).

To further discuss whether the introduction of our two extra syntaxes 
possibly makes sense or not, all we need to know in the moment is a 
clear statement regarding the intended/specified support for ordering 
matching rules in extensible match filters.

>> Although, OpenLDAP currently does not support ordering matching
>> rules in extensible match filters it's possibly just a question of
>> time when this "feature" becomes supported, too (in case the/a
>> specification says so?). On the other hand, other directory server
>> implementations may be already support ordering matching rules in
>> extensible match filters (the way you've explained above) and
>> probably also want to prevent client's to determine the exact
>> time-stamps vaules - just by using the new syntaxes which we
>> derived from gerneralizedTime.
> 
> FYI, eB2Bcom's directory allows all of its 110+ supported matching 
> rules to be used in an extensible match. In fact, an extensible match
> is the only way to invoke a significant number of them. I'm not
> convinced that the new syntaxes are necessary or desirable.
> 
>> 
>> 
>> Now let me please come back to explain the common need for the two
>>  extra syntaxes (named "nowBefore" and "nowAfter") mentioned in our
>>  draft:
>> 
>> attributes need to be searchable to allow an ACL engine (that 
>> supports searchfilter) to process the filter statement in the
>> context of the user or the context of a service's bindDN.
> 
>> So at least search (ideally without read) permission has to be
>> given to self, the service's bindDN or both. Search permission for
>> "self" is not as critical as search access for the service's
>> bindDN. Snoopy bindDN owners could try to gather more detailed
>> information from exntries than originally intended (e.g. looking
>> into the future or past using binary search...)
> 
> could access.
> The new syntaxes would provide only a marginal benefit

Not in the scenario we are focusing on, even more in case a server 
supports ordering matching rules in extensible match filters - like your 
product for example does.

Best regards,
Daniel

>> "generalizedTimeMatch-only" and there's currently no easy or
>> general (even standardized) way to handle/extend ACL processing to
>> exclude distinct matching rules from search (matching) operations,
>> using generalizedTime syntax for the two limiting attributes leads
>> to the binary search problem in case ordering matching rules are
>> usable in combination with extensible match filters.
>> 
>> time-stamp limits (using our matching rule) right in the moment but
>>  they are not able to determine any entry's distinct time-stamps
>> (even not their own where this is appropriate).
>> 
>> Additionally both attribute value syntaxes are not completely new.
>>  They are just syntactically derived from generalizedTime syntax.
>> Both are explicitly not associated with the generalizedTimeOrdering
>>  matching rule to prevent binary searching in extensible match 
>> filters. In our opinion the above mentioned limitation (in regard
>> to privacy protection against binary search) justifies their 
>> introduction. How these syntaxes are used in an userApplication 
>> schema or even product specific ACL definition (where supported) 
>> should of course be left open to the directory designers and 
>> administrators.
>> 
>> 
>> Appendix: Of course you are right, the other two extra
>> offset-syntaxes (defined in our draft) are only nice to have but
>> not needed (in regard to privacy) because clients can of course
>> specify all kind of offsets to do a binary search. Therefore these
>> syntaxes can be removed from the document. generalizedTime syntax
>> is completely sufficient in regard to Offset/Duration matching.
>> 
>> 
>>>>>> To support these kind of requirements the matching rules
>>>>>> are of general interest. Based on our current experimental 
>>>>>> matching basics) of these matching rules in combination
>>>>>> with your implementation of the X680 duration specification
>>>>>> the matching could be of general use for LDAP, too.
>>>>>> 
>>>>>> In our opinion there is currently nothing to be said
>>>>>> against the reasonable use of both mechanisms. What do you
>>>>>> think about this?
>>>>> 
>>>>> New matching rules and derived attributes both have their
>>>>> uses, singly or in combination,
>>>> 
>>>> yes, for sure.
>>>> 
>>>>> but using syntaxes to achieve access control is just wrong to
>>>>> my mind.
>>>> 
>>>> yes, at least as long as extensibleMatch filter expression do
>>>> not support ":<=" or ":>=" comparison operations...
>>> 
>> Hmmm, please let me cite BOFH chap. 13: "Yes means No and No means
>> Yes. Delete all files [Y]?" ;-)
>> 
>> Based on your clarification regarding the possibility to use
>> ordering matching rules in extensible match filters our previous
>> position regarding the sabove "yes, at least as..." has
>> spontaneously changed into the opposite. As explained above we
>> would like to see the additional two syntaxes to solve possible
>> privacy concerns (regardless of distinct products' ACL processing
>> features), so please let me answer your previous statement once
>> again:
>> 
>> 
>>  (which affect varies between different directory server products'
>>  features). The additional syntaxes' limitations are useful in
>> common privacy related scenarios where time-stamp derived
>> attributes should by design only be search able using our matching
>> rules. Preventing snoopy service's (proxy?) bindDNs to get more
>> information about an entry than actually is needed.
>> 
>> 
>> Best regards, Daniel
>> 
>> 
>> 
>>> Regards, Steven
>>> 
>>>> 
>>>> Best regards, Daniel
>>>> 
>>>> 
>>>>>> Steven Legg wrote:
>>>>>>> Daniel Pluta wrote:
>>>>>>>> Dear ldapext,
>>>>>>>> 
>>>>>>>>  regrading our draft specifying "ldap server side
>>>>>>>> current time matching".
>>>>>>> 
>>>>>>> control policy is subject to change. If access control
>>>>>>> policy is reflected in the attribute syntaxes one
>>>>>>> chooses, then that policy is permanently locked-in.
>>>>>>> 
>>>>>>> mechanisms, but of course you are hampered by the absence
>>>>>>> of a common, standardized access control mechanism across
>>>>>>> all LDAP implementations. With that in mind I would take
>>>>>>> a somewhat different approach to a solution.
>>>>>>> 
>>>>>>> property of a collection of attributes while
>>>>>>> simultaneously enforcing restricted access to that
>>>>>>> collection of attributes. What I would do is define a
>>>>>>> schema mechanism for defining derived attributes, i.e.,
>>>>>>> attributes whose values are algorithmically derived by
>>>>>>> the server from the values of other attributes in the
>>>>>>> same entry. The derived attributes can then be subject to
>>>>>>> different access controls than the source attributes.
>>>>>>> 
>>>>>>>  notValidBefore and notValidAfter according to the
>>>>>>> following pseudo code:
>>>>>>> 
>>>>>>> Privileged users and processes would be given permission
>>>>>>> to read and update the notValidBefore and notValidAfter 
>>>>>>> attributes, but regular users would only be able to read
>>>>>>> the currentlyValid attribute. This kind of access control
>>>>>>> policy can be expressed in existing LDAP access control
>>>>>>> schemes even though they differ between implementations.
>>>>>>> 
>>>>>>>  don't see that you achieve anything with the
>>>>>>> nowBeforeOffset and nowAfterOffset syntaxes since a user
>>>>>>> can just use a binary search to determine the actual
>>>>>>> values of the target attributes by adjusting the offsets
>>>>>>> (a client can guess the time at the server with
>>>>>>> reasonable accuracy). Limiting the sign or magnitude of
>>>>>>> the offset would provide partial protection, but a
>>>>>>> derived attribute could also do that. For example, to
>>>>>>> allow regular users to determine when a valid account
>>>>>>> became valid but not allow them to determine whether or
>>>>>>> when an account will become valid at some time in the 
>>>>>>> future I would define a derived attribute of
>>>>>>> GeneralizedTime syntax whose values are determined by the
>>>>>>> following pseudo code:
>>>>>>> 
>>>>>>> if (current time >= notValidBefore) value =
>>>>>>> notValidBefore else absent
>>>>>>> 
>>>>>>> It becomes a question of how expressive should the
>>>>>>> derivation rules be and what form should they take ? I
>>>>>>> think OpenLDAP might have some capabilities in that area
>>>>>>> already.
>>>>>>> 
>>>>>>> The nowOffset syntax isn't required if derived attributes
>>>>>>> are used instead, but if you want to persist with it I
>>>>>>> suggest you align it with the existing ASN.1 DURATION
>>>>>>> data type (see 
>>>>>>> rather than rolling your own format, not the least
>>>>>>> because I already have an implementation that supports
>>>>>>> DURATION as an attribute and assertion syntax for both
>>>>>>> X.500 and LDAP.
>>>>>>> 
>>>>>>> Regards, Steven
>>>>>>> 
>>>>>>>> 
>>>>>>>> -------- Original-Nachricht -------- Betreff: New
>>>>>>>> Version Notification for 
>>>>>>>> draft-pluta-ldap-srv-side-current-time-match-00 Datum:
>>>>>>>> Thu, 25 Mar 2010 15:51:33 -0700 (PDT) Von: IETF I-D
>>>>>>>> Submission Tool <[email-masked]>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> A new version of I-D, 
>>>>>>>> Filename:
>>>>>>>> draft-pluta-ldap-srv-side-current-time-match Revision:
>>>>>>>> 00 Title:         Lightweight Directory Access Protocol
>>>>>>>> (LDAP): Server Side Current Time Matching - Matching
>>>>>>>> Rules and Syntaxes Creation_date:     2010-03-25 WG ID:
>>>>>>>> Independent Submission Number_of_pages: 20
>>>>>>>> 
>>>>>>>> Abstract: This document extends the Lightweight
>>>>>>>> Directory Access Protocol (LDAP) to support server side
>>>>>>>> current time matching.  Matching of attribute values
>>>>>>>> against an LDAP server's current time offers additional
>>>>>>>> functionality with regard to authorization and fulfills
>>>>>>>> enhanced data privacy requirements for restrictive
>>>>>>>> environments. Therefore this specification defines four
>>>>>>>> additional syntaxes and related matching rules useful
>>>>>>>> for extensible matching in association with these
>>>>>>>> syntaxes.  In addition and for general use the matching
>>>>>>>> rules defined in this document are also applicable to
>>>>>>>> any attribute type definitions that are using the
>>>>>>>> 'Generalized Time' syntax.  This specification also
>>>>>>>> contains restrictive attribute type definitions

---

From: Steven Legg <[email-masked]>
Date: Thu, 29 Apr 2010 16:51:28 +1000

Hi Daniel,

>>> Hi Steven, Steven Legg wrote:

[snip]

> to be query able for some kind of verification / debugging possibility.

The immediately preceding sentence is the answer to the "why?"; so that
clients can verify that the server's idea of "now" is reasonable, or to
debug unexpected results.

> attribute for each entry.

You haven't considered that the LDAP server a client is connected to could be
an X.500 server supporting a distributed DIT, or a virtual directory. In both
cases the result returned to the client can contain entries contributed by
more than one server, each of which has its own time. The time reported
by the server the client is directly connected to may be representative of
all, some or even none of the entries in the result. Publishing the time in
each entry means that each entry in the combined result indicates the
particular value of "now" against which it was evaluated.

> what about additionally publishing the server's timezone?

Publishing the server time as local time plus time zone (which is allowed
by the Generalized Time syntax) allows UTC, server local time or time zone
to be recovered from the one value. I would recommend doing that.

> Please see above: time is a must-have, timezone is just nice to have

Fair enough.

>>>>> subset of services (for alumna). Currently this is often controlled 
>>>>> by complete entry provisioning or simple attribute changes (event 
>>>>> or timely triggered or both). Although these
> shouldn't be able to notice such entries' existence

The new syntaxes are not relevant when it comes to hiding the existence
of an entry. You can do that with just the new matching rules and the
existing Generalized Time syntax. If an entry isn't visible, then
neither are its timestamps so their syntax doesn't matter.

 > and they also

And what of the services that do need to match on the lifetime (other than
with respect to the current time) ? This gets back to where I started this
thread; schema mechanisms are not appropriate for enforcing access controls.
They are immutable and affect everyone the same. You don't have the
discretion to have some services permitted to match the lifetimes and some
prohibited. With your syntaxes the directory administrator decides up front
that either all services and users can match the lifetimes or none will
(ever!). That is too inflexible. What you should be doing is extending the
access control mechanisms in OpenLDAP so that it is possible to express
which identities are permitted to apply which matching rules to which
attribute types. That, combined with the new matching rules, would allow
you to do everything you want to do with the new syntaxes and more besides.
It would allow access controls to be tailored for the needs of each service
and could be applied to syntaxes other than timestamps. It would also allow
tighter controls to be placed on existing attributes of Generalized Time syntax.

>> users will soon become disabled so that certain administrative actions 
>> can be put in motion.
> 

That's what I don't like about the new syntaxes. Each new authorization
criterion needs a new syntax, so we get a proliferation of new syntaxes
just like old syntaxes, but with special rules. Put the rules in the
access control models where they belong.

>>> how ordering matching rules may/must/should be supported/processed in 
>>> extensible match filters. On the other hand I also have not

The answer is not useful. You seem to be assuming that if an attribute
is defined without an ordering matching rule, then it is not possible to
do an ordering match on values of the attribute except via an extensible
match. However, all the typical naming attributes (commonName, givenName,
organizationName, and so on) are defined without ordering matching rules,
yet most (if not all) implementations will readily perform <= and >=
filter matching on values of the attributes and allow the values to be
sorted. You can't rely on the absence of an ordering matching rule in
an attribute definition to prevent ordering matching of the attribute's
values. You should be looking at using access control mechanisms to do
that.

[snip]

>>> implementations may be already support ordering matching rules in

There's no "may" about it. We do, and we use the capability extensively,
and it's not going away.

>>> derived from gerneralizedTime.

I would rather do that in the access control mechanisms.

[snip]

> product for example does.

The new syntaxes are not relevant if an entry is hidden. Once an entry
becomes visible the new syntaxes are only protecting timestamps for
which there is no service or user that ever needs to match their values
to something other than the current time.

Regards,
Steven

[snip]