Re: [IPP] Possible updates to IPP INFRA

Hello All,
After a long hiatus, I'd like to revive this topic.
Following the e-mail thread in May of this year, we've had some out-of-band discussions in June with some of the IPP workgroup members. The purpose of today's update is to summarize these discussions and post the main points to the IPP mailing list so that we can work towards creating an IPP Registration document that extends the IPP System Service Register-Output-Device operation to support the Proxy's X.509 certificate. Proposed attributes are defined Mike's previous e-mail in May 18 2020 (also copied below in this thread).
At a high level, we would like to define the use of X.509 certificates to establish cryptographic pairing during Registration of the Output Device to the Cloud through the Proxy. This is for *authenticating* and *authorizing* a Proxy/Output Device using an X.509 certificate.  

For the purposes of the INFRA Spec (finalized in 2015), the Registration (and how the credentials are managed) were out-of-scope. INFRA Spec. just dealt with a pre-existing relationship between the Proxy and Infrastructure Printer.
The Registration piece was defined in detail (also in 2015) in Cloud Imaging Requirements and Model (IMAGINGMODEL). This is the semantic model which does not define the specific operation and attributes.
Later in 2019, IPP System Service v1.0 (SYSTEM) Spec defined the Register-Output-Device operation and its attributes. Now we would like to extend these attributes by adding the use of X.509 certificates.
After more discussion, Mike also suggested adding a "system-mandatory-registration-attributes (1setOf keyword)" System Description attribute (as a semantically analogous version of "system-mandatory-printer-attributes") so that the System can tell a Proxy what information it expects/needs to register an Output Device. This suggestion was seconded by Ira as an important improvement (by the analogy to the one for Printers, necessary for Create-Printer to behave well). So, we will go ahead with this suggestion as well.
In case the X.509 certificate needs to be changed (for expiration or any other reason), I asked how we should update (refresh) the certificate used for registration, and we agreed to define this in the semantics - registering overwrites any previous pairing of UUID with X.509 certificate.
One specification note from Ira - we will NOT change registered operation names - that would be deemed a major breakage in compatibility and we have never done it before.
Finally, the Update-Output-Device-Attributes operation defined in INFRA Spec will not be used to "Update" the registration and the X.509 certificate.  The reason is granting access to a particular System resource is an administrative function, and so should *not* be something that a Proxy operation can do.  Thus, the right place to establish access controls/authorization is in the System operation, *not* the Proxy operation.
Next step is now to work on the IPP Registration document.
Regards,Cihan Colakoglu

On May 18, 2020, at 13:24:34 UTC, Michael Sweet via ipp <ipp at pwg.org> wrote:
Cihan,

Right now I think the path of least resistance is to develop an IPP Registration document that extends the IPP System Service Register-Output-Device operation to support the Proxy's X.509 certificate.  Proposed attributes are:

- "output-device-x509-certificate (1setOf text(MAX))" operation attribute, to be included in the request.
- "output-device-x509-certificate-supported (boolean)" System Description attribute, to tell the Client that the extension is supported.
- "output-device-col-supported (1setOf collection)" Printer Description attribute, to tell the Client which output devices are registered with a given Infrastructure Printer.  Member attributes would be "device-name (name(127))", "device-uuid (uri)", and "device-x509-certificate (1setOf text(MAX))".

The model section (4) of the registration can talk about all of the other concerns you've raised and provide pointers to IPP INFRA, IPP SYSTEM, IPP TRUSTNOONE, and CLOUDMODEL.  We should also talk about OAuth and the use of different authentication methods depending on the configuration and usage, e.g., personal printer connected to a Cloud Imaging System vs. enterprise printer where the Client/End User is a customer or employee.

Longer term we can add this content to an IPP System Service errata update, with a corresponding IPP Shared Infrastructure Extensions errata update that has pointers to IPP SYSTEM.

> On May 15, 2020, at 8:49 AM, Cihan Colakoglu via ipp <ipp at pwg.org> wrote:
> 
> Hello All,
>  
> I was reading the IPP INFRA Spec. (PWG 5100.18-2015:) and found some confusing areas (at least to me).
> Also had some questions about using X.509 certificates for registering the output device through the Proxy to the Cloud.
> I was wondering if an update to IPP INFRA would be warranted, or if we can do an Errata, or maybe even a Best Practice.
>  
> Regarding the issues with Registering an Output Device:
> ·         The INFRA Spec defines “Deregister-Output-Device” operation, but it does not define “Register-Output-Device”.
> ·         Instead, the INFRA Spec says “Update-Output-Device-Attributes” is the inverse of “Deregister-Output-Device”.
> ·         However, IPP System Service (PWG 5100.22-2019:) defines the “Register-Output-Device” and refers to INFRA.
> ·         INFRA does not refer to SYSTEM since INFRA was finalized in 2015, and SYSTEM was finalized in late 2019.
> ·         I understand now INFRA assumed registration was done out-of-band, and it just dealt with an existing association.
> ·         If we update INFRA, we may want to clarify the Registration/Provisioning piece was defined in the SYSTEM Spec.
>  
> Regarding using X.509 Certificates to establish cryptographic pairing during Registration of the Output Device:
> ·         The “Register-Output-Device” operation in SYTEM Spec. does not appear to have an attribute to use a certificate.
> ·         If we want to allow the use of X.509 Certificates for registration, I suppose we could define a new operation attribute.
> ·         There is also the question if a Self-Signed certificate can be used, or if we need a CA-Signed one (Private or Public).
> ·         If we define this, we may want to separate the “Client-to-INFRA-Printer” piece from “Proxy-to-INRA-Printer” piece.
> ·         Then, how would we define what an Admin can do from the Cloud Dashboard/Portal once the Registration is done?
> ·         Should the Registration be done ONLY from the Proxy to the Cloud, and not through the Cloud Portal for security?
>  
> Regarding possible Cloud to Cloud communication use-cases
> ·         In some instances, jobs may need to travel through multiple Clouds to get to the final Output Device.
> ·         I don’t believe IPP INFRA addresses this specifically, however could the Classic fan-out with IPP used for this?
> ·         If we do an update to INFRA, we may want to clarify how this type of communication could be handled with IPP.
>  
> Regarding the IPP Specifications relevant to a Cloud Model:
> ·         I think not everyone can navigate easily through all available (Historic and Current) IPP Specifications.
> ·         So, we may want to list the relevant specifications within the scope of a Cloud Printing model:
> o   IPP INFRA (PWG 5100.18-2015:)
> o   IPP System Service (PWG 5100.22-2019:)
> o   IPP Encrypted Jobs and Documents (Working Draft)
> o   Cloud Imaging Requirements and Model (Link)
> o   Any other?
>  
> I wanted to start a discussion whether it is warranted to update IPP INFRA all together, do an Errata, or a Best Practice.
> 
> Best Regards,
> Cihan Colakoglu