There is still some misunderstandings about what the proposed security
solution for IPP is. Randy Turner from Sharp is currently writing up some
text to explain the propsed solution in more detail which should be
available shortly, but see some initial comments from me inserted in your
text below:
At 06:33 AM 11/6/97 PST, you wrote:
>As someone representing a print server vendor, I would like to go on
>record as being against requiring support for SSL3. Requiring support
>for it will add additional cost to both the client and the printer, and
>most applications will not need it. I have no objection to making
>support for a secure protocol optional. Some vendors will have
>applications which require security, and having a standardized way of
>supporting secure IPP will allow products from those vendors to
>interoperate. However, the rest of us who don't need security, should
>not be forced to incur the additional cost of implementing something
>like SSL3 in order to be IPP compliant.
There is a difference in supporting the whole SSL3 set of functionality vs.
using the negotitiation mechanism, which actually allows you to state that
your IPP client or IPP server does not want to use any security features.
The current discussion is about mandating the capability for IPP clients
and servers to support the negotiation mechanism, but allowing
implementations to negotiate NULL securiry.
Earlier IPP solutions discussed the option of having both a secure and an
insecure URI for the same IPP printer object, but this turned out to be
rather messy, like would you cross-reference between the two URIs, which
one (or both?) would you list in a Directory etc. The latest proposal
solves a number of such issues.
>In other words, basic IPP should not require SSL3 or any other secure
>protocol. However, if some vendor wants to implement a secure version
>of IPP, then the IPP spec should require that they implement it in a
>specific fashion so that their products are compatible with products
>from other vendors who implement secure IPP.
>
>Also, I think SSL3 is a proprietary protocol owned by Netscape. If this
>is the case, we definitely should not MANDATE support for a proprietary
>protocol. I suggest that we support a secure protocol which is in the
>public domain. I suggest TLS. From what I understand about it, TLS is
>based on SSL3, but is in the public domain (or at least will be when the
>spec is finalized). My objection to SSL3 is because I think it's
>proprietary. If I'm wrong and SSL3 is in the public domain, then I have
>no objection to it as long as IPP does not require support for it in
>applications which don't require security.
We DO intend to use TLS for IPP as documented in our latest drafts.
Unfortunately the TLS specifications are not yet frozen so we cannot
reference them. SSL3 is an open specification from Netscape, which has also
been implemented by Microsoft and many others, and is the closest we can
get until the TLS specification gets official. Furthermore, the TLS
specifications will include rules for how to interwork with SSL3. A number
of vendors are already preparing IPP products and we cannot delay the IPP
specifications further in wait for TLS if we want to avoid seeing a number
of "almost IPP, but not quite" implementations in the market place.
>
> Charles Gordon
> Osicom/DPI
>
>
>> -----Original Message-----
>> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
>> Sent: Wednesday, November 05, 1997 8:09 PM
>> To: ipp@pwg.org
>> Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971105
>>
>> Minutes from PWG IPP Phone Conference 971105
>>
>> Attending: Harry Lewis
>> Ron Bergman
>> Randy Turner
>> Carl-Uno Manros
>> Tom Hastings
>> Peter Zehler
>> Xavier Riley
>> John Wenn
>> Ira Mcdonald
>> Stan McConnell
>> Scott Isaacson
>>
>> The following topics were discussed:
>>
>> Comments on minutes from Boulder
>>
>> How to perform checking that the sender of a Cancel-Job operation is
>> the
>> same as the job initiator. It was concluded that the responsibility
>> for
>> this is in the IPP server, which might use a simple user name or a
>> more
>> elaborate user certificate to establish the identity (depending on
>> security
>> level used). The attribute "originating-user-id" has been intended for
>> this. this can contain non-printable information. It was concluded
>> that
>> this is really a hidden atribute which the server uses internally and
>> hence
>> can be deleted from the IPP specification. Some text explaining this
>> should
>> be added instead.
>>
>> Another discussion was held on the use of SSL3 negotiation. Some
>> conclusions oiut of that discussion was: All IPP communication over
>> HTTP
>> will be using the URI scheme "hhtps". Alias names can be given to
>> printers
>> using some other schema e.g. "http', but in such cases the server
>> would
>> refer the user to the real "https" URI before the actual IPP protocol
>> exchange starts. The latter is really an implementation matter and
>> does not
>> need to go into the standards text. It was suggested that we do not
>> specify
>> use of "https", or any other URI scheme in the Model document (but in
>> the
>> Protocol document) apart from in examples. Randy also wanted to
>> mandate use
>> of SSL3 (later TLS) in the Model document. There was not full
>> agreement
>> about this.
>>
>> Some concerns were raised that not all current Web server
>> implementation
>> supporting SSL3 also support null framing only, and that hence only
>> some
>> serevers could be used for IPP if we mandate the SSL3 framing. Some
>> further
>> discussion with vendors is needed.
>>
>> Randy promised to have his proposed security changes out to the DL
>> before
>> the end of the week. At this stage is unclear whether it is meaningful
>> to
>> make that text into a I-D or just consider as a proposal against the
>> planned "last call" texts.
>>
>> Carl-Uno stated that he will hold off the request to AINA for a port
>> number
>> until we know for sure what the security details will be.
>>
>> It had been discovered that the atribute on "page-ranges" needs some
>> further text to explain how it behaves for multi document jobs. Tom
>> will
>> try to improve the text.
>>
>> Scott joined in towards the end of the conference and confirmed that
>> he and
>> Tom were still doing some editing on the Model document, but that it
>> should
>> be ready to send to the IETF this week. It is assumed that Bob is
>> working
>> to the same schedule. No news where Steve Zilles stands with the
>> update of
>> the Rationale document.
>>
>> Carl-Uno pointed oput that he has started the final call for the
>> Requirements and the LPD Mapping documents today (both have been
>> available
>> as drafts for some time).
>>
>> Ira commented that he had found some atribute name differences
>> compared to
>> the latest Model draft. He will submit these differences in response
>> to the
>> "last call".
>>
>> We expect to have the next call same time next week.
>>
>> Carl-Uno
>> Carl-Uno Manros
>> Principal Engineer - Advanced Printing Standards - Xerox Corporation
>> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
>> Phone +1-310-333 8273, Fax +1-310-333 5514
>> Email: manros@cp10.es.xerox.com
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com