Subject: [pkix] What should be in "Next Update" field of the last CRL?

From: Roberto Opazo <[email-masked]>
Date: Wed, 16 Feb 2011 15:49:50 -0300

Hello:

I can't find an specification about what to put in the "Next Update"
field of the last CRL issued by one CA in its last day. I mean, the
day when this CA certificates expires.

Is there any recommendation?

Without a recommendation you could chose very different options:

* NULL. The field is optional after all, but RFC5280 states
"Conforming CRL issuers MUST include the nextUpdate field in all
CRLs."

* 24 hours, as all other CRL's. But that's a lie, CA is going to be
expired in 24 hours, son It can't sign.

* Year 2999. So no one alive today is going to be alive that they, but
it's a lie any way and there could be systems not prepared to process
that date.

So, could you help me with an official recommendation?

-- 
Best regards,

Roberto Opazo

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Feb 2011 14:46:33 -0500

Is the CA being shut down forever?  Or, is a new CA taking over using the key rollover stuff specified in CMP?

Russ

On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Feb 2011 16:56:08 -0500

RFC 5280 says the following about a certificate notAfter field:

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

It seems to me that the same value is appropriate for a CRL.

Russ

On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote:

> CA being shut down forever.
> 
> 2011/2/16 Russ Housley <[email-masked]>:
> Saludos,

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Feb 2011 20:23:45 -0500

That's probably the most right choice, but hard to implement programmatically I think.  The code generating the signature doesn't know/can't know (absent outside info) whether or not the signing cert will be reissued.  I'd suggest that using the same interval time for "Next Update" - at that point, either the cert has been reissued or it hasn't.  If it has, the date is appropriate.  If it hasn't - well the CRL becomes moot as the signing cert is no longer valid.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Feb 2011 20:34:13 -0500

To expand on this - consider a CA with a CRL interval quite a bit longer - say 30 days.  The CA cert will expire 20 days into that period.  It seems to me that issuing a CRL at day 0 with a Next Update of "sometime far in the future" would become problematic if the CA were resigned with a longer expiration date around day 15.

Mike

---

From: Alan Sill <[email-masked]>
Date: Wed, 16 Feb 2011 19:47:04 -0600

A CA can become inactive for the purposes of issuing new credentials  
without necessarily invalidating the certificates already issued.  The  
CRL server can be maintained and can be used to revoke previously  
issued certificates for as long as they are of use to the relying  
parties making use of those certificates.

In principle, a CRL server should be maintained and should issue  
updates (with valid "Next Update" fields) through the full period that  
includes any certificate previously issued by the CA.  Otherwise, any  
relying parties making use of the certificates either to assert or  
grant trust will be unaware of any change to the status of the  
previously issued certs.

An option is to revoke all previously issued certs at a time of your  
choice and put them all into your last CRL update.  the "next Update"  
time would then be set to the previously quoted GeneralizedTime value  
(99991231235959Z) to indicate that there will be no further updates.   
It would also be perfectly valid to leave previously issued certs that  
you as the CA operator would like to allow to remain active out of the  
CRL, and continue to issue CRL updates through the expiration date of  
the last remaining active certificate.

Alan

On Feb 16, 2011, at 7:34 PM, Michael StJohns wrote:

> To expand on this - consider a CA with a CRL interval quite a bit  
> longer - say 30 days.  The CA cert will expire 20 days into that  
> period.  It seems to me that issuing a CRL at day 0 with a Next  
> Update of "sometime far in the future" would become problematic if  
> the CA were resigned with a longer expiration date around day 15.
>
> Mike
>
>
>
>> That's probably the most right choice, but hard to implement  
>> programmatically I think.  The code generating the signature  
>> doesn't know/can't know (absent outside info) whether or not the  
>> signing cert will be reissued.  I'd suggest that using the same  
>> interval time for "Next Update" - at that point, either the cert  
>> has been reissued or it hasn't.  If it has, the date is  
>> appropriate.  If it hasn't - well the CRL becomes moot as the  
>> signing cert is no longer valid.
>>
>> Mike
>>
>>
>>
>>>>> Is the CA being shut down forever?  Or, is a new CA taking over  
>>>>> using the key rollover stuff specified in CMP?
>>>>>
>>>>> Russ
>>>>>
>>>>>

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics, TTU
Vice President of Standards, Open Grid Forum

====================================================================
:  Alan Sill, Texas Tech University  Office: Drane 162, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Feb 2011 20:57:40 -0500

At 08:47 PM 2/16/2011, Alan Sill wrote:
>without necessarily invalidating the certificates already issued.

The specific question referred to a CA certificate that was expiring.  If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point?

Mike

---

From: "Sill, Alan" <[email-masked]>
Date: Wed, 16 Feb 2011 20:34:47 -0600

> The specific question referred to a CA certificate that was expiring.  If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by de…

Mike,

Yes, with respect, you're missing my point. The user or relying party has no way of determining that your CA is no longer in existence. The CRL server can convey information about the revoked certificates you have issued from it previously, if any, and properly written relying party services will fail to accept any certificates from your current or previously existing CA at any time beyond the last "Next Update" time of your most recently fetched CRL, but otherwise no one actually communicates with your CA itself to verify its existence. They don't need to, as the public key that they already have for your CA, along with that of the certificate, are all that they need to check that the cryptography of the certificate is valid. 

Hope this helps,

Alan

---

From: "Sill, Alan" <[email-masked]>
Date: Wed, 16 Feb 2011 20:38:15 -0600

> The specific question referred to a CA certificate that was expiring.  If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by de…

Woops -- you're right; if the CA certificate itself has expired, then the question is of course moot. 

Sorry, I missed that in the original question. 

Alan

---

From: Roberto Opazo <[email-masked]>
Date: Thu, 17 Feb 2011 00:44:43 -0300

Well, the real situation is... Next Monday the CA certificate expires
after 10 years of work. So CA certificate has not been expired yet and
we have a little time to take some decisions.

This is the first time for us on these situation. Next time is going
to be in 20 years, so I expect there will be and standard way to
finish CA live at that time.

Have anybody an experience to share?

How have other CAs ended?

I think using a 24 hours valid period for the last CRL is not good
choice. For instance, the next year a relaying party (RP) could try to
validate a valid signature (like an XML signed last week) and the RP
will get and expired CRL, I mean a CRL whit "Next Update" field
expired. RP would have to note than "Next Update" is pointing to a
date out of the CA's certificate validity period and assume that is
the reason why there are no other CRL and then, decide to trust in an
expired CRL. I think there are no many sw with this logic on the
marked.

That's why I prefer Rus recommendation, but I think It would be nice
having an RFC with a sentence like "CAs conforming to this profile
MUST create a final CRL with 99991231235959Z on "Next Update" field.

After all, Rus is a guru to me, but I can't say to others "Rus told me
to...". So I will have to repeat Rus argument, but It's not the same
when it's me or the company I work for, the person saying that.

Best regards,

Roberto Opazo

-- 
Saludos,

Roberto Opazo

---

From: "Sill, Alan" <[email-masked]>
Date: Wed, 16 Feb 2011 22:12:59 -0600

On Feb 16, 2011, at 9:45 PM, "Roberto Opazo" <[email-masked]> wrote:

> expired CRL.

Any correctly implemented RP software would fail to validate any certificate from a CA with an expired CA certificate, or any certificate at all from a CA that has a most recent "Next Update" in the past. Itdoes no good to second-guess conditions under which a RP would trust a cert that they cannot check for possible revocation.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 17 Feb 2011 11:03:37 +0100

Russ,

I don't believe that using 99991231235959Z is the best approach since this value is to be used for the certificate validity period only.
Its semantics is not appropriate either. Many implementations might fail with such a value.

Since there is no prefect solution, the best I can imagine is the following:

 - place the end of validity of the root key as the nextupdate field of the last issued CRL.

   All implentations will work nicely. 
   It is true that it is a lie, since no CRL will be issued at that date, but 
   since the CA will be dead one second after that date,
   no one can comply about a dead authority.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : Roberto Opazo 
Date : 2011-02-16, 22:56:08
Sujet : Re: [pkix] What should be in "Next Update" field of the last CRL?

Russ

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Feb 2011 08:50:04 -0500

Simple answer: the notAfter date of the issuing CA.  No cert issued by the CA is valid after this date anyway, so the CRL is moot thereafter.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Feb 2011 09:01:45 -0500

> we have a little time to take some decisions.

Subscriber certs should have a notAfter date equal to the maximum validity period or the notAfter date of the issuer's certificate, *whichever is shorter*.  

However, even this doesn't matter because subscriber certs are invalid when the CA cert expires no matter what notAfter date they assert.  Any cert or CRL which claims dates past this date is moot.

"Proper" PKI planning would have each CA retire from active issuance but remain to issue CRLs until all subscriber certs have expired; this 'inactive' period is equal to the maximum validity period of the certs it issued.  At that point the CA can simply be shut off (assuming you've archived all the artifacts you need for proving validity of historical signatures).  This is an operational nicety rather than a technical one, as it's the only way to extract the full validity period for all issued certs; failure to do so means as the CA cert expiry time approaches the subscriber cert lifecycle gets shorter and shorter.

OTOH, you *could* simply resign the CA key, assuming you're OK with that key remaining in service.  I don't recommend this option but I think it would technically work.  As long as the SKID and Subject DN don't change, relying parties may still be able to build a valid chain.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Feb 2011 09:06:05 -0500

On Feb 16, 2011, at 10:12 PM, Sill, Alan wrote:

> Any correctly implemented RP software would fail to validate any certificate from a CA with an expired CA certificate, or any certificate at all from a CA that has a most recent "Next Update" in the past.

ITYM CRL instead of CA; only CRLs have nextUpdate.

That said, you're incorrect.  CRLs don't expire.  CRLs only go stale.  A relying party that uses a stale CRLs increases its risk of accepting revoked certs, but they remain valid statements from the CA.  It *is* common for RPs to *interpret* netUpdate as a "CRL expiry" date, but it is most certainly not correct to do so.  In fact, in some operational scenarios (e.g., intermittently connected networks) this interpretation causes denial-of-service.

-- Tim

---

From: Nuno Ponte <[email-masked]>
Date: Thu, 17 Feb 2011 14:11:07 +0000

Hi,

     That was also the first thing that came to my mind when I read this 
question.

     However, if a certificate is revoked meanwhile, that means it will 
never show up in an issued CRL. What about having a last and definitive 
CRL created at exactly the CA expire date, i.e. CRL_thisUpdate = 
CRL_nextUpdate = CA_notAfter ?

     Regards,

                 Nuno Ponte

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Feb 2011 09:17:02 -0500

On Feb 17, 2011, at 8:11 AM, Nuno Ponte wrote:

> However, if a certificate is revoked meanwhile, that means it will never show up in an issued CRL. What about having a last and definitive CRL created at exactly the CA expire date, i.e. CRL_thisUpdate = CRL_nextUpdate = CA_notAfter ?

"Meanwhile" is meaningless in this case.  Expired certs can be removed from a CRL with zero impact because the validation algorithm discards expired certs *before* status is checked.  Checking status prior to expiry is far, far less efficient; software that checks status before validity should be fixed.

Choosing to keep expired certs on a CRL may be required for legal or policy reasons, but there is no technical requirement to do so.

-- Tim

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Feb 2011 09:42:39 -0500

Roberto:

Another reasonable choice would be a date just after the expiration of every certificate issued by the CA.  This will not disrupt certificates that are supposed to be valid, and the CRL will also have an end-of-life.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Feb 2011 09:46:11 -0500

> Any correctly implemented RP software would fail to validate any certificate from a CA with an expired CA certificate, or any certificate at all from a CA that has a most recent "Next Update" in th…

If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Russ

---

From: Roberto Opazo <[email-masked]>
Date: Thu, 17 Feb 2011 11:58:19 -0300

Tim:

> However, even this doesn't matter because subscriber certs are invalid when the CA
> cert expires no matter what notAfter date they assert.  Any cert or CRL which claims
> dates past this date is moot.

After CA expiration date, it's still possible to need EE certificate
validation, not for a new SSL authentication, but for an electronic
document signed in the past, when the EE certificate was valid.

EE certificates expires, but electronic signatures persist and needs
to be validated.

-- 
Saludos,

Roberto Opazo

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 17 Feb 2011 10:24:30 -0500

Robert,

Yes, a relying party may wish to determine if an EE certificate was 
valid at some time in the past, but such a relying party should not be 
looking for a "current" CRL.

As has been noted, if a certificate has been revoked, its serial number 
only needs to be included on CRLs issued before the certificate 
expired.  So, if a certificate expired 6 months ago, and a relying party 
wants to know whether the certificate was valid a year ago when the 
corresponding private key was used to sign a document, the relying party 
would need to find a CRL that was issued at least 6 months ago.  The 
relying party may wish to check that the nextUpdate time in the CRL is 
after the time that the signature was generated, but should not check 
that the nextUpdate time in the CRL is after the current time, as in 
most cases such a CRL would have been issued after the certificate 
expired and so would not provide any information about the revocation 
status of the certificate.

So, if all of the EE certificates issued by your CA expire no later than 
February 21, 2011, it should be sufficient for the final CRL issued by 
the CA to have a nextUpate time of February 22, 2011 (or some time on 
February 21, 2011 that is later than the notAfter time in every 
certificate issued by the CA).  Such a CRL would work well for any 
relying party trying to verify a certificate before its expiration, and 
any relying party trying to verify a certificate after its revocation 
wouldn't (or at least shouldn't) be comparing the nextUpdate time in the 
CRL to the current time.

If the CA has issued certificates that expire after February 21, 2011, 
then the situation is slightly more complicated, if the CA will shut 
down and no longer issue CRLs after that date.  The safe thing to do 
would be to issue a final CRL with a nextUpdate time that is after the 
expiration (notAfter) dates of all issued certificates that lists all of 
the unexpired certificates as revoked.  One could issue such a CRL that 
does not list the unexpired certificates as revoked, but there is a risk 
involved in that (if the CA that issued the certificates is used as a 
trust anchor) since there would be no way to revoke these certificates 
in the future if the need arose.

Dave

On 02/17/2011 09:58 AM, Roberto Opazo wrote:
> 2011/2/17 Miller, Timothy J.<[email-masked]>:
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Feb 2011 10:29:14 -0500

> document signed in the past, when the EE certificate was valid.

Historical signature validation is a special case, and requires archived status statements--not final status statements.  If a document was signed at T and revoked-for-compromise at T+n, the signature at T is still binding (though it may be more or less questionable depending on the magnitude of n).  An historical signature algorithm would only use the CRL issued for the period covering T for validation.

-- Tim

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 17 Feb 2011 17:11:26 +0100

>     the notAfter SHOULD be assigned the GeneralizedTime value of

I recently saw an implementation that actually uses that date, and it's 
not really a convenient choice.

The use of the date 9999 seems to be in order to use the highest value 
that doesn't have a 5 digits year. But given that the date is 23h 59:59 
on the 31 december, it will result in a date in the morning of 1 january 
10.000 for all locales that have a positive offset to GMT.
I think 99991231120000Z would be more convenient so that the year stays 
9999 whatever the local time used to display it is.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Feb 2011 08:30:11 -0800

> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Exactly. The previous replies on this thread that said that a relying 
party would not validate a certificate that used this CA either were 
thinking that the CA was an intermediate CA or were forgetting the PKIX 
trust anchor model from section 6.1 of 5280.

Given this, I think Russ' second answer is the correct one:

 >Another reasonable choice would be a date just after the expiration of 
every certificate issued by the CA.  This will not disrupt certificates 
that are supposed to be valid, and the CRL will also have an end-of-life.

This allows the no-longer-used CA to still revoke certificates, such as 
if there is a key compromise on an end-entity certificate that happens 
even after the CA is no longer expected to be used.

---

From: "Andrews, Rick" <[email-masked]>
Date: Thu, 17 Feb 2011 08:46:51 -0800

> How have other CAs ended?

Good question. In January 2010, we retired our "RSA Secure Server" CA,
but apparently we're still issuing empty CRLs with it. I suspect that if
we stopped, and simply removed the latest CRL from our download site, it
would have no effect whatsoever.

-Rick Andrews

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Feb 2011 11:58:28 -0500

> trust anchor model from section 6.1 of 5280.

Good point.  But then again, many (most?) extant implementations make the same error.

-- T

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Feb 2011 09:27:26 -0800

> Good point.  But then again, many (most?) extant implementations make the same error.

It is not an error, it is a policy decision based on erroneous 
understanding of PKIX. :-) Seriously, though, because many extant 
implementations do *not* make that error^Wpolicy decision, the answer to 
the question that started this thread should be to deal with both types 
of systems and to continue to set the "next update" to a date when a 
next update can be expected. If the CA has decided to never do a next 
update, use the forever-ish standard for notAfter; otherwise, be honest 
and say when you think you might update the CRL again.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Feb 2011 20:17:23 -0500

>If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Is that true in reality?  The typical trust anchor in a browser is a self-signed cert.  I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.

Mike

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Feb 2011 20:46:22 -0500

> Is that true in reality?  The typical trust anchor in a browser is a self-signed cert.  I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.

Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 2459) imposes this requirement.

Russ

---

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Feb 2011 21:18:14 -0500

>Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 2459) imposes this requirement.

Which is kind of funny because a number of implementations treat the nextUpdate field as a CRL expiration date - and that's doesn't appear to be the processing recommended by 5280. 

 I started researching this and found at least three implementations have either a fixed or configurable behavior which treats ALL certs under a CA as invalid if they don't receive a new CRL before the nextUpdate date.  At least one of these implementations does not have this behavior if it sees a CRL without the nextUpdate field  - but 5280 requires CRLs to have the field.  

Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the most recent CRL - I read it that certs not on the CRLs that are in your posession have the status of "UNDETERMINED".

Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance Policies given incomplete CRL information?

Mike

---

From: "Sill, Alan" <[email-masked]>
Date: Thu, 17 Feb 2011 20:39:47 -0600

> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance Policies given incomplete CRL information?

This is exactly what I tried to point out earlier. It is surely up to each relying party, but all production infrastructure implementationd of which I am aware treat things this way: if a CRL is not available after the time of the "next update" value of the most current one expires, then no certificates from that CA are considered valid.  And despite answers to the contrary given by others on this list, I can't think of any popular implementationd that will accept EE certs from a CA after the expiration of the CA cert, either.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 18 Feb 2011 09:30:38 -0500

> I started researching this and found at least three
> implementations have either a fixed or configurable
> behavior which treats ALL certs under a CA as invalid
> if they don't receive a new CRL before the nextUpdate date.

That is particularly broken behavior, akin to running your car out of
gas every time and walking to the gas station with a can to get some
more.  For CAs that do not issue unscheduled CRLs, there is no way to
receive a new CRL before the nextUpdate date, so the application fails
at the end of every CRL waiting until the new CRL can be issued and
retrieved.  The workaround (forcing CAs to lie about nextUpdate so that
broken applications won't fail) is repulsive - the point of standards is
to enable parties that follow the standard to work correctly.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sill, Alan
Sent: Thursday, February 17, 2011 9:40 PM
To: Michael StJohns
Cc: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last
CRL?

On Feb 17, 2011, at 8:18 PM, "Michael StJohns" <[email-masked]>
wrote:

>>>> If the CA certificate has been installed as a trust anchor, then
the expiration time in the self-signed certificate has no role in the
certification path validation.
>>> 
>>> Is that true in reality?  The typical trust anchor in a browser is a
self-signed cert.  I'd have to check, but I'm pretty sure chaining fails
if the self-signed cert has expired.
> Which is kind of funny because a number of implementations treat the
nextUpdate field as a CRL expiration date - and that's doesn't appear to
be the processing recommended by 5280. 
> 
> I started researching this and found at least three implementations
have either a fixed or configurable behavior which treats ALL certs
under a CA as invalid if they don't receive a new CRL before the
nextUpdate date.  At least one of these implementations does not have
this behavior if it sees a CRL without the nextUpdate field  - but 5280
requires CRLs to have the field.  
> 
> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have
the most recent CRL - I read it that certs not on the CRLs that are in
your posession have the status of "UNDETERMINED".
> 
> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance
Policies given incomplete CRL information?
> Mike

This is exactly what I tried to point out earlier. It is surely up to
each relying party, but all production infrastructure implementationd of
which I am aware treat things this way: if a CRL is not available after
the time of the "next update" value of the most current one expires,
then no certificates from that CA are considered valid.  And despite
answers to the contrary given by others on this list, I can't think of
any popular implementationd that will accept EE certs from a CA after
the expiration of the CA cert, either.

---

From: Mike Helm <[email-masked]>
Date: Fri, 18 Feb 2011 12:56:07 -0800

"Sill, Alan" writes:
>  This is exactly what I tried to point out earlier. It is surely up
> to each relying party, but all production infrastructure
> implementationd of which I am aware treat things this way: if a CRL
> is not available after the time of the "next update" value of the
> most current one expires, then no certificates from that CA are
> considered valid. 

(One of )  the guilty party/ies here is openssl, so the problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault.  openssl has some
other crl quirks, at least some versions do.

The idea is very widespread, tho.  I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final publication
in NIST.  However many PKI specialists also seem to believe this
is the correct behavior.  I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, ==mwh
Michael Helm
ESnet/LBNL

---

From: Tom Gindin <[email-masked]>
Date: Fri, 18 Feb 2011 18:36:35 -0500

In a practical sense, if nextUpdate is taken literally an RP 
should not expect to see a fresh CRL in the first few seconds after it 
because publication is not instantaneous.  So an RP can't really use that 
field as a CRL expiration time to fine granularity.   Treating nextUpdate 
+ gracePeriod as an expiration, with a brief grace period (perhaps less 
than an hour) is far likelier to work.

                Tom Gindin

P.S.    This is my opinion, and not necessarily that of my employer.

From:
Michael StJohns <[email-masked]>
To:
Russ Housley <[email-masked]>
Cc:
IETF PKIX <[email-masked]>
Date:
02/17/2011 09:18 PM
Subject:
Re: [pkix] What should be in "Next Update" field of the last  CRL?
Sent by:
[email-masked]

At 08:46 PM 2/17/2011, Russ Housley wrote:
>Mike:
>
>>> If the CA certificate has been installed as a trust anchor, then the 
expiration time in the self-signed certificate has no role in the 
certification path validation.

 I started researching this and found at least three implementations have 
either a fixed or configurable behavior which treats ALL certs under a CA 
as invalid if they don't receive a new CRL before the nextUpdate date.  At 
least one of these implementations does not have this behavior if it sees 
a CRL without the nextUpdate field  - but 5280 requires CRLs to have the 
field. 

Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the 
most recent CRL - I read it that certs not on the CRLs that are in your 
posession have the status of "UNDETERMINED".

Mike

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Feb 2011 13:19:51 +1300

Roberto Opazo <[email-masked]> writes:

>This is the first time for us on these situation. Next time is going to be in
>20 years, so I expect there will be and standard way to finish CA live at that
>time.

Given that we've had this problem for 20-odd years so far and no-one's fixed
it (and indeed I don't know if anyone even knows how to fix it), I doubt it...

>How have other CAs ended?

The first time, very badly.  After that they set their root lifetimes to
longer than the career lifetime of the person who created the cert, so that
they'll be retired by the time it's a problem.

(I know that the above sounds like a tongue-in-cheek comment, but I'm being
serious, that seems to be the way to manage it, the first time it happens to
you you get burnt, then you set the lifetime to as long as you can to make
sure it never happens again).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Feb 2011 15:04:13 +1300

Jean-Marc Desperrier <[email-masked]> writes:
>The use of the date 9999 seems to be in order to use the highest value that
>doesn't have a 5 digits year. But given that the date is 23h 59:59 on the 31
>december, it will result in a date in the morning of 1 january 10.000 for all
>locales that have a positive offset to GMT. I think 99991231120000Z would be
>more convenient so that the year stays 9999 whatever the local time used to
>display it is.

Given that many time routines are going to reject this magic-value date anyway
because it exceeds the range of a 32-bit time_t (and/or should fall outside
sanity-check ranges for any sensible implementation), I don't think this will
be a problem, you'd need to implement it as:

  read date string;
  if( !memcmp( string, "9999...", length ) )
    return( special_date );
  convert string -> date;
  return( date );

Peter.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 19 Feb 2011 21:42:24 -0500

*sigh*   

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not validated" crept into the process rather than being treated as a per acceptor policy decision.

Mike

---

From: Tom Gindin <[email-masked]>
Date: Sun, 20 Feb 2011 10:06:58 -0500

Signed 32-bit times will be a problem soon enough for real 
certificates.  Issuers use 20-25 year root lifetimes all the time. and 
2**31 on Unix is Jan. 18 or 19, 2038.  There are a LOT of 2037 root 
expirations in a current standard XP store, but nothing later yet.  We can 
recommend that nobody go beyond rollover until exactly 20 years before it, 
and thus put off the evil day until seven years from now, but that's about 
it.  I'm sure most of the members of this list will still be working in 
2018.

                Tom Gindin

From:
Peter Gutmann <[email-masked]>
To:
[email-masked], [email-masked]
Date:
02/18/2011 09:04 PM
Subject:
Re: [pkix] What should be in "Next Update" field of the last CRL?
Sent by:
[email-masked]

>The use of the date 9999 seems to be in order to use the highest value 
that
>more convenient so that the year stays 9999 whatever the local time used 
to

Given that many time routines are going to reject this magic-value date 
anyway
because it exceeds the range of a 32-bit time_t (and/or should fall 
outside
sanity-check ranges for any sensible implementation), I don't think this 
will
be a problem, you'd need to implement it as:

  read date string;

Peter.

---

From: Andrea Caccia <[email-masked]>
Date: Sun, 20 Feb 2011 19:16:22 +0100

After all, why not simply stop the CA when its certificate expires with the last CRL next update generated with the same rules of previous ones?
Advantages:
- no special effort to generate a specific CRL
- no RFC 5280 rule breaking
- every CRL next update is somehow a lie, so the better is to choose the most effective
- there could be the need to generate an additional CRL in the unlikely event that some certificate has been revoked in the time frame between issuance of last CRL and CA cert expiration (also those certificates MUST be present at least in one CRL)
- verification software should correctly manage correctly without modifications the situation and discard signatures because the CA cert is expired and/or no fresh CRL is available within the grace period after CRL next update
- no problem to manage the date (signed 32bit times, local time >31/12/9999, …)

Disadvantages?

Andrea Caccia

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 Feb 2011 08:44:51 +1300

Tom Gindin <[email-masked]> writes:

>I'm sure most of the members of this list will still be working in 2018.

That's OK, I'm sure most of the rest of us will still be waiting for PKI to
start working in 2018 too :-).

Peter.

---

From: [email-masked]
Date: Mon, 21 Feb 2011 12:14:17 +1100 (EST)

For completeness, here is a boring answer to a very boring quip ... 

PKI has been working great for a couple of decades but in closed communities for authorization rather than in open utopian communities for authentication.  

See: 

- the GSM system
- EMV DDA cards 
- cable TV set-top boxes 
- ID cards in Malaysia, Hong Kong, Estonia ... 
- health smartcards in Austria, Italy, France, Germany, Taiwan ... 

I have argued that closed PKI should be actually be regarded as the general case, while the old idea of open PKI (which is what I presume you're referring to) for stranger-to-stranger trust is a special case, not very useful, and unsurprisingly unsuccessful.  

See "Public Key Superstructure" (easily Googled). 

Cheers, 

Steve Wilson
Lockstep
http://lockstep.com.au

-----Original Message-----
From: "Peter Gutmann" <[email-masked]>
Sent: Monday, 21 February, 2011 6:44am
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 21 Feb 2011 09:05:01 -0500

> I have argued that closed PKI should be actually be regarded as the general case, while the old idea of open PKI (which is what I presume you're referring to) for stranger-to-stranger trust is a sp…

SPKI/SDSI, anyone?  :)

-- T

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 22 Feb 2011 15:39:32 +0100

Back to the original topic, I lack the dimension of whether the CA that is
being closed has issued certificates that are still valid.

If there are no valid issued certificates, the issue seems obsolete. Just
close the shop. It's fine if the last CRL has a next-update indicating the
date of death, either of the CA or the last issued certificate.

If there are some certificates still valid and you are closing the CA
anyway, then there is something not entirely right. You either need to
renew the CA or invalidate the still valid certificates.

To in such case set a distant CRL next update time and close the shop
seems to be a confusing solution as it ignores the need for future
revocation and fails to provide a valid CA certificate for the "valid"
issued certificates.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 22 Feb 2011 16:29:37 +0100

In reality this is even worse.

There are clearly real situations where the RP need to have both an expiry
date (Don't use this CRL after..) and a date when the next update is
available.

Since most applications treat nextUpdate as the expiry date, and in order
to stay compliant with these implementations, Microsoft defined the
private extension "nextIssue", expressing the expected date when a new CRL
should be available.

The motivation AFAIK was to allow applications (understanding the private
extension) to start caching the new CRL (which sometimes can be quite big)
in the background before the current CRL expires and thus allow a smooth
user experience, not having to wait for 50 MB CRL downloads on CRL
transitions. At the same time allowing standards compliant implementations
to work without breaking.

I don't promote this for standardization. This is just an example of what
happens when people tries to deal with real issues.

/Stefan

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 22 Feb 2011 12:39:36 -0500

As the author of
http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I
would like to note that it was not the intention of this test suite to
imply that nextUpdate must be treated as an expiration date for a CRL.
Version 1.0 of PKITS came out in September 2004, and the CRLs for tests
4.4.11 and 4.4.12 had nextUpdate times of January 2002 and January
1999, respectively.  An application could be configured to allow for a
CRL to be used after its nextUpdate time had passed, as long as it
verified that the nextUpdate time was not too far in the past, and
still get the correct results for the tests, and that was intentional.

Section 4.4 of that document contains the introduction to the basic
certificate revocation tests and it says:

The application must be able to retrieve valid revocation
data for each certificate in the path. For a CRL to be considered to
contain valid revocation data for a certificate, the CRL must at a
minimum: (1) be signed by the issuer of the certificate or by an entity
that has been authorized by the certificate issuer to provide status
information for the certificate; (2) have a scope that includes the
certificate of interest; and (3) be sufficiently up-to-date.

In general, if the current time is before the time specified in the nextUpdate
field of a CRL, then that CRL should be considered sufficiently
up-to-date since the CRL issuer has indicated that this CRL may contain
the most up-to-date information available. Similarly, if the current
time is after the time specified in the nextUpdate field of a
CRL, then the CRL should not be considered to be sufficiently
up-to-date since the CRL issuer has indicated that more up-to-date
information should be available.

Even if the current time is after the time specified in the nextUpdate
field of a CRL, an application may still make a local decision to treat
the CRL as being sufficiently up-to-date. The

application may, for example, be configurable to allow CRLs to be
treated as sufficiently up-to-date, even if the current time is after
the nextUpdate time, if the CRL was issued recently (e.g., the
user or administrator configuring the system could indicate that a CRL
may be used as long as the current time is within 72 hours of the thisUpdate
time in the CRL, no matter how frequently the CRL issuer chooses to
issue CRLs).

In this section, there are only two tests in which the nextUpdate
time in a CRL is before the current time. In each case, the nextUpdate
time (and thisUpdate time) is more than two years before the
current time. So, it is expected that applications will be configured
so that these CRLs are not considered to be sufficiently up-to-date.

Even if an application is unable to find valid revocation data (that is
considered to be sufficiently up-to-date) for every certificate in the
path, the application may still make a local decision to use the
certification path. The application may, for example, allow the user or
an administrator to configure the application to ignore the
unavailability of revocation data. In the case of an interactive
application, the application may display a warning to the user and then
allow the user to decide whether to proceed to use the certification
path despite the lack of revocation data. However, the application may
not be designed in such a way that the unavailability of revocation
data is always ignored, whether the user (or administrator) wants the
application to behave that way or not. When running the tests in this
section, the application should be configured in such a way that the
certification path is not accepted unless valid, up-to-date revocation
data is available for every certificate in the path. Thus, when run in
this configuration, when the application is unable to find valid,
up-to-date revocation data for every certificate in the path, the
application must either reject the certification path or at least
display a warning to the user indicating that the status of the
certificate can not be determined.

Dave

On 02/19/2011 09:42 PM, Michael StJohns wrote:

*sigh*

Items 4.4.11 and 4.4.12.

Mike

"Sill, Alan" writes:

Thanks, ==mwh
Michael Helm
ESnet/LBNL

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Feb 2011 14:03:35 -0500

Hi David -

Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:

>Expected Result: The path should not validate successfully since the status of the end
>entity's certificate can not be determined.

without reference back to the text you cite.  

It's true that 4.4 has the "local decision to treat the CRL as being sufficiently up-to-date", but the "should not validate successfully" in the test text is going to be or was what gets/got implemented.  Testable criteria always wins...

Mike

At 12:39 PM 2/22/2011, David A. Cooper wrote:
>As the author of <http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I would like to note that it was not the intention of this test suite to imply that nextUpdate must be treated as an expiration date for a CRL.  Version 1.0 of PKITS came out in September 2004, and the CRLs for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and January 1999, respectively.  An application could be configured to allow for a CRL to be used after its nextUpdate time had passed, as long as it verified that the nextUpdate time was not too far in the past, and still get the correct results for the tests, and that was intentional.
>
>Section 4.4 of that document contains the introduction to the basic certificate revocation tests and it says:
>
>The application must be able to retrieve valid revocation data for each certificate in the path. For a CRL to be considered to contain valid revocation data for a certificate, the CRL must at a minimum: (1) be signed by the issuer of the certificate or by an entity that has been authorized by the certificate issuer to provide status information for the certificate; (2) have a scope that includes the certificate of interest; and (3) be sufficiently up-to-date.
>
>In general, if the current time is before the time specified in the nextUpdate field of a CRL, then that CRL should be considered sufficiently up-to-date since the CRL issuer has indicated that this CRL may contain the most up-to-date information available. Similarly, if the current time is after the time specified in the nextUpdate field of a CRL, then the CRL should not be considered to be sufficiently up-to-date since the CRL issuer has indicated that more up-to-date information should be available.
>
>Even if the current time is after the time specified in the nextUpdate field of a CRL, an application may still make a local decision to treat the CRL as being sufficiently up-to-date. The
>application may, for example, be configurable to allow CRLs to be treated as sufficiently up-to-date, even if the current time is after the nextUpdate time, if the CRL was issued recently (e.g., the user or administrator configuring the system could indicate that a CRL may be used as long as the current time is within 72 hours of the thisUpdate time in the CRL, no matter how frequently the CRL issuer chooses to issue CRLs).
>
>In this section, there are only two tests in which the nextUpdate time in a CRL is before the current time. In each case, the nextUpdate time (and thisUpdate time) is more than two years before the current time. So, it is expected that applications will be configured so that these CRLs are not considered to be sufficiently up-to-date.
>
>Even if an application is unable to find valid revocation data (that is considered to be sufficiently up-to-date) for every certificate in the path, the application may still make a local decision to use the certification path. The application may, for example, allow the user or an administrator to configure the application to ignore the unavailability of revocation data. In the case of an interactive application, the application may display a warning to the user and then allow the user to decide whether to proceed to use the certification path despite the lack of revocation data. However, the application may not be designed in such a way that the unavailability of revocation data is always ignored, whether the user (or administrator) wants the application to behave that way or not. When running the tests in this section, the application should be configured in such a way that the certification path is not accepted unless valid, up-to-date revocation data is available for every certificate in the path. Thus, when run in this configuration, when the application is unable to find valid, up-to-date revocation data for every certificate in the path, the application must either reject the certification path or at least display a warning to the user indicating that the status of the certificate can not be determined.
>
>
>
>Dave
>
>><http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf
>>
>>Items 4.4.11 and 4.4.12.
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 22 Feb 2011 17:18:56 -0500

Mike,

I don't understand your point.  These tests don't involve CRLs with
nextUpdate times are a few hours or days in the past, they involve CRLs
with nextUpdate times that are several years in the past.  If "should
not validate successfully" is an acceptable outcome for tests such as
4.4.1and 4.4.4, where no valid CRL is available, then why isn't is also
an acceptable outcome for tests 4.4.11 and 4.4.12, where the only CRLs
that are available are so out-of-date?  If an application is configured
to reject a certification path when some revocation information is
missing, should it accept a certification path if some of the
revocation information is out-of-date by several years?  What's wrong
with implementing "should not validate successfully" for these tests?

Dave

On 02/22/2011 02:03 PM, Michael StJohns wrote:

Hi David -

Expected Result: The
path
should not validate successfully since the status of the end

It's true that 4.4 has the "local decision to treat the CRL as being
sufficiently up-to-date", but the "should not validate
successfully" in the test text is going to be or was what gets/got
implemented.  Testable criteria always wins...

Mike

As the author of
http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf,
I
would like to note that it was not the intention of this test suite to
imply that nextUpdate must be treated as an expiration date for a
CRL.  Version 1.0 of PKITS came out in September 2004, and the CRLs
for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and
January 1999, respectively.  An application could be configured to
allow for a CRL to be used after its nextUpdate time had passed, as
long
as it verified that the nextUpdate time was not too far in the past,
and
still get the correct results for the tests, and that was
intentional.

The application must be able to retrieve valid revocation
data for
each certificate in the path. For a CRL to be considered to contain
valid
revocation data for a certificate, the CRL must at a minimum: (1) be
signed by the issuer of the certificate or by an entity that has been
authorized by the certificate issuer to provide status information for
the certificate; (2) have a scope that includes the certificate of
interest; and (3) be sufficiently up-to-date.

In general, if the current time is before the time specified
in the
nextUpdate field of a CRL, then that CRL should be considered
sufficiently up-to-date since the CRL issuer has indicated that this
CRL
may contain the most up-to-date information available. Similarly, if
the
current time is after the time specified in the nextUpdate field of a
CRL, then the CRL should not be considered to be sufficiently
up-to-date
since the CRL issuer has indicated that more up-to-date information
should be available.

Even if the current time is after the time specified in the
nextUpdate field of a CRL, an application may still make a local
decision to treat the CRL as being sufficiently up-to-date. The

application may, for example, be configurable to allow CRLs
to be
treated as sufficiently up-to-date, even if the current time is after
the
nextUpdate time, if the CRL was issued recently (e.g., the user or
administrator configuring the system could indicate that a CRL may be
used as long as the current time is within 72 hours of the thisUpdate
time in the CRL, no matter how frequently the CRL issuer chooses to
issue
CRLs).

In this section, there are only two tests in which the
nextUpdate
time in a CRL is before the current time. In each case, the
nextUpdate time (and thisUpdate time) is more than two years
before the current time. So, it is expected that applications will be
configured so that these CRLs are not considered to be sufficiently
up-to-date.

Even if an application is unable to find valid revocation
data (that
is considered to be sufficiently up-to-date) for every certificate in
the
path, the application may still make a local decision to use the
certification path. The application may, for example, allow the user or
an administrator to configure the application to ignore the
unavailability of revocation data. In the case of an interactive
application, the application may display a warning to the user and then
allow the user to decide whether to proceed to use the certification
path
despite the lack of revocation data. However, the application may not
be
designed in such a way that the unavailability of revocation data is
always ignored, whether the user (or administrator) wants the
application
to behave that way or not. When running the tests in this section, the
application should be configured in such a way that the certification
path is not accepted unless valid, up-to-date revocation data is
available for every certificate in the path. Thus, when run in this
configuration, when the application is unable to find valid, up-to-date
revocation data for every certificate in the path, the application must
either reject the certification path or at least display a warning to
the
user indicating that the status of the certificate can not be
determined.

Dave

*sigh*

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not
validated" crept into the process rather than being treated as a per
acceptor policy decision.

Mike

"Sill, Alan" writes:

This is exactly what I tried to point out earlier. It is
surely up
to each relying party, but all production infrastructure
implementationd of which I am aware treat things this way: if a CRL
is not available after the time of the "next update" value of
the
most current one expires, then no certificates from that CA are
considered valid.

a copy of it any more & I don't know that it reached final
publication

Thanks, ==mwh
Michael Helm
ESnet/LBNL

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Feb 2011 22:25:13 -0500

At 05:18 PM 2/22/2011, David A. Cooper wrote:
>Mike,
>
>I don't understand your point.  These tests don't involve CRLs with nextUpdate times are a few hours or days in the past, they involve CRLs with nextUpdate times that are several years in the past.

This (how old is too old) isn't going to be all that visible from a testing POV - all the tester knows is that the last known CRL is stale - later than the nextUpdate time.  There's no discussion in 4.4.11 of how late is too late (even though 4.4 notes the CRLs are at least 2 years out of date).  So for 4.4.11 and 4.4.12 it doesn't matter whether the CRL is 1 day out of currency or 10 years.  Indeed, the text of 4.4.11 simply says "CRL has a nextUpdateTime that is in the past".  Also, as I read it, 4.4.12 was a "pre 2000" test - or more simply a Y2K completeness test.

>  If "should not validate successfully" is an acceptable outcome for tests such as 4.4.1and 4.4.4, where no valid CRL is available, then why isn't is also an acceptable outcome for tests 4.4.11 and 4.4.12, where the only CRLs that are available are so out-of-date? 

In neither case is this acceptable always.  In both it should be a matter of configuration. E.g. a CA may choose not to issue a CRL *ever* making 4.4.1s assumption that a missing CRL means the cert is invalid overreaching.  

>Conforming CAs are not required to issue CRLs if other revocation or
>   certificate status mechanisms are provided. 

> If an application is configured to reject a certification path when some revocation information is missing, should it accept a certification path if some of the revocation information is out-of-date by several years?  What's wrong with implementing "should not validate successfully" for these tests?

Because that's not what 3280 or 5280 says (and they are both silent on that as near as I can tell). It's also not PKITS.pdf seems to test.

See above. Each of these test cases should have noted that the testing was against a specific assumption - that CRLs are mandatory and that if the CRL is stale then all certificates are invalid - and should have noted that the acceptor could configure an alternate acceptance model.  The fact these cases were stated as an absolute probably led to various implementations making similar absolute choices.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Feb 2011 23:26:48 -0500

>date (Don't use this CRL after..) and a date when the next update is

yes, that would be nice, but I do not recall anyone proposing an extension
to carry the first data (with a nicer name :-)).

>private extension "nextIssue", expressing the expected date when a new CRL

This is an unfortunate name, as the next update value is the next 
issue date :-). I appreciate the motivation, but ...

The next update value is like a "best is used before" date, analogous 
to what one sees on perishable products. You don't HAVE to consume 
the product before that date, but you may get a stomach ache if you 
consume it too long afterwards :-).

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Feb 2011 08:05:46 +0100

From:  Stephen Kent <[email-masked]>
Date:  Tue, 22 Feb 2011 23:26:48 -0500
To:  Stefan Santesson <[email-masked]>
Cc:  "Kemp, David P." <[email-masked]>, "Sill, Alan"
<[email-masked]>, Michael StJohns <[email-masked]>, IETF PKIX
<[email-masked]>
Subject:  Re: [pkix] What should be in "Next Update" field of the last  CRL?
> 
> This is an unfortunate name, as the next update value is the next issue date
> :-). I appreciate the motivation, but ...
> 
> The next update value is like a "best is used before" date, analogous to what
> one sees on perishable products. You don't HAVE to consume the product before
> that date, but you may get a stomach ache if you consume it too long
> afterwards :-).

Yes, that all sound logical. However on a practical ground that is quite
hard to code into a crypto API. There you need more distinct rules and
predictable outcome. It would of course have been more clean if they defined
a private "notValidAfter" extension, but that would not have produced the
outcome they needed.

To standardize on such extension may however be the least evil thing to do.

/Stefan

---

From: Thomas Pornin <[email-masked]>
Date: Wed, 23 Feb 2011 09:04:23 -0500

On Wed, 2011-02-23 at 08:05 +0100, Stefan Santesson wrote:
> Yes, that all sound logical. However on a practical ground that is
> quite hard to code into a crypto API. There you need more distinct
> rules and predictable outcome.

I second that. Theoretically, each RP would decide, according to its own
arbitrary policy, whether a given CRL is fresh enough. But the rules for
appropriate freshness depend upon the context and are likely to be
CA-specific. Revocation is mostly a kind of damage containment: a way to
"cancel" an existing certificate, even though the signature on the
certificate is cryptographically verifiable, in order to cope with an
unfortunate occurrence, e.g. a key compromise. The revocation
information freshness is a measure of the time-wise extent of the issue:
by accepting a week-old CRL, the RP effectively accepts the risk that it
could be fooled into using a public key which has been compromised
during the last week.

How much freshness is needed ? It really depends on the procedures
deployed by the CA to detect the revocation-implying occurrences, and
how fast it can publish revocation information. Those procedures are
normally described in the Certification Policy Statement of the CA, and
supposedly are compatible with the CPS of the CA's CA, and so on.
Ultimately, this leads to the trust anchor's CPS; however, the TA CPS is
not necessarily precise about applicable freshness for all CA which it
has directly or indirectly issued.

One point of PKI (maybe _the_ point of PKI) is to be able to validate
links between public keys and identities, for an arbitrary large set of
identities and public keys, using a small, fixed set of a priori known
information (the trust anchors). We want to be able to validate
certificates issued by intermediate CA about which we had no prior
knowledge. We cannot have CA-specific knowledge for all possible CA.
Hence, the policy which a RP will use to decide CRL freshness must feed
on whatever CA-specific information it can get hold of, and the only
validated sources it can get, in all generality, are the CA certificate
and the CRL itself (and the CRL issuer certificate, if distinct from the
CA). Whatever CPS say in human language, the validation process is,
ultimately, executed by a computer, which needs Turing-compatible rules.

Using the nextUpdate field as an end-of-validity date is not incorrect.
This is certainly allowed by RFC 5280; if the freshness-decision is a
matter of local policy, that local policy can certainly be: "use
nextUpdate as an end-of-validity date". RFC 5280 even hints at that
usage, in the 6.3.3 section ("CRL Processing"): it is said that the
"local CRL cache" should be updated with a "current CRL" if the
nextUpdate field of the most recent CRL is in the past (RFC 5280 does
not tell what should be done if such an update fails). Moreover, using
the nextUpdate as end-of-validity is not a bad policy, as policies go:
basically, it is the policy known as: "issuing CA knows best". Since
appropriate freshness is CA-specific, it makes sense to follow the rules
used by the CA. Ideally, the CA would publish the CRL end-of-validity
date, which should be at some date after the nextUpdate (there should be
no date without a valid CRL at all): the nextUpdate is a lower bound for
the CRL end-of-validity. If more extensive information is not available,
then the best that can be done is to use the nextUpdate as an
approximation of the end-of-validity.

The point, here, is that whatever entity implements the certificate
validation process needs information, which must be:
  1. processable by a computer;
  2. CA-specific, for CA which the RP might not have been aware of
beforehand.
As I see it, given the current state of standard certificate and CRL
extensions, the nextUpdate field is the only information source that can
be used for that. This does not prevent other freshness policies from
being also correct in the RFC 5280 sense, and possibly appropriate
(although the widespread policy known as "meh, no need to check, it is
probably not revoked anyway" kind of stretches my notion of "appropriate
freshness check"). But the "nextUpdate as end-of-validity" policy is a
good policy, or, at least, as good as a generic policy can get in that
matter.

> To standardize on such extension may however be the least evil thing

As I explain above, such an extension is a way for the CA to make a
statement about what freshness measure is appropriate for the procedures
that it applies to decide about the revocation status. It is a good
thing (as long as the CA does not botch it by publishing an
end-of-validity date which is _before_ the nextUpdate).

"Standardize" is an important word. In many usages of validation, we not
only want to have a validation process which yields a trustworthy
answer; we also want it to yield the same trustworthy answer than for
other people. For instance, in the context of a signed contract, I want
my system to accept the contract as signed only if a judge, applying
validation on the same signature, would also declare it as valid and
binding. Right now, this entails using nextUpdate as an end-of-validity
date because, whether you like it or not, that's what everybody does.

	--Thomas Pornin

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Feb 2011 09:37:25 -0500

> This is an unfortunate name, as the next update value is the next issue date :-). I appreciate the motivation, but ...
> 
> The next update value is like a "best is used before" date, analogous to what one sees on perishable products. You don't HAVE to consume the product before that date, but you may get a stomach ache if you consume it too long afterwards :-).

I am aware of applications that expect the new CRL to be posted by the nextUpdate, but allow a grace time for it to published and distributed.  This seems like a reasonable approach since there are not separate next publication and expiration times.

Russ

---

From: Roberto Opazo <[email-masked]>
Date: Wed, 23 Feb 2011 16:34:52 -0300

I think this thread is mixing two different point:

* How should a RP interpret Next Update field in a CRL? Is it an
expiration date?

* What should be en Next Update field in the last CRL? This scenario
is different than the previous one because there is not going to be
any next CRL in any time. There are many choices here and I really
think that's a problem. If there would not be so many applications
already in the market I would recommend a NULL value. But
unfortunately, I think making a choice is hurter than that. No choice
is going to be perfect, but there should be only one way to fill Next
Update field of the last CRL.

Best regards,

Roberto Opazo

-- 
Saludos,

Roberto Opazo

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 23 Feb 2011 17:22:23 -0500

"If a tree falls in an empty forest, does it make a sound"?

If there are no valid certificates (because either or both of the CA certificate and the EE certificate have expired), does it matter what goes into nextUpdate of the last CRL issued by the CA?  There are indeed many choices, but all of them yield the identical result - an expired certificate is not valid.  For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.

Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.  40 years ago when electrical engineers (the original EEs) were doing Karnaugh maps, we would have called nextUpdate an "X" (don't care) input.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roberto Opazo
Sent: Wednesday, February 23, 2011 2:35 PM
To: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

Best regards,

Roberto Opazo

-- 
Saludos,

Roberto Opazo

---

From: Thomas Pornin <[email-masked]>
Date: Wed, 23 Feb 2011 17:38:11 -0500

On Wed, 2011-02-23 at 17:22 -0500, Kemp, David P. wrote:
> For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.

Also, using the same nextUpdate rules helps quite a lot if, one or two
days after having issued the "last" CRL, someone decides that the CA
should not be closed after all, and reissues the certificate using the
same name and public key, and new validity dates. The simplest choice is
also the choice which entails the lowest risk.

	--Thomas Pornin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 23 Feb 2011 16:27:06 -0800

There's the digital signature use case.  You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them either.

> Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.  40 years ago when electrical engineers…

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Feb 2011 16:31:31 -0800

> There's the digital signature use case.  You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them ei…

No, you know that the key was not known by the CA to be compromised 
before the certificate expired. That's a big difference.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 23 Feb 2011 16:56:27 -0800

> before the certificate expired. That's a big difference.

Yes, it is.  However I'm talking about what a verifier wants to know, not what a likely CRL implementation will actually tell me.  That there is "a big difference" is an unfortunate state of affairs.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 20:02:01 -0500

>* How should a RP interpret Next Update field in a CRL? Is it an

the short answers is NO, it it not an expiration date, even if a lot 
of folks have misinterpreted it as such.

>Update field of the last CRL.

You have received several suggestions based on other aspects of the
EOL of the CA, e.g., whether there are subordinate certs that will 
still be valid, whether the certs are used for auth vs. 
non-repudiaiton, etc. So there is not one, right answer for all of 
these contexts. Also, since the problem you raise also is made worse 
by folks misinterpreting the standards re next update, it is not 
clear what a standards body ought to do.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 20:42:52 -0500

At 9:04 AM -0500 2/23/11, Thomas Pornin wrote:
>unfortunate occurrence, e.g. a key compromise.

Although often cited as such, many folks have found that the principle
reason for revocation is not key compromise, but rather the change of 
the value of some attribute in the cert.

>The revocation

The question of how fresh is fresh enough is purely an RP decision. 
Also, while a careful reading of a CPS can help an RP decide what 
might be the right freshness value on a per CA basis, this might 
impose a serious configuration management burden if an RP deals with 
a lot of different CAs. So I think we are heading down a serious rat 
hole here.

>information (the trust anchors).

not always true.  see the RPKI in the SIDR WG for a counter example, i.e.,
cert identities are mot relevant in that PKI.

>...

I agree that an RP can elect to treat the next update value as an 
expiration date, because the RP can do anything that it wants in this 
regard. But, I believe that RPs are not getting the option to make 
this decision. Instead, SW used by RPs are unilaterally interpreting 
the next update value this way, and not allowing the RP to choose 
otherwise. That's not good.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 23:02:49 -0500

At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>There's the digital signature use case.  You want to know that the 
>EE and CA(s) were valid at the time the document was signed, and you 
>want to know that nobody has subsequently compromised them either.
>

For non-repudiation purposes, the RP should have acquired the CRL(s) 
issued for  the relevant cert(s) immediately after the time of the 
transaction in question.  Also, the transaction, and the certs and 
CRLs, should be time-stamped by a TSA.  For more details, see the 
LTANS WG RFCs.

Steve

---

From: Andrea Caccia <[email-masked]>
Date: Thu, 24 Feb 2011 10:40:09 +0100

Il giorno 24/feb/2011, alle ore 05.02, Stephen Kent ha scritto:

> For non-repudiation purposes, the RP should have acquired the CRL(s) issued for  the relevant cert(s) immediately after the time of the transaction in question.  Also, the transaction, and the certs and CRLs, should be time-stamped by a TSA.  For more details, see the LTANS WG RFCs.

Possibly 2 CRLs as "immediately after the time of the transaction" the CA could not had time to revoke the cert.
For this reason, it there are still valid issued certificates the last CRL should be issued at the time the CA cert expires or even after if there are revocations not processed.

In case there are valid certificates the safest way (not necessarily the best for all perspectives) would be to revoke all valid certificates with a revocation date = CA cert expiration.

Andrea Caccia

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Feb 2011 05:04:34 -0500

At 10:40 AM +0100 2/24/11, Andrea Caccia wrote:
>>>  There's the digital signature use case.  You want to know that 
>>>the EE and CA(s) were valid at the time the document was signed, 
>>>and you want to know that nobody has subsequently compromised them 
>>>either.
>>>
>>
>>  For non-repudiation purposes, the RP should have acquired the 
>>CRL(s) issued for  the relevant cert(s) immediately after the time 
>>of the transaction in question.  Also, the transaction, and the 
>>certs and CRLs, should be time-stamped by a TSA.  For more details, 
>>see the LTANS WG RFCs.
>
>Possibly 2 CRLs as "immediately after the time of the transaction" 
>the CA could not had time to revoke the cert.

If a transaction occurs at time T, and a CRL is issued at T+delta, 
and if the CPS for the CA says that it processes all revocation 
requests in less than delta
time, one CRL should suffice.  It may not be reasonable for an RP to wait for
multiple CRL intervals to consider a transaction safe, depdnding on 
the frequency of issuance of CRLs, the CPS details, etc.

>For this reason, it there are still valid issued certificates the 
>last CRL should be issued at the time the CA cert expires or even 
>after if there are revocations not processed.

If the public key from the CA cert is used to verify the CRL, a CRL 
signed by the CA after the CA's cert expires probably ought not be 
verifiable.

>In case there are valid certificates the safest way (not necessarily 
>the best for all perspectives) would be to revoke all valid 
>certificates with a revocation date = CA cert expiration.

probably a bit before the CA cert expiration date, for the reasons I 
cited above.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Feb 2011 08:25:42 -0500

> the frequency of issuance of CRLs, the CPS details, etc.

I think you have to figure in epsilon, which I'll define as "the time the CA CP/CPS defines as the maximum reporting window."  IOW, if the CP says the CA will process revocation requests hourly and publish a CRL immediately *and* requires Subscribers to report lost or suspected compromised key material within 72 hours, then the CRL you want is the CRL published at T+73h rather than T+1h.

OTOH, a CP that permits retroactive revocation (revocation request at time T for claimed time T-n) can really mess up your day.  

This is why we pay lawyers.  :)

-- T

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 24 Feb 2011 10:58:27 -0500

On Feb 23, 2011, at 5:22 PM, Kemp, David P. wrote:

I think the point of the IETF is to write complete specifications - that is, one's without "don't care" inputs. Specification SHOULD discourage the use of magic values in any field, but especially one that  that might be used to "reduce the amount of work" an implementation must do in validation. Leaving aspects of interoperability to the imagination of developers, even if it shouldn't matter, is typically a bad idea.

BTW,

Assuming:
 - "Tree" implies respiration of CO2->02+C via ambient gaseous atmosphere consisting of at least those elements, with one or more leaves consisting of a solid matrix holding the necessities for said respiration.
 - "Falls" implies some sort of force, e.g. gravity, which accelerates said tree through said atmosphere.
 - "Sound" implies a compression wave traveling through said gaseous atmosphere.
Then yes. A solid object with non-zero velocity relative to a gaseous atmosphere will generate a compression wave.

---

From: Roberto Opazo <[email-masked]>
Date: Thu, 24 Feb 2011 13:21:46 -0300

> Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.

Choices has effects, no matter if you see it or not.

Right now, if you put a 24 more hour time in Next Update of the last
CRL, you will have problems validating signatures than wore generated
when certificates were valid, but are been validated after the time
you put on Next Update field of the last CRL.

Magic values create confusion, that is why I think standards should
have a reference for this special situation.

---

Best regards,

Roberto Opazo

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Feb 2011 12:27:42 -0500

> you put on Next Update field of the last CRL.

Signature validation after certificate expiry is a *special case* that's already covered.  You validate using the CRL valid at the *time of signing*, not the final CRL from the PKI.

This is why secure time stamping is so important.  Else you introduce the question of "what time was it signed?"

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 24 Feb 2011 12:33:27 -0500

The issue that you raise has nothing to do with the value of nextUpdate
in the last CRL.  X.509 defines the Validity field (notBefore and
notAfter) in a certificate as follows:

validity is the time interval during which the CA
warrants that

it will maintain information about the status of the certificate.

You cannot use the same process to determine whether a certificate was
valid at some time in the past (e.g., when a signature was generated)
that you use to determine whether a certificate is currently valid,
particularly if the certificate has already expired.

The problem in the scenario that you describe below isn't the value of
nextUpdate in the last CRL, it is the validation procedure that you
think relying parties may use.  The relying party in this scenario should
not be comparing the nextUpdate time in the CRL to the current
time.  In this scenario, the relying party needs to find a CRL with
thisUpdate and nextUpdate times that satisfy these two criteria:

1)  The CRL is sufficiently recent relative to the time the
signature was generated.  As previously described in this thread,
the meaning of "sufficiently recent" may depend on the application.  It
may mean a CRL with a nextUpdate time that is later than the time the
signature was generated (even if the thisUpdate time was before the
signature was generated) or it may mean a CRL with a thisUpdate time
that is long enough after the signature generation time to allow for
any potential key compromise to have been reported and processed.

2) The CRL must either have a thisUpdate time that is before
the notAfter time in the certificate or have an expiredCertsOnCRL
extension that specifies a time that is before the notAfter time in the
certificate.  (The expiredCertsOnCRL extension indicates that the CRL
includes revocation status for certificates that expired on or after
the time specified in the extension.)  If neither of these conditions
are satisfied, then the CRL may not include status information for the
certificate.

Consider a scenario similar to the one you describe, but in which the
CA is not at the end of its life.  A subscriber generates a signature
two days before his or her certificate expires, a relying party wishes
to validate this signature 3 days after the certificate expires, and
the CA issues CRLs once a day with nextUpdate times that are 24 hours
after the thisUpdate times.  If the relying party insisted on using a
CRL with a nextUpdate time that is after the current time, the only
such CRL available would be one that was issued after the certificate
expired.  Such a CRL may not provide status information for the
certificate since it had already expired before the CRL was issued, and
so cannot be used to verify that the certificate had not been revoked.

Similarly, if a CA that was getting ready to shut down issued its last
CRL shortly after the final certificate that it had issued had expired,
this CRL could be empty since a CRL only needs to list revoked
certificates that have not yet expired.  So again, this last CRL could
not be used to determine whether a certificate was valid at some time
in the past before it expired, regardless of the value of nextUpdate in
the CRL.

In either case, the relying party will not be able to obtain a CRL with
a nextUpate time that is after the current time that can be relied upon
to indicate whether the certificate had been revoked before it expired.

On 02/24/2011 11:21 AM, Roberto Opazo wrote:

---

Best regards,

Roberto Opazo

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 25 Feb 2011 13:59:59 +0100

We are far away from the original topic...
A minor correction to the text:
The text states: 
"In this scenario, the relying party needs to find a CRL with thisUpdate and nextUpdate times that satisfy these two criteria".
The first criteria is not correctly stated: 
"The CRL is sufficiently recent relative to the time the signature was generated.
As previously described in this thread, the meaning of "sufficiently recent" may depend on the application."   
Proposed rewording:
" The nextUpdate field of the CRL is sufficiently later than the time the signature was time-stamped 
(since you never know when the signature was generated)".
Denis

----- Message reçu ----- 
De : pkix-bounces 
À : Roberto Opazo 
Date : 2011-02-24, 18:33:27
Sujet : Re: [pkix] What should be in "Next Update" field of the last CRL?

The issue that you raise has nothing to do with the value of nextUpdate in the last CRL.  X.509 defines the Validity field (notBefore and notAfter) in a certificate as follows:

      validity is the time interval during which the CA warrants that
      it will maintain information about the status of the certificate.

You cannot use the same process to determine whether a certificate was valid at some time in the past (e.g., when a signature was generated) that you use to determine whether a certificate is currently valid, particularly if the certificate has already expired.

The problem in the scenario that you describe below isn't the value of nextUpdate in the last CRL, it is the validation procedure that you think relying parties may use.  The relying party in this scenario should not be comparing the nextUpdate time in the CRL to the current time.  In this scenario, the relying party needs to find a CRL with thisUpdate and nextUpdate times that satisfy these two criteria:

1)  The CRL is sufficiently recent relative to the time the signature was generated.  As previously described in this thread, the meaning of "sufficiently recent" may depend on the application.  It may mean a CRL with a nextUpdate time that is later than the time the signature was generated (even if the thisUpdate time was before the signature was generated) or it may mean a CRL with a thisUpdate time that is long enough after the signature generation time to allow for any potential key compromise to have been reported and processed.

2) The CRL must either have a thisUpdate time that is before the notAfter time in the certificate or have an expiredCertsOnCRL extension that specifies a time that is before the notAfter time in the certificate.  (The expiredCertsOnCRL extension indicates that the CRL includes revocation status for certificates that expired on or after the time specified in the extension.)  If neither of these conditions are satisfied, then the CRL may not include status information for the certificate.

Consider a scenario similar to the one you describe, but in which the CA is not at the end of its life.  A subscriber generates a signature two days before his or her certificate expires, a relying party wishes to validate this signature 3 days after the certificate expires, and the CA issues CRLs once a day with nextUpdate times that are 24 hours after the thisUpdate times.  If the relying party insisted on using a CRL with a nextUpdate time that is after the current time, the only such CRL available would be one that was issued after the certificate expired.  Such a CRL may not provide status information for the certificate since it had already expired before the CRL was issued, and so cannot be used to verify that the certificate had not been revoked.

Similarly, if a CA that was getting ready to shut down issued its last CRL shortly after the final certificate that it had issued had expired, this CRL could be empty since a CRL only needs to list revoked certificates that have not yet expired.  So again, this last CRL could not be used to determine whether a certificate was valid at some time in the past before it expired, regardless of the value of nextUpdate in the CRL.

In either case, the relying party will not be able to obtain a CRL with a nextUpate time that is after the current time that can be relied upon to indicate whether the certificate had been revoked before it expired.

---

Best regards,

Roberto Opazo

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 25 Feb 2011 10:50:17 -0500

-----Original Message-----
Michael StJohns

> It's true that 4.4 has the "local decision to treat
> the CRL as being sufficiently up-to-date", but the
> "should not validate successfully" in the test text
> is going to be or was what gets/got implemented.
> Testable criteria always wins...
>
>    Mike

Agree completely.

Years ago when the Microsoft extension was discussed here, an
alternative proposal (an extension carrying the CA's preferred value of
epsilon, the time after nextUpdate at which a CRL should be considered
expired) was also discussed.  Even in the absence of such an extension,
it would have been nice if the PKI test suite had included an
RP-configurable value of epsilon.  Passing the test would require
applications to support accepting certs while in possession of a CRL
that is "fresh enough" after nextUpdate while rejecting certs if no CRL
is fresh enough.

But that's water under the bridge now, unless the test suite is ever
updated.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2011 09:53:47 -0500

At 8:25 AM -0500 2/24/11, Miller, Timothy J. wrote:
>I think you have to figure in epsilon, which I'll define as "the 
>time the CA CP/CPS defines as the maximum reporting window."  IOW, 
>if the CP says the CA will process revocation requests hourly and 
>publish a CRL immediately *and* requires Subscribers to report lost 
>or suspected compromised key material within 72 hours, then the CRL 
>you want is the CRL published at T+73h rather than T+1h.

good point.

>OTOH, a CP that permits retroactive revocation (revocation request 
>at time T for claimed time T-n) can really mess up your day.

and is a violation of the fundamental notion of CRL semantics :-). yes, there
is a CRL extension to express the notion of "I wish I had revoked 
this previously" but we don't support it in 5280, right?

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 28 Feb 2011 10:17:54 -0500

Steve,

As to your last comment, 5280 Section 5.3.2 does describe invalidity date.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, February 28, 2011 9:54 AM
To: Miller, Timothy J.
Cc: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

good point.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Feb 2011 17:10:29 +0100

On 11-02-24 6:27 PM, "Miller, Timothy J." <[email-masked]> wrote:

>Signature validation after certificate expiry is a *special case* that's
>already covered.  You validate using the CRL valid at the *time of
>signing*, not the final CRL from the PKI.
>

This in essence is the correct answer to the original question.
A last CRL issued after certificate expiry is not relevant for validating
that certificate. Unless the CRL includes the expired certificates on CRL
extension (not supported by RFC 5280), the certificate you are looking for
may not be listed in that CRL. Yet it may have been revoked.

/Stefan

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2011 11:43:00 -0500

>As to your last comment, 5280 Section 5.3.2 does describe invalidity date.

That's a pity; it's a bad idea and I thought we deprecated it. Guess 
another one slipped through :-).

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 28 Feb 2011 13:38:26 -0500

Steve,

Why do you think it is a bad idea?

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, February 28, 2011 11:43 AM
To: Santosh Chokhani
Cc: Miller, Timothy J.; IETF PKIX
Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2011 16:46:55 -0500

>Why do you think it is a bad idea?

because it legitimizes the notion of "whoops, I should have revoked this
earlier, but I'm telling you now," i.e., a CRL "mulligan."

For NR purposes, an RP needs to know by which time it can acquire and 
archive a CRL for future reference, in case of a dispute. As others 
have noted, we did not
make this potentially useful info available in machine readable form, 
i.e., in an extension. So, absent that capability, I think the 
feature in question is of marginal use.

An RP that knows that it needs to wait for a specified interval for 
issuance of a CRL that will, once and for all, allow the RP to act on 
a transaction does not benefit from this "feature"  if the cert in 
question is not revoked.  If the cert is retroactively revoked, but 
after the transaction date, then there is utility. But, it is not 
clear how often this situation arises, and thus whether it is worth 
the added complexity and confusion caused by the feature.

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 28 Feb 2011 19:12:04 -0500

Steve,

The pro of having this feature is that archival of CRL provides you with something useful for investigatory purposes.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, February 28, 2011 4:47 PM
To: Santosh Chokhani
Cc: Miller, Timothy J.; IETF PKIX
Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?

Steve