Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Ben Campbell <[e-mail]>]

> On Oct 26, 2017, at 5:44 PM, Chris Newman <[e-mail]> wrote:
> 
>> My inclination is to remove the "client has determined that the certificate can be safely used" clause, but I'd like to see what Chris suggests here.
> 
> Here's an attempt to reword without using the term "safely" which I agree is not ideal:
> 
> ...  An MUA MUST NOT provide a client certificate during the
>   TLS handshake unless the server requests one and the MUA has
>   been authorized to use that client certificate with that account.
>   Having the end-user explicitly configure a client certificate for use
>   with a given account is sufficient to meet this requirement. However,
>   installing a client certificate for use with one account MUST NOT
>   automatically authorize use of that certificate with other accounts.
>   This is not intended to prohibit site-specific authorization mechanisms,
>   such as a site-administrator-controlled mechanism to authorize use of a
>   client certificate with a given account, or a domain-name matching
>   mechanism.
> 
> The issue is that some TLS libraries have a general pool of client certificates visible to the library (Mozilla NSS works this way, and I happen to like this design). Use of a client certificate with the wrong server causes both privacy and interoperability problems. There's presently no standardized mechanism that an TLS client library can use to identify a particular client certificate as authorized for use with a given server. On the flip site, requiring explicit end-user configuration of a client certificate with each account adds to the already user-hostile experience of client certificates. We really want to allow more user-friendly mechanisms to authorize use of a client certificate with a given account, so we need a rule that protects privacy/interoperability but doesn't prohibit UI innovation. I'm open to suggestions for better wording.
> 

That’s more clear, thanks!

Ben.