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: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