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

[Martin Rex <[e-mail]>]

Peter Saint-Andre wrote:
> 
> >> 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.

I do NOT see any reason to cache (and later compare) the entire chain
of certificates.  It is ONLY the server certificate that matters here.

What could be distinguished is what kind of override the user or the
application configuration is requesting.  Is it only an override for
the server-id-check (but otherwise a server certificate that
succeeds a regular path validation), or is it an _untrusted_ server
certificate, for which no certificate path validation can be
performed.  If it is only the former, performing regular certificate
path validation and revocation checking is sensible.  For the
latter, a certificate path validation can not be performed.



> >>
> >>        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).

Similarily here, "forcing the user to view the entire certification
path" does not seem appropriate.  It is the server's certificate
that matters and which needs to be cached.  When there is a lack
of trust to the servers certificate (because it is a self-signed
cert or issued by some private CA) then the certification path
is irrelevant and can not be verified with a regular
certificate path validation for "pinned" server certs.


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

There appears to be a misunderstanding about rfc-2119 terminology
(which is not affected by case).

compare
http://www.ietf.org/mail-archive/web/ietf/current/msg59589.html

If the document wants to use the rfc-2119 terminology in lower case
typesetting for non-rfc-2119 meaning, it should explicitly say so.
Preferably, it should use different words/expressions than "must".


-Martin