[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Security Demo
Philippe,
We should also decide on Thursday how many days prior to the event we will do the rehearsal for the demo. It seems like we have to make our travel plans before this Friday.
Hicham
-----Original Message-----
From: Philippe DeSmedt [mailto:PDeSmedt@viquity.com]
Sent: Tuesday, March 27, 2001 3:30 PM
To: ebxml-poc@lists.ebxml.org
Cc: SHIMAMURA Masayoshi; 'iwasa'
Subject: RE: Security Demo
All,
I suggest we put this on the agenda for Thursday's PoC conference call. I'll
send out a conference call schedule later in the day. Thank you to those who
have volunteered already to host the calls. More volunteers are still
welcome.
Thanks.
-Philippe
_______________________________
Philippe De Smedt
Architect
Viquity Corporation (www.viquity.com)
1161 N. Fair Oaks Avenue
Sunnyvale, CA 94089-2102
(408) 548-9722
(408) 747-5586 (fax)
pdesmedt@viquity.com
-----Original Message-----
From: iwasa [mailto:iwasa@fsc.fujitsu.com]
Sent: Tuesday, March 27, 2001 3:16 PM
To: ebxml-poc@lists.ebxml.org
Cc: SHIMAMURA Masayoshi
Subject: Re: Security Demo
POC members,
I think we should have some discussion for Vienna demonstration.
At least we need to decide following spec to realize interoperability:
1.TR&P version
2.Security Technology and version(As Shimamura has suggested)
My proposal is:
1.TR&P Version : SOAP Adapted version(Hopefully 1.0)
*We need to negotiate with TR&P, when can we get
the version we can use for Vienna.
2.Security Technology and Version:
I would propose to use following two technologies.
-XML Signature
*Because TR&P spec says it's a mandatory function
(Is this still correct?)
-PGP/MIME
*Because we can use it easily rather than S/MIME
3.Security Detail:
-We need to discuss more detail soon. I'll discuss someone
who knows security well.
As realizing security interoperability is take time to make sure
it works, we need to decide the direction ASAP.
I'm hoping to have some discussion here. Thanks in advance.
Regards,
-------------------------------------------------------
Kazunori IWASA
Industry Relations, Fujitsu Software Corporation
3055 Orchard Drive, San Jose, CA 95134-2022
TEL: +1(408)456-7983 FAX: +1(408)456-7979
e-mail: iwasa@fs.fujitsu.com
-------------------------------------------------------
----- Original Message -----
From: "SHIMAMURA Masayoshi" <shima.masa@jp.fujitsu.com>
To: <ebxml-poc@lists.ebxml.org>
Cc: <ebxml-transport@lists.ebxml.org>
Sent: Thursday, March 22, 2001 6:55 PM
Subject: Re: Security Demo
> POC Members,
>
> I think the POC Team still does not discuss detail of security demo for
> Vienna. As I pointed out, we need to decide many items for the demo (see
> attached). I'd like to propose that the POC Team begins discussion about
> security demo as soon as possible.
>
> Regards,
>
> --
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783)
> Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
>
>
> > Date: Sun, 11 Feb 2001 16:21:38 +0900
> > From: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> > Subject: Security Demo
> > To: ebxml-poc@lists.ebxml.org
> > Cc: ebxml-transport@lists.ebxml.org
> >
> > POC Members,
> >
> > I believe we need more discussion for security demo of the ebXML Message
> > Service. I'd like to propose that we discuss following issues in
> > Vancouver meeting.
> >
> >
> > 1. What security technologies are used?
> > In the draft proposal of the security demo, three security
> > technologies were proposed.
> > - XML Signature
> > - S/MIME
> > - PGP/MIME
> >
> > We need to decide what security technologies are used to reduce our
> > implementation work. In addition, there are some different version of
> > standard in S/MIME and PGP/MIME. We also need to decide what version
> > of standard is used.
> > - S/MIME
> > - version 2 (RFC 2311 - 2315, 2268)
> > - version 3 (RFC 2630 - 2634, etc.)
> > - PGP/MIME
> > - PGP (RFC 1991, 2015)
> > - OpenPGP (RFC 2440)
> >
> >
> > 2. What algorithms are used?
> > In the security technologies, several algorithms can be used (see
> > following examples). We need to decide what algorithms are used for
> > interoperability.
> >
> > - Used algorithms in XML Signature
> > Algorithm Type Algorithm Requirements
> > ---------------------------------------------------------------
> > Digest SHA1 Required
> > Encoding base64 Required
> > MAC HMAC-SHA1 Required
> > Signature DSAwithSHA1(DSS) Required
> > RSAwithSHA1 Recommended
> > Canonicalization minimal Recommended
> > Canonical XML with Comments Recommended
> > Canonical XML (omits comments) Required
> > Transform XSLT Optional
> > XPath Recommended
> > Enveloped Signature Required
> >
> > - Used algorithms in S/MIME Version 3
> > - Digest Algorithms
> > SHA-1
> > MD5
> > - Signature Algorithms
> > DSA
> > RSA
> > - Key Management Algorithms
> > - Key Agreement Algorithms
> > X9.42 Ephemeral-Static Diffie-Hellman
> > - Key Transport Algorithms
> > RSA
> > - Symmetric Key-Encryption Key Algorithms
> > Triple-DES Key Wrap
> > RC2 Key Wrap
> > - Content Encryption Algorithms
> > Triple-DES CBC
> > RC2 CBC
> > - Message Authentication Code Algorithms
> > HMAC with SHA-1
> > - Triple-DES and RC2 Key Wrap Algorithms
> > Key Checksum
> > Triple-DES Key Wrap
> > Triple-DES Key Unwrap
> > RC2 Key Wrap
> > RC2 Key Unwrap
> >
> > - Used algorithms in OpenPGP
> > - Public Key Algorithms
> > ID Algorithm
> > -- ---------
> > 1 - RSA (Encrypt or Sign)
> > 2 - RSA Encrypt-Only
> > 3 - RSA Sign-Only
> > 16 - Elgamal (Encrypt-Only), see [ELGAMAL]
> > 17 - DSA (Digital Signature Standard)
> > 18 - Reserved for Elliptic Curve
> > 19 - Reserved for ECDSA
> > 20 - Elgamal (Encrypt or Sign)
> > 21 - Reserved for Diffie-Hellman (X9.42,
> > as defined for IETF-S/MIME)
> > 100 to 110 - Private/Experimental algorithm.
> >
> > Implementations MUST implement DSA for signatures, and Elgamal
for
> > encryption. Implementations SHOULD implement RSA keys.
> > Implementations MAY implement any other algorithm.
> >
> > - Symmetric Key Algorithms
> > ID Algorithm
> > -- ---------
> > 0 - Plaintext or unencrypted data
> > 1 - IDEA [IDEA]
> > 2 - Triple-DES (DES-EDE, as per spec -
> > 168 bit key derived from 192)
> > 3 - CAST5 (128 bit key, as per RFC 2144)
> > 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
> > 5 - SAFER-SK128 (13 rounds) [SAFER]
> > 6 - Reserved for DES/SK
> > 7 - Reserved for AES with 128-bit key
> > 8 - Reserved for AES with 192-bit key
> > 9 - Reserved for AES with 256-bit key
> > 100 to 110 - Private/Experimental algorithm.
> >
> > Implementations MUST implement Triple-DES. Implementations SHOULD
> > implement IDEA and CAST5.Implementations MAY implement any other
> > algorithm.
> >
> > - Compression Algorithms
> > ID Algorithm
> > -- ---------
> > 0 - Uncompressed
> > 1 - ZIP (RFC 1951)
> > 2 - ZLIB (RFC 1950)
> > 100 to 110 - Private/Experimental algorithm.
> >
> > Implementations MUST implement uncompressed data. Implementations
> > SHOULD implement ZIP. Implementations MAY implement ZLIB.
> >
> > - Hash Algorithms
> > ID Algorithm Text Name
> > -- --------- ---- ----
> > 1 - MD5 "MD5"
> > 2 - SHA-1 "SHA1"
> > 3 - RIPE-MD/160 "RIPEMD160"
> > 4 - Reserved for double-width SHA (experimental)
> > 5 - MD2 "MD2"
> > 6 - Reserved for TIGER/192 "TIGER192"
> > 7 - Reserved for HAVAL (5 pass, 160-bit) "HAVAL-5-160"
> > 100 to 110 - Private/Experimental algorithm.
> >
> > Implementations MUST implement SHA-1. Implementations SHOULD
> > implement MD5.
> >
> >
> > 3. How to test interoperability of the security technologies?
> > As showed above, the security technologies utilize many algorithms.
> > I think interoperability test of the security technologies require
> > long time. So I'd like to propose that we test interoperability of
> > the security technologies previously on the internet among POC
> > members.
> >
> >
> > Regards,
> >
> > --
> > SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> > TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783)
> > Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC