Re: [certid] Bad certificate handling

[=JeffH <[e-mail]>]

[e-mail] said:
 > On Wed, 2010-09-22 at 09:59 -0600, Peter Saint-Andre wrote:
 > > The part of the text that you have not quoted does say that this
 > > practice is typically offered only to advanced users (and I don't think
 > > that Barry's mother counts as an advanced user). However, we've
 > > provisionally made the text even more scary, as follows:
 > >
 > >       Security Note: Some existing interactive user agents give advanced
 > >       users the option of proceeding despite an identity mismatch.
 > >       Although this behavior can be appropriate in certain specialized
 > >       circumstances, in general it needs to be exposed only to advanced
 > >       users and even then 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 basis (i.e., for this connection attempt and all
 > >       subsequent connection attempts for the life of the application
 > >       session, but not for connection attempts during future application
 > >       sessions).
 > >
 > > Jeff still needs to review that text before we finalize it.
 >
 > There is a trade-off in making the acceptance temporary.  ...
 >
 > The current remark about temporary acceptance might suggest to readers
 > that it is better than permanent acceptance, which is at best an
 > oversimplification and possibly untrue.  Thus, I propose that the remark
 > be removed.

agreed. Jhutz also suggested such.


 > Separately, I wonder if it makes sense for server-id-check to
 > specifically discuss the handling of certificates that don't match a
 > reference identifier when the considerations are essentially the same
 > for certificates with other problems (most commonly, expired or
 > untrusted issuer) and, indeed, modern browsers tend to provide a single
 > UI for these three most common problems.  I'm not sure where would be
 > the right place to standardize handling of bad certificates in general.
 > There is a W3C document, but it only applies to interactive user agents:
 >
 > http://www.w3.org/TR/wsc-ui/    [WSC-UI]

Which is entitled: "Web Security Context: User Interface Guidelines"

Note that we already cite this doc (tho we need to update our cite because it 
is now a Recommendation).

In any case, this is a good catch, thanks. In reading WSC-UI, it appears to 
overall address our needs for more full explanation of interactive user agent 
behavior in error condition cases (although it doesn't differentiate between 
"pinning" a cert temporarily vs permanently).

Given all this, I suggest we change the last part of the last sentence of the 
"Security Note" quoted above to something like..

        ..., by forcing the user to view the entire certification path
        and only then allowing the user to choose whether to accept the
        certificate on a temporary or permanent basis. See [WSC-UI] for
        further guidance.

..and leave it at that in -tls-server-id-check. We should also consider making 
[WSC-UI] a normative reference now that it is at Recommendation maturity level.

=JeffH