Re: [security-services] the Time Issue

[Stephen Farrell <stephen.farrell@baltimore.ie>]

Phill,

I know I promised to shut up, but I'll buy you a beer sometime instead:-)

> 1) Steve proposes that we have a fixed resolution of a second to match
> X.509. 

Nope, 'twas for simplicity, nothin' to do with wanting to match X.509.
It just turns out that X.509 has evolved to those settings too.

> I think that tying the protocol to a particular resolution is an
> unnecessary restriction.

IMO we should either fix, or specify a finest-granularity, for the
resolution. Otherwise we get unintended behaviour. I don't mind 
which (fixed or finest-grained), but I imagine that all xml parsers
will be able to handle 1s values input to them, hence my suggestion
of fixed.

> 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 interop problems weren't caused by "<" vs. "<=", 'twas mostly to do 
with the presence or absence of "00" seconds (hey, isn't that resolution:-)
and repeated en/decode cycles buggering up hashes. Look back at the PKIX 
archives or Peter G's style guide [1]. 

> The X.509 semantics map precisely to the
> NotOnOrAfter semantics by adding a second. 

Therefore they're as easy to implement? My point was not that one's harder,
but that gratuitous change is a bad idea. That remains my point.

> It is very easy to get the X.509
> semantics wrong, it is much harder to get notonorafter wrong.

Blatent assertion, no more.

> 3) The UTC issue. I have no problems with stating that all times must be in
> UTC. 

If you'd stopped there, we'd be fine!

> 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.

That's not clear to me. Are you saying you want UTC (Z), GMT (same really) or 
numeric-offsets from UTC, or unspecified timezones? 

Stephen.

[1] http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com