ietf-smime
[Top] [All Lists]

Re: draft-housley-binarytime-00.txt

2004-09-13 02:46:08


Russ, 

I think you have misunderstood some of the remarks:

The new text adds the syntax of the existing signingTime attribute
to the new one, thus make the new one a superset.

The suggestion was to add a binary time to the existing one
(assumed that anything should be done), but certainly not to
reintroduce the options of the existing attributes. 

There is no need at all to introduce these options, they serve
nothing at all, since the other attribute exists. 

But I'll address the statements of the text (a second time). 

1.1  BinaryTime

   Many operating systems represent date and time as an integer.  This
   document specifies an ASN.1 type for representing a date and time in
   a manner that is compatible with these operating systems.  This
   approach has several advantages over the UTCTime and GeneralizedTime
   types.

Not many systems represent data and time in BER as far as I remember.

   First, a BinaryTime value is smaller than either a UTCTime or a
   GeneralizedTime value.

True, but very weak conpared to the size of the document, ...

   Second, in many operating systems, the value can be used without
   conversion.  The operating systems that do require conversion can do
   so with straightforward computation.

You need at least some conversion from a BER encoded variable length
integer to some value. You don't any indication why you want to compare
the date with some local integer value?  

As far as I remember, date comparisions have to be made in case
if you want to check certificates. In this case, the logic to
convert a local time value to an Generalizedtime already exists
on the machine. Of course, if you assume that no certs are used
at all, ... then you might still save more octets by reducing
the SignerInfo structure.  

   Third, date comparison is very easy with BinaryTime.  Integer
   comparison is easy, even when multi-precision integers are involved.
   Date comparison with UTCTime or GeneralizedTime can be complex when
   the two values to be compared are provided in different time zones.

There are no time zones involved in the signingTime attribute.
One change in RFC 3369 vs 2630 to uppercase the MUST.
 
String comparison is as easy as integer comparison. 
 
In 25 years, time definitions of 32 bit machines may become difficult
to compare with an integer. Nothing guarantees you that the local
time definitions with simply shift or else. 

The textual representation of generalizedtime in zulu holmds at least
a few years more, and beyond 9999 there is already an RFC :-) 

   This is a rare instance where both memory and processor cycles are
   saved.

Processor cycles are not saved, since soon, i.e. in about 25 years,
you have to check whether you are beyond epoch, etc. So may need
at least some (almso rather simple) logic as with the adjustments
of UTCTime.

Or, to resume: the only arguments that I can see is to save a few octets.
If you want to do this, code in PER for example.


5  Security Considerations

   This specification does not introduce any new security considerations
   beyond those already discussed in [CMS].

CMS has no security considerations concerning the signingTime attribute.
Anyway, in the following you are doing quite the contrary, i.e., you
add new considerations. 

   Use of the updated signing-time attribute does not necessarily
   provide confidence in the time that the signature value was produced.
   Therefore, acceptance of a purported signing time is a matter of a
   recipient's discretion.  RFC 3161 [TSP] specifies a protocol for
   obtaining time stamps from a trusted entity.

   The original signing-time attribute defined in [CMS] has the same
   semantics as the updated signing-time attribute specified in this
   document.  If both of these attributes are present, they SHOULD

SHOULD assumes that unless good reasons the data should be identical,
or, that a client should perform a comparison? If you don't assume
any work to be done by the client, you should mention that nothing
can be said about the two values.

   provide the same date and time.

At least, if both are present, the only vaguely valid argument about
savings of space vanished, and cpu cycles are also necessary to skip
or parse. 

RFC 3369 has a lot of text saying that ther must only be one occurence
of the signingTime attribuet and only one value.

With this new specification you now add a second occurence. Does this
mean that you consider the existing 3369 spec is too strong? 

Does someone remember the reason why the 3369 spec says that
all dates between 1950 and 2005\xE0 MUST be coded in UTCTime? 
Is it because of existing systems or in order to have a 
canonocal form, i.e. like DER? 
With the proposed spec identical information can have two different
signatures.

Peter