There are a number of steps in the process of validating a signature, and
checking the cert for revocation is one of them. I think that when any of
these steps fail, the best response is to inform the user. Speaking for
myself as a user, if I receive a signed message, but the signature does not
validate, I will want to know why the validation failed; I will then make
the judgement of how much to trust the message, and I feel I can make that
judgement better, on a case-by-case basis, than can some hardcoded rules in
my user agent. For example, if a signature validation fails even though the
cert is valid, this is different than the case where the 'From' address
does not match an address in the cert, which is yet different from a
signature which is valid except that the cert was revoked. I guess I'm
saying that every time a signature on a message is checked, the user agent
should report the outcome as either successful or failed for a particular
reason. In the case we are discussing, where there is no CRL, I think the
user agent would inform the user that the signature checked, but it could
not be determined that the cert was not revoked. It would then be up to the
user to decide what to do with the message.
This is easily done with a human user, but more difficult for an automated
message reception process. One solution would be to have a set of possible
reasons for validation failure; the automated process could be setup to
decide what to do for each type of failure.
elliott ginsburg
At 10:09 AM 3/23/98 , Russ Housley wrote:
Elliott:
I agree with you; however, there are still some large Cas that do not issue
CRLs. How should we deal with this situation? Should we say that
certificates for such CAs cannot be used with S/MIME?
Russ
At 11:30 AM 3/20/98 -0500, Elliott Ginsburg wrote:
In section 2.1:
"...All agents SHOULD check the nextUpdate field in the CRL against the
current time. If the current time is later than the nextUpdate time, the
actioin that the agent takes is a local decision. For instance, it could
warn a human user, it could retrieve a new CRL if able, and so on."
I think that since this section requires the checking of certs against
CRLs, that we ought to require (MUST) that the agent check the nextUpdate
field. I also think that we can be a little more specific about what the
agent does if it is later than this time. I suggest the following:
"...All agents MUSTcheck the nextUpdate field in the CRL against the
current time. If the current time is later than the nextUpdate time, the
agent MUST take some appropriate action. For instance, one recommended set
of actions would be: 1) retrieve a new CRL if possible, or 2) issue a
warning that revocation could not be checked."
elliott ginsburg