Keith Moore wrote:
> > Is it assumed that each application that uses TLS uses its own original
> > scheme e.g. "http" or should it allocate a new scheme if combined with TLS
> > (Annex E seems to suggest that you use "https" as for SSL3)?
>
> Ideally, a single URL scheme could be used either with or without TLS,
> with the authentication and privacy technology to be used negotiated
> by the client and server. Client and server should each be
> configurable as to which ciphersuites, CAs, etc. are acceptable to
> each party.
>
> In general, neither the scheme name, nor the port number, is
> sufficient for such configuration. For instance, "https" (and port
> 443) can be used with many different ciphersuites, covering a wide
> variety of services and strengths, some of which are unlikely to be
> acceptable. While we don't intend to deprecate https/http and the
> other dual-port schemes that are widely deployed, neither do we want
> to propagate this mechanism to new protocols.
Yes, indeed this is a wise policy to persue.
>
>
> > Do you see any reasons to allocate new schemes and/or port numbers for IPP
> > (differently from HTTP) when using HTTP as transport? If you think new
> > schemes and ports are needed, do we need one for use of IPP without TLS,
> > and another set for use with TLS?
>
> IANA has been requested to not assign any new "SSL" or "TLS" ports.
> For new protocols, TLS must either to be explicitly configured
> separately from the port number, negotiated in-band (using STARTTLS or
> some such), or assumed by default.
>
> As for IPP:
>
> + IPP servers listening on port 443 should assume TLS/SSL will
> be used when the connection is opened.
> IPP clients should use "https:", without overriding the port #,
> to indicate they want to talk to an IPP server on port 443.
>
> + IPP servers listening on other ports, including any port that might
> be designated specifically for IPP, should assume that neither TLS
> nor SSL is used when the connection is established. TLS or other
> security technologies might eventually be used on such servers,
> if someone defines a means of negotiating security in-band over
> HTTP.
Again this is awise approach. In our "Intergration Facility or (MLPI) we
provide for this option.
>
>
> IPP clients should specify "http:", perhaps with a port #
> (other than 443), to indicate that they want to talk to such servers.
>
> + If a specific port is to be allocated for IPP, there should be
> an "ipp:" URL scheme defined, which defaults to that port.
Not necessary if you use and intergration scheam or facility to
provide for multipul port configuration.
>
>
> The definition of the ipp: scheme should also define how security
> is to be negotiated on that port - whether it defaults to TLS
> (perhaps with the possibility of fallback to a null encryption
> layer) or whether it uses in-band negotiation.
Hummmmm? intresting conclusion or answer. But it would again seem
unecessary if integration for IPP on multipul ports using stacked protocols
or multi=leyer approach for cyphers.
>
>
> In every case it remains necessary for clients and servers to be
> configurable as to which TLS ciphersuites are acceptable.
Agreed. But this should not necessarly be a configuration restriction.
>
>
> Keith
Regards,