> -----Original Message----- > From: Peter Saint-Andre [mailto:[email protected]] > Sent: Wednesday, September 29, 2010 3:40 PM > To: Jim Schaad > Cc: '=JeffH'; 'IETF cert-based identity' > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > On 9/29/10 4:19 PM, Jim Schaad wrote: > > > > > >> -----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. > > Yes, that's important. > > I think this text is a bit confusing because it uses the term "match" > for comparing the entire cached certificate against the entire presented > certificate, whereas in the rest of the document we use the term "match" > for comparing reference identifiers against presented identifiers. > > Therefore I propose the following adjusted text: > > 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 is the same as the cached certificate, > including verification of the entire certification path. If the > presented certificate is not the same as the cached certificate then > the client MUST proceed as described under Section 4.6.4. >
You might change the text to be "cached a certificate with certificate path" for the text in (a) and (b) This makes it more clear that the entire certificate path is supposed to be cached. (This is a potentially harder thing for configuration settings as a certificate path would be required to be loaded. But making it more explicitly is probably helpful.) > >> 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. > > I think it might be better to delete the last sentence entirely since it is > really an > implementation detail (the main point is that the client SHOULD terminate the > connection). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
