RE: CRL Processing Algorithm

Mauricio,

I think the following current text from section 6.3 is sufficient:

   This algorithm assumes that all of the needed CRLs are available in a
   local cache.  Further, if the next update time of a CRL has passed,
   the algorithm assumes a mechanism to fetch a current CRL and place it
   in the local CRL cache.

This text is also present in rfc3280bis.

Matt Cooper wrote:
> 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.

More so, since most implementations treat nextUpdate also as an expiration field (since there is no other
date to indicate when the CRL is too old to be used), Microsoft CA also adds another optional non-critical
CRL extension "Next Publish". This in practice works as an optional extra nextUpdate field to specify
when a new CRL is likely to be available even before the NextUpdate time. This provides a natural grace
period between NextPublish and NextUpdate for those understanding the extension.

Extension OID 1.3.6.1.4.1.311.21.4

Structure:
   --------------------------------------------
    --  Choice of Time: UTCTime before 2005, GeneralizedTime
    --  starting in 2005.
    --------------------------------------------
    ChoiceOfTime ::= CHOICE {
        utcTime                 UTCTime,
        generalTime             GeneralizedTime
    }

I think one of the reasons NextUpdate originally was treated as a hard deadline by SC logon was since SCL was
used to seeing this extension to refresh the CRL before it expires.
This is an example of "practical" patching of standards as a response to implementation realities and it
happened many years ago.

This is a bit confusing but in practice I think the standard had been better off with 2 dates from the
beginning. A "next update" and a "valid until" field would have solved this. But this is not the case and now
is way too late to change it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Matt Cooper
> Sent: den 30 augusti 2007 17:55
> To: ietf-pkix <at> imc.org
> Cc: Mauricio Balassiano
> Subject: RE: CRL Processing Algorithm
>
>
>
> 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: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Mauricio Balassiano
> Sent: Wednesday, August 29, 2007 5:17 PM
> To: 'Russ Housley'; ietf-pkix <at> imc.org
> 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: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
> Em nome de Russ Housley Enviada em: quarta-feira, 29 de agosto de 2007
> 15:46
> Para: ietf-pkix <at> imc.org
> 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
>
> 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.
> >
> >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/>
> >CERTISIGN
> >Mauricio Schueftan Balassiano
> >Departamento de Normas e Gerência de PKI
> >(21) 4501 1850
> >
> >Certisign Certificadora Digital
> ><http://www.certisign.com.br>certisign.com.br
> >
> >