On Wed, 2010-09-29 at 14:27 -0700, =JeffH wrote: > 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?
The cases of "no cached certificate" and "different cached certificate" could probably be combined into "certificate not cached" to simplify things. I.e.: ### 4.6. Outcome ... 4.6.1. Case #1: Match Found ... 4.6.2. Case #2: No Match Found, Certificate Cached If the client does not find a presented identifier matching any of the reference identifiers, but the presented certificate has been designated as acceptable for this application service (a) by a human user during a previous interaction with the service or (b) via configuration settings, the server identity check succeeds. [XXX: What is the validated identity of the server? Should the cached certificate rather be designated as acceptable for a reference identifier, which can be taken as the identity of the server?] 4.6.3. Case #3: No Match Found, Certificate Not Cached If the client does not find a presented identifier matching any of the reference identifiers and the presented certificate has not been accepted as described in section 4.6.2, then the client MUST NOT consider the certificate to include a validated identity for the application service. Instead, the client MUST proceed as follows. [...] ### -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
