> On Oct 26, 2017, at 5:44 PM, Chris Newman <[email protected]> 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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
