OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-cppa] UPDATED: EncryptionAlgorithm element underTransportSecurityProtocol



Pete,

Here is my amended text for the entry about EncryptionAlgorithm
that incorporate sample values for cipher suites. 

========Background============

Issue 155 states, among other things,"

More details are needed in the CPPA
specification regarding SSL 3.0. 

The need to state the encryption algorithm was
specifically called out."

We do now, of course, have PKI agreements
for either client-side or server-side authentication
represented.

We do allow preference for a given SSL version to 
be stated (presumably either SSL-3 SSL-3.1 TLS 1.0,
since SSL-2 generally deprecated along with SSL-1).

I do think it is worthwhile being able to announce
a capability, preference and agreement about high strength
encryption. I am uncertain how much anyone will need or
benefit from explicitly mentioning algorithms.

I have added Pete Wenzel's suggestion to illustrate
the cipher suite values that can be used here.


========suggested language==============================

8.4.28 TransportSecurityProtocol element
The TransportSecurityProtocol element identifies the transport 
layer security protocol that is supported by the parent Transport. 
The IMPLIED version attribute identifies the specific version of the
protocol. 

For encryption, the protocol is SSL (Secure Socket Layer) Version 3.0 
[SSL], which uses public-key encryption.

8.4.28.1 EncryptionAlgorithm

Zero or more EncryptionAlgorithm elements may be included under the 
TransportSecurityProtocol element. Multiple elements are
of more use in a CPP context, to announce capability or
preferences; normally, a CPA will contain the agreed upon
context. When zero elements are present in a CPA, whatever outcome
the TransportSecurityProtocol handshake decides,
is what the parties in effect agree upon.

The elements' ordering will reflect the preference
for algorithms. A primary reason for including this element is to permit
use of the minimumStrength attribute; a large value for this
attribute can indicate that a high encrytion strength 
is desired or has been agreed upon for the TransportSecurityProtocol.

See section 8.4.48 for the full description 
of this element.

For SSL and TLS, it is customary to specify cipher suite values
under the EncryptionAlgorithm element. These values include:
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, 
SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5,
SSL_RSA_WITH_RC4_128_SHA,
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and
so on. Consult the original specifications for enumerations
and discussions of these values.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC