ietf-smime
[Top] [All Lists]

re: cert-03 - signature validation failure

1998-04-07 09:47:39

I want to propose a change to how signature validation failure is handled. In
the current draft, it essentially says that the user agent must do something
when signature validation fails, but what it does is up to the implementation.
I don't think it is acceptable to leave this decision unspecified; here is
some
of my rationale:

* A valid signature on a message serves the purpose of creating for the
recipient an enhanced level of trust in the origin and the integrity of the
message.  The actual level of trust which a user assigns depends on many
things, including the trust in the certificate issuer, the algorithms used,
the
availability of current revocation status, etc.; it also depends on the
importance the user places on the message (the user's context).

* Because the user's context cannot be known, it is not possible to create a
fixed set of actions which the validating software must take upon encountering
these failures. For example, for one message a recipient may be willing to
accept that revocation could not be verified, where for a 'more important'
message, the recipient may not accept anything except successful validation.
* As another example, a recipient may receive a message where the signature
does not validate; however, the user may consider the subject important enough
that s/he may want to use out-of-band means to verify the content; to do this,
the user has to be able to receive the message itself.

* In some domains these actions may be dictated by the  security policicy, and
leaving the implementation up to chance will create the situation where no
available products are usable.

I also realize that there is a major problem that must be overcome:

* There are three general classes of recipients that must be accommodated:
human users, security gateways, and automatic message processors.

I propose that we specify the following behavior for a user agent performing
signature validation:

* The validation module MUST return the status of the validation and, for any
failure, the reason for the failure. 

* The user agent SHOULD make it possible to configure the actions it takes
upon
signature validation failure; this SHOULD be settable depending on the reason
for the failure. In the absence of this configurability, the default is that
the user agent MUST make this status available to the recipient and MUST make
it possible to receive the message with the invalid signature.

To accomplish this, I propose that we define a status return for the
validation
module, consisting of an integer status code, a textual string, and supporting
information. It could be similar to the one in the CMP document:

PKIStatusInfo ::= SEQUENCE{
 status Integer,
 statusString string OPTIONAL,
 statusInfo StatusInfo OPTIONAL }

To do this, we would need to agree on what the possible returns are; for
example, 

 * success
 * no Internet mail addresses in a certificate match the sender of a message
 * no certificate chain leads to a trusted CA
 * no ability to check the CRL for a certificate
 * an invalid CRL was received
 * the CRL being checked is expired
 * the certificate is expired
 * the certificate has been revoked


UAs for human users could either display the textual status or map the integer
to a response. Security gateways and automatic message processors could use
the
integer code to determine their action. If configuration is available, it
could
be specified according to the return status.

If we can agree on something like this, I will propose the precise wording
changes to the CERT document.

elliott ginsburg