Subject: Path validation decision based on notAfter

From: [email-masked]
Date: Fri, 7 Feb 2003 13:00:30 +0100

Is it legal for a certificate to have a longer validity period than its CA
certificate? In other words: Should not a path validation algorithm
(according to RFC 3280) reject an alleged CA certificate if its notAfter
value is lower than the one in the certificate (supposedly) issued by it?
The standard does not say a word about it, but I think it is quite
reasonable to include this condition in the path validation algorithm.
Unless I am missing something and there are cases (cross-certification
maybe?) where it is necessary to allow such certification chains.

Luciano Medina

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Feb 2003 14:20:45 +0100

Luciano,

> The standard does not say a word about it,

Extract from RFC 3280:

6.1.3  Basic Certificate Processing

    The basic path processing actions to be performed for certificate i
    (for all i in [1..n]) are listed below.

       (a)  Verify the basic certificate information.  The certificate
       MUST satisfy each of the following:

  (snip)

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

Denis

> but I think it is quite

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 Feb 2003 09:33:05 -0500

This does not address Luciano's question. Luciano is asking
(I think) whether it's OK to have an end-entity certificate
whose notAfter date is January 1, 2005 if the preceding CA
certificate has a notAfter date of June 30, 2004 (for example).
Assume that the current date is February 6, 2003.

The answer is that this is fine. The validation algorithm
does not prohibit it and that's a good thing. It's not
unusual for the CA that issues an end-entity certificate
to have several CA certificates, with varying validity periods.
Cross-certificates with that CA as the subject, for instance.

As long as all of the certificates in a path have a validity
period that includes the current time, there's no problem.

Steve Hanna

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Feb 2003 16:04:26 +0100

Steve,

> (I think) whether it's OK to have an end-entity certificate

Luciano was not raising that question. He was not speaking
specifically of an end-entity certificate.

> does not prohibit it and that's a good thing. 

Now, to answer your question, this is not fine if you assume that the 
current date is November 30, 2004. So it is useless (but not prohibited) to 
place such a date in an end-entity certificate.

Denis

 > It's not

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 Feb 2003 10:33:33 -0500

> specifically of an end-entity certificate.

I'll leave it to Luciano to explain what his question was.

My answer applies equally well if the second certificate
in the path is a CA certificate. It's just easier to describe
if one is a CA certificate and the other is an end-entity
certificate.

> place such a date in an end-entity certificate.

Certainly, that path would not be valid on November 30, 2004.
But the path is valid on February 6, 2003 (and for more than
a year after that).

The CA in question may have several CA certificates issued for
it (cross-certificates from various parties). Some of these
CA certificates may only be valid for a few more months. But
this should not prevent the CA from issuing an end-entity
certificate with a validity period that extends far into the
future. The cross-certificates may be reissued with a later
notAfter date. But even if they aren't, relying parties that
don't need the expired cross-certificates will still be able to
validate the end-entity certificate for a long time. RPs that
have the CA in question as their trust anchor, for instance.
Or RPs that use other cross-certificates to reach that CA.

So it is not useless for a CA to issue an end-entity cert
whose validity period extends beyond the validity period
of a CA certificate whose subject is that CA.

Thanks,

Steve

---

From: "Joel S. Kazin" <[email-masked]>
Date: Thu, 06 Feb 2003 10:41:11 -0500

The RFC may be ambiguous.

If the CA certificate expires next week and the end entity certificate
expires a year from now and I check the certificate today it will pass.
However, if I check it in a month the certificate will fail.

If the CA certificate is renewed tomorrow and I check the certificate
a month from now it will pass.

Note that if the CA re-keys its signing certificate the EE certificate will
not pass if it is checked in a month.

The reason that I and others would reject such a certificate is that the
CA is making a statement about actions it may take in the future,
re-certifying an existing key as opposed to a current or past action.

Neither Entrust nor Microsoft will issue such a problematic certificate.

>>maybe?) where it is necessary to allow such certification chains.

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[email-masked]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  +1 914-769-8780
Mobile  +1 914-645-5598

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 Feb 2003 11:43:42 -0500

I see no ambiguity in the RFC. Could you be more
explicit in explaining what's ambiguous?

Also, I don't think Entrust or Microsoft can avoid issuing
such a "problematic" certificate. The CA that issues the
end-entity certificate (let's call it Andrew) may not know
about all CA certificates that have Andrew as the subject.
Even if the CA somehow knew of all such CA certificates
at the time it issued the end-entity certificate, it couldn't
prevent another CA from later issuing a short-lived CA
certificate with Andrew as the subject.

So Andrew cannot prevent this situation from happening.
And, as I described in my earlier email, the situation
is perfectly fine. As long as all certs in the path are
valid, there should be no need for each cert to have
an earlier notAfter date than the preceding cert. If
we add such a requirement, what's next? Will we require
the subject names to be in alphabetical order? ;-)

Steve