Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]] 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/