"David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil> 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 <housley(_at_)vigilsec(_dot_)com> 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.