OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [security-services] the "NotOnOrAfter" issue

> There are some amazing subtleties, so that getting the math 
> right can be 
> tricky; remember that you *subtract* the offset, so you have to 
> "borrow", so things like 2am on March 1, 2000 in Boston 
> (EST5EDT) can be 
> hard. If you do the "obvious" thing -- parse the time into something 
> like the Unix time_t, number of seconds since an epoch -- you 
> lose out 
> because of leap-seconds; they get lost.

I agree with you about the subtleties and complexities existing, but I
stand by my statement that this processing should (and more-and-more
often will as XML in general and schema in particular continue to gather
momentum) happen in a layer that the SAML-processor is built on.

Even if you don't accept that, look at it this way: If your
SAML-consumer accepts a general dateTime then you are responsible for
making sure that it is used correctly in comparisons. (This may mean
converting it to UTC, or may involve having the comparisons handled by
your schema implementation, etc.) If your SAML-consumer requires an
unqualified UTC dateTime then all you are doing is pushing the
conversion requirement to the SAML-producer. I don't see the gain... But
again I could be missing something.

> Now I, personally, don't care 
> about leap seconds, but if I were writing a high-value 
> financial system 
> I would be very concerned if my infrastructure vendor wasn't aware of 
> thsoe kinds of things. 

Again agreed, although I would suggest that companies building
high-value finanacial systems with SAML components are the exact
companies most likely to be using tools/libraries that implement schema
and all its primitives (like dateTime)--removing the requirement for
individual modules within individual application tasks to implement
things like time-zone independent date comparison.

> As for sub-seconds, it's an issue of clarity -- folks are used to 
> rounding, not truncation; 

OK, I admit you lost me there. I see rounding and truncation as possible
solutions to a problem of "how do I express a number with X significant
digits in a representation that can only handle Y significant digits,
where Y < X?" I don't see what that problem has to do with what we are
talking about.

Unless there is a good reason for picking a one second resolution (which
I haven't seen yet, but will freely grant may be something I am ignorant
of) I don't see why I shouldn't be able to create an assertion that has
a lifespan of 13.656 seconds.

We may want to call out the fact that 13 will be considered 13.000 for
the purposes of comparing with 13.656, but I still don't see where
rounding/truncation enters in.

> what should 1.5 - .5 be?  What 
> about 1.6 - .9? 

I feel like I'm walking into a trap. 1.5 - 0.5 is 1.0 (which is assumed
to mean 1.00000000000000000...), and 1.6 - 0.9 is 0.7 (which is assumed
to mean 0.70000000000000...). 

Not that these are really relevant questions. We aren't using the time
values to indicate the length of an assertion's lifetime, we are using
them as markers of the instants when the lifetime starts and finishes.
The important question for security purposes is "Is time instant X
within the valid lifetime of this assertion?", not "How many seconds
long is the lifetime of this assertion?". Consequently it's really only
the comparison operators that matter, and there is no issue there until
you get into the domain of floating point error...

>   etc? I think truncation is the only safe answer, otherwise 
> you have to 
> worry about XML Schema implementation errors when doing 
> valuespace/lexical-space conversions of entries like 
> 2.999999999999999999999 seconds.  But as I said, folks are 
> used to rounding. 

Still lost on why this would matter.

> Remember, if it's subclasses, it CAN Be treatred as a 
> dateTime, so it's 
> no extra work.  It's just a matter of enforcing the semantics in the 
> contract definition, which is a good thing. 

If we decide we need these constraints in the schema, then subclassing
is clearly the way to go. However my general philosophy is not to remove
any flexibility from a system unless there is a good reason to do so. I
have no use for fractional seconds, but I haven't seen (or at least I
haven't understood) a good reason for removing them yet, either.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC