As you later suggest the client should use the Validate-Job operation
first, not the Create-Job operation.
Tom
At 08:53 01/07/1998 PST, Turner, Randy wrote:
>
>
> A client IPP implementation would never issue a
> "print-job" operation in the clear, and it would know
> that if it is using an "HTTP:" scheme that thats what
> is happening. An HTTP client wanting to use security
> for the connection would never use "print-job". It would
> always use "create-job" with a
> "client-security-requested" attribute. It would then
> send issue "send-data" ops , etc..
>
> 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.
>>
>> ---
>
>