Subject: IPP> RE: SSL3

From: "Gordon, Charles" <[email-masked]>
Date: Thu, 6 Nov 1997 09:33:42 -0500

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.

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.

						Charles Gordon
						Osicom/DPI

> -----Original Message-----
> From:	Carl-Uno Manros [SMTP:[email-masked]]
> Sent:	Wednesday, November 05, 1997 8:09 PM
> To:	[email-masked]
> 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: [email-masked]