RE: nextUpdate

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

All,

> -----Original Message-----
> From: Friedrichs, Paul (Contractor) 
> Sent: Wednesday, March 03, 2004 4:59 AM
.....
> I don't see why nextUpdate should even be in a 
> validation algorithm.

Please allow me to clarify that. I'm learning as I go here. If I were to
design (standard or otherwise) relying party software at this point, I would
have it do the following (in addition to making sure everything else was OK,
including, of course, that if the cert is revoked, it is rejected): 

1) If nextUpdate is in the past, attempt to pull the latest CRL. Stop trying
if unsuccessful after a preconfigured amount of time and pass to the
business app a flag that nextUpdate is in the past (in case there is
liability relevance - I now think there is no security relevance, as I
explained in my last email). (Would it be better to pass a flag if
nextUpdate were in the future?)
2) Pass time since *thisUpdate* to the business app. (Assuming the
certificate is not determined to be revoked, this is the only available
piece of information that is relevant to the relying party's risk of relying
upon compromised certs. The risk exists regardless of whether nextUpdate is
in the future or in the past. Up to this point, we have been simplifying
this to be "before nextUpdate," but the evaluation of acceptability of this
risk is a business, not technical, decision, so it should not be made in the
validation module.)

This might be more complicated than the current paradigm, but I think it is
more correct. 

Was it Einstein who cautioned that one should make things as simple as
possible but no simpler?

V/R Paul