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

From: "Andris Berzins" <[email-masked]>
Date: Thu, 03 Jan 2013 14:02:15 +0200

OK. Let's assume situation where end entity requests certificate to be revoked, but next CRL will be published only 
after this currently valid certificate will be expired.

Very interesting situation. So the goal of rfc5280 is to archive the fact that it was revoked before it expired on at 
least one published CRL.

But does it make sense?

Let's assume that relying party checked freshest CRL and concluded that presented certificate is valid (although 
CA already received revocation request). So the relying party did some damaging actions by the request of end 
entity.  Does this feature, that end entity can proof that its cert was revoked before it expired, makes relying party 
to rollback that transaction although relying party checked CRL at that time correctly?

Perhaps I can generalize the question.
Is relying party obligated to take the risk that although current CRL says that cert is not revoked, the next published 
CRL can tell that at that time revocation request was already received.
Or is end entity liable and has to take risk that even if revocation is requested now, the revocation will take legal 
effect only after CA's CRL's nextUpdate date is reached?

Quoting "Santosh Chokhani" <[email-masked]>:
> Andris,
> 
> The rationale behind this is to provide for archive and future verification 
>(e.g., for non-repudiation purposes) for .
> 
> Let us make the following assumptions:
> 
> 
> 1.     The CRLs are the official archive.
> 
> 2.     Delta CRLs are not the official archive
> 
> 3.     A new CRL Y can be built using the previous CRL X and a delta issued 
>when Y is issued.
> 
> In that case, you want a certificate on at least one CRL and maintain on del
>ta until it is recorded in a CRL that is archived.
> 
> 5280 language is unnecessarily constraining.  It should state, “expired cert
>ificates shall be removed from the CRL, except a revoked certificate shall a
>ppear on at least one CRL.
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andr
>is Berzins
> Sent: Thursday, December 27, 2012 3:06 PM
> To: [email-masked]
> Subject: [pkix] why revoked certificate entry has to be included in one CRL 
>issued beyond certificate validity period
> 
> rfc5280 states:
> 
> "An entry MUST NOT be removed
> from the CRL until it appears on one regularly scheduled CRL issued
> beyond the revoked certificate's validity period."
> 
> and
> 
> "If a certificate revocation notice first appears on a delta CRL, then
> it is possible for the certificate validity period to expire before
> the next complete CRL for the same scope is issued.  In this case,
> the revocation notice MUST be included in all subsequent delta CRLs
> until the revocation notice is included on at least one explicitly
> issued complete CRL for this scope."
> 
> Why is that required?

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 3 Jan 2013 14:13:52 +0100

Andris,

For non-repudiation purposes (e.g. QES) CRL's nextUpdate date is not used.
Validation is based only on information whose status is stable and was already finished in the past.

Only thisUpdate date of CRL is used for non-repudiation purposes.

The date on which the revocation occurred is specified in revocationDate field of CRL but the real e.g. compromise was earlier than is the time value in revocationDate. The revocationDate of a CRL does not give you the real time when a certificate was revoked but the revocationDate is the START of the interval since when a certificate is to be invalid according to signed evidence created by CA.

The real revocation date will be earlier than is the date in the revocationDate field of CRL e.g. according to judgement in court.

And as was it clarified by Piyush in thread 2560bis:
"according to 5280, revocationDate cannot precede thisUpdate of an earlier CRL if the revocation for the certificate is being reported the first time.

Not saying that OCSP has to follow these rules, but given that it is deviating from CRLs on the meaning of revocationTime and revocationReason, a separated section describing these fields should be added. "

Peter Rybar
National Security Authority
Information Security and Electronic Signature Department

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andris Berzins
Sent: Thursday, January 03, 2013 1:02 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

But does it make sense?

> issued complete CRL for this scope."

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

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Jan 2013 13:37:48 +0000

Consider validation of an archived signature and all will become clear.  :)  E.g., if the action is the signing of a contract, the actual validation of the signature may be long after expiry of all certs in the signature--for example, when the contract is contested in court.  Proving validity at time of signing is important in this case, and the requirement to appear on at least one CRL is critical to that proof.

Yes, in a TLS or transactional context, appearance on a CRL after expiry doesn't make a difference, but PKI has more use cases than that.

-- T

>Sent: Thursday, January 03, 2013 7:02 AM
>To: Santosh Chokhani
>Cc: [email-masked]
>Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL
>OK. Let's assume situation where end entity requests certificate to be
>revoked, but next CRL will be published only

---

From: "Andris Berzins" <[email-masked]>
Date: Thu, 03 Jan 2013 15:49:05 +0200

Quoting "Peter Rybar" <[email-masked]>:
> The date on which the revocation occurred is specified in revocationDate fie
>ld of CRL but the real e.g. compromise was earlier than is the time value in
> revocationDate. The revocationDate of a CRL does not give you the real time
> when a certificate was revoked but the revocationDate is the START of the i
>nterval since when a certificate is to be invalid according to signed eviden
>ce created by CA.

Remember that there is even "invalidation date" entry extension that might much more way back.

> 
> The real revocation date will be earlier than is the date in the revocationD
>ate field of CRL e.g. according to judgement in court.

Nice. So what the relying party should do? If the relying party checks CRL that is current (current time between 
thisUpdate and nextUpdate), it still risks that in next CRL revocation date might be precede current time of check 
or the court will rule that real revocation was much earlier and thus relying party has to take losses?

> "according to 5280, revocationDate cannot precede thisUpdate of an earlier C
>RL if the revocation for the certificate is being reported the first time.
> 
> Not saying that OCSP has to follow these rules, but given that it is deviati
>ng from CRLs on the meaning of revocationTime and revocationReason, a separa
>ted section describing these fields should be added. "
> 
> 
> Peter Rybar
> Subject: Re: [pkix] why revoked certificate entry has to be included in one 
>CRL issued beyond certificate validity period
> 
> Very interesting situation. So the goal of rfc5280 is to archive the fact th
>at it was revoked before it expired on at
> least one published CRL.
> 
> But does it make sense?
> 
> entity.  Does this feature, that end entity can proof that its cert was revo
>ked before it expired, makes relying party
> Is relying party obligated to take the risk that although current CRL says t
>hat cert is not revoked, the next published
> Or is end entity liable and has to take risk that even if revocation is requ
>ested now, the revocation will take legal

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Jan 2013 14:07:38 +0000

>party has to take losses?

You can only act on what you know at the time you need to act.  What happens in a dispute is up to the judge at the time of the dispute--which is in the future--so isn't part of that calculus.  The situation is analogous to an in-person fraud committed by a con-man with forged corporate endorsements; the defrauded party is entitled to recoup losses, but whether he can recoup from the misrepresented corporation depends on the specific facts of the case (e.g., if there was negligence or complicity).

-- T

---

From: "Andris Berzins" <[email-masked]>
Date: Thu, 03 Jan 2013 16:09:13 +0200

Quoting "Miller, Timothy J." <[email-masked]>:
> Consider validation of an archived signature and all will become clear.  :) 
> E.g., if the action is the signing of a contract, the actual validation of 
>the signature may be long after expiry of all certs in the signature--for ex
>ample, when the contract is contested in court.  Proving validity at time of
> signing is important in this case, and the requirement to appear on at leas
>t one CRL is critical to that proof.

So this is for CA's own record keeping (assuming it has no other database of revocation than published CRL's). For 
relying party it makes no sense, because relying party is not and can not be obligated to collect all CA's issued 
CRLs. But even then, so what that the CA knows that the cert was revoked some small time before expiration, if it 
could not distribute that information by the time when the relying party made the decision?

> Yes, in a TLS or transactional context, appearance on a CRL after expiry doe
>sn't make a difference, but PKI has more use cases than that.

For signatures you would first need to prove the time of signing, by using timestamp, which in most deployments 
would also assure that on the time of timestamping the certificate was valid.

>>CRL

---

From: "Andris Berzins" <[email-masked]>
Date: Thu, 03 Jan 2013 16:22:05 +0200

Quoting "Miller, Timothy J." <[email-masked]>:
>> Nice. So what the relying party should do? If the relying party checks CRL t
>>hat
>> is current (current time between
>> or the court will rule that real revocation was much earlier and thus relyin
>>g
>> party has to take losses?
> 
> You can only act on what you know at the time you need to act.  What happens
> in a dispute is up to the judge at the time of the dispute--which is in the
> future--so isn't part of that calculus.  The situation is analogous to an i
>n-person fraud committed by a con-man with forged corporate endorsements; th
>e defrauded party is entitled to recoup losses, but whether he can recoup fr
>om the misrepresented corporation depends on the specific facts of the case 
>(e.g., if there was negligence or complicity).
> 
> -- T

What would you recommend for relying party? Is it safe to execute transaction after checking cert validity in CRL 
who's thisUpdate is current and nextUpdate is in future? Or am I still at risk that in next CRL CA can declare that 
certificate at that time was already revoked and I might have to recoup losses?

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 03 Jan 2013 15:27:11 +0100

Peter,

I think you are mixing up the terminology.

There is only one revocation date.
Whether you can convince the court that you did not use your private key
at some event is another thing. They will look at all facts of the case,
technical and non-technical.

/Stefan

On 1/3/13 2:13 PM, "Peter Rybar" <[email-masked]> wrote:

>The date on which the revocation occurred is specified in revocationDate
>field of CRL but the real e.g. compromise was earlier than is the time
>value in revocationDate. The revocationDate of a CRL does not give you
>the real time when a certificate was revoked but the revocationDate is
>the START of the interval since when a certificate is to be invalid
>according to signed evidence created by CA.
>
>The real revocation date will be earlier than is the date in the
>revocationDate field of CRL e.g. according to judgement in court.
>
>"according to 5280, revocationDate cannot precede thisUpdate of an
>earlier CRL if the revocation for the certificate is being reported the
>first time.
>
>Not saying that OCSP has to follow these rules, but given that it is
>deviating from CRLs on the meaning of revocationTime and
>revocationReason, a separated section describing these fields should be
>added. "
>
> 
>Peter Rybar
>Subject: Re: [pkix] why revoked certificate entry has to be included in
>one CRL issued beyond certificate validity period
>
>Very interesting situation. So the goal of rfc5280 is to archive the fact
>that it was revoked before it expired on at
>least one published CRL.
>
>But does it make sense?
>
>entity.  Does this feature, that end entity can proof that its cert was
>revoked before it expired, makes relying party
>Is relying party obligated to take the risk that although current CRL
>says that cert is not revoked, the next published
>Or is end entity liable and has to take risk that even if revocation is
>requested now, the revocation will take legal
>> 5280 language is unnecessarily constraining.  It should state, ³expired
>>cert

---

From: "Andris Berzins" <[email-masked]>
Date: Thu, 03 Jan 2013 16:36:32 +0200

If talking about courts, are there any case studies available or known cases?

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 03 Jan 2013 15:39:35 +0100

Andris,

Depending upon the kind of transaction, you can apply a grace period or not.

If you do not apply a grace period, you need to accept a risk.
If you apply a grace period, you don't take the risk, but you must wait
until the end of the grace period to validate the transaction (i.e. the 
signature).

For details about the grace period; see, for example, ETSI TS 101 903 
(pages 19 and 20).

Denis

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 3 Jan 2013 15:49:28 +0100

OK,
The compromise date will be earlier than is the date in the
revocationDate field of CRL e.g. according to judgement in court.

Revocation date is only ONE value (when is used only in CRL), but is it really the same time value of revocation in CRL (revocationDate) and also in OCSP (revocationTime)?

As was indicated, OCSP definition in RFC is not precise about the value of revocationTime when also revocationDate of CRL is used.

Peter

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, January 03, 2013 3:27 PM
To: Peter Rybar; 'Andris Berzins'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

Peter,

/Stefan

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 3 Jan 2013 16:07:11 +0100

> Nice. So what the relying party should do?

Wait for CRL or for OCSP where the time included in thisUpdate field is after the time to which the validation is expected (time-stamp or audit trail).

It means the grace period (mentioned by Denis) is dynamic and was finished in the time when the time value in thisUpdate of CRL/OCSP was greater than the time to which you validate the certificate.

Some documents are at address:
http://www.nbusr.sk/en/electronic-signature/verification.1.html

Certificate Path Validation (pdf, 354.4 kB)
http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/kontrola_cert_cesty_en.pdf 

Peter Rybar

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 03 Jan 2013 16:36:52 +0100

>Nice. So what the relying party should do?

Realize that we are not living in a perfect world.
Evaluate the risk vs. the benefits from using this imperfect technology
and make a reasonable decision.

/Stefan

---

From: "Andris Berzins" <[email-masked]>
Date: Thu, 03 Jan 2013 21:10:11 +0200

Quoting "Peter Rybar" <[email-masked]>:
> Wait for CRL or for OCSP where the time included in thisUpdate field is afte
>r the time to which the validation is expected (time-stamp or audit trail).
> 
> It means the grace period (mentioned by Denis) is dynamic and was finished i
>n the time when the time value in thisUpdate of CRL/OCSP was greater than th
>e time to which you validate the certificate.

Greater than is not enough. Relying party is supposed to get next published CRL or else if any of CRLs published 
are missed then:
1. Certificate could have been revoked short before expiration and relying party missed that single published CRL 
beyond certificate expiration.
2. Certificate could have been "on hold" and now is released. Without parsing all published CRLs relying party can 
not detect this.

By the same analogy this grace period approach should be applied to whole path not only on end entity certificate. 
For example, if root CA publishes CRL for intermediate CA's once in 3 month, then grace period has to be 3 month 
or else relying party takes a risk?

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 04 Jan 2013 09:46:39 +0100

Andris,

The risk of a compromise or of a revocation of a signer's private key is 
much higher that the risk of revocation of a CA.
A signer's might even ask for the revocation of its certificate whereas 
it is not justified by a stolen card and a stolen PIN.
So applying an additional specific grace period for CAs does not make 
sense.

If revocation happens very close to the date contained within the 
time-stamp token, some software might say: the signature
is valid, some other will say the signature is not valid.  In some 
cases, the electronic signature may have been made by the
right signer, but under constraints or under the use of drugs.

So it is not because a signature is technically valid, that it cannot be 
challenged by the signer.
The same applies with manual signatures.

Denis

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 4 Jan 2013 09:52:40 +0100

> CA publishes CRL once in 3 month, then grace period has to be 3 month

The maximum grace period when CA publishes CRL once in 3 month is 3 month but CRL or OCSP response can be published also before the time period indicated in nextUpdate.

The value in nextUpdate is only a wish or presumption of CA when CA must be able to publish and at least one CRL will be published.
The nextUpdate value of OCSP indicates that OCSP service is not finished and at least in nextUpdate period new request/response can be processed.

CRL can be issued each 5 hours with nextUpdate set on 3 month.

It means validation algorithm is based on the value included in thisUpdate field. 
The value in nextUpdate is only information for decision "how max long" it is possible to wait but it is not included in validation conditions.

The risk, as was pointed by Stefan, is when thisUpdate is before the time to which validation is realized because OCSP or CRL issued later can revoke certificate.

The time line: thisUpdate-1, thisUpdate-2, time to which validation is realized, thisUpdate-3, thisUpdate-4.

Only CRLs/OCSPs issued with thisUpdate-3 or thisUpdate-4 time values are stable.

CRLs/OCSPs issued with thisUpdate-1 or thisUpdate-2 time values are used with potential risk - certificate could be revoked before the time to which validation is realized (TIME-STAMP or audit trail) in later CRL/OCSP (this situation with such potential risk is always in on-line services e.g. when SSL/TSL certificates are used and RFC5280 validation algorithm is defined with such potential risk for on-line services based on certificate usage).

Peter Rybar

---

From: "Andris Berzins" <[email-masked]>
Date: Fri, 04 Jan 2013 13:51:56 +0200

Quoting "Peter Rybar" <[email-masked]>:
> The risk, as was pointed by Stefan, is when thisUpdate is before the time to
> which validation is realized because OCSP or CRL issued later can revoke ce
>rtificate.
> 

thisUpdate-4 is not stable, because in thisUpdate-3 the cert could have been marked as "onHold" with revocation 
date before validation is realized.

> 
> CRLs/OCSPs issued with thisUpdate-1 or thisUpdate-2 time values are used wit
>h potential risk - certificate could be revoked before the time to which val
>idation is realized (TIME-STAMP or audit trail) in later CRL/OCSP (this situ
>ation with such potential risk is always in on-line services e.g. when SSL/T
>SL certificates are used and RFC5280 validation algorithm is defined with su
>ch potential risk for on-line services based on certificate usage).
> 
> Peter Rybar
> 
> Subject: RE: [pkix] why revoked certificate entry has to be included in one

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 4 Jan 2013 14:40:45 +0100

The usage of certificateHold is forbidden in some systems and also by legislation in some EU countries.

It is unclear how long the certificate can be in certificateHold status because the final result revoked or not revoked is after unknown period of investigation during certificateHold.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 4 Jan 2013 14:07:20 +0000

>date before validation is realized.

So what?  

-- T

---

From: "Andris Berzins" <[email-masked]>
Date: Fri, 04 Jan 2013 16:58:57 +0200

>> date before validation is realized.

So to verify revocation status, relying party is obligated to collect all consecutive CRL publications without missing 
one.

Conclusion - CRLs can not be used to determine revocation status accurately even with grace period workarounds.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Jan 2013 16:20:12 +0100

On 1/4/13 3:58 PM, "Andris Berzins" <[email-masked]> wrote:

>So to verify revocation status, relying party is obligated to collect all
>consecutive CRL publications without missing
>one.
>
>Conclusion - CRLs can not be used to determine revocation status
>accurately even with grace period workarounds.

Revocation is a reactive countermeasure. That makes it by definition
imperfect. There will always be a time window before information about the
breach is available and there will always be some degree of uncertainty
about when the breach actually took place.

Quite some security measures used today have this limitation.

That does not make it useless!
It just make it what it is, a tool for reducing risk, not eliminating it.

For those who can mange risk, this technology is actually quite useful.

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 4 Jan 2013 15:25:34 +0000

In order to determine revocation status accurately, an RP needs one CRL.

In order to determine hold status up to a certain frequency resolution, the RP would need samples (CRLs) above the Nyquist rate.   If a certificate could be put on hold and removed from it with 1 hour resolution and an RP had some reason to collect a historical record of all the hold periods over a one year interval, it would need a lot of samples :-).  Advocates for hold can present use cases and CRL sampling requirements to address those requirements, but AFAIK DoD has no requirement to ever use, much less archive, hold status.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andris Berzins
Sent: Friday, January 04, 2013 9:59 AM
To: Miller, Timothy J.
Cc: 'Stefan Santesson'; [email-masked]
Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

Quoting "Miller, Timothy J." <[email-masked]>:
>> thisUpdate-4 is not stable, because in thisUpdate-3 the cert could 
>> have been marked as "onHold" with revocation date before validation 
>> is realized.
> 
> So what?

So to verify revocation status, relying party is obligated to collect all consecutive CRL publications without missing one.

---

From: "Andris Berzins" <[email-masked]>
Date: Fri, 04 Jan 2013 19:21:29 +0200

> For those who can mange risk, this technology is actually quite useful.

Or relying party can use OCSP that serves status information directly from CA repository.

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 5 Jan 2013 06:08:09 +0530

Hi Andris,

Please see inline.

> Sent: Friday, January 04, 2013 12:40 AM
> To: Peter Rybar
> > Wait for CRL or for OCSP where the time included in thisUpdate field
> >is afte r the time to which the validation is expected (time-stamp or audit
> trail).
> >
> > It means the grace period (mentioned by Denis) is dynamic and was
> >finished i n the time when the time value in thisUpdate of CRL/OCSP was
> >greater than th e time to which you validate the certificate.
> 
> Greater than is not enough. Relying party is supposed to get next published
> CRL or else if any of CRLs published are missed then:
> 1. Certificate could have been revoked short before expiration and relying
> party missed that single published CRL beyond certificate expiration.
> 2. Certificate could have been "on hold" and now is released. Without parsing
> all published CRLs relying party can not detect this.
[Piyush]True for the corner case where certificate is about to expire. You can address it by applying the grace period to certificate expiry i.e. prohibit the use of certificates if the time to expiry is less than the grace period.
> For example, if root CA publishes CRL for intermediate CA's once in 3 month,
> then grace period has to be 3 month or else relying party takes a risk?
>
[Piyush] The difference between thisUpdate and nextUpdate does not necessarily maps to the frequency of CRL publishing. Most root CAs would issue a new CRL immediately when the content of revocation list changes. The relying parties should check for newer CRLs even if the CRL in their possession is currently valid.
 
> > http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-
> podpis/legislativ
> >a/kontrola_cert_cesty_en.pdf
> >
> > Peter Rybar
> >
> >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >>> Andris Berzins
> >>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> >>>> Andr
> >>>> is Berzins

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Jan 2013 10:31:39 -0500

Peter,

On 1/4/13 3:52 AM, Peter Rybar wrote:
> The value in nextUpdate is only a wish or presumption of CA when CA 
> must be able to publish and at least one CRL will be published. 
The CPS for a CA may state that the nextUpdate value is a binding 
commitment by the CA, contrary to
your comment above. In general, this value is a time/date by which the 
CA will publish a new CRL,
though that does not preclude publication prior to that time.

It also would be poor CA practice to regularly publish CRLs well short 
of the nextUpdate value,
as someone has suggested.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Jan 2013 10:37:27 -0500

> So to verify revocation status, relying party is obligated to collect all consecutive CRL publications without missing one.
Wrong.
> Conclusion - CRLs can not be used to determine revocation status accurately even with grace period workarounds.
0 for 2.

In reality, for NR purposes, an RP may be able to wait for the CRL 
issued after a transaction,
because CAs often issued (scheduled) CRLs on a daily basis. Also, an RP 
could simply refuse to
accept a cert from a transaction partner if the cert were about to expire.

Steve

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 8 Jan 2013 17:59:03 +0100

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?

Peter

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, January 07, 2013 4:32 PM
To: [email-masked]; [email-masked]
Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

Peter,

Steve