This is because its possible for redirection ot occur with
any operation, and a client would want to make sure that
a TLS-session is in progress to a particular IPP server
before sending any sensitive data. Keep in mind that this
is not only possible with IPP redirects, but is possible with
standard HTTP redirects as well, which is out-of-band to
actual IPP operations, and our normative scope as well
(except for the protocol doc).
By the way, it is possible to issue a "print-job" operation
within the context of a TLS session. The client would issue
a "validate-job" with the "client-security-requested" operation
attribute set, and then use the returned redirect URI to issue
the "print-job" operation securely.
Randy
> -----Original Message-----
> From: Carl-Uno Manros [SMTP:carl@manros.com]
> Sent: Wednesday, January 07, 1998 6:36 AM
> To: Turner, Randy; 'Tom Hastings'
> Cc: 'ipp@pwg.org'
> Subject: RE: IPP> Additional proposal details
>
> At 10:53 PM 1/6/98 -0800, Turner, Randy wrote:
> >
> >See my response to your comments below.
> >
> >My comments are marked RT>
> >
> >R.
> >
>
> Randy, I have not copied your while message, only one comment from
> you,
> where I think you are breaking the security.
>
> Carl-Uno
>
>
> >> -- It allows a TLS-capable server the ability
> >> to only require TLS negotiation for
> >> particular operations that require the server
> >> to allocate resources. For instance, a
> >> server that requires all print jobs to be
> >> authenticated might still want all clients
> >> to be able to get attributes for the printer,
> >> as well as validate job parameters, without
> >> going to the expense of performing TLS
> >> negotiation. It basically allows an
> >> administrator to decide what types of
> >> operations should be authenticated. In the
> >> current spec, ALL operations are authenticated
> >> or NONE are. This is a nice scalability
> >> feature
> >>
> >> TH> This is a good feature. However, if a client wants security
> and
> >> TH> only has an HTTP URL, how does it get started? It certainly
> >> doesn't
> >> TH> want to do a Print-Job and send valuable data, before gettting
> the
> >> TH> TLS URL. So this means that the client that wants security is
> >> forced
> >> TH> to do a Validate-Job with the HTTP://... URL in order to get
> back
> >> TH> the redirect HTTPS://... URL, correct?
> >>
> > RT>You'll note that most of the scalability and flexibility of
> > RT>this proposal mostly applies to IPP servers and subsequently
> > RT>server administration framework. If a CLIENT wants a
> >particular
> > RT>operation to be "secure" , then it includes the
> > RT>"client-security-requested" operation attribute with whatever
> > RT>operation it is attempting.
> >
>
> CM> If you try this with a job submission operation, you have already
> sent
> CM> your MIME type application/ipp, which means that all your data
> were sent
> CM> unencrypted before you got the secure URI back, so your feature
> does
> CM> not make any sense in combination with certain operations. It is
> not as
> CM> generic as you describe it above. Instead you might actually
> mislead
> CM> a user to think that their transmission is secure, when in reality
> CM> it is not.
>
> ---