Greetings again,
I posted this without overtly suggest a fix for this:
> The Client can learn the Printer's maximum TLS version via the "TLS" DNS-SD TXT record key (5100.14 section 4.2.3.4). The "uri-security-supported" attribute simply uses 'tls' but lists no version (which troubles me because DNS-SD shouldn't be more descriptive than IPP).
To bring IPP to parity with IPP + DNS-SD, I think we need to either add additional keywords for "uri-security-supported", like 'tls-1.2' and 'tls-1.3', or we create a new attribute. Even with this addition, I also think a new 'client-error-tls-negotiation-failure' status code should be defined.
Have a good weekend,
Smith
/**
Smith Kennedy
Wireless & Standards Architect - IPG-PPS
Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
Chair, IEEE ISTO Printer Working Group
HP Inc.
*/
> On Jul 27, 2018, at 2:25 PM, Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com> wrote:
>> Greetings,
>> In my presentation to the Mopria Technical Working Group yesterday, a question arose about TLS version negotiation failures, and whether the Client would be notified of such failures at the IPP level. I responded that there might be a response at the IPP level but that Clients (and Printers) need to also be aware of the TLS and HTTP levels. But then I remembered that, in the latest draft of the IPP Authentication Methods white paper, Mike and I expanded and revised section 3.1.7 "The 'certificate' IPP Authentication Method" to include the following:
> The Printer SHOULD return the IPP status code listed in Table 3.1 when the corresponding authentication exception occurs. The Client SHOULD respond to the reported status code with the corresponding response listed in Table 3.1.
>>>> Operation Status Code
>> Authentication Exception
>> Recommended Client Response
>> 'client-error-not-authenticated'
>> Authentication required but no X.509 certificate supplied
>> Close the connection; select a certificate (with possible user interaction); retry connection with selected certificate
>> 'client-error-not-authorized'
>> Access denied for the identity specified by the provided X.509 certificate; try again
>> Close the connection; select a different certificate (with possible user interaction); retry connection with selected certificate
>> 'client-error-forbidden'
>> Access denied for the identity specified by the provided X.509 certificate; don't try again
>> Close the connection and present User with error dialog (“Access denied”)
>> Table 3.1 : IPP 'certificate' Authentication Method Error Condition Status Codes
>> None of these seem to cover a lower-level protocol negotiation level failure. Do we need to add a new one for TLS version negotiation failure? The Client can learn the Printer's maximum TLS version via the "TLS" DNS-SD TXT record key (5100.14 section 4.2.3.4). The "uri-security-supported" attribute simply uses 'tls' but lists no version (which troubles me because DNS-SD shouldn't be more descriptive than IPP).
>> Thoughts?
>> Smith
>> /**
> Smith Kennedy
> Wireless & Standards Architect - IPG-PPS
> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
> Chair, IEEE ISTO Printer Working Group
> HP Inc.
> */
>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180728/9563866b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180728/9563866b/attachment.p7s>