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/blueroofmusichttp://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>
