[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