Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Jan 2013 12:48:25 -0500

Peter,

On 1/8/13 11:59 AM, Peter Rybar wrote:
> Steve,
> I agree, CA must be able to setup the time/date value in nextUpdate according to conditions defined e.g. in CPS.
> But the background of such rules is sometimes funny like it is not only according to max time while CA is able to recovery CA technology from some accident but also according to a number of days in holidays :-)
>
> What is wrong when CRL is regularly published, according to CPS, each one hour and nextUpdate is setup to 24 hours as indication that maximum recovery period is one day?
>
>

What's wrong is that RPs have no requirement to check for a new CRL 
before than the
indicated NextUpdate. Regularly publishing a CRL 20X more frequently 
than the indicated
nextUpdate suggests a confused CA. if the CA wants to publish CRLs 
regularly at 1 hour intervals,
then out that info into the CRLs.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 8 Jan 2013 18:47:50 +0000

On 1/8/13 11:48 AM, "Stephen Kent" <[email-masked]> wrote:

>> I agree, CA must be able to setup the time/date value in nextUpdate
>>according to conditions defined e.g. in CPS.
>> But the background of such rules is sometimes funny like it is not only
>>according to max time while CA is able to recovery CA technology from
>>some accident but also according to a number of days in holidays :-)
>>
>> What is wrong when CRL is regularly published, according to CPS, each
>>one hour and nextUpdate is setup to 24 hours as indication that maximum
>>recovery period is one day?
>
>before than the indicated NextUpdate. Regularly publishing a CRL 20X more
>frequently
>than the indicated nextUpdate suggests a confused CA. if the CA wants to
>publish CRLs
>regularly at 1 hour intervals, then out that info into the CRLs.

In practice, we found that RP software frequently attempts to find a fresh
CRL at higher periodicity than nextUpdate, but also presumes stale CRLs
are invalid and so will create denial of service when there's a retrieval
failure.  Producing CRLs at a higher frequency than indicated in
nextUpdate covers for this case; a transient failure in CRL availability
does not result in widespread DoS, because CRLs are valid for multiple
production intervals.  E.g., DoD CRLs are produced at 18 hour intervals,
but nextUpdate is set as production time + 7 days.

-- T

---

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Jan 2013 14:12:05 -0500

Tim,

Your example, and the rationale for it, are just what I worry about.
RP software is written badly, so a CA behaves poorly, to accommodate
the bad RP software. This is just another example of why accmmodating
bad software leads to more bad software ...

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 8 Jan 2013 19:22:51 +0000

While I appreciate and would prefer the BOFH approach to deficiency
remediation, practically speaking you can't push a rope.  :)  Absent an
enforcement regime (e.g., trademark licensing a la VPNC or USB-IF) we're
stuck with what we get.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 8 Jan 2013 21:33:31 +0000

To be fair, the last time this came up a few years ago PKIX missed the opportunity to define an Internet Private CRL Extension that would allow CAs to suggest a grace period beyond which RPs should not consider the CRL fresh.  If a standard useBy date were defined, consumers would have an easier time jawboning RP software vendors to stop treating nextUpdate as an expiration date. 

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, January 08, 2013 2:23 PM
To: Stephen Kent
Cc: pkix
Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

While I appreciate and would prefer the BOFH approach to deficiency remediation, practically speaking you can't push a rope.  :)  Absent an enforcement regime (e.g., trademark licensing a la VPNC or USB-IF) we're stuck with what we get.

-- T

>bad software leads to more bad software ...

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

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 8 Jan 2013 15:36:09 -0800

The question is - who is in the best position to determine that grace period
beyond CRL issuance time.
I would think that it is up to the RP to determine its risk window. 

CA should not and cannot make that determination for a relying party.

On the other hand, such a private extension would have given some comfort to
those RPs who are reluctant to define their own risk tolerance.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kemp, David P.
> Sent: Tuesday, January 08, 2013 1:34 PM
> To: pkix
> Subject: Re: [pkix] why revoked certificate entry has to be included in
one
> CRL issued beyond certificate validity period
> 
> To be fair, the last time this came up a few years ago PKIX missed the
> opportunity to define an Internet Private CRL Extension that would allow
CAs
> to suggest a grace period beyond which RPs should not consider the CRL
> fresh.  If a standard useBy date were defined, consumers would have an
> easier time jawboning RP software vendors to stop treating nextUpdate as
> an expiration date.
> 
> Dave
> 
> 
> 
> Subject: Re: [pkix] why revoked certificate entry has to be included in
one
> CRL issued beyond certificate validity period
>