Randy,
We already have that as an Appendix in the Protocol Specification draft. We
should just check if we need to do any further edits to the Appendix. Check
Bob's latest draft.
Carl-Uno
At 05:29 AM 12/9/97 PST, Turner, Randy wrote:
>>>I wrote the TLS requirement based on the availability of
>TLS as a proposed standard. And like Scott has pointed
>out, I did not mention SSL3 because of comments I
>received on the DL and from others about referencing
>something like SSL3 that is not somehow on the
>standards track.
>>I guess what I'm proposing is that we include an
>informative appendix (non-normative) that talks about
>how to interoperate in "legacy" SSL3 environments. This
>is exactly how its done in the TLS 1.0 document as well.
>>Randy
>>> -----Original Message-----
>> From: Scott Isaacson [SMTP:SISAACSON at novell.com]
>> Sent: Monday, December 08, 1997 10:46 PM
>> To: cmanros at cp10.es.xerox.com; moore at cs.utk.edu;
>>rturner at sharplabs.com>> Cc: ipp at pwg.org; Harald.T.Alvestrand at uninett.no>> Subject: RE: IPP> Re: Area Directors' comments on IPP
>>>> Randy and all,
>>>> To be perfectly clear, let's review some of the language that has been
>> written down (both in the last call I-D and in emails since then).
>>>> >>> "Turner, Randy" <rturner at sharplabs.com> 12/08 9:33 PM >>>
>>>>>> > The problem with not mentioning SSL3 as allowable in our
>> > specification is that, until TLS becomes available, there will
>> > be no interoperable implementations of IPP for IPP servers
>> > implemented as CGI behind generic HTTP servers.
>>>> The security text that Randy wrote during the WG final comment period
>> does
>> not metion SSL3 at all. Does it need to? I beleive that the I-D used
>> to
>> say that SSL3 might be used by implementers however such an product
>> would
>> NOT be compliant. It was just as statement about the realities of
>> deploying
>> IPP over existing (now, today) infrastructure.
>>>> > And thats assuming that all the server installed base upgrade
>> > when these TLS servers become available (which is unlikely).
>> > I'm open to other wording in the spec, but we need to
>> > document that SSL3 servers CAN interoperate with clients
>> > that implement TLS, and vice versa.
>>>> The text that Randy proposes is:
>>>> "Within the context of this document, a "secure" implementation is one
>> that
>> utilizes a transport layer that supports Transport Layer Security
>> (TLS)
>> Version 1.0."
>>>> > And I totally agree that we need to try to meet our security
>> > requirements without mandating encumbered security
>> > mechanisms. To this end, some combination MD5,
>> > Diffie-Hellman, and Triple-DES should give us a reasonable
>> > level of security.
>> > I don't feel that these technologies place an undue
>> > burden on simple IPP services since we have agreed that
>> > "secure" IPP clients and servers are optional.
>>>> Randy has written the following proposed text to support the idea of
>> "if
>> security is implemented, it MUST be TSL":
>>>> "Since the security levels or the specific threats that any given IPP
>> system
>> administrator may be concerned with cannot be anticipated, IPP MUST be
>> capable of operating with different security mechanisms and security
>> policies as required by the individual installation. Security policies
>> might
>> vary from very strong, to very weak, to none at all, and corresponding
>> security mechanisms will be required. TLS Version 1.0 supports the
>> type of
>> negotiated levels of security required by most, if not all, potential
>> IPP
>> environments. IPP environments that require no security can elect to
>> deploy
>> IPP implementations that do not utilize the optional TLS security
>> mechanisms."
>>>> Keith and Harald, is this acceptable?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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 at cp10.es.xerox.com