Re: Updated IPP OAuth draft posted

"Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email protected]> Wed, 30 Aug 2023 02:01:56 +0000
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Hi Mike,

Thanks as always for the draft updates. I have some feedback to share following a discussion with an HP colleague. Line numbers are from the clean PDF below.

Line 341: "is signed by a Trust Anchor" >>> "is signed by a Trust Anchor held by the system's certificate store". We are suggesting this or similar clarification because there can be more than one set of Trust Anchors on a host. Examples of this would be how Safari and Firefox and Chrome all use different "certificate stores". The hosting OS usually has its own, and in some cases third party apps (like browsers) have their own. I don't know if the print spooler / Client needs its own?

Section 4.1.3: I think we need to remove discussion of certificate validation for URIs that contain hostnames that fall under the "Internal Name" category defined in the CA/Browser Forum Baseline Requirements v2.0.0. Trust Anchors that comply with the CA/Browser Forum Baseline Requirements v2.0.0 (and earlier versions since 2015 or 2016) do not and presumably will not ever be wiling to issue certificates for hosts with either .local hostnames or private IPv4 addresses. (And we probably need to add a reference to the CA/Browser Forum Baseline Requirements v2.0.0 in the document too...)

Section 4.4: "An implementation provides an initial list containing well-known public servers which can be customized by an Administrator."
It seems that different implementations would be shipping with different lists? For proprietary universal printing solutions, they might have an implementation-specific registry for trusted "well-known public servers". What should an IPP Everywhere Client or Printer implementation have? And what would an IPP Everywhere client do about a "trusted network service" to update the list?
So the list is not undateable by IPP i.e., a Set-Printer-Attributes operation?

Section 10.3: After reading some of the CA/Browser Forum Baseline Requirements v2.0.0, I'm worried that ACME IOT is in conflict with the CA/Browser Forum Baseline Requirements v2.0.0? Does this seem like reasonable critique, and if so, should we remove mention of ACME IOT for the 1.0 and stick with purely globally unique Fully Qualified Domain Names?

I'm wasn't familiar with the CA/Browser Forum's work until very recently, and I don't recall us citing their documents in the past but perhaps we need to start doing that?

Cheers,

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Jul 25, 2023, at 6:55 AM, Michael Sweet via ipp <[email protected]> wrote:
> 
> CAUTION: External Email
> 
> All,
> 
> I have posted an updated interim draft of the IPP OAuth Extensions v1.0 to:
> 
>        https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippoauth10-20230725.docx
>        https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippoauth10-20230725.pdf
>        https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippoauth10-20230725-rev.pdf
> 
> ________________________
> Michael Sweet
> 
> _______________________________________________
> ipp mailing list
> [email protected]
> https://www.pwg.org/mailman/listinfo/ipp
>

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)