Subject: Re: [IPP] RFC: job-name and allowed characters, additions to IPP Everywhere

From: Michael Sweet <[email-masked]>
Date: Thu, 10 May 2012 11:03:42 -0700

Good catch, yes DEL should also be banned (it is in 5198)

On May 10, 2012, at 10:57 AM, James Howard Young <[email-masked]> wrote:

> Hello Michael,
> 
> If you wish to disallow US-ASCII CONTROL chararacters in name
> values (and this is probably a good thing) then you might
> also want to consider disallowing decimal 127 (0x7f, octal 177)
> as well.  This is the dredded ASCII "DEL" character.
> 
> Here's a couple of quick links to some ASCII tables:
> 
>  http://www.asciitable.com/
>  http://www.table-ascii.com/
> 
> Sincerely,
> 
> Jim Young
> Long ago print server implementer
> 
> On 5/10/12 1:24 PM, "Michael Sweet" <[email-masked]> wrote:
> 
>> 
>> 
>> 
>> All,
>> 
>> 
>> I recently got a CUPS bug report (http://www.cups.org/str.php?L4072)
>> where control characters in the job-name value were causing problems with
>> a particular IPP printer.
>> 
>> 
>> In doing some research on what is allowed for a name value, it seems that
>> RFC 2911 and 3196 don't go beyond referencing the RFCs defining UTF-8
>> (3629) and US-ASCII (2045), and I don't see anything in those documents
>> that would prevent the use of control
>> characters in the range of 0 to 31 (decimal).  Appendix B of RFC 5198
>> (Unicode Format for Network Interchange) talks a bit about this issue but
>> doesn't make any normative requirements.
>> 
>> 
>> Given the interoperability and security implications of control
>> characters in name and text values, I would like to document the issues
>> and possibly add some normative requirements. Here is what I'd like to
>> add to IPP Everywhere:
>> 
>> 
>> 1. Clients and Printers MUST NOT accept or transfer name values
>> containing control characters. For US-ASCII that covers the characters
>> from 0x00 to 0x1F (C0) and for UTF-8/Unicode it covers the characters
>> from 0x00 to 0x1F (C0) and 0x80 to 0x9F (C1).
>> 
>> 
>> 2. Clients and Printers MUST NOT accept or transfer text values
>> containing control characters other than CR and LF.
>> 
>> 
>> 3. Implementation guidance for Create-Job/Print-Job/Print-URI: Printers
>> MAY filter out disallowed characters in job-name but MUST return job-name
>> in the unsupported attributes group. Status code is
>> client-error-unsupported-attributes-or-values (for
>> ipp-attribute-fidelity=true
>> or job-mandatory-attributes=job-name) or
>> successful-ok-ignored-or-substituted-attributes (otherwise).
>> 
>> 
>> 4. Add discussion of security considerations for logging of control
>> characters, specific reference to RFC 5198.
>> 
>> 
>> Thoughts?
>> 
>> 
>> __________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> 
>> 
>> 
>> 
>> 
>> -- 
>> This message has been scanned for viruses and
>> dangerous content by MailScanner <http://www.mailscanner.info/>, and is
>> 
>> believed to be clean.
>> 
>> 
>> 
> 
> 
> 

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Thu, 10 May 2012 16:30:52 -0400

Hi,

Thanks for the DEL catch James!

Mike - bullet (2) (MUST NOT accept/transfer controls except CR or LF)
runs afoul of the ABNF for "ipp-printer-device-id" in [PWG5107.2] which
also allows HT (per IEEE 1284 parent spec).

And for attributes shared/coordinated w/ IETF or PWG MIBs, note that
DisplayString (RFC 2579) allows NVT-ASCII per TELNET (RFC 853),
which defines several control characters but allows *all* of the C0 control
characters.

Examples of ASCII attributes include:  sysDescr, sysName, sysLocation,
sysContact, and hrDeviceDescr.

Examples of ambiguous (OCTET STRING) charset attributes (often UTF-8)
include: prtGeneralPrinterName, prtGeneralServicePerson, and
prtGeneralCurrentOperator, and prtGeneralSerialNumber.

I have personally seen quite a few MIB walks of printers w/ HT and/or VT
in their sysLocation or sysContact values.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Michael Sweet <[email-masked]>
Date: Thu, 10 May 2012 16:38:04 -0700

Ira,

> also allows HT (per IEEE 1284 parent spec).

I have no problem adding HT as an allowed character.  I am less inclined to allow VT mainly because I see it rarely and there is no "standard" vertical tab spacing as there is for HT (8 columns for most terminal emulators and web browsers).  But even HT is problematic for display (less so for parsing and logging).

> sysContact, and hrDeviceDescr.

We can define how such values are mapped; realistically I think that we can simply state that any mapping of SNMP properties to IPP attributes MUST include filtering of control characters not allowed by the corresponding attribute type.

(and for things that *are* a direct mapping like prtAlert, prtMarkerSupply, etc. we use octetString which will remain unaffected...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair