Re: [IPP] Possible updates to IPP INFRA

Michael Sweet via ipp <ipp@pwg.org> Mon, 18 May 2020 13:24 UTC

Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F983A0BAA for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 18 May 2020 06:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiRqZGOzRLOu for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 18 May 2020 06:24:46 -0700 (PDT)
Received: from mail.pwg.org (mail.pwg.org [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 708BE3A0BA8 for <ipp-archive2@ietf.org>; Mon, 18 May 2020 06:24:43 -0700 (PDT)
Received: by mail.pwg.org (Postfix, from userid 1002) id 4DBBE626D; Mon, 18 May 2020 13:24:42 +0000 (UTC)
Received: from mail.pwg.org (localhost [IPv6:::1]) by mail.pwg.org (Postfix) with ESMTP id EAC3A3F5; Mon, 18 May 2020 13:24:38 +0000 (UTC)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: by mail.pwg.org (Postfix, from userid 1002) id BFA1F3A8E; Mon, 18 May 2020 13:24:37 +0000 (UTC)
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by mail.pwg.org (Postfix) with ESMTP id E68C53F5 for <ipp@pwg.org>; Mon, 18 May 2020 13:24:36 +0000 (UTC)
Received: from mbp16.lan (host-148-170-144-200.public.eastlink.ca [148.170.144.200]) by mail.msweet.org (Postfix) with ESMTPSA id 21018808B8; Mon, 18 May 2020 13:24:36 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <7bcdf18abe71413f9cb9da678d9782d5@dda.kyocera.com>
Date: Mon, 18 May 2020 09:24:34 -0400
Message-Id: <DBFDB84D-DAEC-48C7-A593-9F8BFA99BF21@msweet.org>
References: <7bcdf18abe71413f9cb9da678d9782d5@dda.kyocera.com>
To: Cihan Colakoglu <Cihan.Colakoglu@dda.kyocera.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Cc: PWG IPP Workgroup <ipp@pwg.org>
Subject: Re: [IPP] Possible updates to IPP INFRA
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
From: Michael Sweet via ipp <ipp@pwg.org>
Reply-To: Michael Sweet <msweet@msweet.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: ipp-bounces@pwg.org
Sender: "ipp" <ipp-bounces@pwg.org>

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@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
> Kyocera Document Solutions
>  
> 
>  
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

________________________
Michael Sweet



_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp