Subject: CRL Processing Algorithm

From: "Mauricio Balassiano" <[email-masked]>
Date: Wed, 29 Aug 2007 11:59:10 -0300

Hi all,

Is the CRL Processing Algorithm described in RFC 3280 correct when it does
not require conforming implementations that support CRLs to verify that
current time is in between the CRL validity start date (This Update) and the
CRL next update ? 

According to the section 6.3.3 – CRL Processing - of RFC 3280, conforming
implementations must update the local CRL cache by obtaining a complete CRL
if the current time is after the value of the CRL next update field. In this
case, they must update the local CRL cache with the current complete CRL,
verify that the current time is before the next update value in the new CRL,
and continue processing with the new CRL.

Considering only these steps, implementations compliant to this algorithm
could update the local CRL cache with a badly issued complete CRL, for
example with a validity start date in some point in the future, and validate
certificates based on this CRL.

I suggest the update of this RFC in order to include as a requirement for
conformant implementations the necessity of verifying that the current time
is after the value of the CRL this update field and before the value of the
CRL next update field before updating the local CRL cache. That would make
much more sense as it would be a similar requirement to the basic
certificate processing algorithm, also described in this RFC, which requires
conformant implementations to verify if the certificate validity period
(period of time from not before through not after certificate fields)
includes the current time. 

Certificate Authorities, End-Entity Certificates and also CRLs, are
“electronic documents” that carries a pair of date and time indications,
indicating the start and end of the time period over which they are intended
to be used. Any attempt to use them out of this period should be denied by
the applications.   

Thanks,

  _____  

 <http://www.certisign.com.br>  <http://www.certisign.com.br/> CERTISIGN
<http://www.certisign.com.br> Mauricio Schueftan Balassiano
Departamento de Normas e Gerência de PKI
(21) 4501 1850

Certisign Certificadora Digital
certisign.com.br <http://www.certisign.com.br>

---

From: "Scott Shorter" <[email-masked]>
Date: Wed, 29 Aug 2007 10:22:40 -0700

Mauricio,
 
Regarding comparing the current time to the nextUpdate field, you cannot assume that the attempt to obtain a fresh CRL will be successful.  You do not want signature verification to fail completely if the CRL is unavailable (perhaps because the relying party is offline, has network difficulties, or the CA failed to issue the new CRL for whatever reason) - depending on the application it is often better to use a somewhat stale CRL than assume the certificate is revoked just because you haven't seen the latest one.  A good toolkit should report when a fresh CRL could not be retrieved, however, so that the relying application can act on that information if appropriate.
 
This is why the semantics of the CRL date fields differs from those in certificates - they aren't a validity period, only a guideline for when to expect a new CRL.
 
One should hope that the entities you trust to issue CRLs won't create them with thisUpdate fields in the future.

Regards,
Scott

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mauricio Balassiano
Sent: Wednesday, August 29, 2007 10:59 AM
To: 'pkix'
Subject: CRL Processing Algorithm

Hi all,

Is the CRL Processing Algorithm described in RFC 3280 correct when it does not require conforming implementations that support CRLs to verify that current time is in between the CRL validity start date (This Update) and the CRL next update ? 

According to the section 6.3.3 - CRL Processing - of RFC 3280, conforming implementations must update the local CRL cache by obtaining a complete CRL if the current time is after the value of the CRL next update field. In this case, they must update the local CRL cache with the current complete CRL, verify that the current time is before the next update value in the new CRL, and continue processing with the new CRL.

Considering only these steps, implementations compliant to this algorithm could update the local CRL cache with a badly issued complete CRL, for example with a validity start date in some point in the future, and validate certificates based on this CRL.

I suggest the update of this RFC in order to include as a requirement for conformant implementations the necessity of verifying that the current time is after the value of the CRL this update field and before the value of the CRL next update field before updating the local CRL cache. That would make much more sense as it would be a similar requirement to the basic certificate processing algorithm, also described in this RFC, which requires conformant implementations to verify if the certificate validity period (period of time from not before through not after certificate fields) includes the current time. 

Certificate Authorities, End-Entity Certificates and also CRLs, are "electronic documents" that carries a pair of date and time indications, indicating the start and end of the time period over which they are intended to be used. Any attempt to use them out of this period should be denied by the applications.   

Thanks,

________________________________

<http://www.certisign.com.br>   <http://www.certisign.com.br/>  <http://www.certisign.com.br> Mauricio Schueftan Balassiano
Departamento de Normas e Gerência de PKI
(21) 4501 1850

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Aug 2007 14:46:25 -0400

My memory is that this was discussed during the development of RFC 
2459, the predecessor to RFC 3280.  I did not check the archives, so 
take my memory with a grain of salt.

The idea is to allow the most recent CRL that is available to be 
used.  Perhaps the repository is unavailable to get a newer one, or 
perhaps the client is not connected to the network at the 
moment.  Policy might permit the use of the best available 
CRL.  Policy might also require one that is more timely.  The RFC 
does not dictate the policy.

Russ

At 10:59 AM 8/29/2007, Mauricio Balassiano wrote:
>Hi all,
>
>Is the CRL Processing Algorithm described in RFC 3280 correct when 
>it does not require conforming implementations that support CRLs to 
>verify that current time is in between the CRL validity start date 
>(This Update) and the CRL next update ?
>
>According to the section 6.3.3 – CRL Processing - of RFC 3280, 
>conforming implementations must update the local CRL cache by 
>obtaining a complete CRL if the current time is after the value of 
>the CRL next update field. In this case, they must update the local 
>CRL cache with the current complete CRL, verify that the current 
>time is before the next update value in the new CRL, and continue 
>processing with the new CRL.
>
>Considering only these steps, implementations compliant to this 
>algorithm could update the local CRL cache with a badly issued 
>complete CRL, for example with a validity start date in some point 
>in the future, and validate certificates based on this CRL.
>
>I suggest the update of this RFC in order to include as a 
>requirement for conformant implementations the necessity of 
>verifying that the current time is after the value of the CRL this 
>update field and before the value of the CRL next update field 
>before updating the local CRL cache. That would make much more sense 
>as it would be a similar requirement to the basic certificate 
>processing algorithm, also described in this RFC, which requires 
>conformant implementations to verify if the certificate validity 
>period (period of time from not before through not after certificate 
>fields) includes the current time.
>
>"electronic documents" that carries a pair of date and time 
>indications, indicating the start and end of the time period over 
>which they are intended to be used. Any attempt to use them out of 
>this period should be denied by the applications.
>
>Thanks,
>
><http://www.certisign.com.br/>
>CERTISIGN
>Mauricio Schueftan Balassiano
><http://www.certisign.com.br>certisign.com.br
>
>

---

From: "Mauricio Balassiano" <[email-masked]>
Date: Wed, 29 Aug 2007 17:57:45 -0300

Hi Scott,

Thanks for the response. I agree with you that not always the freshest CRL
will be available to the applications, but I still can’t understand the
advantage of not considering as a requirement the verification if the
current time is after the CRL this update field.  

What I could understand by your example “depending on the application it is
often better to use a somewhat stale CRL than assume the certificate is
revoked just because you haven't seen the latest one” is that applications
might have a CRL that is not the latest one but still use it to validate
certificates once the freshest CRL is unavailable. In that case, it is clear
that the current date need to be before the CRL next update field.

Now imagine the case where a CA issues and publishes a stale CRL with the
CRL this update filed in some point in the future. Applications, compliant
to the RFC 3280, that obtain that stale CRL could store it in cache and use
it to validate certificates until the current date is equal to the CRL next
update field.

Please let me know if that makes sense.       

Regards,

Mauricio

  _____  

De: Scott Shorter [mailto:[email-masked]] 
Enviada em: quarta-feira, 29 de agosto de 2007 14:23
Para: Mauricio Balassiano; pkix
Assunto: RE: CRL Processing Algorithm

Mauricio,

Regarding comparing the current time to the nextUpdate field, you cannot
assume that the attempt to obtain a fresh CRL will be successful.  You do
not want signature verification to fail completely if the CRL is unavailable
(perhaps because the relying party is offline, has network difficulties, or
the CA failed to issue the new CRL for whatever reason) - depending on the
application it is often better to use a somewhat stale CRL than assume the
certificate is revoked just because you haven't seen the latest one.  A good
toolkit should report when a fresh CRL could not be retrieved, however, so
that the relying application can act on that information if appropriate.

This is why the semantics of the CRL date fields differs from those in
certificates - they aren't a validity period, only a guideline for when to
expect a new CRL.

One should hope that the entities you trust to issue CRLs won't create them
with thisUpdate fields in the future.

Regards,
Scott

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mauricio Balassiano
Sent: Wednesday, August 29, 2007 10:59 AM
To: 'pkix'
Subject: CRL Processing Algorithm

Hi all,

Thanks,

  _____  

 <http://www.certisign.com.br>  <http://www.certisign.com.br/> CERTISIGN
<http://www.certisign.com.br/>  <http://www.certisign.com.br> Mauricio
Schueftan Balassiano
Departamento de Normas e Gerência de PKI
(21) 4501 1850

---

From: "Mauricio Balassiano" <[email-masked]>
Date: Wed, 29 Aug 2007 18:17:19 -0300

Hi Russ,

Thanks a lot for your response, but as I have answered Scott, I agree that
the repository for some reason can be unavailable and that the application
need to be allowed to use the most recent CRL, but in my opinion only if the
current time is in between the CRL this update and next update fields.

I also understand the the algorithm described in the RFC can be adapted to
the specific application policy, but why can't the minimum requeriment force
applications to verify also the CRL this update field in order to avoid
badly issued CRLs ?   

Thanks,
Mauricio

-----Mensagem original-----
De: [email-masked] [mailto:[email-masked]] Em
nome de Russ Housley
Enviada em: quarta-feira, 29 de agosto de 2007 15:46
Para: [email-masked]
Assunto: Re: CRL Processing Algorithm

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Aug 2007 18:24:28 -0400

>current time is in between the CRL this update and next update fields.

What you are saying above is just not an accurate characterization of 
the semantics of a CRL, as was noted previously.

Unlike a cert, a CRL does not expire. A fresher CRL is preferable to 
an older CRL, but both are still valid CRLs. The NextUpdate field was 
added to CRLs based on feedback from the early work on CRLs done in 
the PEM WG, and the PSRG before that. That field is an important 
piece of info for a relying party, as it tell the RP when it should 
expect to be able to acquire the next, scheduled CRL. But, as noted i 
previous messages, an RP may be unable to gain access to the CRL that 
was supposed to be issued at the indicated date/time, and so the RP 
is free to make use of the CRL it has.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 29 Aug 2007 17:05:42 -0700

You trust the CA to do things right.

Besides, if you did the time check, you will need to account for lack of clock synchronization.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mauricio Balassiano
Sent: Wednesday, August 29, 2007 5:17 PM
To: 'Russ Housley'; [email-masked]
Subject: RES: CRL Processing Algorithm

Hi Russ,

Thanks,
Mauricio

-----Mensagem original-----

Russ

At 10:59 AM 8/29/2007, Mauricio Balassiano wrote:
>According to the section 6.3.3 - CRL Processing - of RFC 3280,

---

From: "Matt Cooper" <[email-masked]>
Date: Thu, 30 Aug 2007 08:54:48 -0700

Hi Mauricio,

The behavior you are advocating has long been a misunderstanding of what nextUpdate means.  Let me first point out that the field in the CRL is called nextUpdate, *not* notAfter.  Unlike certificates, which express notAfter, CRLs do not expire.  They are a snapshot of the revocation list as it exists at time thisUpdate.  nextUpdate suggests to the relying party when they should seek fresher data - it does not infer that the data on hand is necessarily bad or unusable.  It is therefore up to the relying party to decide.

That said, many implementations today treat nextUpdate as an expiration date, just as you are suggesting.  In practice, this can lead to undesirable behavior because the implementation will wait until the nextUpdate has passed to attempt to obtain a CRL, and then fail if one is unavailable.  If the application is offline for some reason, or, if there is a network outage anywhere between the relying party and the CRL, the application is now unusable.

An example of this behavior is Microsoft Smart Card Logon (SCL).  Once configured on the domain, users can use a smart card to authenticate to the Domain Controller and logon to their workstation.  Problem here is that if for some reason the CRL for the user certificate is unavailable at the point nextUpdate passes, the user can not log on because the Domain Controller will reject it.  Now imagine that the CRL is unavailable because of a network problem and an entire corporation grinds to a halt when no one can log on in the morning.  That behavior is clearly unacceptable.  Microsoft recognized this was a problem and added a "grace period" setting that allows a Domain Controller to utilize CRLs for a fixed interval beyond the nextUpdate.

In the end, it is up to us, as the implementers, to create software that will function effectively in real world environments while meeting both the security and availability requirements of the end users.  Handling the nextUpdate of the CRL appropriately is critical to achieving this goal.  The specifics of how best to handle nextUpdate are dictated by the environment the application runs in, how high an assurance level is required, and how critical availability is.  For example, a server application that requires a very high level of assurance might require only the freshest CRL (in some environments, even fresher than the nextUpdate).  On the other hand, a low assurance end user application that must be available at all times might opt to use a cached CRL indefinitely until a newer one is available.

Best Regards,
 
Matt Cooper
CygnaCom Solutions
7925 Jones Branch Dr, Suite 5200
McLean, VA  22102
http://www.cygnacom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mauricio Balassiano
Sent: Wednesday, August 29, 2007 5:17 PM
To: 'Russ Housley'; [email-masked]
Subject: RES: CRL Processing Algorithm

Hi Russ,

Thanks a lot for your response, but as I have answered Scott, I agree that the repository for some reason can be unavailable and that the application need to be allowed to use the most recent CRL, but in my opinion only if the current time is in between the CRL this update and next update fields.

I also understand the the algorithm described in the RFC can be adapted to the specific application policy, but why can't the minimum requeriment force applications to verify also the CRL this update field in order to avoid
badly issued CRLs ?   

Thanks,
Mauricio

-----Mensagem original-----
De: [email-masked] [mailto:[email-masked]] Em nome de Russ Housley Enviada em: quarta-feira, 29 de agosto de 2007 15:46
Para: [email-masked]
Assunto: Re: CRL Processing Algorithm

My memory is that this was discussed during the development of RFC 2459, the predecessor to RFC 3280.  I did not check the archives, so take my memory with a grain of salt.

The idea is to allow the most recent CRL that is available to be used.  Perhaps the repository is unavailable to get a newer one, or perhaps the client is not connected to the network at the moment.  Policy might permit the use of the best available CRL.  Policy might also require one that is more timely.  The RFC does not dictate the policy.

Russ