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

[Michael Sierchio]

On Tue, Sep 6, 2016 at 10:40 AM, Jakob Bohm  wrote:
...

> 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.

...

That would be really useful. An expired or revoked certificate may still be
used to verify a signature generated at a time when the certificate was
valid.

-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred."

- The Mahābhārata
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users