Small issues with TXT record of printing part

[tillkamppeter]

Below is the complete DNS-SD record of the printer part of my HP OfficeJet Pro 8730. I do not know whether one can extract all of these items from the get-printer-attributes IPP request, and there are items which depend on the interface, like the MAC address. Interesting is the "rfo=ipp/faxout/". This means that the printer has a URI "ipp://HOST:PORT/ipp/faxout" for sending faxes. You can do a get-printer-attributes IPP request on this URI and generate a PPD file (and there are also many non-PPD-typical fax-specific options), create a queue, and then print jobs with "-o phone=XXX" with XXX being a fax number and you send a fax. Works even with IPP-over-USB. I have tested this. There is no hint for this fax support in the get-printer-attributes IPP response for the printing part. Probably one should try a get-printer-attributes IPP request on the ipp/faxout URI and if this succeeds add "rfo=ipp/faxout" to the TXT record. Here is the IPP response for get-printer-attributes on the printer part: HP-OfficeJet-Pro-8730-ipp-attrs.txt

Service Type: _ipp._tcp
Service Name: HP OfficeJet Pro 8730 [08C229]
Domain Name: local
Interface: enx00051bb07395 IPv4
Address: HP18602408C229.local/10.0.0.3:631
TXT adminurl = http://HP18602408C229.local./#hId-pgAirPrint
TXT Duplex = T
TXT URF = CP1,MT1-2-8-9-10-11,PQ3-4-5,RS300-600,SRGB24,OB10,W8,DEVW8,DEVRGB24,ADOBERGB24,DM3,FN3,IS1-2,V1.4
TXT note = 
TXT Fax = T
TXT rp = ipp/print
TXT ty = HP OfficeJet Pro 8730
TXT priority = 20
TXT mopria-certified = 1.3
TXT txtvers = 1
TXT TLS = 1.2
TXT product = (HP OfficeJet Pro 8730)
TXT usb_MDL = OfficeJet Pro 8730
TXT qtotal = 1
TXT usb_MFG = HP
TXT mac = 18:60:24:08:c2:29
TXT kind = document,envelope,photo,postcard
TXT UUID = dbcc4b58-fc4c-f6fd-b4d6-2b00d554ad47
TXT Scan = T
TXT Color = T
TXT pdl = application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/postscript,application/pdf,image/jpeg,application/PCLm,image/urf,image/pwg-raster
TXT PaperMax = legal-A4
TXT rfo = ipp/faxout

Missing in TXT record of both ippusbxd and ipp-usb are:

• Fax
• Scan
• TLS
• mac
• rfo

Fax, Scan, and rfo can be derived by checking the scan and fax URIs (the scan URI you are checking already). mac does not make sense for localhost. The TXT record of ipp-usb has usb_CMD, which the network record misses. Not really a problem. Could you add themissing Fax, Scan, and rfo items?

[tillkamppeter]

After your commits c3bd1c1, d989a81, and 7d21f23e the scanning and faxing properties are correctly reflected in the "Internet Printer" DNS-SD record, making it mainly missing the "mac" and "TLS" entries. AFAIK there is no such thing as a MAC address for a localhost-to-USB connection, and it also does not make much sense (am I right? If not, please tell and open a new issue). On TLS we concluded that it does not make much sense on USB in OpenPrinting/ippusbxd#11. Therefore I am closing this issue here.

[alexpevzner]

Have no idea who might ever want to get printer MAC address from DNS-SD. The only idea that comes to mind is to use it to merge together advertisings from IPv4 and IPv6 world, if device UUID is not available. My Kyocera doesn't advertise MAC.

Regarding TLS, I cannot allow HTTP upgrade to TLS, because at this case I will loose control on the HTTP traffic, so I explicitly disable such an upgrade, as well as websocket upgrade for the similar reason (though, nobody tries).

However, I can terminate TLS in the ipp-usb proxy my myself. It doesn't make a lot of sense for PC, where ipp-usb works on localhost behind CUPS, but I want to attract Raspberry Pi / OpenWrt users as well, where ipp-usb can be very usable, because it allows to convert USB printer into network printer, and doesn't require full-scale CUPS installation to do it.

The most nonobvious part of TLS support is usable logistics of TLS certificate. Instruction to generate certificate, using command-line openssl, and save it into the "/var/ipp-usb/dev/0482-069d-VCF9192281-Kyocera-ECOSYS-M2040dn.crt" file obviously will not work, it is too difficult for common user to deal with.

The best idea that comes to my mind, is to automatically generate self-signed RSA cert when device is first detected and save it on a per-device basis. After all, these certificates will not be worse that those that comes with devices, preinstalled at factory.

[tillkamppeter]

Great, this would also mean that you get TLS with devices which by themselves do not do TLS. So a Raspberry Pi replaces the original network interface of a cheapo printer to make it more secure.

[alexpevzner]

Please note that these certificates cannot be validated the usual way, because they are not signed by any CA.

I believe that TLS without certificate validation doesn't add a lot of security.

In sane-airscan I plan to eventually add to configuration file a while list of trusted certificates (identified by fingerprint), which will make it really secure. May be, the similar solution could by eventually implemented in CUPS as well, for secure printing.