No, that's not the issue. Yes, the CA is part of the certificate.
The client may need several certificates to authenticate itself
to each of several different servers, because each client certificate
is signed by only one CA, and not all servers trust the same CA.
The client has no knowledge of which certificate to use, and TLS
doesn't give it a way find out which CAs the server trusts.
So this has to be configured into the client on a per-printer basis -
either explicitly or as part of the URL.
> >If it's desired to make IPP work without prior authorization
> >(and assuming the server requires authentication at all), the
> >client is still going to need to know what authentication method to
> >use and which CAs the server supports. This is more information than
> >can be conveyed in one bit (the difference between using "http"
> >and "https").
>
> The authentication method is negotiated when the client sends its
> "preferred" list of auth/privacy methods to use during TLS startup.
Only if it uses TLS. How does the client find out whether to use TLS
or digest or both? (it might use TLS for privacy, and digest for
authentication)
> IPP clients will "not" arbitrarily authenticate itself to IPP servers
> around the world. TLS-enabled IPP servers will be pre-configured with
> ACLs or some such to allow specifically authorized clients to access
> the resource.
Yes, but how does this work for the client who wants to print
on the printer at Kinko's? (whether nearby or across the world)
Presumably, the user's going to have to establish a billing account,
and when he does that he'll get a certificate back from Kinko's that
he can use to authenticate himself to Kinko's printer. (my guess
is that it's a lot easier for Kinko's to issue a certificate
that says "this is Kinko's user #23434" than for Kinko's to
decide whether to accept some certificate that the user already
has, signed by some random CA, that says "this is Keith Moore".)
(note that there's a big gap in defining "ACLs or some such")
> >> 6. Compound schemes is a new idea and not well understood in its'
> >> ramifications. In the current IANA registry for URL schemes, there
> >> are no examples that indicate that scheme "translation" to another
> >> scheme is required.
> >
> >IPP is the first group to try to layer something on top of HTTP.
> >So naturally there are no examples for how to do this. That's
> >what comes with breaking new ground.
> >
> >Note that the translation is only required to talk to HTTP proxies.
> >The general case is that the IPP client talks directly to the IPP
> >server, and there's no URI translation going on at all.
>
> Your previous comments that say something like "IPP clients will only use
> HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP
> as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These
> generic web servers will not understand IPP URLs either, and this case
> of generic web server extension could make up a significant set of
> initial releases of IPP.
This is a reasonable concern. I'm thinking that it's not such a problem
if http: URLs are always used at the HTTP layer - as long as they're only
used at the HTTP layer. I might be able to convince IESG of this.
> >I respect the IPP group's concern that translation of IPP URLs
> >while tunneling over HTTP proxies is untried and may cause operational
> >problems. However, the IPP group is ignoring IESG concerns about
> >operational problems that might be caused by reusing HTTP proxies
> >in the first place to circumvent firewall policy, or the confusion
> >resulting from users' inability to distinguish printer URLs from
> >http: URLs.
> >
> >If IPP's use of HTTP proxies causes too many problems, it may be
> >necessary to reconsider using HTTP proxies - or to allow people
> >to use them, but warn that this might not always work. Sooner
> >or later the proxies will support IPP. Of course it's nice if
> >proxies support a new protocol immediately, but if they don't -
> >this is no more of a barrier than any other new protocol has to face.
>
> There is no problem with our current version and HTTP proxies. Its the
> introduction of an unsupported URL scheme that has generated
> concerns about breaking the infrastructure. We have layered where
> appropriate, and have taken special care not to "break" the infrastructure.
With due respect, the IESG disagrees. The layering of a new protocol
over HTTP, and the proposed reuse of http: URLs, has generated concerns
about breaking widely-held assumptions - specifically, firewall policies
and assumptions about what http: means and how it is used.
> I'm concerned that if we did work on a "standardized" URL, that it would
> "still" be a "one-off" solution only used by IPP, since the majority of
> internet protocols I am seeing working on security
> (IMAP/POP/FTP/SMTP/LDAP, etc) are working on SASL profiles for
> accomplishing this functionality. Which would make all of this
> work even less of a benefit.
I don't think this would be a one-off. There's a lot of interest in
using TLS for most of these protocols, and the mechanism for negotiating
TLS (typically a STARTTLS command) sort of sits alongside of SASL.
So I think we're going to be needing URLS that can specify use of
either SASL methods, or TLS, or both, for several different protocols.
I've already been asked by someone else from outside of the IPP group,
to hold a discussion at the next IETF meeting, about a reusable
mechanism for specifying various kinds of security in URLs.
> >With an eye toward making them acceptable to IESG while addressing
> >the IPP group's concerns:
> >
> >- I will recruit a team of experts from the HTTP working group
> >and ask them to quickly review the ipp: scheme proposal for potential
> >interoperability problems with proxies.
> >
> >- I will recruit experts from the web and TLS communities to design
> >appropriate URL parameters for use with TLS, which can be shared
> >by other URL schemes besides ipp:.
> >
> >The IPP documents have been submitted for IESG ballot, and may be
> >on IESG's agenda for discussion as early as July 16th. I would
> >therefore like a decision from IPP by July 15th as to whether
> >the IPP working group is willing to pursue this course of action.
>
> If we subscribe to your schedule I think its only fair that we get a
> schedule back from you for completion of this work, provided we agree
> to it.
Well, if I can get IESG to agree to let IPP use http: in HTTP
protocol elements, then we don't need the first team of experts.
As for the second, I would need to talk to security experts
before I could even get a time estimate. But it might be
that this doesn't have to be critical path for IPP going to
proposed. I'll ask the security ADs what they think.
Keith