IPP> Additional proposal details

IPP> Additional proposal details

Carl-Uno Manros carl at manros.com
Wed Jan 7 09:35:30 EST 1998


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.



---




More information about the Ipp mailing list