Subject: draft-housley-binarytime-00.txt

From: Russ Housley <[email-masked]>
Date: Wed, 01 Sep 2004 09:21:46 -0400

Since this WG has most of the CMS experts in it, I would appreciate review 
of the document that was posted earlier this 
week:  draft-housley-binarytime-00.txt.

My intention is to request that this document be published as a 
standards-track RFC.

Thanks,
   Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Sep 2004 02:55:11 +1200

Russ Housley <[email-masked]> writes:

>Since this WG has most of the CMS experts in it, I would appreciate review of
>the document that was posted earlier this week:  draft-housley-
>binarytime-00.txt.

Uhh... what on earth motivated this?  It's a time format that's even more
limited than UTCTime.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Wed, 01 Sep 2004 11:31:00 -0400

The document states the rationale.  No conversion to operating system 
representation and it is smaller.  In what way do you find it limiting?

The INTEGER is not limited to four octets.  Did you read it that way?

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 02 Sep 2004 04:41:55 +1200

>representation and it is smaller.  In what way do you find it limiting?

It doesn't go beyond 2038, whereas UTCTime at least goes to 2050.

The proposal isn't so much limiting as... bizarre.  The ASN.1 time formats
have been around forever. everything supports them, and this proposal is for a
format that isn't even as "flexible" as the not-very-flexible UTCTime.  What
real problem is this addressing?  Why a time_t?  Why not a 64-bit time to keep
the Java guys happy?  Or the Windows nanoseconds-since-1600 time?  Or the
Macintosh seconds-since 1904?  You could make it a choice, so no-one would
feel left out, with at least one of the choices being an identified-by-OID
value so everyone could add their own favourite oddball format...

Peter.

---

From: Russ Housley <[email-masked]>
Date: Wed, 01 Sep 2004 13:33:24 -0400

>It doesn't go beyond 2038, whereas UTCTime at least goes to 2050.

Not so.  A 4-octet value takes us to 2038.  After that a 5-octet value is 
needed.  Many operating systems already use a 64-bit value internally.

>value so everyone could add their own favourite oddball format...

Any of these is possible, but a choice defeats the whole point, which is to 
avoid complex conversion.

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 01 Sep 2004 14:36:13 -0400

Peter,

Your criticism is what seems bizarre.  The one sentence omitted
from what you quote below states that it DOES go beyond 2038.  An
INTEGER number of seconds since Jan 1 1970 will go until the
heat death of the universe and beyond.

The question for more rational discussion is:  is a binary signing time
value useful?  If the answer is yes, the only remaining questions are
epoch and resolution.  Since there were very few CMS digital
signatures in existence before 1970, using an epoch of 1600 or 1904
would seem to offer little benefit.  It is also difficult to articulate
a rationale for specifying the moment of signing to nanosecond
resolution.

The reason for a binary attribute in the first place is primarily
space efficiency.  CMS can be used to sign large numbers of
small objects, and certificates don't need to accompany
those objects.  ASN.1 structures can be PER encoded, but
PER offers minimal compression of UTC or Generalized Times
(7 bits vs. 8 per character).   Once you have squeezed out all bits
permitted by the standard, you look for additional opportunities.
Defining a binary time attribute is one such opportunity.

Will this be useful for S/MIME?  Of course not.  But it is
useful for some other applications of CMS.

Dave

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 03 Sep 2004 16:09:52 +1200

"David P. Kemp" <[email-masked]> 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.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 03 Sep 2004 14:51:05 -0400

>a few bytes in the time encoding, you'll double the space through having to use 

You read past the part about this being useful for CMS but not for 
S/MIME.   The situations where saving a few bytes is useful occur when 
1) the objects being signed are small, 2) signature values are small 
(i.e. DSA/ECDSA, not RSA), and 3) encoding overhead is small (i.e. PER, 
not BER/DER).  There are no existing applications in this space, and 
thus no backwards compatibilty issues.  But CMS  and a newly defined 
attribute can be applied to future applications without having any 
impact on existing apps.

The other Peter's suggestion:

    Time ::= CHOICE {
        utcTime          UTCTime,
        generalizedTime  GeneralizedTime,
	epochSeconds     INTEGER}

is fine with me, but I'm not sure existing applications would deal with 
an unrecognized CHOICE value as gracefully as they would with an 
unrecognized attribute.  To avoid problems, the S/MIME -msg spec would 
have to state that epochSeconds MUST NOT be used by sending applications.

Dave

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 05 Sep 2004 18:22:03 +1200

"David P. Kemp" <[email-masked]> writes:

>There are no existing applications in this space

In other words in the 20-odd years that ASN.1 has been around, this pressing
need to save a handful of bytes in time encodings has never been an issue.
This suggests a simple solution...

The main reason why I object to something that's mostly just a gratuitously
incompatible re-encoding of an existing field is because it's being pushed as
a standards-track document.  Because of this, users will demand that it be
supported (even though they have no idea why they need it) simply because it's
a standards-track RFC, and it wouldn't have been made standards-track if there
wasn't some reason for having it even if we don't know what it is.
Implementors then have to support yet another attribute, yet another date
format, double the size of the date data in sigs because of the nead to
support both the existing and new format, act in some appropriate manner when
the two dates disagree (actually from existing experience with apps that
deliberately set inconsistent times in signed data that allows multiple time
fields, nothing ever checks this, they just pick one or the other date
arbitrarily), etc etc etc.

Now as you say above, the demand for this to date has been zero.  This
suggests that the correct track for the new time encoding is either
"Experimental" or "grab a private OID and go for it", to match the actual
demand from users.

Russ Housley <[email-masked]> writes:

>However, i am aware of smartcard environments without mktime().

Since they are presumably also without a RTC (thus making the inability to
convert a UTCTime moot, since there's nothing to check it against), this
wouldn't appear to be a real problem.

(I have been informed in private mail of the existence of several C one-liners
 (and at least one in Fortran, this problem has been studied for awhile) to
 convert the ASN.1-style ASCII date to a binary format, so it's likely that
 the additional code needed to handle binary times would entail more overhead
 than a basic mktime()-equivalent).

Peter.

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Sep 2004 10:33:35 -0400

Peter:

So, if it were an experimental document, you would have not issues?

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 12 Sep 2004 00:49:56 +1200

>So, if it were an experimental document, you would have not issues?

Experimental would be fine.  As long as there's an indication to the masses
that there's a different degree of importance between support for
extensions/options like MessageDigest and ones like BinaryTime.

(I'd still suggest though that if space saving is the primary concern, an
 approach like the SimpleSigningAttributes one would be better, since apart
 from the 15-20 bytes *per extension* saved you could use further tweaks like
 making ContentType default to "data" (the most common case), using enums
 instead of OIDs (that is, make it a CHOICE between standard-content-type as
 an enum and OIDs for nonstandard types), etc etc etc.  Peter Sylvester's
 suggestion of packing everything in with the data is even more compact, if
 slightly less flexible).

Peter.