[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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:
Hi Daniel, Daniel Pluta wrote:
Hi Steven, Steven Legg wrote:
Daniel Pluta wrote:
Steven Legg wrote:
Daniel Pluta wrote:
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.
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.
Ok, that's fine.
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.
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.
As we've written (above and in our draft, sect. 7.3) we prefer and have
always preferred the Root-DSE. Publishing an additional operational
attribute carrying the current time of the server (an entry is delivered
from) has been mentioned (sect. 7.4) but left open for discussion to
determine whether such kind of information is useful for someone else.
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.
Unlike your suggested approach using filter statements like for example
(&(currTime>=9:00)(currTime<=12:00)) to enable client side filtering for
an operational attribute called e.g. currTime that contains the server's
time during delivery our concept does not and has never had a need for
such kind of attribute.
With your argument concerning the distributed DIT in mind this entry
local attribute does not seem to make sense (even in regard to your
scenario) so we tend to remove sect. 7.4 from the draft.
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?
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.
That's fine and it complies with what we've suggested in sect. 6.2.
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.
You're completely right here. We've also thought about that previously
but canceled it because in our opinion this won't be a general but only
a product specific solution.
[snip]
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.
Many thanks for this explanation. We have not thought about this, yet.
It obviously does not scale.
I would rather do that in the access control mechanisms.
We too. ;-)
[snip]
Last but not least, towards an 01-version please let me give a first
short summary regarding the intermediate status of our ongoing
discussion (please feel free to comment):
General remarks:
- LDAP Server Side Current Time Matching seems to be of interest
- Steven, many thanks for the discussion and your valuable feedback!
Attribute Value Syntaxes to enforce/denie some kind of access:
- Doesn't seem to make sense in general - better use ACLs.
- No need for the many syntactically dedicated ext. matching rule
Matching Rules:
- Instead of all the extensible matching rules only two:
- equality matching rule: "nowMatch"
- ordering matching rule: "nowOrderingMatch"
- both matching rules support now and timely offset matching
- both matching rules support extensible match filters
Assertion Syntaxes:
- Two standalone assertion syntaxes preferred:
- simple "NOW"
- flexible X.680 (based on your already avail. implementation)
- both compatible with the above matching rules
- Alternative:
Differentiation between "now" and "nowOffset" assertion syntax
not strictly needed: both can be integrated in one "Assertion
Syntax" that supports any offset (also "NOW" using some kind
of a zero offset?).
- In my opinion: "NOW" would offer improved readability
Operational Attribute for each Entry:
- Distributed DIT could result in many different "NOW"s
- Currently there's no known use-case for something like this.
- Remove from draft
[- Nevertheless, keep it just for informational reasons]?!
Root-DSE:
- "supportedFeature" seems to be ok
- "serverTime" whether in UTC or <g-differential> format
- both seem to be reasonable
Best regards,
Daniel
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext