RE: nextUpdate

[Sharon Boeyen <sharon.boeyen@entrust.com>]

Hello Paul,

PKITS is testing the path validation procedure and as such it is required to
fail in such a circumstance as dictated by the standards. However, along
with failure of that process, the relying party (application or user) should
also receive an error message that indicates the reason for the failure
(e.g. revocation status could not be determined). The relying party then can
make a decision as to whether they want to use the certificate, even though
the revocation status could not be checked. In your example, the
certificates could still be used, however the relying party is making a
decision to do so knowing that the revocation status could not be accurately
determined. 

The PKITS test suite is doing what it is supposed to do correctly and should
not be changed.

Cheers,
Sharon

-----Original Message-----
From: pkits@nist.gov [mailto:pkits@nist.gov] On Behalf Of Friedrichs, Paul
(Contractor)
Sent: Saturday, February 28, 2004 5:00 PM
To: Multiple recipients of list
Subject: nextUpdate



Hi Everyone,

It was brought to my attention that
http://csrc.nist.gov/pki/testing/PKITS.pdf in sections 4.4.11 and 4.4.12 on
pages 18-29, says:

> 4.4.11 Invalid Old CRL nextUpdate Test11
> 
> In this test the intermediate CA's CRL has a nextUpdate time that
> is in the past, indicating that the CA has already issued updated 
> revocation information. Since the information in the CRL is 
> out-of-date and a more up-to-date CRL (that should have already 
> been issued) can not be obtained, the end entity certificate should 
> be rejected due to the lack of sufficiently fresh certificate 
> status information.
> 
> Procedure: Validate Invalid Old CRL nextUpdate Test11 EE using the
> default settings or open and verify Signed Test Message 6.2.2.28 
> using the default settings.
> 
> Expected Result: The path should not validate successfully since
> the status of the end entity's certificate can not be determined.

and

> 4.4.12 Invalid pre2000 CRL nextUpdate Test12
> 
> In this test the intermediate CA's CRL has a nextUpdate time that
> is in 1999 indicating that the CA has already issued updated 
> revocation information. Since the information in the CRL is outof-date 
> and a more up-to-date CRL (that should have already been issued) can 
> not be obtained, the end entity certificate should be rejected due to 
> the lack of sufficiently fresh certificate status information.
> 
> Procedure: Validate Invalid pre2000 CRL nextUpdate Test12 EE using the
> default settings or open and verify Signed Test Message 6.2.2.29 using 
> the default settings.
> 
> Expected Result: The path should not validate successfully since the
> status of the end entity's certificate can not be determined.

I don't understand how we can accept this. There are two reasons why I think
this is unacceptable as a product requirement: 

1) We can't assume every relying party will always be able to obtain every
current CRL it "requires." 

In general, relying party software can't anticipate that it will need a
certain CRL in the near future. (I think software should, however, try its
best to anticipate and keep up to date on routinely-used CRLs.) If, when the
relying party "needs" a CRL, the relying party doesn't have one whose
nextUpdate is in the future, *suddenly* the relying party "must*"get a new
CRL *now*.  At this point, the software should continue to attempt to obtain
the CRL (or the status information by other means), but there is a
possibility that the information won't be available "in time." If we require
all relying party software to stop the business process (I would even say
"require the relying party software to fail") if this crisis isn't
satisfied, no PKITS-compliant relying party software will be reliable (or
robust or secure). It is a denial of service vulnerability.

Let's say we're talking about CRLs used for smart card logon to Windows 2000
machines across the enterprise. Let's say most of the enterprise goes on
vacation during the holidays. One could imagine being able to shut down the
entire enterprise by denying access to the CRLs on the first morning after
the holidays because the last CRLs that were pulled by the domain
controllers have nextUpdate in the past. From the DoD's perspective, an
enemy could disable the military enterprise in this way and attack when the
enemy expects the enterprise will be "down." Some could say, "yes, but just
make your CRL availability better," but this shouldn't become an imperative
created by us. This would be a PKITS-inflicted enterprise vulnerability
necessitating that solution (which might be prohibitively expensive or
impossible, and which in any case would become an unnecessary single point
of failure). (Please forgive me if my description of Windows 2000 smart card
logon is incorrect. I'm not claiming it's broken or anything. I hope its use
of nextUpdate is sufficiently robust to obviate or at least balance with
this concern.) Arguments that directories and networks should be adequately
available require a characterization of a relying party's circumstances that
PKITS cannot assume to be the case for everyone. 

DoD needs to be able to fight while hurt. We can't assume everything will be
working all the time. To achieve robustness on a large scale, robustness
needs to be considered at each component interface. The component requiring
this consideration here is the relying party's software. PKITS is mandating
the kind of brittleness that caused the power black-out a few months back.
The most significant challenge and portion of war plans is what to do in
case you're not told what to do. If we wrote our war plans the way PKITS is
treating nextUpdate, our nation's defense would be very poor.

The current PKITS would make PKI even more brittle than it has to be. It
would make PKI-using systems less reliable than they could be. It would make
PKI less valuable than it could be. By requiring greater directory and
network availability, it would make PKI more costly than it has to be. We'd
be reducing the likelihood of widespread adoption of PKI.

2) We can't assume every relying party will always consider authentication
more important than availability.

Some application functions might suffer greater harm from loss of
availability than from erroneous authentication. It's not for us to say that
erroneous authentication is always more serious than loss of availability.
Let's give stakeholders the tools they need to effect the decision optimal
for each of them.

Would a department store stop selling to people in the check-out line if the
department store suddenly could not check credit card status using the
latest information? Perhaps, but the business application owner must decide
what to do. It is a business trade between possibly allowing an attacker in
versus keeping *everyone* out. That's the store's decision, not ours. It's
not something for someone else to impose on them.  If we make that decision
for the business owners, many business owners will choose not to use our
product. The status checking program should tell the application or
businessman what the problem is to allow for the optimal business decision
to be made. Software should provide a warning to the application/user. The
application/user could anticipate this warning and act according to
predefined business rules. The contingency decision can be anticipated and
programmed as business logic. For example, the business rule might be a
function of staleness and of max dollar value of the transaction. To contain
overall risk or to track one suspicious actor, the application might also
keep track of all the transactions permitted to occur in this situation. The
check-out clerk never has to know what the business rule is and never has to
see a warning (unless or until the business rule prohibits the specific
transaction).

A day-old newspaper hasn't "expired." Certainly it's day old, but if you've
been out of touch for a while, and can't get the latest edition, you might
still want to read it. A day-old newspaper is better than no newspaper. No
one should tell you you can't read it.

I think no PKI should say "don't rely on my certs after nextUpdate." But I
completely agree that it can say "if you rely on my certs after nextUpdate,
you invalidate my warranty (such as it is)." Even if the CRL were fresh, the
certificate might already be reported to the PKI as being compromised.
Revocation status isn't a binary challenge. Over time, there are various
risks associated with liability, integrity, availability, etc. 

Ultimately, "sufficiency" must be each relying party's determination based
on the relying party's specific trade-off between authentication (or
liability) risk and availability.

Even an absent CRL is better than also not being able to chain the
certificate. At least a decision-maker can know that the certificate is
authentic. It's possible to have biometrically-locked PKI hardware tokens
and certificate assertions (of no more than pseudonimity elsewhere linked to
identity) that essentially eliminate the need for revocation, making the
possibility of revocation very small, and therefore the absence of all
revocation status information not important. The current one-size-fits-all
way of looking at PKI technology makes it unnecessarily very brittle. We
certainly shouldn't mandate such brittleness.

There is no way that we will be able to tell DoD leadership that we are
intentionally configured to stop mission critical functionality because
something else fails to do something else unless these are case-by-case
"business" decisions. Unless I am mistaken, PKITS now prevents these
case-by-case business decisions. The current case-by-case business decision
is whether to use PKI. Please don't make it worse.

I strongly recommend that PKITS "permit" the use of old CRLs - period. We
need to stop breaking products. Of secondary importance to me, I think the
best solution might be to permit this only wherever a warning (to the
application *or* to a human user, but not necessarily to a human - it
depends on the kind of application) is generated (with time since nextUpdate
and perhaps the claimed subject name) and, if you like, as long as this
robustness can be disabled entirely (for those relying parties whose
network/directory availability and authentication-versus-availability
prioritization make it optimal for them always to require the latest
revocation status).

Am I missing something?

Many Thanks,

V/R Paul