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.
###
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
