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 Time Issue

Title: RE: [security-services] the Time Issue

> Subsecond resolution bothers me because XML Schema is silent on the
> matter of roundoff errors, etc., between lexical form and native form,
> and back.  See archives for discussion of "round-tripping," e.g. If we
> need subsecond, then let's say msec and allow .000 only.

I would like to understand this better. At this point I do not see a problem. What archives are you referring to? Clearly not SAML. I hope not X.509, as I have no idea where these would be. Perhaps you mean PKIX. Could you specify a year and month or quarter? Better still, could somebody outline this discussion to this list?

It is my understanding that much time and effort was spent in X.509 and PKIX to make it possible to receive a certificate, unpack its contents into local formats, discarding the original and subsequently reassemble the certificate, such that that the original signature will still verify. In spite of the effort, this still is not guarenteed to work in all cases, at least according to Peter Gutmann.

I can see no scenario in SAML where this is required or even desirable. I suggest we adopt as an explicit non-goal the ability to convert the contents of an assertion to a local format and back. If you need the orginal for some purpose such as audit, just keep a copy. Does the time precision issue still exist if this non-goal is accepted?

On the subject of time zones, I will repeat what I said on the call. I don't see much value in supporting timezones other than 0, unless daylight savings (summer time) is also supported. I recognize that this is extremely difficult to get right especially on the day of transition, so I agree there would be benefit to strictly prohibiting any timezone but 0.


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

Powered by eList eXpress LLC