Re: Doubt regarding O-SSL and setting the duration of certificates

Frank Migge <fm@xxxxxxxxxxxx> · Wed, 13 Sep 2017 07:51:37 +0900

This is an interesting 
statement.

>> should use the GeneralizedTime value 99991231235959Z (10) in 
the notAfter field ...

>> Solutions verifying a DevID are expected to accept this value 
indefinitely

Isn't using that large a time value in certificates problematic? Not all
 systems
 can handle it today. At best, they may gracefully decline it as 
invalid. 
Windows up to version 10 is unable to display it, and fails to work with
 such a cert.

Even closer into the future, 20 years from now, I am not sure how far 
the industry came in dealing with the upcoming year 2038 problem on 
32bit systems. It is indirectly related to OpenSSL when system time is 
used, converted to or from. Particularly in IOT/ICS industry situations 
with scaled down CPUs, long device lifespans and support requirements, 
functional validation with future time settings would definitely be a 
good idea on the test plan.

Frank

   	Robert Moskowitz
        Wednesday,

 September 13, 2017 12:57 AM

    IEEE 802.1ARce (latest draft addendum) specifies:

    8.7 validity

    The time period over which the DevID issuer expects the device to be
    used.

    All times are stated in the Universal Coordinated Time (UTC) time
    zone. Times up to and including

    23:59:59 December 31, 2049 UTC are encoded as UTCTime as
    YYMMDDHHmmssZ. Times later than

    23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as
    YYYYMMDDHHmmssZ.

    The time the DevID is created is encoded in the notBefore field of
    DevID certificates. Each DevID chain

    certificate has a notBefore value that encodes a time that is the
    same as or prior to that of any DevID

    certificate that relies on the chain for certificate validation.

    The latest time a DevID is expected to be used is encoded in the
    notAfter field of the DevID certificate.

    Each DevID chain certificate has a notBefore value that encodes a
    time that is the same as or later than that of any DevID certificate
    that relies on the chain for certificate validation.

    Devices possessing an IDevID are expected to operate indefinitely
    into the future and should use the

    GeneralizedTime value 99991231235959Z (10) in the notAfter field of
    IDevID certificates. Solutions

    verifying a DevID are expected to accept this value indefinitely.
    Values in notAfter fields are treated as

    specified in RFC 5280.

    Footnote: (10) 

    This value corresponds to one second before the year 10 000; note
    the creation of an opportunity for the Y10K bug fix industry.

    =====================

    It is really rare to find humor in IEEE specifications!

    Bob

    On 09/12/2017 11:39 AM, Alejandro
      Pulido wrote:

   	Robert Moskowitz
        Tuesday,

 September 12, 2017 11:30 PM

    Depends on the question....

    'Infinite' duration is used in IEEE 802.1AR Device Identities.  The
    concept is the vendor installs the certificate in read-only memory. 
    It is expected to be good for the life of the device.

    On 09/11/2017 05:32 AM, Alejandro
      Pulido wrote:

   	Alejandro Pulido
        Monday,

 September 11, 2017 6:32 PM

Dear team of OpenSSL,

First of all, congratulations for your invaluable work!

I have a question regarding the issue of certificates 
X.509 with infinite duration and I don't know where to submit it.

Please, could you help me?

Thank you very much and kind regards

Alejandro J 
Pulido Duque

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