[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] UPDATED: EncryptionAlgorithmelementunderTransportSecurityProtocol
I did include cipher suites for TLS in the examples.
I agree we should include a ref for TLS, and we
should delete the 2 year old statement.
I am undecided what to say about the TLS version
number in light of this statement from RFC 2246
This document
describes TLS Version 1.0,
which uses the version { 3, 1 }.
Will SSL 3.1 be regarded as the same as TLS with
the version set to 1.0?
We should probably say for standardization.
People might plausibly write down "TLS" and a version
attribute of either "1.0" or "3.1"
Can we just refer to appendix E of RFC 2246
to cover the backward compatibility information?
Dale
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, March 29, 2002 1:44 PM
To: Dale Moberg
Cc: Arvola Chan; Cppa (E-mail); Tony Weida (E-mail)
Subject: RE: [ebxml-cppa] UPDATED: EncryptionAlgorithm
elementunderTransportSecurityProtocol
While we are on the subject, isn't time that the spec talks about TLS,
rather than SSL? After all, TLS is the public standard while SSL is a
proprietary protocol. Currently, the only place TLS is mentioned is in
the
[SSL] reference and all that is there is a 2-year-old statement left
over
from tpaML saying that IETF is working on "Transport Layer Security".
As I
understand it, to a first approximation, the change is only to
substitute
the name "TLS" for "SSL" along with a non-normative discussion of the
extent to which an implementation can use SSL although the CPA say
"TLS".
Regards,
Marty
************************************************************************
*************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
************************************************************************
*************
Dale Moberg
<dmoberg@cycloneco To: Arvola Chan
<arvola@tibco.com>, "Cppa (E-mail)"
mmerce.com>
<ebxml-cppa@lists.oasis-open.org>
cc: "Tony Weida
(E-mail)" <rweida@hotmail.com>
03/29/2002 03:23 Subject: RE:
[ebxml-cppa] UPDATED: EncryptionAlgorithm element
PM
underTransportSecurityProtocol
I thought we were adding EncryptionAlgorithm under
TransportSecurityProtocol, because it pertains to information
about the TransportSecurityProtocol. But I suppose it can go
as a sub-element of the TransportClientSecurity and
TransportServerSecurity. Is there some reason why
one place would be better than the other?
Dale
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, March 29, 2002 11:59 AM
To: Dale Moberg; Cppa (E-mail)
Cc: Tony Weida (E-mail)
Subject: RE: [ebxml-cppa] UPDATED: EncryptionAlgorithm element
underTransportSecurityProtocol
Dale:
Your suggested language for section 8.4.28 is slightly incorrect.
The TransportSecurityProtocol element does not have sub-elements.
EncryptionAlgorithm is a sub-element of the TransportClientSecurity and
TransportServerSecurity elements. (TransportSecurityProtocol and
EncryptionAlgorithm are siblings.)
Excerpt from schema:
==========================================================
<element name="TransportClientSecurity">
<complexType>
<sequence>
<element name="TransportSecurityProtocol"
type="tns:protocol.type"/>
<element name="ClientCertificateRef"
type="tns:CertificateRef.type"
minOccurs="0"/>
<element name="ServerSecurityDetailsRef"
type="tns:SecurityDetailsRef.type" minOccurs="0"/>
<element ref="tns:EncryptionAlgorithm" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="TransportServerSecurity">
<complexType>
<sequence>
<element name="TransportSecurityProtocol"
type="tns:protocol.type"/>
<element name="ServerCertificateRef"
type="tns:CertificateRef.type"/>
<element name="ClientSecurityDetailsRef"
type="tns:SecurityDetailsRef.type" minOccurs="0"/>
<element ref="tns:EncryptionAlgorithm" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
================================================================
The EncryptionAlgorithm element is defined as follows:
<element name="EncryptionAlgorithm">
<complexType>
<simpleContent>
<extension base="tns:non-empty-string">
<attribute name="minimumStrength" type="integer"/>
<attribute name="oid" type="tns:non-empty-string"/>
<attribute name="w3c" type="tns:non-empty-string"/>
<attribute name="enumerationType"
type="tns:non-empty-string"/>
</extension>
</simpleContent>
</complexType>
</element>
Where would you put potentially multiple cipher suite values under
EncryptionAlgorithm? Will some schema change be necessary?
-Arvola
-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Friday, March 29, 2002 9:48 AM
To: Cppa (E-mail)
Cc: Tony Weida (E-mail)
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.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC