[certid] section 4.6 rewrite (aka: Bad certificate handling)

[=JeffH <[e-mail]>]

I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad certificate 
handling) and indeed its language needed some semi-major rewriting, which we've 
done. The entire new section "4.6 Outcome" is below.

comments?

thanks,

=JeffH

###

4.6.  Outcome

    The outcome of the checking procedure is one of the following cases.

4.6.1.  Case #1: Match Found

    If the client has found a presented identifier that matches a
    reference identifier, matching has succeeded.  In this case, the
    client MUST use the matched reference identifier as the validated
    identity of the server.

4.6.2.  Case #2: No Match Found, Cached Certificate

    If the client does not find a presented identifier matching any of
    the reference identifiers, and (a) a human user has previously
    accepted and cached a certificate for this application service during
    a previous interaction with the service or (b) a certificate has been
    cached via configuration settings, then the client MUST verify that
    the presented certificate matches the cached certificate.  If the
    presented certificate does not match the cached certificate then the
    client MUST proceed as described under Section 4.6.4.

4.6.3.  Case #3: No Match Found, No Cached Certificate

    If the client does not find a presented identifier matching any of
    the reference identifiers, and the client has not previously cached a
    certificate for this application service based on user acceptance or
    configuration, then the client MUST proceed as described under
    Section 4.6.4.

4.6.4.  Fallback

    If the client is an interactive client that is directly controlled by
    a human user, then it SHOULD inform the user of the identity mismatch
    and automatically terminate the connection with a bad certificate
    error; this behavior is preferable because it prevents users from
    inadvertently bypassing security protections in hostile situations.

       Security Note: Some interactive clients give advanced users the
       option of proceeding with acceptance and caching of the presented
       certificate despite an identity mismatch.  Although this behavior
       can be appropriate in certain specialized circumstances, in
       general it ought to be exposed only to advanced users.  Even then
       it needs to be handled with extreme caution, for example by first
       encouraging even an advanced user to terminate the connection and,
       if the advanced user chooses to proceed anyway, by forcing the
       user to view the entire certification path and only then allowing
       the user to accept the certificate (on a temporary or permanent
       basis, at the user's option).

    Otherwise, if the client is an automated application not directly
    controlled by a human user, then it SHOULD terminate the connection
    with a bad certificate error and log the error appropriately.  An
    automated application MAY provide a configuration setting that
    disables this behavior, but MUST enable the behavior by default.

###