Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

The clients should nonce or should use the next update as a guideline.

This problem is not related to TLS alone.  Every relying party has to
deal with the freshness of revocation information. 

> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On 
> Behalf Of Kemp, David P.
> Sent: Friday, March 26, 2010 9:38 AM
> To: pkix@ietf.org; tls@ietf.org
> Cc: dev+ietf@seantek.com
> Subject: Re: [pkix] Possible revocation delay issue with TLS stapling
> 
> Another proof that the law of unintended consequences is 
> operating in full force.  Some time ago, guidance for how CRL 
> nextUpdate should be populated was discussed here.  One camp 
> suggested that nextUpdate should actually say when the next 
> CRL would be issued; the other camp suggested that because 
> some applications treat nextUpdate as an expiration, CRL 
> issuers should, for example, put nextUpdate 7 days in the 
> future for CRLs that are actually issued every 24 hours, 
> thereby treating scheduled CRLs as unscheduled.
> 
> Rather than defining a new "suggested expiration" CRL 
> extension for applications to use as a default, the WG by 
> inaction ratified the treatment of nextUpdate as a de-facto 
> expiration date.  The resulting confusing consequences were 
> predictable.
> 
> Dave
> 
> 
> -----Original Message-----
> From: Jean-Marc Desperrier
> 
> One thing I can confirm is that, as often the next CRL is 
> generated earlier that the next update in the CRL, I've seen 
> one actual CA case where the policy is such that getting the 
> latest CRL *could* get you a fresher info than getting an OCSP token.
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
> 