Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

On 09/13/2017 09:31 AM, Michael Richardson wrote:

Robert Moskowitz  wrote:
 > The devices never test out the lifetime of their certs. That is up to

Exactly...
(Do you think about the MacGyver/StarTrek/A-Team/Leverage/MissionImpossible
plot line that goes along with each engineering decision?...)


Never was into watching TV.  Maybe saw half a dozen MI and maybe 4 - 5 
StarTrek, so I really can't answer this...  :)



 > validating servers. And the iDevID is not really intended for operational
 > use. Rather it is the security bootstrap for the lDevID. See the work 
being
 > done in the ANIMA workgroup as an example of what to do with this. 
Michael
 > Richardson, who recently joined this list is working on the related 
Internet
 > Draft(s).

 > I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will 
try
 > that tomorrow

 > I HAVE made certs with this value and I am displaying their content. But 
that
 > system is off right now. I will get one of the samples also tomorrow.

 > And yes, the industry does need to think some about this...

I suspect that the value: literal value 1231235959Z will simply come to
mean "the end of time", even after the year 10,000.  It has a well known
DER encoding, and one can memcmp() it.
Perhaps we will define an OID which means "no expiry", and start including
that.  I don't think the expiry date is an optional part.


Nice thought.  Not really an option.


I will also have example vouchers, voucher requests and ECDSA ("prime256v1")
certs with known private keys (so you can replicate my work) for the ANIMA
BRSKI document, perhaps next week.


Do we agree on the DN and SAN content per 802.1AR?  I am not entirely 
confident with my reading of what I contributed to!  Well at that time I 
left the cert profile to others.  I can send you a whole pki tree zipped 
up.  Do you have any 'live' specimens?




I'd rather publish Curve25519/EdDSA examples, but it's too bleeding edge for 
the moment.


We wait until 1.1.1 ships.  But MAYBE we should be doing builds and 
testing now instead of after it ships...



--
]   Never tell me the odds! | ipv6 mesh networks [


Odds are it won't make a difference.

Bob

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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Erwann Abalea via openssl-users]

> Le 13 sept. 2017 à 17:08, Michael Wojcik  a 
> écrit :
> 
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Michael Richardson
>> Sent: Wednesday, September 13, 2017 09:32
>> 
>> I suspect that the value: literal value 1231235959Z will simply come to
>> mean "the end of time", even after the year 10,000.  It has a well known
>> DER encoding, and one can memcmp() it.
> 
> Personally, I'm really hoping we're not still using ASN.1 in the year 1.

Why not? ;)

X.680 relies in ISO8601 for the date/time definitions. GeneralizedTime uses the 
Basic format from ISO8601 for the date (year on 4 digits, month on 2 starting 
with 01, day on 2 starting with 01), liberal time of day (minutes and/or 
seconds can be omitted, optional fraction of second/minute/hour depending on 
what is included), and a timezone from -15h to +15h with a one hour or one 
minute accuracy, or Z for UTC.

BER accepts pretty much everything from this definition, DER has a few 
restrictions:
 - in ISO8601, there are 2 different midnights (00:00:00 and 24:00:00), the DER 
encoding requires such date/time to be transformed into 00:00:00 the day after
 - DER only accepts the « Z » timezone and not the +/-HH(MM) variant
 - DER requires the minutes and seconds to be present in the time of day, and 
no fraction of a second

In theory, the very last date/time expressed in ASN.1 is 123124+1500, 
and it would be valid if expressed in BER. In DER, the very last date/time 
would have been 1231235960Z (in case a positive leap second gets inserted 
that day), but something else was preferred. It’s still possible that there’s a 
negative leap second happening at that exact day, removing second 59 completely.
Just think of this as a magical value.

Cordialement,
Erwann Abalea

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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

On 09/13/2017 09:39 AM, Salz, Rich via openssl-users wrote:

An X509v3 certificate has “notBefore” and “notAfter” fields.  If either of 
those is not present, then it is not an X509v3 certificate.  The time marked by 
those fields is the validity period.

If you want “never expires” X509v3 certificates, the best you can do it put a 
very large value in the notAfter field.  Some software may have issues around 
32bit representation of classic Unix time_t and therefore have problems with 
times greater than 2038; OpenSSL does not have those problems.

The OpenSSL command-line tools do not handle every possible corner case, 
including the ability to reasonably set dates that more than 7,500 years in the 
future.  You will have to modify the source.


It handles notAfter past 2038 (25*365 days from today):

   openssl req -config $dir/openssl-root.cnf\
-set_serial 0x$(openssl rand -hex $sn)\
-keyform $format -outform $format\
-key $dir/private/ca.key.$format -subj "$DN"\
-new -x509 -days 9125 -sha256 -extensions v3_ca\
-out $dir/certs/ca.cert.$format

   openssl x509 -inform $format -in $dir/certs/ca.cert.$format\
-text -noout

...
Validity
Not Before: Sep 13 17:09:50 2017 GMT
Not After : Sep  7 17:09:50 2042 GMT
...

I create 802.1AR cert with:

default_enddate   = 1231235959Z # per IEEE 802.1AR

in the config:

...
Validity
Not Before: Sep  7 04:43:27 2017 GMT
Not After : Dec 31 23:59:59  GMT
...


So it seems you can create things like signing certs with enddates out 
beyond 2038 and you can create EE certs with 'end of time' enddates.


The rest is up to the software that uses these certs...

Bob

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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Michael Richardson
> Sent: Wednesday, September 13, 2017 09:32
>
> I suspect that the value: literal value 1231235959Z will simply come to
> mean "the end of time", even after the year 10,000.  It has a well known
> DER encoding, and one can memcmp() it.

Personally, I'm really hoping we're not still using ASN.1 in the year 1.

But I'll put something on my calendar for the year  to remediate any 
possible issues in my software around this issue.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Salz, Rich via openssl-users]

An X509v3 certificate has “notBefore” and “notAfter” fields.  If either of 
those is not present, then it is not an X509v3 certificate.  The time marked by 
those fields is the validity period.

If you want “never expires” X509v3 certificates, the best you can do it put a 
very large value in the notAfter field.  Some software may have issues around 
32bit representation of classic Unix time_t and therefore have problems with 
times greater than 2038; OpenSSL does not have those problems.

The OpenSSL command-line tools do not handle every possible corner case, 
including the ability to reasonably set dates that more than 7,500 years in the 
future.  You will have to modify the source.


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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Michael Richardson]

Robert Moskowitz  wrote:
> The devices never test out the lifetime of their certs. That is up to

Exactly...
(Do you think about the MacGyver/StarTrek/A-Team/Leverage/MissionImpossible
plot line that goes along with each engineering decision?...)

> validating servers. And the iDevID is not really intended for operational
> use. Rather it is the security bootstrap for the lDevID. See the work 
being
> done in the ANIMA workgroup as an example of what to do with this. Michael
> Richardson, who recently joined this list is working on the related 
Internet
> Draft(s).

> I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will 
try
> that tomorrow

> I HAVE made certs with this value and I am displaying their content. But 
that
> system is off right now. I will get one of the samples also tomorrow.

> And yes, the industry does need to think some about this...

I suspect that the value: literal value 1231235959Z will simply come to
mean "the end of time", even after the year 10,000.  It has a well known
DER encoding, and one can memcmp() it.
Perhaps we will define an OID which means "no expiry", and start including
that.  I don't think the expiry date is an optional part.

I will also have example vouchers, voucher requests and ECDSA ("prime256v1")
certs with known private keys (so you can replicate my work) for the ANIMA
BRSKI document, perhaps next week.  I'd rather publish Curve25519/EdDSA
examples, but it's too bleeding edge for the moment.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Alejandro Pulido]

Hello!


Thanks for the response.

I was thinking of setting the duration fo the certificate to infinite,

i.e. the Validity period set to infinite.

Because in the information I have, the only possibility is to set the duration 
(in days) with the command, but the command doesn't allow to put other value 
rather an integer.


Thanks again



Alejandro J Pulido Duque

De: Robert Moskowitz 
Enviado: martes, 12 de septiembre de 2017 14:30:20
Para: openssl-users@openssl.org; Alejandro Pulido
Asunto: Re: [openssl-users] Doubt regarding O-SSL and setting the duration of 
certificates

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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

The devices never test out the lifetime of their certs.  That is up to 
the validating servers.  And the iDevID is not really intended for 
operational use.  Rather it is the security bootstrap for the lDevID.  
See the work being done in the ANIMA workgroup as an example of what to 
do with this.  Michael Richardson, who recently joined this list is 
working on the related Internet Draft(s).


I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will 
try that tomorrow


I HAVE made certs with this value and I am displaying their content.  
But that system is off right now.  I will get one of the samples also 
tomorrow.


And yes, the industry does need to think some about this...

On 09/12/2017 06:51 PM, Frank Migge wrote:

This is an interesting statement.

>> should use the GeneralizedTime value 1231235959Z (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 
MMDDHHmmssZ.


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 1231235959Z (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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Frank Migge]

This is an interesting statement.

>> should use the GeneralizedTime value 1231235959Z (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
> MMDDHHmmssZ.
>
> 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 1231235959Z (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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

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


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 1231235959Z (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:


Hello!


Thanks for the response.

I was thinking of setting the duration fo the certificate to infinite,

i.e. the Validity period set to infinite.

Because in the information I have, the only possibility is to set the 
duration (in days) with the command, but the command doesn't allow to 
put other value rather an integer.



Thanks again



*/Alejandro J Pulido Duque/*

*De:* Robert Moskowitz 
*Enviado:* martes, 12 de septiembre de 2017 14:30:20
*Para:* openssl-users@openssl.org; Alejandro Pulido
*Asunto:* Re: [openssl-users] Doubt regarding O-SSL and setting the 
duration of certificates

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:

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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

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:

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

[openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Alejandro Pulido]

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