Subject: Re: Path validation decision based on notAfter

From: [email-masked]
Date: Fri, 7 Feb 2003 16:53:48 +0100

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

Yes, Steve, my question was what you understood. Your answer seems
reasonable, and actually all the trouble arised when I started to play
around with cross-certificates.
Thanks to all who replied.

Luciano Medina

                      Steve Hanna                                                                                                      
                      <steve.hanna@sun.        To:       Denis Pinkas <[email-masked]>                                          
                      com>                     cc:       [email-masked], [email-masked]                               
                                               Subject:  Re: Path validation decision based on notAfter                                
                      06/02/2003 16:33                                                                                                 

Denis Pinkas wrote:
> > This does not address Luciano's question. Luciano is asking
> > (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.

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.

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

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: "Trevor Freeman" <[email-masked]>
Date: Thu, 6 Feb 2003 22:32:38 -0800

Joel,
The motivation why we chose not to issue such a certificate has nothing
with path validation. As Steve rightly points out, a CA may have been
certified several times resulting in multiple paths for any certificate
it issues. Each path can have different validity ranges, but all that
counts is each certificate valid at the time you validate the
certificate.
Our decision to limit the CA to issuing certificate within the lifetime
of its own certificate is purely to simplify the certificate lifecycle
management issue by ensuring that if a CAs certificate expires, them all
certificate issued by that CA have also expired.
Trevor

-----Original Message-----
From: Joel S. Kazin [mailto:[email-masked]] 
Sent: Thursday, February 06, 2003 7:41 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Path validation decision based on notAfter

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.

At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote:

>Luciano,
>
>>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,
>
>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
>>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
>
>

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: [email-masked] (Peter Gutmann)
Date: Mon, 10 Feb 2003 16:55:29 +1300

Steve Hanna <[email-masked]> writes:

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

When I looked at this, it seemed like a coin-flip decision: There was no clear
opinion on the list as to which was better.  I asked a few users, and they
couldn't identify any strong reason to do it one way or the other either.  In
the end I decided to do validity-period nesting because (again based on user
feedback) it would cause less confusion and make cert management easier if the
EE validity was constrained to that of the CA cert that issued it - you don't
get users confused over why their cert has expired even though the validity
period shows it hasn't, and you know that all the EE certs will automatically
roll over once the CA cert rolls over.

Peter.