Subject: Re: [pkix] Doubt on revocation processing requirements

From: Jorge López <[email-masked]>
Date: Sun, 3 Oct 2010 15:51:43 +0200

Thanks everybody for your valuable responses (though a bit late from my side
:-(  )

You are right Stefan in the sense that the scenario that I am describing is
possibly a bit far from what actually happens in real world. But I was just
wondering if it was being considered by current CAs.

Best,

Jorge.

2010/9/14 Stefan Santesson <[email-masked]>

>
>
>
> On 10-09-12 6:39 PM, "Jorge López" <[email-masked]> wrote:
>
> > 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?).
> >
>
> 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.
>
> > 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.
> >
>
> 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.
>
> > 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".
> >
>
> 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.
>
> > 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;"
> >
>
> 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.
>
> > 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?
>
> 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
>
> >
> > Thanks in advance,
> >
> > -----
> > Jorge L. Hernández-Ardieta
> >
> > 2010/9/9 David A. Cooper <[email-masked]>
> >> 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:
> >>>>
> >>>>
> >>>>> 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.
> >>>>
> >>>
> >>> 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.
> >>>
> >>
> >>
> >> _______________________________________________
> >> pkix mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/pkix
> >
> >
> >
> > _______________________________________________
> > pkix mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pkix
>
>
>