Some comments inline: Michel Drescher wrote:
Dave, Andreas,
I think this is the right path we are heading.
David Snelling wrote:
Andreas,
I believe we should include some normative statements about cypher suites. I would suggest we pick one or possible two that are pretty universal and say the MUST be supported by the server side. Clients SHOULD use these. and both MAY us others, including ones not yet on the list.
I think this is overly restricted. While I agree that we should add a core set of cipher suites that MUST be supported, using MAY for the rest is too relaxing. I would have a SHOULD for them.
I agree with Dave's wording here. I think he's got it right when this is stated as a compliance statement.
Regarding cipher suites defining no encryption. We should still allow them as they serve important use cases, but we should not require implementations to support them.
Not sure, I think I have to see against which compliance statement this would apply.
Regarding cipher suites that make use of weak methods. We should disallow them as they claim protection they actually do not provide, such as RSA export grade authentication, RC4 encryption, or MD2(?) message hashing.
As a summary, we should add three sections to the profile and explain where we sourced the list of cipher suites from (was it the IETF? TLS specification?): a) A section with cipher suites that MUST be supported (strongest protection in all three aspects of a cipher suite) b) A section with Cipher suites that MUST NOT be supported c) A section stating that all the rest SHOULD be supported.
I think this is reasonable and is quite close to what the WS-I BSP 1.0 has done with sections on - Mandatory - Recommended - Discouraged - Prohibited And this comes back to the question I asked in the initial email and I hope that Takuya can answer. What is the relationship of the claims of the Secure Channel and the WS-I BSP claims (sections 3.2). Btw, I am looking at the Aug 2006 version of the WS-I BSP and not the one that Takuya has in the References which is one year older (Aug 2005).
We also should think of adding an expiry date to the profile to enable regular updates in case a security method is considered unsafe after the publication date of the profile (for example, SHA-1 was considered safe until very recently, but the discussions are still ongoing on this one).
An expiry date is probably a good idea for this kind of document. -- Andreas Savva Fujitsu Laboratories Ltd