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

[Peter Saint-Andre <[e-mail]>]

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.

>> 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/