Subject: [pkix] Doubt on revocation processing requirements

From: Jorge López <[email-masked]>
Date: Sat, 4 Sep 2010 12:55:07 +0200

Hi all,

I've got a straight question. Is there any time frame during which a CA
should process a revocation request?

For revocation request processing I mean that the CA evaluates the request
and, if accepted, schedules the inclusion of the corresponding certificate
info in the next CRL. That is, the revocationDate is established for such
request.

In other words, the CA receives the revocation request at time t_0, but
processes it at time t_1 (I guess that revocationDate is thus set to t_1).
Is there any restriction for t_1 - t_0 value?

I have not seen any related information in RFC 5280...

Best,

Jorge López

---

From: Kyle Hamilton <[email-masked]>
Date: Sat, 4 Sep 2010 22:46:48 -0700

Restriction of t_1 - t_0 is a policy decision which is not within the
scope of decisions made by PKIX.  Some PKIs may have more loose
requirements, since their certificates are not necessarily used to
secure transactions transactions with values high enough to warrant
immediate processing; others may have tighter requirements to protect
(for example) the data on the
corporate/governmental/defense-department network.  Different
environments can set their PKI up differently.

The revocationDate is when the CA processes the revocation request
(note that 'revocation' is a misnomer, carried over from X.509, for
the overloaded conglomeration of "this key is valid in the PKI but has
not transitioned to in-use status" [certificateHold], "this key is
valid even though it appears on a delta CRL" [removeFromCrl reason
code], and 'this key is to be considered invalid because' [the other
reason codes]).  The next guarantee of fresher revocation data is the
'notAfter' date on the issued CRL.  It would be good practice to
ensure that all revocation requests are processed before the next CRL
is issued, but there's no mandate from the specification itself.

-Kyle H

On Sat, Sep 4, 2010 at 3:55 AM, Jorge López <[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: Jorge López <[email-masked]>
Date: Sun, 5 Sep 2010 17:27:38 +0200

Thanks Kyle for the explanation.

Jorge López.

2010/9/5 Kyle Hamilton <[email-masked]>

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 07 Sep 2010 12:02:14 +0200

> On Sat, Sep 4, 2010 at 3:55 AM, Jorge López<[email-masked]>  wrote:
>> >  [...]

 > The revocationDate is when the CA processes the revocation request

I think that point should also be a policy matter, and may depend on the 
revocation reason.

But when key is to be considered invalid and if it can be determinated 
properly, t_0 sounds like a better default choice than t_1 for the 
revocation date.

In some case, it makes sense for the requester to be able to request an 
earlier revocation date than t_0 when he can determine the key was not 
to be trusted anymore after that earlier time.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 8 Sep 2010 14:03:36 -0400

In many cases it does not make sense for the revocation date to be prior to t_1 (i.e. the time when relying parties have the revocation information needed to process or reject transactions.)

If the user wishes to commit fraud and blame it on someone else, then allowing him to backdate revocation times provides the opportunity to do so.

Dave

---

From: [email-masked]
Date: Wed, 8 Sep 2010 15:59:53 -0700 (PST)

> I think that point should also be a policy matter, and may depend on the

Touché.  It likely *should* be okay for a 'keyCompromise' reason to be pre-dated, depending on the PKI's requirements.  However, this moves various things into policy that most organizations don't think about; see below.

'removeFromCrl' is a reason that shouldn't have a pre-dated response, as that's a statement that as of X date any holds on the authority conveyed by the certificate should be removed, and it's impossible to usefully pre-date that.  (This is only applicable to delta CRLs.)

> properly, t_0 sounds like a better default choice than t_1 for the

What would the semantics of this be?  Specifically, the semantics of "this key was relied upon, and there was no revocation status information available at, a time after the t_0 revocation date and before it was actually entered at t_1"?

Some would say that the liability for that kind of statement would be on the entity that didn't process the revocation request in a timely fashion -- i.e., the entity that has obligations if it doesn't state that the key is revoked between the time that the revocation request is received and when it is processed.

Others would say "the relying party must beware", but that does away with one of the largest benefits of using a PKI: the ability to push off onto a third party, which can have deep domain knowledge in what it takes to know and document that an entity exists, the task of knowing who a particular interaction is with.  If there's no liability to the relying party for circumstances like key compromise, what is the point?

Still others might say that "it's not a notice that it was revoked as of a particular time, it's a notice that it *should have been revoked* at that particular time."  This would allow CRL processing to turn into a retrospective transaction verifier, and might serve to automatically raise alerts that reliances made by RPs after the revocationDate need to be followed up on, either to undo the transaction or to trace the information theft or whatever.

> earlier revocation date than t_0 when he can determine the key was not to be
> trusted anymore after that earlier time.

S/MIME?  TLS client authentication?  TLS server authentication?  Locally-defined mechanisms?  S/MIME might be appropriate, since presentations and decisions aren't made only once, but rather every time the message is viewed.  TLS clients typically don't have follow-ups on their authenticated certificates, and generally TLS servers don't either (since they can be rekeyed and re-certified via completely different PKIs and the client typically doesn't even bat an eye).

This isn't to say that some PKIs have stronger requirements, and I will be the first to say that there are things that should be outside the scope of the standards, particularly when it comes to policy decisions that are made due to the local value protected.  The standard shouldn't dictate a particular behavior which is more appropriately set in the local policy, except in the most basic form.  It should not try to be universally useful for all circumstances and thus rely on local implementations to figure out how to work around undesirable characteristics that are more appropriately policy decisions (and thus break the assumptions that were made in the threat model, causing them to be pushed out to the implementor who is generally much less crypto-savvy than those who hang around here).

-Kyle H

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 09 Sep 2010 13:33:35 -0400

I think RFC 5280 is very clear about the meaning of revocationDate.  
Section 5.1.2.6 indicates that it is "The date on which the revocation 
occurred".  This is further supported by Section 5.3.2, which also 
provides a meaning for indicating something close to when the 
certificate "should have been revoked":

    The invalidity date is a non-critical CRL entry extension that
    provides the date on which it is known or suspected that the private
    key was compromised or that the certificate otherwise became invalid.
    This date may be earlier than the revocation date in the CRL entry,
    which is the date at which the CA processed the revocation.  When a
    revocation is first posted by a CRL issuer in a CRL, the invalidity
    date may precede the date of issue of earlier CRLs, but the
    revocation date SHOULD NOT precede the date of issue of earlier CRLs.
    Whenever this information is available, CRL issuers are strongly
    encouraged to share it with CRL users.

Dave

On 09/08/2010 06:59 PM, [email-masked] wrote:
> On Tue, Sep 7, 2010 at 3:02 AM, Jean-Marc Desperrier<[email-masked]>  wrote:
>    
>> Kyle Hamilton wrote:
>>

---

From: Jorge López <[email-masked]>
Date: Sun, 12 Sep 2010 18:39:26 +0200

Hi again,

I am particularly concerned with the next scenario:

Let's suppose a subscriber that requests the revocation of certificate c1,
indicating time t_0 as the time on which he suspects that the private key
was compromised (i.e. invalidityDate). The CA receives the revocation
request at time t_1, but do not process it till time t_3. Meanwhile, at time
t_2 (t_1 < t_2 < t_3) the CA publishes a new CRL without -obviously- the
revocation information about c1. Therefore, delay t_3 - t_1 prevents the CA
from publishing a properly updated CRL at time t_2. (question: is this
possible? is the CA mandated to process all revocation request before
publishing a new CRL or is it a policy issue again?).

A relying party that is validating certificate c1 at a time later than t_0
but before t_2, and following the IETF/ETSI/etc. recommendations, waits the
grace period before concluding about the validity or invalidity of such
certificate. Because next CRL is published at time t_2, that is the one used
for the certificate status validation, reaching the conclusion that the c1
is valid. Neither the invalidityData helped to solve this problematic
scenario.

I've learnt from this thread (thanks all) that the revocationDate depends on
policy issues in the last term. However, the liability matters seems to be
still an obscure thing, though in previous example, and IMHO, the CA should
be the one liable for such an outdated revocation information.

European Directive on electronic signatures clearly states in art. 4.2 that
"As a minimum Member States shall ensure that a
certification-service-provider who has issued a certificate as a
qualified certificate to the public is liable for damage caused to
any entity or legal or natural person who reasonably relies on
the certificate for failure to register revocation of the certificate unless
the certification-service-provider proves that he has not acted
negligently".

Also, Annex II indicates that "Certification-service-providers must [...]
ensure the operation of a prompt and secure directory and a secure and
immediate revocation service;"

Therefore, implementing this legislation might imply developing an inmediate
revocation request processing. That is, t_3 - t_1 = 0. Is there anyone from
CA's world that could explain how this is implemented and solved in
real-world cases?

Thanks in advance,

-----
Jorge L. Hernández-Ardieta

2010/9/9 David A. Cooper <[email-masked]>

> occurred".  This is further supported by Section 5.3.2, which also provides
> a meaning for indicating something close to when the certificate "should
> have been revoked":
>
>> Still others might say that "it's not a notice that it was revoked as of a
>> particular time, it's a notice that it *should have been revoked* at that
>> particular time."  This would allow CRL processing to turn into a
>> retrospective transaction verifier, and might serve to automatically raise
>> alerts that reliances made by RPs after the revocationDate need to be
>> followed up on, either to undo the transaction or to trace the information
>> theft or whatever.
>>
>>
>
>

---

From: Kyle Hamilton <[email-masked]>
Date: Sun, 12 Sep 2010 17:17:57 -0700

I am not a lawyer (standard disclaimer), the following is not legal
advice, it's merely the way I see things.

There are two ways to define "not acted negligently".  First, it is
entirely reasonable to require an HSM to authenticate the reader
before access, and that provides for a means for someone to enter a
PIN to allow access to the CA key about 15 minutes before the
"notAfter" time on the prior CRL.  If CRLs are specified (in the CP
and CPS) as being generated on that schedule, and if OCSP is specified
as being updated no less often than CRL, then it means that the design
of the PKI emphasizes security of the CA key over immediacy of
revocation information.  (A designated OCSP responder can be put into
place after the fact if more timely revocation information is
necessary; a CA is simply the electronic signing key of a corporation
or natural person, used to convey records of trust decisions made
regarding the entities it chooses to certify.  That means that a CA
can sign an OCSP responder certificate if the example CA's operator
decides that they don't want to rearchitect the PKI, but they want to
provide more timely answers.)

The alternative is "We acted on this within 5 minutes of it being
brought to our attention and authenticating the person making the
claim."  Which is entirely reasonable -- in most corporations, 30
minutes to 2 hours would be reasonable due to passphrase owners and
keyshare holders needing to get to locations where they can do
whatever they need to do with whatever software they need to use and
the tokens that make the PKI more secure.

I think that it's most appropriate to recognize that a CA's best
interest is usually to process all verified-valid revocation requests
before producing a new CRL -- there's no need to specify it, as what
you're describing would very likely be considered "negligent".  But
that's not for us technical people to say, that's up to the
organizations which have evolved over time to settle disputes (courts)
to say.  We *cannot* take that power away from those organizations.
Courts exist because there are *always* corner cases where the line
isn't clear.  For example, the end entity could be worked up and
failing to authenticate himself properly, and the CA representative
only manages to get the authentication done 3 minutes after the
notAfter time.  Who's responsible for that one?  Are the policies for
authentication unnecessarily arduous?  Or is the end entity at fault
for not being coherent enough to authenticate properly?  That is one
problem with trying to understand "liability" as a binary 1 or 0...
and the edge-cases come out more sharply the more rules (and thus
exclusions) are made.

-Kyle H

On Sun, Sep 12, 2010 at 9:39 AM, Jorge López <[email-masked]> wrote:
>>> Still others might say that "it's not a notice that it was revoked as of
>>> a particular time, it's a notice that it *should have been revoked* at that

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 13 Sep 2010 19:21:47 +0200

Jorge López wrote:
> I've learnt from this thread (thanks all) that the revocationDate
> depends on policy issues in the last term.

My understanding of David's last message is that I stand corrected on 
this, and that RFC5280 (in paragraph 5.3.2) is quite explicit about the 
fact revocationDate is explicitly the time at which the request was 
processed, with little space for interpretation and policy issues.
In particular, that date SHOULD be later than the issuance date of the 
latest previous CRL.

The Invalidity Date CRL extension is the one to be used when you want to 
include inside the CRL the date about which you have received 
information is the latest at which the key was to be considered trusted, 
disregarding when exactly the CA was able to process the request or the 
issue with the key was reported.

Though RFC 5280 taken in full is clear about that, I think a good part 
of paragraph 5.3.2 is providing guidance about the use of revocationDate 
that should be present in paragraph 5.1.2.6 instead.

The text included in paragraph 5.1.2.6 that says revocationDate 
specifies "The date on which the revocation occurred" can be open to 
misinterpretation if one does not also carefully take into account the 
text in 5.3.2.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 02:38:51 +0200

On 10-09-12 6:39 PM, "Jorge López" <[email-masked]> wrote:

> indicating time t_0 as the time on which he suspects that the private key was
> compromised (i.e. invalidityDate). The CA receives the revocation request at
> time t_1, but do not process it till time t_3. Meanwhile, at time t_2 (t_1 <
> t_2 < t_3) the CA publishes a new CRL without -obviously- the revocation
> information about c1. Therefore, delay t_3 - t_1 prevents the CA from
> publishing a properly updated CRL at time t_2. (question: is this possible? is
> the CA mandated to process all revocation request before publishing a new CRL
> or is it a policy issue again?).
> 

It is a policy issue.

> A relying party that is validating certificate c1 at a time later than t_0 but
> before t_2, and following the IETF/ETSI/etc. recommendations, waits the grace
> period before concluding about the validity or invalidity of such certificate.
> Because next CRL is published at time t_2, that is the one used for the
> certificate status validation, reaching the conclusion that the c1 is valid.
> Neither the invalidityData helped to solve this problematic scenario.
> 

Are you sure you are not hunting ghosts here?
This is the reality of revocation and is shared with all statements that are
alive for some time. There is always some grace period.

If this is a real unacceptable problem, then you should consider using
another approach to revocation than classic CRLs.

> still an obscure thing, though in previous example, and IMHO, the CA should be
> the one liable for such an outdated revocation information. 
> 

Typically a CA is only liable for negligence with respect to following its
published practices. If the CA following its practices and procedures it is
normally not liable.

> "As a minimum Member States shall ensure that a certification-service-provider
> who has issued a certificate as a qualified certificate to the public is
> liable for damage caused to any entity or legal or natural person who
> reasonably relies on the certificate for failure to register revocation of the
> certificate unless the certification-service-provider proves that he has
> not acted negligently".
> 

Yes, not the last words in that sentence.
In addition, the CA can set a maximum reliance limit (according to the same
directive). In all Qualified certificates I have seen that max limit is 0.
That is, you are on your own because if you lost anything you exceeded the
reliance limit.

If the CA acted negligently.. It is probably another story.
Interestingly though. Despite about 200 CAs issuing qualified certificates
in EU, there are practically no court cases (if any) where the CA is accused
of causing damage.

> immediate revocation service;"

Yes, you can't use any shitty policy. But immediate is a relative term and
must be interpreted in the light of what is reasonable.

> CA's world that could explain how this is implemented and solved in real-world
> cases?

I think that would be "instant" more than "immediate".

The ETSI Standard TS 101 456 (The policy for CAs Issuing QCs states):

"The CA shall ensure that certificates are revoked in a timely manner based
on authorized and validated certificate revocation requests."

And

"the maximum delay between receipt of a revocation request or report and the
change to revocation status information being available to all relying
parties. This shall be at most 1 day."

/Stefan

>> I think RFC 5280 is very clear about the meaning of revocationDate.  Section
>> 5.1.2.6 indicates that it is "The date on which the revocation occurred".
>>  This is further supported by Section 5.3.2, which also provides a meaning
>> for indicating something close to when the certificate "should have been
>> revoked":
>>