> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > =JeffH > Sent: Wednesday, September 29, 2010 2:28 PM > To: IETF cert-based identity > Subject: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > 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.
There was one case in the original text here that I was expecting to be kept. This was the case of the chain of certificates being changed from when it was originally presented. Given the suggestion that the chain is shown for advanced users (see 4.6.4) I am wondering about the fact that we are no longer looking at anything more that the terminal certificate at this point. > > 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. I would like to see the MAY and MUST here be lower cased. They are implied by the SHOULD in the preceding sentence and do not need to be re-iterated. > > ### > > > > > _______________________________________________ > certid mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/certid _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
