Subject: RE: delta CRLs - NR assumptions

From: "Manger, James H" <[email-masked]>
Date: Wed, 6 Jun 2001 15:37:13 +1000

There are a couple of assumptions underlying some of Denis Pinkas's
arguments that warrant closer examination.  I have derived the assumptions
from the clear & helpful description of Denis's rational (in an e-mail on 12
May).  I think these assumptions are the root cause of much of the
disagreement.  I also believe these assumptions are incorrect.

Assumption 1 (A1): Two different verifiers must get the same result about a
certificate's revocation state at any instant in time for a non-repudiation
service to work, since the goal of NR is to resolve disputes.

A non-repudiation service works because an independent 3rd party can confirm
that the evidence PRODUCED BY THE RELYING PARTY (signature, certificates,
CRLs, timestamps) is correct.  Whether or not there were different sets of
evidence - perhaps giving a different answer - that the relying party could
have collected (by noticing an "emergency" CRL for instance) is irrelevant.
Only one set of evidence matters for a given NR dispute: that produced by
the relying party.

The rule for deciding if NR evidence is "correct" is also very important,
which bring us to the 2nd assumption.

Assumption 2 (A2): The validation rule, for a non-repudiation service, may
say "use the freshest revocation information that is provided by the CA".

As Denis points out, the relying party cannot be sure they have the freshest
information if "emergency" CRLs are allowed.  The solution, however, is not
to impose rules on CRL extensions & update times, but to recognize that A2
is a bad validation rule for a NR service.

A better validation rule for a NR service may be "the relying party must use
revocation information that they reasonably assume to be the freshest
information provided by the CA (delta CRLs do not need to be supported)".
Now a relying party can protected themself, as the nextUpdate field
indicates when it is reasonable to expect new revocation information to be
available.

Consequences: "emergency" CRLs should be allowed (but NR validation rules
should not require them to be noticed); thisUpdate values may be before the
previous nextUpdate (but NR validation rules should not require that the new
CRL is noticed until the old nextUpdate time); CRLs do not need to include a
freshedCRL extension (but NR validation rules should not require a delta CRL
to be noticed if neither the cert nor full CRL reference it).  In short,
keep the X.509 CRL rules, change the NR validation rules.

In practise, NR validation rules are unlikely to mention "freshest
information" at all, as the period for which information is "freshest" is
controlled by the CRL issuer, not the relying party or signer.  Instead, a
NR validation rule should specify how fresh the revocation information has
to be (e.g. 12 hours).  This value will often be a time in the future (e.g.
the revocation information must be 24 hours fresher than the signature) to
give the signer time to detect & report a compromise of their key (and the
CA to publish it & relying parties to notice it) before they lose their
right to repudiate a signature created with the compromised key.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Jun 2001 13:33:19 +1000

> [Denis] "What about when they are two differents sets of evidence from the
same relying party which are both valid (according to the way to use CRLs)
but are contradictory ? "

[James] No problem.  The relying party chooses which ever set they want.
[The subscriber may know a different set of evidence was available, but how
can they know that the relying party had it?  They cannot.]

> [Denis] "I see a problem here. If you use delta-CRls, full CRL only or
OCSP (from the same CA) you do not necessarily get the same result. For a
given signature policy, allowing only one means to obtain the revocation
status would allow to make sure that everydody gets the same information."

[James] There is no requirement that everyone gets the same result.  NR is a
statement by a subscriber such as "I agree to X if you can produce evidence
that matches rules Y".  *Any* evidence matching the rules is sufficient,
regardless of any other sets of evidence.

> [Denis] "In other words, it will be necessary to wait to make sure that a
report of key compromise can be done. "

[James] Yes, for many applications.

---

From: "David Cross" <[email-masked]>
Date: Fri, 15 Jun 2001 07:25:27 -0700

I concur James - there is no requirement and there should be no
requirement that everyone receive the same results.  Just as emergency
CRLs should be allowed by a CA that deems it necessary under a given
circumstance.

David B. Cross

 -----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Thursday, June 14, 2001 8:33 PM
To: [email-masked]'
Subject: RE: delta CRLs - NR assumptions

		> [Denis] "What about when they are two differents sets
of evidence from the same relying party which are both valid (according
to the way to use CRLs) but are contradictory ? "

	[James] No problem.  The relying party chooses which ever set
they want.     [The subscriber may know a different set of evidence was
available, but how can they know that the relying party had it?  They
cannot.]

		> [Denis] "I see a problem here. If you use delta-CRls,
full CRL only or OCSP (from the same CA) you do not necessarily get the
same result. For a given signature policy, allowing only one means to
obtain the revocation status would allow to make sure that everydody
gets the same information."

	[James] There is no requirement that everyone gets the same
result.  NR is a statement by a subscriber such as "I agree to X if you
can produce evidence that matches rules Y".  *Any* evidence matching the
rules is sufficient, regardless of any other sets of evidence.

		> [Denis] "In other words, it will be necessary to wait
to make sure that a report of key compromise can be done. "

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Jun 2001 09:36:02 -0700

> I see a problem here. If you use delta-CRls, 

I see lots of problems if you use delta CRLs. A veritable sea of troubles
bringing waves of misery and destruction upon an unhappy world.

If you want to ban anything to prevent this woe, then ban delta CRLs, this
solution would have the considerable advantage of reducing the size of the
RFC by several dead trees.

It is simply not possible to ban emergency CRLs. Nor do I accept the premise
that consistency is more desirable than correct answers. If an OCSP service
reacts on the basis of continuously updated real time data then it will
inevitably give answers that are different (i.e. right more often) to those
that an application relying on stale CRL data will give. Call such behaviour
'inconsistent' if you like.

	Phill

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 15 Jun 2001 13:33:29 -0400

I do not see much of any problem with delta CRL.  A CA can communicate
current revocation information as complete or as incremental.

It is up to the relying parties and the CP/CPS to determine how current the
revocation information needs to be.

Delta CRL is good mechanism.  It makes lot of engineering sense.  If a CA or
CP/CPS wants all relying parties to use information as of certain time, they
can do so by issuing CRLs and/or delta CRLs at define times.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Friday, June 15, 2001 12:36 PM
To: 'Denis Pinkas'; Manger, James H
Cc: [email-masked]
Subject: RE: delta CRLs - NR assumptions

	Phill

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 15 Jun 2001 10:59:27 -0700

At 01:33 PM 6/15/01 +1000, Manger, James H wrote:

>NR is a statement by a subscriber such as "I agree to X if you can produce 
>evidence that matches rules Y".

That is one of the most concise functional definitions I think I've read.

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 22 Jun 2001 15:37:42 -0400

Denis:

     Let me start by emphasizing what we are in agreement on here, since
it's of the most practical importance anyway.  That is, there is no
requirement that CRL's issued shortly after the expiration of a revoked
certificate have the CRL entry for that certificate removed, and it is wise
that entries for NR certificates not be removed too quickly after
expiration; however, there is no value and some cost in allowing such
entries to stay on the CRL indefinitely - they should be removed in a few
days or a week after expiration, and certainly in less than a month.  I
could not find any guidance about the purging of CRL entries for expired
certificates in X.509v4 (except for one comment about removeFromCRL being
usable for the purpose) - so I think PKIX is on its own here.
     I don't, however, think that best practices for certificate rollover
are very relevant to this case.  If NR ever takes off, it will become
attractive to dishonest subjects, and if they've read these exchanges they
WILL sign a document which they intend to repudiate with a certificate with
a short time left - assuming that they have one.  For a major purchase or
contract, they might even wait until the last few days of a certificate
lifetime.  If the CA leaves revocations on CRL's for a while, by policy,
such a strategy will not work.
     Lastly, the phrase I quoted appears in a section mainly devoted to
CRL's, although the sentence before it does itself deal with certificate
publication.  However, it would be a truly perverse practice to encourage
revoked NR certificates to be kept available longer than the indication
that they have been revoked.

          Tom Gindin

Denis Pinkas <[email-masked]> on 06/22/2001 12:33:12 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: delta CRLs - NR assumptions

Tom,

>      Denis:
>
>      With respect to your second point, there is no requirement that
> revoked certificates be removed from the CRL as quickly as possible after
> they expire, especially for NR.  To quote from X.509v4 section 7.3, "It
is
> a matter for the security policy and responsibility of the authority to
> keep old certificates for a period of time if a non repudiation of data
> service is provided." (The same statement appears in X.509v3 section
11.2)

The phrase you quote has no relationship with your argument just below:
keeping an old certificate is different from maintaining a certificate
number on a CRL.

> I think that it is appropriate for PKIX to specify a minimum time after
> expiration before an NR certificate may be removed from a CRL, or to
state
> that a CA should publish such a minimum time.

I agree if this minimum is about a few days, even a week, otherwise CRLs
would grow. In most cases, people should get their new certificate about a
month in advance before the expiration of their current certificate and
thus
use the new one instead of the old one. In this way the problem disappears.

>      The question of the length of a grace period for compromise
discovery
> is a separate issue.  In the "espolicies" document you have the RP
> (actually the Signature Validation Policy) specifying the length of the
> grace period - but how does the CA know what the maximum grace period
> allowed should be?

The caution period is part of the validation policy (not the grace period).

The caution period has to take into account the grace period, the time for
the CA to process revocation requests and the maximum time to make
available
the revocation status; the two laters being defined by the policy of the
CA.

Denis

> The conformity of the two S/MIME documents with each
> other and with your views reflects the fact that you are an author of
both
> of them, of course.
>
>           Tom
>
> Denis Pinkas <[email-masked]> on 06/20/2001 08:54:04 AM
>
> To:   Tom Gindin/Watson/IBM@IBMUS
> cc:   [email-masked]
> Subject:  Re: delta CRLs - NR assumptions
>
> Tom,
>
> >      Denis:
> >
> >      In NR, you can expect to have consistent results for time T from
any
> > CRL with thisUpdate >= T (exclusive of the effects of hold),
>
> Not really. For two reasons:
>
> 1) it may take time for a signer to discover that his key has been
>    compromised.
>
> 2) in addition, if the certificate is close to expire, in case it is
>    revoked, it will not appear in the CRL any more.
>
> > but not from any CRL retrieved at time T.
>
> In practise, when you receive a signature, you want to have a reasonable
> assurance that the signature is going to be valid. So you use the current
> CRL, i.e. the one where time T is between thisUpdate and nextUpdate.
>
> The next (normal) CRL is not necessarilly adequate either, since as said
> above, it may take time for a signer to discover that his key has been
> compromised. So why, in the document "Electronic Signature Formats for
long
> term electronic signatures" from the S/MIME working group, soon to be
> published as RFC 3126, in section 2.8 a grace period is mentionned
> "allowing
> any entity from the certification chain to declare a key compromise".
>
> Along the same idea, a caution period is defined in the document
> "Electronic
> Signature Policies" from the S/MIME working group, soon to be publised as
> RFC 3125, in section B.8.3.:
>
> Caution Period
>
>    Before an electronic signature may really be valid, the verifier has
>    to be sure that the holder of the private key was really the only one
>    in possession of key at the time of signing.  However, there is an
>    inevitable delay between a compromise or loss of key being noted, and
>    a report of revocation being distributed.  To allow greater
>    confidence in the validity of a signature, a "cautionary period" may
>    be identified before a signature may be said to be valid with high
>    confidence.  A verifier may revalidate a signature after this
>    cautionary signature, or wait for this period before validating a
>    signature.
>
> > That's why section 4.6 of the techNR draft reads the way it does, as
does
> section 5.5.
>
> This is why I disagree with the writing of these two sections.
>
> Denis
>
> > The security considerations
> > section of new-part-1 should certainly warn even non-NR users that
> caching
> > CRL's on a CA that issues emergency CRL's may cause them to get
> obsolescent
> > revocation information.  However, given that the publication of CRL's
is
> > not truly instantaneous, even re-fetching them or using OCSP is not an
> > absolute protection against that problem, although it reduces it
greatly.
> >
> >           Tom Gindin
> >
> > Denis Pinkas <[email-masked]>@mail.imc.org on 06/18/2001
12:39:59
> PM
> >
> > Sent by:  [email-masked]
> >
> > To:   "Housley, Russ" <[email-masked]>
> > cc:   [email-masked]
> > Subject:  Re: delta CRLs - NR assumptions
> >
> > Russ,
> >
> > > Denis:
> >
> > > > > Consequences: "emergency" CRLs should be allowed
> >
> > > >I disagree.
> >
> > > I believe that this is the core of the disagreement, and I do not see
> > > anyone changing their minds.  The PKIX Profile does not require CAs
to
> > > issue CRLs, or emergency CRLs.  However, when CAs choose to employ
> CRLs,
> > > the CAs policy will dictate whether emergency CRLs are issued or not.
> >
> > > The PKIX Profile is NOT going to be changed to prohibit the issuing
of
> > > emergency CRLs.
> >
> > This seems fine as far as CAs are concerned: this leaves the choice to
> the
> > CAs.
> >
> > However, this has implications on the way relying parties should
process
> > CRLs.
> >
> > It would be appropriate to give some guidance or some warnings
> > in the security considerations section.
> >
> > If a CA issues no emergency CRLs, then there is no problem. Only one
CRL
> > may
> > be valid at one time.
> >
> > If a CA indicates that it MAY issue emergency CRLs at any time (for
some
> > scope or reason), then a cache for that CRL should not be used. In this
> > way,
> > the client will always try to fetch the latest CRL, ... but will have
no
> > guarantee that he ever got the latest.
> >
> > Finally, when CRLs are used for supporting non repudiation, since one
> goal
> > of non repudiation is to solve disputes, we had better to have non
> > conflicting information from the same authority while using the same
> > revocation mechanism.
> >
> > A few words in the security considerations section would certainly be
> > appropriate. If you agree in principle, I would be happy to provide
them.
> > Denis
> > > Russ