Subject: Can't find info on certificate validity dates

From: Aram Perez <[email-masked]>
Date: Thu, 11 Aug 2005 16:58:57 -0700

Hi Folks,

Is there an RFC that talks about the validity dates on CA  
certificates and the validity dates for the certificates it (the CA)  
issues? For example, if a "conformant" CA certificate has a notAfter  
date of Dec. 31, 2005, should it issue certificates that have a  
notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
couldn't find anything related to my question. The cert path  
validation algorithm of 3280 only mentions that the current time be  
within the validity dates of the cert being processed.

Thanks,
Aram Perez

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Aug 2005 13:57:06 -0400

It is best if all of the certificates that will be validated by a given CA 
certificate have a notAfter data that is earlier (or the same) as the the 
notAfter date in the CA certificate.

If the CA certificate is renewed (the same subject name and the same public 
key are used with a different validity period), it is possible to avoid 
this dependence.  However, I believe that most CAs will change their key 
pair when a new certificate is needed.

Russ

---

From: Joel Rees <[email-masked]>
Date: Tue, 23 Aug 2005 14:49:37 +0900

I'm a little late here, but I'd like to check on this --

On 平成 17/08/18, at 2:57, Russ Housley wrote:

>
> It is best if all of the certificates that will be validated by a  
> given CA certificate have a notAfter data that is earlier (or the  
> same) as the the notAfter date in the CA certificate.
>
> If the CA certificate is renewed (the same subject name and the  
> same public key are used with a different validity period), it is  
> possible to avoid this dependence.  However, I believe that most  
> CAs will change their key pair when a new certificate is needed.
>
> Russ
>

Would there be problems with using overlapping certificates even when  
the key doesn't change?

I'm inclined to think the key should change anyway, to limit the  
scope of compromise, but would there be anything specifically wrong  
with issuing the initial certificate for, say, two years, with a  
policy that indicates that it will only be used for signing during  
the first year, etc., then issuing a new certificate on the same key  
at the end of each year until whoever makes the decision thinks it  
would be good to roll the key over?

I'm thinking a rollover pair in such a setup would be one certificate  
more than necessary, but then superfluity is not always evil.

My intent with such a plan would be to push period refresh. I'm not  
inclined to trust machines for very long periods of time.

How far out in left field is this idea?

--
Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Aug 2005 09:47:21 -0400

Joel:

Do not expect a relying party to recognize a certificate policy OID and 
take any special actions to enforce a policy like: "certificate validity 
period is two years, but it should only be used for signing during the 
first."  There is a certificate extension (private key usage period) for 
this purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
published in 1999) to discourage its use.

 > Would there be problems with using overlapping certificates even when

Did you mean to say: "... even when the key does change?"

You encourage key change over to limit the scope of compromise.  I agree 
with this suggestion.

Russ

At 01:49 AM 8/23/2005, Joel Rees wrote:

>On å¹³æˆ 17/08/18, at 2:57, Russ Housley wrote:
>
>>
>digitcom, inc.   æ ªå¼ä¼šç¤¾ãƒ‡ã‚¸ã‚³ãƒ

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 24 Aug 2005 18:00:06 +0200

Russ Housley wrote:
> Do not expect a relying party to recognize a certificate policy OID 
> and take any special actions to enforce a policy like: "certificate 
> validity period is two years, but it should only be used for signing 
> during the first."
But the certificate policy solution seems quite adequate in that use 
case where we more want to simply inform that the key won't be used 
anymore to sign certificate after the initial period than really want to 
enforce the non-signing rule through that extension.
>   There is a certificate extension (private key usage period) for this 
> purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
I think is missing here the fact that this point has been rediscussed in 
the last IETF meeting, with the suggestion that there might be valid 
cases of using that extension, and AFAIR the resolution is that we'll 
remove from RFC3280bis the paragraph discouraging its use.
>> Would there be problems with using overlapping certificates even when
Nope. Many people are doing that. But they usually more extend the 
notAfter date, and keep the same notBefore.
>> more than necessary, but then superfluity is not always evil.
That the only way to handle it that situation on long term you will 
after the initial run almost always have two valid certificate at any 
given time.
But when you only change the validity period you don't really need the 
first anymore after you create the new one.

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Aug 2005 14:22:55 -0400

My recollection of that discussion is that we will remove all discussion of 
the private key validity period extension altogether in RFC 3280bis.  It 
was pointed out that this is the only extension for which use is actively 
discouraged.  There are many other extensions that have been defined in 
subsequent editions of X.509 for which there is no discussion at all.  It 
was agreed to remove discussion of this one rather than adding discussion 
of all of the new ones.

Russ

At 12:00 PM 8/24/2005, Jean-Marc Desperrier wrote:
>the last IETF meeting, with the suggestion that there might be valid cases 
>of using that extension, and AFAIR the resolution is that we'll remove 
>from RFC3280bis the paragraph discouraging its use.