Yes this is correct. One of the debating points though is still whether you
will be able to go out and buy a "NULL package" SSL3 implementation, or if
you have to craft that on your own. It also seems that a number of current
web servers which use HTTP 1.1 and SSL3 do not accept negotiation to
"NULL", so if you want to use an existing web server implementation as
basis for your IPP server, your choices might be limited.
Carl-Uno
>> -----Original Message-----
>> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
>> Sent: Thursday, November 06, 1997 12:26 PM
>> To: Gordon, Charles
>> Cc: ipp@pwg.org
>> Subject: IPP> RE: SSL3
>>
>> Charles,
>>
>> 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
>
>
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