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

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.
>>>> 
>>>> We specifically require the server's idea of UTC.
>> 
>> 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)
> 
> 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.
>>> 
>>> I think this is reasonable justification for new matching rules.
>>> 
>> 
>> Fine, thanks.
>> 
>> 
>>>> The comparison result need to be independent of the replica
>>>> (its timezone) a client connects to.
>>> 
>>> It should be already because all comparisons are according to
>>> UTC.
>> 
>> 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.
>>>> 
>>>> 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.
>>> 
>>>> - 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 overhead is worth for?
>>> - Depending on the first and the second point: What's the reason
>>> (use
>>> 
>>> 
>>> 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.
>> 
>> 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).
> 
> 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?).
> 
> 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.
> 
>> 
>> 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.
> 
> 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, 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.
> 
> The pertinent question is: why? The IESG will probably want to know.

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

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.
>>>>> 
>>>>>> 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.
>>> 
>>> 
>>> In that case you don't need extra syntaxes or all four matching 
>>> rules.
>> 
>> 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:
>> 
>> 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.
> 
> An ACL engine in a directory is not itself subject to access
> controls.
> 
>> 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...)
> 
> 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

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

> Regards, Steven
>> 
>> 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.
>> 
>> 
>>>>>> 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?
>>>>> 
>>>>> 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...
>>> 
>>> ... which they do and always have :-).
>> 
>> 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
>>>>>>> 
>>>>>>>> 
>>>>>>>> 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 <idsubmission@ietf.org>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 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 Ldapext@ietf.org 
>>>>>>>> https://www.ietf.org/mailman/listinfo/ldapext