Smith,
No problem having another updated draft... :) As for this:
> On Mar 14, 2018, at 12:56 AM, Kennedy, Smith (Wireless & Standards Architec) <smith.kennedy at hp.com> 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.
>>>> 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.
>> 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.
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. :)
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180314/09abdf4c/attachment.html>