ietf-smime
[Top] [All Lists]

Re: draft-housley-binarytime-00.txt

2004-09-02 21:09:59

"David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil> writes:

The one sentence omitted from what you quote below states that it DOES go 
beyond 
2038.  

Yeah, sorry, it was late at night and I read through it very quickly.

The reason for a binary attribute in the first place is primarily space 
efficiency.

As Peter Sylvester has pointed out, in order to be compatible with existing
apps, you'd need to include *both* attributes (the TLS WG has just had a debate
about the 10-year old obsolete known-insecure SSLv2 protocol and why virtually
everything still has to support it by default for backwards-compatibility, so
you'll never get rid of the existing signing time). As a result, you won't save 
a few bytes in the time encoding, you'll double the space through having to use 
two different formats.

In addition the space saving is insignificant, a few bytes.  I can save the
same amount by not encoding the optional NULL parameter in algorithm 
identifiers, and that without breaking backwards compatibility like 
binary-time does.

If saving a few bytes really is so critically important then this should be
pursued by creating a new ASN.1 time type so that everyone may benefit from 
it.  If it's part of the standard time CHOICE then it can be used everywhere 
where UTC/GeneralisedTime is currently used.

Peter.