[openssl-users] dates, times, durations in next release (commands)

[Jakob Bohm]

On 06/09/2016 19:11, Salz, Rich wrote:
>
> I am thinking of standardizing the syntax for dates, times, and 
> durations used by the applications in the next releases, based on 
> http://www.w3schools.com/xml/schema_dtypes_date.asp (with the 
> extension that lowercase letters can also be used).
>
> Objects that need dates (x509 etc) will have a standard –start flag.  
> It takes an ISO date-time, the time defaulting to 00:00.  A time and 
> duration can be specified by putting /duration after the start date.  
> Or the abosolute time can be specified with an –end flag.  For example
>
>                 -start 2017-02-10/p30d
>
>                 -start 2017-02-10 –end 2017-03-12
>
> Both mean the same thing, from Feb 10 for 30 days.
>
> Comments?
>
>

Please don't break compatibility with any command lines that
may have been embedded into thousands of scripts around the
world.  So if a date/time/period string was acceptable to
the old code, it should remain acceptable to the new code.
This does not preclude unifying the parser code and rules,
it simply means that the established syntax forms need to be
accepted and take priority over any new forms added where the
same string could have different meanings.

Another related (long standing) issue is the inability to
state an "as of" date to the various commands and APIs that
validate signatures, certificates etc.  Both past and future
dates can be needed in various use cases.

For any date related code, do not limit to the timespan of
the system (or POSIX) time_t type.  This would fail for long-
duration root certificates, long-duration Android code signing
certificates and for fields that specify dates other than
certificate validity (such as date of birth or date of
foundation for company/organizational entities).  As test cases,
try encoding the foundation date of e.g. the country China (not
its current regime, but the country itself) or the religious
organization commonly referred to as the Roman Catholic Church.

Similarly, try encoding various future dates listed in
documents such as the various Climate related treaties (though
those would be less likely to appear in certificates).

And of cause, never confuse the PKIX profile with the ITU-T
standards.  For example, PKIX limits some data fields to 1s
precision while the standards do not.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded