Hi Keith and Harry,
I think it's useful to note that even LDAPv3 has recently been
permitted to publish standards track RFCs WITHOUT any security
mechanism (and a rather naive note that suggests read-only
implementations).
I maintain that even a read-only implementation of LDAPv3 without
any security (for read) is a good deal more dangerous in the
business liability and exposure sense that an implementation
of IPP without any security in some printers is.
Cheers,
- Ira McDonald (High North Inc)
------------------------------------------------------------------------
[Keith and Harry's notes]
>From ipp-owner at pwg.org Wed Jul 15 12:25:40 1998
Return-Path: <ipp-owner at pwg.org>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA02665; Wed, 15 Jul 98 12:25:39 EDT
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
id AA15090; Wed, 15 Jul 98 12:18:22 EDT
Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <55042(2)>; Wed, 15 Jul 1998 09:18:20 PDT
Received: from localhost (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA26143 for <imcdonal at eso.mc.xerox.com>; Wed, 15 Jul 1998 12:14:37 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 12:10:38 -0400
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25365 for ipp-outgoing; Wed, 15 Jul 1998 12:07:28 -0400 (EDT)
Message-Id: <199807151607.MAA16598 at spot.cs.utk.edu>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore at cs.utk.edu>
To: Harry Lewis <harryl at us.ibm.com>
Cc: ipp at pwg.org, moore at cs.utk.edu, moore at cs.utk.edu
Subject: Re: IPP> possible compromise?
In-Reply-To: Your message of "Wed, 15 Jul 1998 11:28:58 EDT."
<5030050015552513000002L532*@MHS>
Date: Wed, 15 Jul 1998 09:07:05 PDT
Sender: owner-ipp at pwg.org
Status: R
> Keith, I am trying very hard to follow this discussion to some form =
> of bedrock. I'm not so adamant about the URL scheme... as long as
> I can base my initial implementation on existing, off-the-shelf HTTP
> servers, which I think we have safely agreed upon.
>> What I do need, however, is a timely end to the development process
> for this standards specification. I suspect you would agree - none of
> us have inexhaustible resources.
>> To this end, security appears to be a real "monkey wrench". Your
> statement represents a basic "open loop" in my estimation.
>> It is insufficient, at this point, to be in the position of taking a
> proposal to the IESG which we know will fail to ratify and which is
> completely "Catch22" in context. We can't have security because it's
> not there yet... yet we can't use the security which is there.
> Unless there is some certainty of a very near term resolution of
> the security issue which will satisfy the IESG, I claim we MUST
> focus (and adjust, if appropriate) the IPP effort on utilization
> of a viable interim security method.
Harry,
I share your concern about the need for a timely end to the development
process.
While I do have doubts about the viability of IPP security for some
of the scenarios that IPP has envisioned, I also recognize that my
expertise is limited in this area. I would rather leave it to
the security ADs to evaluate the adequacy of IPP security. If it's
okay with them, it will be okay with me.
Even if the security ADs share my concerns, I will push to get the
Proposed Standard versions of the IPP specifications published quickly
and with as few changes as possible -- perhaps with some sort of
disclaimer about the limitations of the current security setup. The
vast majority of printing applications do not need a fully general
security solution, and IPP should not be kept waiting until such a
solution exists. It may be that IPP needs additional work to
define URL parameters and/or profiles for how TLS should be used
in some of the scenarios, but even if this is necessary I believe
that most of the work can be done in separate documents that aren't
in the critical path for the main IPP set.
I am pushing for the IESG review to be complete by the end of July,
though there is some chance that the review will take two weeks
longer than that. But I am hopeful that IESG can get the feedback to
IPP by end July, and complete IESG approval of any revisions before
the Chicago IETF.
Keith