Subject: RFC3280bis: NotAfter 99991231235959Z

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 09:55:47 -0500

I would like to add some text about certificates that are not 
intended to expire.  I propose the following paragraph.

In some situations, devices are given permanent certificates.  For 
example, a device could be issued a certificate that binds its model 
and serial number to its public key.  Such a certificate is intended 
to be used for the entire lifetime of the device.  It indicate the 
permanent nature of such a certificate, the notAfter SHOULD be 
assigned the GeneralizedTime value of 99991231235959Z.

Any concerns?

Russ

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 15 Nov 2006 17:39:13 +0100

Some utility written in C language time (The time function returns the number of seconds elapsed since midnight (00:00:00), January 1, 1970,) will crash. ;-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, November 15, 2006 3:56 PM
To: [email-masked]
Subject: RFC3280bis: NotAfter 99991231235959Z

Any concerns?

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Nov 2006 16:50:00 +0000

Russ Housley wrote:
> 
> I would like to add some text about certificates that are not intended 
> to expire.  I propose the following paragraph.
> 
> example, a device could be issued a certificate that binds its model and 
> serial number to its public key.  Such a certificate is intended to be 
> used for the entire lifetime of the device.  It indicate the permanent 
> nature of such a certificate, the notAfter SHOULD be assigned the 
> GeneralizedTime value of 99991231235959Z.
> 
> Any concerns?

I like the idea, but according to my local folders, when we discussed
this off list before and came up with a variant wording which I think
was:

"In some situations, devices are given certificates for which no good
expiration date can be assigned.  For example, a device could be issued
a certificate that binds its model and serial number to its public key;
such a certificate is intended to be used for the entire lifetime of the 
device.

To indicate that a certificate has no well defined expiration date, the
notAfter MUST be assigned the GeneralizedTime value of 99991231235959Z."

There was some discussion about whether that last MUST is right or
not, (and I don't care myself), but I guess we never did put any of
it into the draft,

Cheers
Stephen.

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 12:04:47 -0500

I am fine with the alternate wording.  I want the 99991231235959Z 
suggestion in the document.

Russ

At 11:50 AM 11/15/2006, Stephen Farrell wrote:

>>example, a device could be issued a certificate that binds its 
>>model and serial number to its public key.  Such a certificate is 
>>intended to be used for the entire lifetime of the device.  It 
>>indicate the permanent nature of such a certificate, the notAfter 
>>SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
>>Any concerns?
>
>such a certificate is intended to be used for the entire lifetime of 
>the device.
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 15:01:48 -0500

I would hope that the time function would not be called with this 
input.  The point is to flag the value as not expiring.

Russ

At 11:39 AM 11/15/2006, Peter Rybar wrote:
>Some utility written in C language time (The time function returns 
>the number of seconds elapsed since midnight (00:00:00), January 1, 
>1970,) will crash. ;-)
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley

---

From: Max Pritikin <[email-masked]>
Date: Wed, 15 Nov 2006 16:54:28 -0600

I think this implies that "6.1.3  Basic Certificate Processing" text:

          (2)  The certificate validity period includes the current  
time.

will need to be modified to read something like:

	(2) The certificate or any prior certificate validity period is  
either equal to GeneralizedTime value 99991231235959Z or includes the  
current time.

This indicating that the certificate chain validation no longer  
includes checking the current time against the validity period for  
these values. Alternatively every certificate in the chain could be  
required to use this large GeneralizedTime value.

Thanks,

	- max

On Nov 15, 2006, at 2:01 PM, Russ Housley wrote:

>> the number of seconds elapsed since midnight (00:00:00), January  
>> 1, 1970,) will crash. ;-)
>>
>> From: [email-masked] [mailto:owner-ietf- 
>> [email-masked]] On Behalf Of Russ Housley