"David P. Kemp" <dpkemp@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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.