headers
Peter Lipp | 3 Mar 2000 15:36
Picon

AW: draft-ietf-smime-idea

> In fact, I think there are already FAR too many algorithms,
> variations, etc., in the  S/MIME standard as
> it is, and to virtually no good purpose that I can see.
Yes! As long as there is a strong enough free cipher in there, everybody
should be happy. Maybe another one to choose from, and yes, as AES becomes a
standard, there will be a need to add it(them).

What do the ton's of ciphersuites in TLS buy us if there are major vendors
only supporting the RSA ones and all the products need to be able to talk to
them? Yes, we can say "all ciphersuites implemented in our toolkit"!

Peter
______________________________________
Dr. Peter Lipp
IAIK, TU Graz
Inffeldgasse 16a, A-8010 Graz, Austria
Tel: +43 316 873 5513
Fax: +43 316 873 5520
Web: www.iaik.at
Attachment (smime.p7s): application/x-pkcs7-signature, 6102 bytes
Permalink | Reply | 0 comments |
headers
Teiwes, Stephan (iT_SEC | 3 Mar 2000 18:53

RE: draft-ietf-smime-idea

Firstly, I would like to apologize for the delay of my response (I was busy
on CeBIT).

We highly respect all comments on the draft and would like to proceed in the
following way:

1. we will submit an IPR statement to the IETF and this working group very
soon

2. we will remove all sentences in the draft which could lead to the
impression of marketing; it is not our intention to misuse the draft for
marketing purposes

I would like to remark that the sentence "Organization who make already use
of IDEA for other applications also want to use IDEA in S/MIME." has been
introduced for justification. We sent already an long list of IDEA users in
industry to the SMIME working group (also Mr. Hoffman got this list, and
thus he should not say that he has never heart of anyone wanting to use
IDEA). We can proove that IDEA is widely used in Europe. According to our
experience customers in industry often like to choose a symmetric cipher as
a part of their security policy. This demand should be considered in SMIME,
and that's why we wrote the draft. 

3. The short statement and reference on the security of IDEA has been
introduced in appendix B when Mr. Hoffman asked us to include such a
statement (after submission of draft verion 0). Basically, we reacted on his
doubts about the IDEA security. Anyway, we will remove the statement
"Experts in cryptography consider IDEA to be a highly secure symmetric
cipher [IDEA]" as it can be directly obtained from the stated literature.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Mar 2000 12:56
Picon
Favicon

I-D ACTION:draft-ietf-smime-cast-128-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Use of the CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-01.txt
	Pages		: 6
	Date		: 03-Mar-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into 
the S/MIME Cryptographic Message Syntax (CMS) as an additional  
algorithm for symmetric encryption.  The relevant OIDs and processing 
steps are provided so that CAST-128 may be included in the CMS 
specification [RFC2630] for symmetric content and key encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cast-128-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 7 Mar 2000 01:21

Triple Wrapping Survey

I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not id-data.
The inner Signed Data has the id-data OID in the content type.

2.  Can your implementation handle MIME without Base64 encoding?  I am 
interested in using "binary" instead of Base64 to reduce the overhead.

Russ
Permalink | Reply | 0 comments |
headers
Aram Perez | 7 Mar 2000 15:29

RE: Triple Wrapping Survey

Hi Russ,

I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:housley <at> spyrus.com]
Sent: Monday, March 06, 2000 7:21 PM
To: ietf-smime <at> imc.org
Subject: Triple Wrapping Survey

I have a few questions for implementors.  First some background, then the 
questions.

The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME 
encodings.  If each of these encodings uses Base64, then the overhead is 
huge.  I am interested in ways to reduce the overhead, hopefully without 
hurting IMAP usability.

1.  Can your implementation handle
	MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?

The outer SignedData has the OID for EnvelopedData in the content type, not 
id-data.
The EnvelopedData has the OID for SignedData in the content type, not
id-data.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Blake Ramsdell | 7 Mar 2000 21:26

RE: Triple Wrapping Survey

I think that the point Russ was making is "can you handle nesting of CMS
objects" not "can you handle nesting of MIME wrapped CMS objects".  In our
case, we can only do MIME wrapped CMS objects, but we can handle binary
encoding of those objects.

Blake

-----Original Message-----
From: Aram Perez [mailto:aperez <at> syndata.com]
Sent: Tuesday, March 07, 2000 6:30 AM
To: ietf-smime <at> imc.org
Subject: RE: Triple Wrapping Survey

Hi Russ,

I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:housley <at> spyrus.com]
Sent: Monday, March 06, 2000 7:21 PM
To: ietf-smime <at> imc.org
Subject: Triple Wrapping Survey

I have a few questions for implementors.  First some background, then the 
questions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
RFC Editor | 8 Mar 2000 00:26
Picon
Favicon

RFC 2785 on Methods for Avoiding "Small-Subgroup" Attacks


A new Request for Comments is now available in online RFC libraries.

        RFC 2785

        Title:	    Methods for Avoiding the "Small-Subgroup" Attacks
                    on the Diffie-Hellman Key Agreement Method for
                    S/MIME 
        Author(s):  R. Zuccherato
        Status:     Informational
	Date:       March 2000
        Mailbox:    robert.zuccherato <at> entrust.com
        Pages:      11
        Characters: 24415
	Updates/Obsoletes/SeeAlso: None
        I-D Tag:    draft-ietf-smime-small-subgroup-03.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2785.txt

In some circumstances the use of the Diffie-Hellman key agreement
scheme in a prime order subgroup of a large prime p is vulnerable to
certain attacks known as "small-subgroup" attacks.  Methods exist,
however, to prevent these attacks.  This document will describe the
situations relevant to implementations of S/MIME version 3 in which
protection is necessary and the methods that can be used to prevent
these attacks. 

This document is a product of the S/MIME Mail Security Working Group
of the IETF.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 9 Mar 2000 12:30
Picon
Favicon

I-D ACTION:draft-ietf-smime-domsec-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-04.txt
	Pages		: 8
	Date		: 08-Mar-00
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that have internal PKIs
which are not accessible by the outside world, but wish to interoperate
securely using the S/MIME protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-domsec-04.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 9 Mar 2000 17:39

LAST CALL: draft-ietf-smime-cast-128-01.txt

The CAST-128 algorithm specification is ready for Working Group Last 
Call.  Please post comments to the ietf-smime mail list before 23 March 2000.

Russ

= = = = = = = = = =

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the 
IETF.

	Title		: Use of the CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-01.txt
	Pages		: 6
	Date		: 03-Mar-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into
the S/MIME Cryptographic Message Syntax (CMS) as an additional
algorithm for symmetric encryption.  The relevant OIDs and processing
steps are provided so that CAST-128 may be included in the CMS
specification [RFC2630] for symmetric content and key encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cast-128-01.txt".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Schaad | 9 Mar 2000 16:18

RE: Triple Wrapping Survey

>Hi Russ,
>
>I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
>understand MIME, all implementations should handle binary as this is the
>default unless otherwise specified.

There are some known existing implemenations which cannot correctly handle the
binary versions.  I do not know any longer how wide spread these versions are.

jim

>
>Regards,
>Aram Perez
>
>-----Original Message-----
>From: Russ Housley [mailto:housley <at> spyrus.com]
>Sent: Monday, March 06, 2000 7:21 PM
>To: ietf-smime <at> imc.org
>Subject: Triple Wrapping Survey
>
>
>I have a few questions for implementors.  First some background, then the 

>questions.
>
>The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME

>encodings.  If each of these encodings uses Base64, then the overhead is 
>huge.  I am interested in ways to reduce the overhead, hopefully without
(Continue reading)

Permalink | Reply | 0 comments |

Gmane