RE: nextUpdate

["Friedrichs, Paul (Contractor)" <FriedriP@ncr.disa.mil>]

Sam, All,

> -----Original Message-----
> From: Sam Roberts [mailto:sroberts@certicom.com]
> Sent: Tuesday, March 02, 2004 9:50 AM
> To: Multiple recipients of list
> Subject: Re: nextUpdate
> 
.......
> 
> In your example above, if you get access to a private key on a smart
> card using your retina and a second person, that's great, the 
> smartcard
> trusts you to use the key, and will sign something for you. But, when
> you send me email signed with that private key, and I can't check the
> revocation status of your cert, I've no way of knowing that actually,
> you and your buddy were fired last week, and don't work for the DoD
> anymore, and I shouldn't trust anything you guys write me.

This example is from the perspective of the relying party itself rather than
that of the validation algorithm. It expresses the concern of the relying
party, not the correctness or "security" of an algorithm. I think it is the
only correct way to think about the challenge.

But is your concern here that my cert has been revoked or that I have left
the company and therefore should not be trusted? Which is it? If I had been
fired last week and shouldn't be trusted by you but nextUpdate is in the
future, are you "secure"? The argument throughout your email seems to be
that you are. I could be doing all sorts of bad stuff to you but RFC3280
says you're secure. You have "no way of knowing that actually, you and your
buddy were fired last week, and don't work for the DoD anymore, and I
shouldn't trust anything you guys write me." How can you take this risk?!?! 

Given that you are taking this risk, for any given ten minute period in
which you take this risk, you are potentially relying on compromised certs.
For each successive ten minutes, you are "ten minutes more likely to be"
relying upon compromised certs of other people who have been fired since I
was fired. But nextUpdate is six hours in the future. Many ten minutes pass.
Suddenly, nextUpdate is in the past. Try as you might, you can't get another
CRL. You still have "no way of knowing that actually, you and your buddy
were fired last week, and don't work for the DoD anymore, and I shouldn't
trust anything you guys write me." But the additional risk of trusting
compromised certs you are incurring on the margin is no greater than that
which you accepted with the previous ten minutes. 

Except to trigger attempts to obtain newer information, I don't see any
security relevance in nextUpdate. The only difference between the ten
minutes after nextUpdate and the ten minutes before nextUpdate is that the
relying party knows that there is newer revocation information. But that
doesn't change the relying party's risk I described above. In the situation
where the information is not available, wouldn't the only possible affect be
on any warranty the PKI might have provided the relying party? It seems to
me nextUpdate is purely a business and not a security element. "Whose fault
was it?" And since at least some PKIs (e.g., the DoD's) offer no warranty,
those PKIs' nextUpdate assertions are of *no* value to the relying party
(except for triggering attempts to obtain newer information). They're
meaningless. They're a red herring. I don't see why nextUpdate should even
be in a validation algorithm.

Revocation is (only) a mechanism. The stakeholder's authentication concern
is relying upon compromised credentials. I think we've been excessively
focused on the mechanism to the point of calling it the goal, the
requirement. 

V/R Paul