On Wed, Sep 24, 2014 at 6:22 AM, Michael Sweet <msweet@apple.com> wrote:
> Martin,
>
> HTTP implementations that use the OS supplied TLS libraries don't have the
> same close integration that a browser using its own TLS library has. CUPS
> works with three different TLS libraries [1] (used to be four, but we
> dropped OpenSSL support) and all of them have vastly different interfaces
> and capabilities from the standpoint of cipher suite selection and
> classification. None of them directly allow selection based on the kind of
> classification that is specified in 9.2.2 and it isn't clear to me yet
> whether I can even specify the kind of priority ordering that is being
> touted as a solution for interop problems.
>
FWIW, you cannot provide a priority ordering for NSS.
-Ekr
> The reason is that these general purpose TLS libraries are themselves
> enforcing best practices and site policy with their defaults, and
> discourage developers from straying unless they are experts and know what
> they are doing. 9.2.2 is forcing HTTP developers to act as TLS experts...
>
> [1] For CUPS 2.0 we support GNU TLS, SecureTransport (OSX), and SSPI
> (Windows).
>
> Sent from my iPad
>
> > On Sep 24, 2014, at 2:14 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> >> On 24 September 2014 02:08, Simone Bordet <simone.bordet@gmail.com>
> wrote:
> >> Old h2 clients that are dynamically linked to a new TLS implementation
> >> will have X but not know that is acceptable.
> >
> > Implementations shouldn't be enabling cipher suites that they don't
> understand.
> >
>