Keith and Harold,
I think that the Application Area in general has a serious process problem.
We have spent considerable time and effort in the IPP project studying and
evaluating security services and security options. In parallell, the
Security Area seems to contuinually change the rules of the game. As I have
stated before, I think that we, the Application Area standards developers
are the main customers of the Security Area and they seem to ignore us
totally. We are getting tired of trying to predict what may or may not fly
in the IESG, when it comes to security options.
If the security people are going to dictate in every detail what we can or
cannot do, then I think it is their responsibility to make sure that they
participate in our WGs to give advice us advice in the context of our needs
and discussions, rather than come down and criticize what we have done
every time we think we have found an acceptable solution.
Keith and Harald, with all due respect, your advice in th area of security
has not been very reliable either; we need the advice directly from the
people who is going to review this aspect of our work in the IESG.
Yesterday's Application Area WG meetings in the IETF showed very clearly to
me that several other Application Area WGs are in the same boat as we are
here. I pointed out these problems in the Application Area WG Chair
meetings during the previous two IETF meetings, but the situation has not
improved. Action, please!
My 2 cents,
Carl-Uno Manros
In my role as co-chair if the IPP WG
At 10:22 AM 12/8/97 PST, Keith Moore wrote:
>> 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure that our
>> specs say that we MUST support the mandatory features that are minimum
>> requirements for TLS, such as the cypher suite.
>>1. IESG has not allowed other groups to reference SSL, and it unlikely
>that an exception would be made for IPP. If IPP uses SSL-like
>technology, the reference should be to the TLS RFC.
>>2. If IPP specifies TLS authentication, IPP must either implicitly use
>the mandatory ciphersuite from the TLS spec, or specify at least one
>mandatory TLS ciphersuite.
>>3. It will be very difficult for IPP to convince IESG to accept any
>mandatory TLS ciphersuite that uses encumbered algorithms, especially
>given that adequate unencumbered algorithms seem to be available.
>>Suggestion: specify MUST implement ciphersuite
>TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one
>or more of the ciphersuites commonly used with SSL3.
>>Keith
>>>>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