On 9/29/10 5:20 PM, Jim Schaad wrote: > > >> -----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.)
I'm always in favor of making such things explicit. This will be fixed in the next version -- I now have "certificate (with certificate path)" in multiple locations of the working copy. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
