Subject: [IPP] Updated draft of IPP Job Save Password posted for review

From: "Kennedy, Smith (Wireless & Standards Architec)" <[email-masked]>
Date: Mon, 12 Mar 2018 03:24:57 +0000

Greetings,

I have just posted a new draft of IPP Job Save Password:

   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311.pdf
   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311.odt
   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311-rev.pdf
   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311-rev.odt

This draft refactors the proposed attributes as per the discussion back in December 2017 and that we further briefly discussed at the February 2018 F2F.

Cheers,

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 12 Mar 2018 09:48:28 -0400

Smith,

Some quick feedback after looking at the new draft:

- Abstract: The wording here seems a little redundantly redundant. :)

- Sections 4.1.3 and 4.1.5: RFC updates - 7616 for Digest and 7617 for Basic.

- Section 4.1.6 (and this is probably an errata for IPP Scan and IPP INFRA as well): access-x509-certificate is insufficient by itself for authentication - you need the private key as well to do the signing (to prove that you "own" the certificate...) Probably need to say that the printer obtains the signing key through an out-of-band means.

- Section 5.1: Not sure how to use this attribute; we don't have its equivalent for IPP Scan or INFRA.

- I think we'll need to add an Additional Semantics section to briefly say that job-save-accesses gets copied to the Job Object but not returned as a Job attribute.

- Section 16: Should say more about protecting the values of job-save-accesses in transit and at rest.

Overall I think the draft is shaping up, although my gut says we still need to frame/document the scope and usage a little more - right now I can see how this would provide credentials for the save process but not how it requires those credentials for the reprint use case.

> On Mar 11, 2018, at 11:24 PM, Kennedy, Smith (Wireless & Standards Architec) <[email-masked]> wrote:
> 
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Ira McDonald <[email-masked]>
Date: Mon, 12 Mar 2018 10:43:06 -0400

Hi,

>From here (Detroit area in Michigan), entire PWG site (HTTP and FTP) has
been down for several hours.
I can't reach the home page via HTTP.   FTP connects, but an "ls" hangs
indefinitely and Control-C hangs
trying to break the connections.

So I can't fetch these files just now.

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: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Mar 12, 2018 at 9:48 AM, Michael Sweet <[email-masked]> wrote:

> - Section 4.1.6 (and this is probably an errata for IPP Scan and IPP INFRA
> as well): access-x509-certificate is insufficient by itself for
> authentication - you need the private key as well to do the signing (to
> prove that you "own" the certificate...) Probably need to say that the
> printer obtains the signing key through an out-of-band means.
>
> - I think we'll need to add an Additional Semantics section to briefly say
> that job-save-accesses gets copied to the Job Object but not returned as a
> Job attribute.
>
> - Section 16: Should say more about protecting the values of
> job-save-accesses in transit and at rest.
>
> Overall I think the draft is shaping up, although my gut says we still
> need to frame/document the scope and usage a little more - right now I can
> see how this would provide credentials for the save process but not how it
> requires those credentials for the reprint use case.
>
>
> > This draft refactors the proposed attributes as per the discussion back
> in December 2017 and that we further briefly discussed at the February 2018
> F2F.
> >
> > Cheers,
> >
> > Smith
> >
> > /**
> >    Smith Kennedy

---

From: "Kennedy, Smith (Wireless & Standards Architec)" <[email-masked]>
Date: Mon, 12 Mar 2018 15:02:32 +0000

Hmmm, maybe something on your end? HTTP, HTTPS, and FTP all working for me to both ftp.pwg.org <http://ftp.pwg.org/> and www.pwg.org <http://www.pwg.org/>.

Smith

> On Mar 12, 2018, at 8:43 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> From here (Detroit area in Michigan), entire PWG site (HTTP and FTP) has been down for several hours.
> I can't reach the home page via HTTP.   FTP connects, but an "ls" hangs indefinitely and Control-C hangs
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Mon, Mar 12, 2018 at 9:48 AM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> Smith,
> 
> > On Mar 11, 2018, at 11:24 PM, Kennedy, Smith (Wireless & Standards Architec) <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Greetings,
> >
> >   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311.pdf>
> >   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311.odt <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311.odt>
> >   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311-rev.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311-rev.pdf>
> >   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311-rev.odt <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180311-rev.odt>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>

---

From: Ira McDonald <[email-masked]>
Date: Mon, 12 Mar 2018 11:18:20 -0400

Hi Smith,

Probably on my end - my ISP seems to be selectively going in the weeds for
PWG (otherwise working
fine to all other sites so far this morning) - yesterday, PWG home page was
taking *forever* with Firefox
mentioning stalled CDN servers.

Cheers,
- Ira

PS - I'm going to do a hard reboot - have stopped and reloaded Firefox
several times.

On Mon, Mar 12, 2018 at 11:02 AM, Kennedy, Smith (Wireless & Standards
Architec) <[email-masked]> wrote:

> Hmmm, maybe something on your end? HTTP, HTTPS, and FTP all working for me
> to both ftp.pwg.org and www.pwg.org.
>
> Smith
>
>
>
> <(734)%20944-0094>
> <(906)%20494-2434>
>> - Section 4.1.6 (and this is probably an errata for IPP Scan and IPP
>> INFRA as well): access-x509-certificate is insufficient by itself for
>> - I think we'll need to add an Additional Semantics section to briefly
>> say that job-save-accesses gets copied to the Job Object but not returned
>> as a Job attribute.
>>

---

From: "Kennedy, Smith (Wireless & Standards Architec)" <[email-masked]>
Date: Wed, 14 Mar 2018 04:56:15 +0000

Hi Mike,

I know everybody hates it when I do this but I've edited the March 11 draft to hopefully resolve most of the issues raised. New draft and -rev copies to the last two revisions here:

https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313.pdf> 
https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313.odt <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313.odt> 
https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180311.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180311.pdf> 
https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180311.odt <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180311.odt> 
https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180205.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180205.pdf> 
https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180205.odt <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-savepassword-20180313-rev-20180205.odt> 

> Overall I think the draft is shaping up, although my gut says we still need to frame/document the scope and usage a little more - right now I can see how this would provide credentials for the save…

Isn't that a printer implementation question if the credential is acquired out of band of IPP? HP historically hasn't been interested in that use case but I can imagine that might be a factor in complex printing topologies, where the output device and the Printer object don't reside on the same device.

Smith

/**
    Smith Kennedy

> On Mar 12, 2018, at 7:48 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 14 Mar 2018 11:44:09 -0400

Smith,

No problem having another updated draft... :)  As for this:

> On Mar 14, 2018, at 12:56 AM, Kennedy, Smith (Wireless & Standards Architec) <[email-masked]> wrote:
> ,,,

Well, in the case of the access-xxx member attributes, their usage is fairly unambiguous - the values are the authentication credentials that get passed through to the corresponding URI.

What is currently unspecified is how a Printer can use the access-x509-certificate value, as you need to cryptographically sign a challenge from the TLS server using the corresponding private key in order to pass it (as part of the TLS handshake).  That part isn't mentioned in the current IPP Scan or IPP INFRA specifications and is what I am saying is an out-of-band, implementation-specific detail that we *should* mention so that implementors are aware they need to do more than just pass a public cert without challenge/authentication.

...

My other specific concern is that we still are not addressing the "preserve access control for reprints" use case. Clearly a job that is saved with a username/password could be re-printed by submitting a new job referencing the saved file, which would require the same (or equivalent) credentials.  But a reprint using the Resubmit-Job operation bypasses the saved file and uses the original document data.  The definition of Resubmit-Job specifies the following access rights:

Access Rights: The authenticated user (see [RFC2911] section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client- error-not-authorized' as appropriate.

which allows Jane (assuming she submitted the original job or is an operator or administrator) to reprint the job, re-using (or overriding) any job-password value to hold the job at the printer for release and printing.  But that doesn't allow arbitrary users to later reprint that job, nor does it require job-password to be preserved or used (the Resubmit-Job operation can override Job Templates from the original submission...)

Perhaps I am over thinking this, but *if* we are addressing the "protected" reprint use case I think we should document the solution we've come up with and the steps that a Client and Printer take in implementing it. :)