Smith,
On Jan 24, 2014, at 2:54 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
> Thanks for your reply Mike!
>> To try to be more concise, should IPPIGv2 include Printer recommendations to prevent or stop an imprudent Client from sending “sensitive information” in the clear before the Printer can respond with a 426 Upgrade?
There isn't much you can do beside advertise only IPPS with any discovery protocol or directory service.
> I do understand that HTTP/1.1 Expect isn’t required for an upgrade. If the Client included the HTTP/1.1 Expect header, the Printer could reply early with a 426 before the sensitive information hit the wire.
Exactly. I think we need to document both the best practices and recovery strategies for common issues in the IIG2.
>> It goes beyond TLS - some IPP operations may require authentication, others may not depending on the policy configured in the Printer. So Clients should always include the Expect header unless they know the Printer does not support it, and that allows the correct things to happen without leaking information the Server wants to be confidential based on its configuration.
>> Right! I was thinking about that as well this morning. Should there be yet another attribute like “ipp-operations-requiring-tls”? (Or if we really want to shoot down the rabbit hole, “ipp-operations-security-policy-col”? Gack…) Is there anything like this in the SM?
Nothing yet, but the IDS workgroup has, as part of its charter, a mandate to define policy mechanisms. This may lead to a corresponding IPP binding spec in the future.
But regardless, IPP and HTTP already provide the necessary infrastructure for a Printer to enforce and a Client to respond to policy requirements for authentication, access control, and confidentiality. That is enough for the IIG2...
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair