[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. C.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC