Keith and Harald,
I want to verify with you what I interpreted to be new additional security
requirements from our Munich discussions:
1) You are expecting that every new IPP session starts up with a security
2) You are expecting that every IPP Client and Printer has the capability
to support more than the security defined by RFCs 2068 and 2069, e.g.
features corresponding to SSL2 in TLS.
We have started looking into this and are running into the following issues:
1) We have identified several scenarios where security is not needed and
where the overhead of security negotiation and mandatory support for
unnecessary security features is a useless extra burden.
2) TLS is not yet really stable and furthermore does not provide a lot of
security negotiation features.
3) SASL could potentially offer a better negotiation package, but does not
work well with TLS; actually according to recent discussions on the
security DLs, it seems that they are almost totally incompatible. SASL on
its own does not provide what we need.
4) It is also not clear how TLS and HTTP can be made to work together.
5) In the Munich IPP meeting we stated that we thought this was really a
problem for HTTP, and that we could live with most any solution that worked
for HTTP. We are still of that opinion.
We are still digging around to see if we can come up with some half baked
solution that might approximately meet your requirements, but we recent the
idea that we have to develop a separate and special security solution for
IPP just because the appropriate security standardization projects are
still working on their specs.
I am looking for some constructive advice from you as Area Directors.
Is our only option to wait until the security WGs have sorted themselves
out, or are you prepared to relax the requirements? We have been prepared
to let IPP use existing implemented (proprietary) security features and
products for the Internet as an intermediate step, until the IETF security
groups can provide us with standardized and implemented security solutions.
It seems to us that the overall IETF requirement that application standards
include security features before they are fully specified, stable and
implemented is putting up an artificial barrier to application area
projects being able to finish their specifications.
for the IPP WG
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