Subject: Re: [pkix] Same notAfter date for CA and EE certificate

From: Tom Gindin <[email-masked]>
Date: Tue, 1 Mar 2011 08:35:58 -0500

Jim:

        How long before is "well before"?  I doubt that it's wise to have 
any EE certificates whose expiration is less than one hour before the CA's 
own, but multiple weeks may not be necessary.  In any case, it makes more 
sense to provide a guideline for "minimum time by which certificate 
notAfter should precede issuer notAfter" than "minimum time by which 
certificate notBefore should precede issuer notAfter".

                Tom Gindin

From:
"Jim Schaad" <[email-masked]>
To:
"'IETF PKIX'" <[email-masked]>
Date:
02/28/2011 06:19 PM
Subject:
[pkix] Same notAfter date for CA and EE certificate
Sent by:
[email-masked]

When reading the thread on how to issue the last CRL, the following text
popped into my head

An entry is added to the CRL as part of the next update
   following notification of revocation.  An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

The problem is that the MUST NOT cannot be followed if the EE and the CA
have the same expiration date.  Any CRL issued after the expiration date 
of
the revoked EE certificate would be after the validity period of the CA
certificate and thus not acceptable.

This is a potential issue for certificates that are issued at the last
second, and is more of an issue for historical checking of revocations.
I.e. you cannot do a query for a CRL that was issued delta time after a
signature operation.

Yet one more reason to recommend that a CA stop issuing certificates well
before its own expiration I guess.  Does anybody feel that the text should
be updated since the MUST NOT cannot possibly be satisfied.

Jim

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 1 Mar 2011 09:04:52 -0500

The MUST NOT is trivially satisfied - the entry is never removed from
the CRL because it was never added "as part of next update following
notification".  And the case of an EE cert being issued at the last
second with the same notAfter as the CA is (as far as I can tell) not
worth worrying about.

If the EE cert is issued 6 hours before expiration and immediately
reported for revocation, and the CA has 24 hour CRLs (the last of which
was issued 1 hour before issuance of the EE cert), then expiration will
take care of invalidating the cert 17 hours quicker than the
(nonexistent) next CRL could have.

If the last CRL is issued 1 hour after issuance of the EE cert, it will
revoke that cert and the entry will never be removed, also trivially
satisfying the MUST NOT.

Did you have a sequence of events where the MUST NOT text would be a
problem?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jim Schaad
Sent: Monday, February 28, 2011 6:39 PM
To: 'IETF PKIX'
Subject: [pkix] Same notAfter date for CA and EE certificate

Yet one more reason to recommend that a CA stop issuing certificates
well
before its own expiration I guess.  Does anybody feel that the text
should
be updated since the MUST NOT cannot possibly be satisfied.

Jim

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 06 Mar 2011 12:50:56 +0100

Jim,

A CA does not have an expriation date, only CA certificates do.
I guess that the result of this is that a standards compliant CA can't die
before it has fulfilled this requirement.

I think the text is OK.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 7 Mar 2011 11:58:22 +0100

Stefan,
Two points:
a) When a CA is using self-signed certificates (most of the cases), the root key has an expiration date. 
b) The current sentence should be changed. Change proposal (strawman proposal):
"Unless the CA stops business at the end of the validity period of its current
 CA key and the validity of an issued certificate expires exactly at the same time, 
an entry MUST NOT be removed from the CRL until it appears on one regularly 
scheduled CRL issued  beyond the revoked certificate's validity period. In order 
to avoid to take into account the limitation, it is RECOMMENDED that a CA stops 
issuing certificates at least a few days before its own expiration".
Denis
----- Message reçu ----- 
De : pkix-bounces 
À : Jim Schaad,'IETF PKIX' 
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate

Jim,

I think the text is OK.

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 08:04:16 -0500

The requirement for appearing on "one CRL after certificate expiry" is incorrect and there is no need for it.

It should be replaced with that a certificate must not be removed from CRL until after it appear on at least one CRL".

(This is useful in forensic analysis in case of a dispute when archived CRL (vice CA database) is used.

The requirement to remove the certificate from CRL after certificate expiry should remain, but with the above re-stated caveat.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, March 07, 2011 5:58 AM
To: Jim Schaad (IETF); pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Stefan,

Two points:

Denis
----- Message reçu -----
De : pkix-bounces<mailto%20:[email-masked]>
À : Jim Schaad,'IETF PKIX'<mailto%20:[email-masked],[email-masked]>
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate

Jim,

I think the text is OK.

/Stefan

On 11-03-01 12:39 AM, "Jim Schaad" <[email-masked]<mailto:[email-masked]>> wrote:

>[email-masked]<mailto:[email-masked]>

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 7 Mar 2011 14:23:02 +0100

Santosh,

See comments in lines.

----- Message reçu ----- 
De : Santosh Chokhani 
À : [email-masked],Jim Schaad (IETF),pkix 
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

The requirement for appearing on “one CRL after certificate expiry” is incorrect and there is no need for it.

It should be replaced with that a certificate must not be removed from CRL until after it appear on at least one CRL”.
I read this sentence three times, but unfortunately I can't understand what you mean this sentence. 

The requirement to remove the certificate from CRL after certificate expiry should remain, but with the above re-stated caveat.
I am not sure I understand what you mean, but since it is time now to propose some text to fix the issue (and close this thread), 
why don't you post your own strawman proposal ?

Denis

Stefan,
Two points:
----- Message reçu ----- 
De : pkix-bounces 
À : Jim Schaad,'IETF PKIX' 
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate

Jim,

I think the text is OK.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 07 Mar 2011 16:07:47 +0100

Denis,

Your proposed text is very confusing and provides requirements out of
context (e.g. Requirements on when a CA should stop issuing certificates
does not belong here and the recommendation is wrong. A CA does not expire
and even if it would, what purpose is there to issue a new cert a few days
before the CA is shut down if that certificate is intended to be valid for
e.g. one year?).

What the text addresses is:

If a revoked certificate expires at time T and there is one CRL issued at
T-x and another issued at T+y, then revocation of that certificate must also
be present in the T+y CRL. The reason seems quite obvious to me.

I still find the current text accurate.

/Stefan

From:  Denis Pinkas <[email-masked]>
Reply-To:  <[email-masked]>
Date:  Mon, 7 Mar 2011 14:23:02 +0100
To:  pkix <[email-masked]>
Subject:  Re: [pkix] Same notAfter date for CA and EE certificate

> Santosh,
>  
> See comments in lines.
>  
>>  
>> -----  Message reçu -----
>>  
>> De  : Santosh Chokhani <mailto :[email-masked]>
>>  
>> À  : [email-masked],Jim  Schaad (IETF),pkix <mailto
>> :[email-masked],[email-masked],[email-masked]>
>>  
>> The  requirement for appearing on one CRL after certificate expiry is
>> incorrect  and there is no need for it.
>>  
>>  
>> It  should be replaced with that a certificate must not be removed from CRL
>> until  after it appear on at least one CRL.
>> The  requirement to remove the certificate from CRL after certificate expiry
>> should  remain, but with the above re-stated caveat.
> I am not sure I understand what you mean, but since it is time now to propose
> some text to fix the issue (and close this thread),
>> Denis  Pinkas
>>> De  : pkix-bounces <mailto%20:[email-masked]>
>>>  
>>>  
>>> 
>>> <mailto%20:[email-masked],[email-masked]>
>>>  
>>>  
>>> 
>>> On 11-03-01 12:39 AM, "Jim Schaad" <[email-masked]
>>> <mailto:[email-masked]> >  wrote:
>>> 
>>>> >[email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Mar 2011 10:18:53 -0500

Santosh:

I think that "incorrect" is a bit strong.

I think we all agree on the concept here, but I have concerns with your wording.

The case that needs to be addressed is the expiration of a certificate between the time that it is revoked and the time that it appears on the CRL.  This leads to your "at least one CRL" wording.  The point is making sure that it appears at least once, so "must not be removed" does not cover that situation.

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 10:25:07 -0500

Russ,

It needs to appear on only one CRL that is published and archived.

It need not appear on at least one CRL after the certificate expiry as 5280 says.

Look for a mathematical explanation in response to Denis, which will take some time to compose.

From: Russ Housley [mailto:[email-masked]]
Sent: Monday, March 07, 2011 10:19 AM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Santosh:

Russ

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, March 07, 2011 5:58 AM
To: Jim Schaad (IETF); pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Stefan,

Two points:

Denis
----- Message reçu -----
De : pkix-bounces<x-msg://249/mailto%20:[email-masked]>
À : Jim Schaad,'IETF PKIX'<x-msg://249/mailto%20:[email-masked],[email-masked]>
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate

Jim,

I think the text is OK.

/Stefan

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 10:41:36 -0500

Denis,

It is saying the following:

Let us say a certificate is revoked at time x.  Let us say that the next CRL after x is issued at time x + a.  Let us say that the certificate expires at x + a + b and the CRL is issued again at x + a + b + c.

In this scenario, the certificate needs to appear only on the first CRL.  5280 requires it to appear on both.

Taking another scenario,

Let us say a certificate is revoked at time y.  Let us say that the certificate expires at y + p.  Let us say that the next CRL after y is issued at time y + p + r.  Both 5280 and what the requirement ought to be, will require the certificate to appear on this CRL.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, March 07, 2011 8:23 AM
To: pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Santosh,

See comments in lines.

----- Message reçu -----
De : Santosh Chokhani<mailto%20:[email-masked]>
À : [email-masked],Jim Schaad (IETF),pkix<mailto%20:[email-masked],[email-masked],[email-masked]>
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

Denis

Stefan,

Two points:

Denis
----- Message reçu -----
De : pkix-bounces<mailto%20:[email-masked]>
À : Jim Schaad,'IETF PKIX'<mailto%20:[email-masked],[email-masked]>
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 07 Mar 2011 16:57:16 +0100

Santosh,

In your first example, the certificate must be listed in both CRLs.

Lets say a signature is received and validated at x+a+b+c+20 minutes. The
signing time is after x but before x+a+b.
The validator obtains the last CRL (x+a+b+c) and determines that it is the
most recent CRL that covers time within the certificates validity period
(x+a to x+a+b+c).
The certificate does not appear on this CRL and is accepted as valid.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Mon, 7 Mar 2011 10:41:36 -0500
To:  "[email-masked]" <[email-masked]>, pkix <[email-masked]>
Subject:  Re: [pkix] Same notAfter date for CA and EE certificate

> Let us say a certificate is revoked at time x.  Let us say that the next CRL
> after x is issued at time x + a.  Let us say that the certificate expires at x
> + a + b and the CRL is issued again at x + a + b + c.
>  
> Let us say a certificate is revoked at time y.  Let us say that the
> certificate expires at y + p.  Let us say that the next CRL after y is issued
> at time y + p + r.  Both 5280 and what the requirement ought to be, will
> require the certificate to appear on this CRL.
>  
>  
> 
>> De : Santosh Chokhani <mailto%20:[email-masked]>
>> 
>> <mailto%20:[email-masked],[email-masked],[email-masked]>
>> 
>> The requirement for appearing on ³one CRL after certificate expiry² is
>> until after it appear on at least one CRL².
>>> À : Jim Schaad,'IETF PKIX' <mailto%20:[email-masked],[email-masked]>
>>>

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Mar 2011 10:58:07 -0500

Santosh:

You are correct that RFC 5280 requires the certificate to appear on both.  I recall the discussion was that it was better for the certificate to appear on one more CRL than absolutely necessary than for the certificate to not appear on any CRLs.  The wording is simple, and the extra burden is very minor.

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 10:59:05 -0500

Stefan,

The certificate has already expired.  You need other means such as LTANS to verify expired objects.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, March 07, 2011 10:57 AM
To: Santosh Chokhani; [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Santosh,

Lets say a signature is received and validated at x+a+b+c+20 minutes. The signing time is after x but before x+a+b.
The validator obtains the last CRL (x+a+b+c) and determines that it is the most recent CRL that covers time within the certificates validity period (x+a to x+a+b+c).
The certificate does not appear on this CRL and is accepted as valid.

/Stefan

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 Mar 2011 10:41:36 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Denis,

Taking another scenario,

Santosh,

See comments in lines.

----- Message reçu -----
De : Santosh Chokhani<mailto%20:[email-masked]>
À : [email-masked],Jim Schaad (IETF),pkix<mailto%20:[email-masked],[email-masked],[email-masked]>
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

Denis

Stefan,

Two points:

Denis
----- Message reçu -----
De : pkix-bounces<mailto%20:[email-masked]>
À : Jim Schaad,'IETF PKIX'<mailto%20:[email-masked],[email-masked]>
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________ pkix mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 11:00:44 -0500

Russ,

I agree on the burden part.

I was just addressing the issue some folks feel what if the CA does not issue a CRL after the subject certificate  expiry.  In that scenario, 5280 requirement imposes an undue burden.

From: Russ Housley [mailto:[email-masked]]
Sent: Monday, March 07, 2011 10:58 AM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Santosh:

Russ

Denis,

Taking another scenario,

Santosh,

See comments in lines.

----- Message reçu -----
De : Santosh Chokhani<x-msg://289/mailto%20:[email-masked]>
À : [email-masked],Jim Schaad (IETF),pkix<x-msg://289/mailto%20:[email-masked],[email-masked],[email-masked]>
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

Denis

Stefan,

Two points:

Denis
----- Message reçu -----
De : pkix-bounces<x-msg://289/mailto%20:[email-masked]>
À : Jim Schaad,'IETF PKIX'<x-msg://289/mailto%20:[email-masked],[email-masked]>
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 07 Mar 2011 17:50:46 +0100

A CRL covers events taken place from the last CRL until the current CRL. As
such it covers events within the validity of the certificates validity time.

We need simple generic algorithms. If the certificate is listed in your case
B, it should be listed in your case A, exactly as the standard currently
mandates.

It decreases the chance of error and malfunctioning applications.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Mon, 7 Mar 2011 10:59:05 -0500
To:  Stefan Santesson <[email-masked]>, "[email-masked]"
<[email-masked]>, pkix <[email-masked]>
Subject:  RE: [pkix] Same notAfter date for CA and EE certificate

> most recent CRL that covers time within the certificates validity period (x+a
> to x+a+b+c).
> 
>> after x is issued at time x + a.  Let us say that the certificate expires at
>> x + a + b and the CRL is issued again at x + a + b + c.
>>

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 12:16:57 -0500

Stefan,

An expired certificate does not have a definitive revocation information in it.

As you know X.509 and 5280 do not really have a concept of CRL issuance frequency either.

So, what you say is not particularly useful or actionable by PK enabled application.  Work it out for yourself.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, March 07, 2011 11:51 AM
To: Santosh Chokhani; [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

A CRL covers events taken place from the last CRL until the current CRL. As such it covers events within the validity of the certificates validity time.

We need simple generic algorithms. If the certificate is listed in your case B, it should be listed in your case A, exactly as the standard currently mandates.

/Stefan

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 Mar 2011 10:59:05 -0500
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Subject: RE: [pkix] Same notAfter date for CA and EE certificate

Stefan,

From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, March 07, 2011 10:57 AM
To: Santosh Chokhani; [email-masked]<mailto:[email-masked]>; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Santosh,

/Stefan

Denis,

Taking another scenario,

Santosh,

See comments in lines.

----- Message reçu -----
De : Santosh Chokhani<mailto%20:[email-masked]>
À : [email-masked],Jim Schaad (IETF),pkix<mailto%20:[email-masked],[email-masked],[email-masked]>
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

Denis

Stefan,

Two points:

Denis
----- Message reçu -----
De : pkix-bounces<mailto%20:[email-masked]>
À : Jim Schaad,'IETF PKIX'<mailto%20:[email-masked],[email-masked]>
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 07 Mar 2011 22:05:49 +0100

I still think the current text represent the least evil and most generic
approach that will cause the least problems.

Algorithm is darn simple.

   Revocation (oldCRL) {   // Create new CRL with all entries from old CRL
       newCRL = New CRL(oldCRL)
       newCRL.add(certificatesMarkedForRevocation)
       for (entry:allCRLEntries) {    // Cleanup
            If revokedCertExpiryDate > lastCRLIssueDate {
                                 // Keep CRL Entry
             } else {
                   newCRL.remove(entry)
             }
       Sign(newCRL)
    }

Done.

If I have to treat the case differently dependent on whether the
certificate has been on a CRL before or not. The algorithm for revocation
is getting more complicated as well as any code trying to understand the
information in the CRL.

Where is the benefit from making it more complicated?

/Stefan

Date:  Mon, 7 Mar 2011 12:16:57 -0500

>A CRL covers events taken place from the last CRL until the current CRL.
>As such it covers events within the validity of the certificates validity
>time.
>
> 
>
>We need simple generic algorithms. If the certificate is listed in your
>case B, it should be listed in your case A, exactly as the standard
>currently mandates.
>
> 
>
>>Lets say a signature is received and validated at x+a+b+c+20 minutes.
>>The signing time is after x but before x+a+b.
>>
>>The validator obtains the last CRL (x+a+b+c) and determines that it is
>>the most recent CRL that covers time within the certificates validity
>>period (x+a to x+a+b+c).
>>
>>>Let us say a certificate is revoked at time x.  Let us say that the
>>>next CRL after x is issued at time x + a.  Let us say that the
>>>certificate expires at x + a + b and the CRL is issued again at x + a +
>>>b + c.
>>> 
>>>certificate expires at y + p.  Let us say that the next CRL after y is
>>>issued at time y + p + r.  Both 5280 and what the requirement ought to
>>>be, will require the certificate to appear on this CRL.
>>> 
>>> 
>>>It should be replaced with that a certificate must not be removed from
>>>CRL until after it appear on at least one CRL².
>>>
>>>
>>>The requirement to remove the certificate from CRL after certificate
>>>expiry should remain, but with the above re-stated caveat.
>>>
>>>
>>>I am not sure I understand what you mean, but since it is time now to
>>>propose some text to fix the issue (and close this thread),
>>><mailto:[email-masked]>> wrote:
>>>

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 7 Mar 2011 16:12:51 -0500

I do not think the other algorithm is any harder.

You clean the list and then add new revocations to it.

It is a very simple programming logic.

I am trying to help who worry that they will not be issuing a CRL after certificate expiry.

The current language is simply unnecessary.  It is a bad idea to over-specify a standard when the basic requirement is equally easy to express and implement.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 4:06 PM
To: Santosh Chokhani; [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Done.

/Stefan

---

From: Tom Gindin <[email-masked]>
Date: Mon, 7 Mar 2011 22:59:14 -0500

Santosh:

        From the standpoint of a typical archiving RP which polls every N 
hours, the measurement which determines whether the revocation's 
publication is useful to the RP is the number of polls which occur while 
the current published CRL contains the certificate of interest.  The 
"publish once after certificate expiration" requirement seems evidently 
intended for archiving RP's, since only retrospective verifications are 
concerned with whether an expired certificate was revoked before its 
expiration.
        I think that this suggest that best practice is to define a 
minimum amount of time between expiration and removal from the CRL, at 
least as a SHOULD, and then an archiving RP should have a polling interval 
of less than half that.

                Tom Gindin

From:
Santosh Chokhani <[email-masked]>
To:
"[email-masked]" <[email-masked]>, pkix <[email-masked]>
Date:
03/07/2011 10:47 AM
Subject:
Re: [pkix] Same notAfter date for CA and EE certificate
Sent by:
[email-masked]

Denis,

Let us say a certificate is revoked at time x.  Let us say that the next 
CRL after x is issued at time x + a.  Let us say that the certificate 
expires at x + a + b and the CRL is issued again at x + a + b + c.
 
In this scenario, the certificate needs to appear only on the first CRL.  
5280 requires it to appear on both.
 
Taking another scenario, 
 
Let us say a certificate is revoked at time y.  Let us say that the 
certificate expires at y + p.  Let us say that the next CRL after y is 
issued at time y + p + r.  Both 5280 and what the requirement ought to be, 
will require the certificate to appear on this CRL.

Santosh,
 
See comments in lines.
 
----- Message reçu ----- 
De : Santosh Chokhani 
À : [email-masked],Jim Schaad (IETF),pkix 
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate
 
The requirement for appearing on ?one CRL after certificate expiry? is 
incorrect and there is no need for it.
It should be replaced with that a certificate must not be removed from CRL 
until after it appear on at least one CRL?.
I read this sentence three times, but unfortunately I can't understand 
what you mean this sentence. 
(This is useful in forensic analysis in case of a dispute when archived 
CRL (vice CA database) is used.
The requirement to remove the certificate from CRL after certificate 
expiry should remain, but with the above re-stated caveat.
I am not sure I understand what you mean, but since it is time now to 
propose some text to fix the issue (and close this thread), 
why don't you post your own strawman proposal ?
 
Denis
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Denis Pinkas
Sent: Monday, March 07, 2011 5:58 AM
To: Jim Schaad (IETF); pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate
Stefan,
Two points:
a) When a CA is using self-signed certificates (most of the cases), the 
root key has an expiration date. 
b) The current sentence should be changed. Change proposal (strawman 
proposal):
"Unless the CA stops business at the end of the validity period of its 
current
CA key and the validity of an issued certificate expires exactly at the 
same time, 
an entry MUST NOT be removed from the CRL until it appears on one 
regularly 
scheduled CRL issued  beyond the revoked certificate's validity period. In 
order 
to avoid to take into account the limitation, it is RECOMMENDED that a CA 
stops 
issuing certificates at least a few days before its own expiration".
Denis
----- Message reçu ----- 
De : pkix-bounces 
À : Jim Schaad,'IETF PKIX' 
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 8 Mar 2011 07:08:47 -0500

Tom,

The standards do not support any of this.

Besides, the rule is very simple.  If the certificate is expired, you do not use it.  The rule is pretty invariant for encryption and on-line authentication.  For digital signature on an object, if you need to verify, other things such as trusted time stamp, past CRL, CRL that contains expired certificates, etc. come into play.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 10:59 PM
To: Santosh Chokhani
Cc: [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

        Santosh:

                Tom Gindin

From:

Denis,

 
 
Taking another scenario, 

 
Santosh,
 
See comments in lines.
 
----- Message reçu ----- 
De : Santosh Chokhani 
À : [email-masked],Jim Schaad (IETF),pkix 
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : Jim Schaad,'IETF PKIX' 
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 8 Mar 2011 09:28:50 -0500

How about new notation using absolute times (in increasing order)
instead of deltas:

Time: Event
----  -----
x:    Notice to revoke cert X is received  (Case 1 - user X)
a:    CRL A is issued with nextUpdate time c
y:    Notice to revoke cert Y is received  (Case 2 - user Y)
b:    Cert X and cert Y expire
c:    CRL C is issued if the CA cert is valid

An RP can ask either "is this cert valid at current time t (now)" or
"was this cert valid at some time s in the past (s<t)".  The question
can be asked at any time t<=x, x<t<=a, a<t<=y, y<t<=b, b<t<=c, or c<t.

For Stefan's question regarding Case 1, c<t and the signature time is s
where x<s<b.  To retroactively validate a signature, the RP needs the
first CRL after the signature (but it may optionally consider additional
CRLs).

For x<s<a, the RP needs CRL A.  For a<s<b, the RP needs CRL C if it
exists.

So for:
 1) retroactive validation of
 2) a previously revoked cert for
 3) a signature generated after the last CRL issued prior to EE cert
expiration,

then Stefan is correct - the RP would normally need a CRL issued after
EE cert expiration.

But if the CA stupidly created EE certs that expire at the same time b
as the CA cert, then Santosh is correct.  CRL C cannot be created
because there is no valid key to sign it, so the RP MUST accept CRL A as
the latest available source of revocation information.

The alternative (come up with a scheme to allow a dead CA to somehow
zombie-sign CRL C just to work around that CA's stupidity) is a
non-starter.  The special-case RP processing using CRL A for retroactive
validation of last-second signatures is MUCH simpler than the
alternative.

Dave

Note: For simplicity the timeline deliberately ignores processing delays
(if a notice to revoke is received 15 seconds before the CRL signing
time, is the revocation included in the CRL?).  And someone (Tom?)
rightly points out that RPs might wait for several CRLs before accepting
as final a transaction occurring at time s.  None of these affect the
fact that an RP can only consider information that is available, and if
CRL C cannot be created, then it cannot be considered.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Monday, March 07, 2011 4:13 PM
To: Stefan Santesson; [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

I am trying to help who worry that they will not be issuing a CRL after
certificate expiry.

The current language is simply unnecessary.  It is a bad idea to
over-specify a standard when the basic requirement is equally easy to
express and implement.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 4:06 PM
To: Santosh Chokhani; [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

   Revocation (oldCRL) {   // Create new CRL with all entries from old
CRL
       newCRL = New CRL(oldCRL)
       newCRL.add(certificatesMarkedForRevocation)
       for (entry:allCRLEntries) {    // Cleanup
            If revokedCertExpiryDate > lastCRLIssueDate {
                                 // Keep CRL Entry
             } else {
                   newCRL.remove(entry)
             }
       Sign(newCRL)
    }

Done.

If I have to treat the case differently dependent on whether the
certificate has been on a CRL before or not. The algorithm for
revocation
is getting more complicated as well as any code trying to understand the
information in the CRL.

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 8 Mar 2011 11:09:57 -0500

Dave,

The focus of my point is at what point in time a certificate comes off CRL.

Verification of historical signature etc., requires additional logic which neither X.509 and nor 5280 define.

If you want to verify a signature as of a given time X, you can look at the CRL in effect at time X or at time X + delta depending on your desire and also factor in invalidity date.

All of these items relate to non-repudiation.  One could define and possibly standardize that.  But, that does not change the fact that keep a CRL on for an extra cycle from expiry date does not solve the problem.

Note that CRL issuance in most implementations is much more frequent (between twice to seven times as fast) than what you can infer from the next update field.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Tuesday, March 08, 2011 9:29 AM
To: pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Time: Event
----  -----

So for:

Dave

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 4:06 PM
To: Santosh Chokhani; [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

Done.

/Stefan

---

From: Tom Gindin <[email-masked]>
Date: Thu, 10 Mar 2011 09:11:58 -0500

Santosh:

        The requirement of "one published CRL after expiration" is only 
relevant to long-lived digital signatures on objects, and mainly to allow 
an RP which archives CRL's to get one which answers the question of 
whether a signing certificate had been revoked before it expired.  An RP 
which is performing encryption, on-line authentication, or validating 
signed requests is not going to accept either an expired certificate or a 
certificate from an expired issuer for any of its major purposes, and thus 
will not care if such a certificate was ever revoked.
        Part of the confusion on this issue is that I don't know of a 
clear definition of the process for retrospective validation.  While most 
of RFC 5280 validation can be applied to retrospective validation with 
only tweaks in wording, the acquisition of relevant revocation information 
changes significantly.
        Here's my provisional list of the tweaks, with the main change to 
6.3.3 part a:
6.1.1 - b: The current date/time becomes the validation date/time, meaning 
the date and time to which the validation is relevant and not that at 
which it is performed.  A "Retrospective" validation is one where the 
validation date/time is earlier than the start of the validation process.
6.1.3 - a: Both occurences of "current time" become "validation time", 
with the meaning given above.  That change doesn't really distinguish 5280 
from retrospective, since for 5280 the validation time is the current 
time.
6.3, second paragraph: The fetch mechanism for current CRL's is not 
assumed for retrospective validation.
6.3.3: Part a would be the subject of most updates to the process for 
retrospective validation.  My strawman text below requires the RP's 
archive to contain a CRL issued between the validation time and the time 
at which a revoked certificate with the signer's expiration time could be 
expected to be purged.  The purpose of my heuristic earlier was to make 
the endpoint of that interval calculable by RP software.  Obviously, a CRL 
extension specifying the time between certificate expiration and CRL entry 
removal would make that calculation better.
        A-0: A CRL should not be used for retrospective validation if its 
thisUpdate field is prior to the validation time, except for the base CRL 
of a delta CRL whose thisUpdate field is after that time.  A delta CRL 
should only be used for retrospective validation if its thisUpdate field 
is prior to the expiration time of the subject certificate.  A base CRL 
should only be used for retrospective validation if its thisUpdate field 
is prior to the time at which a revoked certificate with the expiration 
time of the subject certificate should have been removed from CRL's.

                Tom Gindin

From:
Santosh Chokhani <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>, pkix <[email-masked]>
Date:
03/08/2011 07:08 AM
Subject:
RE: [pkix] Same notAfter date for CA and EE certificate

Tom,

Besides, the rule is very simple.  If the certificate is expired, you do 
not use it.  The rule is pretty invariant for encryption and on-line 
authentication.  For digital signature on an object, if you need to 
verify, other things such as trusted time stamp, past CRL, CRL that 
contains expired certificates, etc. come into play.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 10:59 PM
To: Santosh Chokhani
Cc: [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

        Santosh:

of less than half that.

                Tom Gindin

From:

Denis,

 
 
Taking another scenario, 

 
Santosh,
 
See comments in lines.
 
----- Message reçu ----- 
De : Santosh Chokhani 
À : [email-masked],Jim Schaad (IETF),pkix 
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

 
Denis

order 
----- Message reçu ----- 
De : pkix-bounces 
À : Jim Schaad,'IETF PKIX' 
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 11 Mar 2011 01:23:10 -0500

Tom,

You can verify signature on the long-lived signatures as long as the revocation appears on only one CRL.  Revoked certificate appearing in one extra CRL does not help any better.

You can use a simple locate and back-off algorithm based on this update and TOI to get the appropriate CRL.

Also note that revocation appearing in one extra CRL does not necessary make it any easier to do the above.  A simple case in point is what if the CA issued another CRL a delta time (delta being very very small and reason for delta being so small is an emergency manual CRL) after the CRL was issued on which the expired CRL appears for the last time.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, March 10, 2011 9:12 AM
To: Santosh Chokhani
Cc: [email-masked]; pkix
Subject: RE: [pkix] Same notAfter date for CA and EE certificate

        Santosh:

                Tom Gindin

From:

Tom,

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 10:59 PM
To: Santosh Chokhani
Cc: [email-masked]; pkix
Subject: Re: [pkix] Same notAfter date for CA and EE certificate

        Santosh:

of less than half that.

                Tom Gindin

From:

Denis,

 
 
Taking another scenario, 

 
Santosh,
 
See comments in lines.
 
----- Message reçu ----- 
De : Santosh Chokhani 
À : [email-masked],Jim Schaad (IETF),pkix 
Date : 2011-03-07, 14:04:16
Sujet : RE: [pkix] Same notAfter date for CA and EE certificate

 
Denis

order 
----- Message reçu ----- 
De : pkix-bounces 
À : Jim Schaad,'IETF PKIX' 
Date : 2011-03-06, 12:50:56
Sujet : Re: [pkix] Same notAfter date for CA and EE certificate
Jim,

I think the text is OK.

/Stefan