[IPP] IPP Scan operational attribute addition to the specification

[IPP] IPP Scan operational attribute addition to the specification

[IPP] IPP Scan operational attribute addition to the specification

Ira McDonald blueroofmusic at gmail.com
Fri Jun 20 17:32:25 UTC 2014


Hi Pete,

Yes, please send out a Stable draft that I can send out for PWG Last Call
with Mike's proposed text (note that PWG Last Calls are supposed to be
started by a WG chair or a PWG officer).

Please keep in Mike's editor's note about reservations on X.509
Certificates.
Besides the ambiguities about private key management, there is the issue
about Certification Revocation List (CRL) handling - which is a cumbersome
and nowhere near real-time band-aid for the inherent concerns about X.509
certificates.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
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: blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Fri, Jun 20, 2014 at 1:14 PM, Zehler, Peter <Peter.Zehler at xerox.com>
wrote:

>  All,
>
> I’ve seen no objections to Mike’s note.  I will assume that these are the
> additions we will use.  I can send out a PWG wide Last Call version later
> today.
>
> Pete
>
>
>
> Peter Zehler
>
> [image: parc]
> Email: Peter.Zehler at Xerox.com
> Office: +1 (585) 265-8755
>
> Mobile: +1 (585) 329-9508
> FAX: +1 (585) 265-7441
> US Mail: Peter Zehler
> Palo Alto Research Center Incorporated
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
>
> *From:* Michael Sweet [mailto:msweet at apple.com]
> *Sent:* Monday, June 16, 2014 8:33 PM
> *To:* Ira McDonald
> *Cc:* ipp at pwg.org; Zehler, Peter
> *Subject:* Re: [IPP] Fwd: IPP Scan operational attribute
>
>
>
> Based on discussions in the conference call, here is a summary of the
> proposed additions to IPP Scan:
>
>
>
>
>
> 8.1.1 destination-accesses (1setOf collection | no-value)
>
>
>
> The "destination-accesses" operation attribute allows the Client to
> provide authentication information for each of the "destination-uris"
> values. If provided, this attribute MUST have the same cardinality (have
> the same number of values) as the "destinations-uris" Job Template
> attribute. The ith value of the "destination-accesses" attribute
> corresponds to the ith value of the "destination-uris" attribute.
>
>
>
> Each collection value contains zero of more member attribute which provide
> the authentication information required for the corresponding destination.
> A Client MAY also provide the no-value out-of-band value for a given
> destination to specify that no authentication information is supplied.
>
>
>
> Printers specify which member attributes are supported using the
> "destination-accesses-supported" Printer attribute (section 8.4.1).
>  Printers specify which member attributes are required for a given
> destination in the "destination-mandatory-access-attributes" member
> attribute (section 8.4.2.7) of the "destination-uri-ready" Printer
> attribute (section 8.4.2).
>
>
>
>
>
> 8.1.1.1 access-oauth-token (1setOf octetString(MAX))
>
>
>
> The "access-oauth-token" member attribute provides a Base64-encoded OAuth
> Access Token as defined in The OAuth 2.0 Authorization Framework [RFC6749].
> When the size of the access token exceeds 1023 octets (the maximum size of
> an octetString value), the Client separates the token into multiple
> octetString values and sends the result as an ordered set to the Printer.
> The Printer reassembles each octetString to produce the complete access
> token value to be used with the destination.
>
>
>
> Printers that support this attribute MUST list 'access-oauth-token' in the
> "destination-accesses-supported" Printer attribute (section 8.4.1).
>
>
>
>
>
> 8.1.1.2 access-password (text(MAX))
>
>
>
> The "access-password" member attribute provides a password string,
> typically for HTTP Basic or Digest authentication [RFC2617]. Clients MUST
> provide the password using the UTF-8 encoding [STD63] in Unicode
> Normalization Form C as required for Network Unicode [RFC5198]. Printers
> MUST convert the password, as needed, to whatever encoding is required by
> the destination URI.
>
>
>
> Printers that support this attribute MUST list 'access-password' in the
> "destination-accesses-supported" Printer attribute (section 8.4.1).
>
>
>
>
>
> 8.1.1.3 access-pin (text(MAX))
>
>
>
> The "access-pin" member attribute provides a Personal Identification
> Number string. Clients MUST restrict the characters to the US ASCII digits
> '0' (code 48) through '9' (code 57) and Printers MUST reject values
> containing characters other than the digits '0' through '9'.
>
>
>
> Printers that support this attribute MUST list 'access-pin' in the
> "destination-accesses-supported" Printer attribute (section 8.4.1).
>
>
>
>
>
> 8.1.1.4 access-user-name (text(MAX))
>
>
>
> The "access-user-name" member attribute provides a user name string,
> typically for HTTP Basic or Digest authentication [RFC2617]. Clients MUST
> provide the user name using the UTF-8 encoding [STD63] in Unicode
> Normalization Form C as required for Network Unicode [RFC5198]. Printers
> MUST convert the user name, as needed, to whatever encoding is required by
> the destination URI.
>
>
>
> Printers that support this attribute MUST list 'access-user-name' in the
> "destination-accesses-supported" Printer attribute (section 8.4.1).
>
>
>
>
>
> [Editor's note: I am really not happy with the following, and would be
> happy to punt X.509 certificate passing for now since we don't have a good
> plan for management of private keys associated with x.509 certs...]
>
>
>
> 8.1.1.5 access-x509-certificate (1setOf octetString(MAX))
>
>
>
> The "access-x509-certificate" member attribute provides a PEM-encoded
> X.509 certificate identifying the User or Client that is making the
> request.  When the size of the certificate exceeds 1023 octets (the maximum
> size of an octetString value), the Client separates the certificate into
> multiple octetString values and sends the result as an ordered set to the
> Printer. The Printer reassembles each octetString to produce the complete
> X.509 certificate to be used with the destination.
>
>
>
> Printers that support this attribute MUST list 'access-x509-certificate'
> in the "destination-accesses-supported" Printer attribute (section 8.4.1)
> and MUST provide a method for loading the corresponding private key that is
> used for authenticating the holder of the X.509 certificate.
>
>
>
>
>
> 8.4.1  destination-accesses-supported (1setOf type2 keyword)
>
>
>
> The "destination-accesses-supported" Printer attribute lists the supported
> member attributes of the "destination-accesses" operation attribute
> (section 8.1.1).  This attribute MUST be supported if the
> "destination-accesses" attribute is supported.
>
>
>
>
>
> 8.4.2.7 destination-mandatory-access-attributes (1setOf type2 keyword)
>
>
>
> The "destination-mandatory-access-atributes" member attribute lists the
> member attributes that MUST be supplied in a Job Creation request when
> using this destination.
>
>
>
>
>
> ... plus the corresponding registrations in section 14 and normative
> references in section 15.1 (add RFC2617 and RFC6749)
>
>
>
>
>
> On Jun 16, 2014, at 11:24 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
>
>
>
>     Hi Mike,
>
> Agreed.
>
> It shouldn't be an opaque blob - the "access-type" should be sufficiently
> fine-grained
>
> to allow explicit multi-factor scenarios.
>
> And Pete and I want to state that binary data MUST be sent as straight
> "octetString"
> and and text data (e.g., password) MUST be sent as UTF-8 (with no trailing
> '\0').
>
> The only downside (potentially pretty large for explicit multi-factor
> "access-type"
>
> values is rapid loss of interoperability when vendors roll their own name
> values
>
> for combinations we didn't anticipate.
>
> Cheers,
>
> - Ira
>
>
>   Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> 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: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Mon, Jun 16, 2014 at 11:19 AM, Michael Sweet <msweet at apple.com> wrote:
>
> Ira,
>
>
>
> On Jun 16, 2014, at 11:02 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
>
>   Hi Mike,
>
> The reason for some sparse syntax was to support Pete's use case (over the
> phone)
>
> of wanting two or more credentials for the *same* destination (i.e.,
> multi-factor auth is
>
> in use).  This is a critically important real-world use case.
>
>
>
> Then we need to define it and its requirements.
>
>
>
>   With the straight parallel 1setOf approach, there has to be a nested
> collection to hold
> the auth-type, auth-data, etc. for each credential for one destination -
> ugly and fragile.
>
>
>
> If the auth type defines multiple credentials then those can be provided
> via separate data values in the 1setOf, or using type-specific member
> attributes.  In short, we need to define what the attributes contain, not
> provide a BLOB holder that will become an interoperability nightmare.
>
>
>
>  Pete and I particularly liked the use of the simple (1setOf
> octetString(MAX)) with auto
> concatenation to support large credentials (X.509 certificates, etc.).
>
>
>
> That is indeed a simple solution, but let's not make it an opaque blob.
>
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
>
>
>
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140620/72d91c25/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2783 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140620/72d91c25/attachment.png>


More information about the ipp mailing list