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: [security-services] the Time Issue


Some points:

1) Steve proposes that we have a fixed resolution of a second to match
X.509. I think that tying the protocol to a particular resolution is an
unnecessary restriction.

2) Matching the semantics of X.509. I am none too happy with the argument
that we should match the X.509 semantics because it took so long to get the
implementations to interoperate. The X.509 semantics map precisely to the
NotOnOrAfter semantics by adding a second. It is very easy to get the X.509
semantics wrong, it is much harder to get notonorafter wrong.

3) The UTC issue. I have no problems with stating that all times must be in
UTC. I am somewhat less sure as to the best way to manage the timezone
issue. One way is to state that all times MUST be expressed in GMT, i.e. the
timezone offset is zero. Another is to allow the use of local timezone
offsets so that the local and GMT time are both known.

The concern is what to do if an application inserts a local timezone. Should
it be permissively accepted or definitively rejected. I think that we should
either insist on GMT and require processors to reject timezone offsets or
allow explicit to allow numeric timezone offsets. Named timezones are
obviously right out.

	Phill



Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC