Internet-Drafts | 4 Jun 22:19 2004
Picon

I-D ACTION:draft-ietf-smime-rfc2632bis-07.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		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-07.txt
	Pages		: 13
	Date		: 2004-6-4
	
This document specifies conventions for X.509 certificate usage by
S/MIME (Secure/Multipurpose Internet Mail Extensions) agents. S/MIME
provides a method to send and receive secure MIME messages, and
certificates are an integral part of S/MIME agent processing. S/MIME
agents validate certificates as described in RFC 3280, the Internet
X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME
agents must meet the certificate processing requirements in this
document as well as those in RFC 3280.
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

(Continue reading)

Russ Housley | 9 Jun 14:28 2004

Anti-spam news article


This news article will be of interest to members of this IETF mail list.

Russ

---

Subject: No More Spam From Fakes
Web Titans Seek Standard To Authenticate Senders And Thwart Junk E-Mail

By RIVA RICHMOND
DOW JONES NEWSWIRES
June 9, 2004; Page D9

NEW YORK -- Names just don't have the value they used to -- at least
when it comes to e-mail.

After all, spammers, virus writers and identity thieves now regularly
affix fake names to their e-mail messages in hopes of conning users
into opening them and evading block lists. Take a message today from
"Sonia Sauders," subject line "Re: Hey cutie." It could have been a
note from a college chum, but was actually a pitch for porn. With
billions of these messages cluttering e-mail in boxes every day,
there's simply no trusting a name anymore.

But this could change soon, if Internet heavyweights such as Microsoft
Corp., Yahoo Inc., Time Warner Inc.'s America Online unit and EarthLink
Inc. have their way. These otherwise fierce rivals are working together
to come up with standard technologies for authenticating e-mail
senders, which the companies say will make it easier for mail
(Continue reading)

Peter Gutmann | 9 Jun 15:16 2004
Picon
Picon
Picon

Re: Anti-spam news article


Russ Housley <housley <at> vigilsec.com> writes:

>This news article will be of interest to members of this IETF mail list.

Probably off-topic, but I just have to add my $0.02: This was debated on the
cryptography list a week or two back, and before that in another forum, the
general feeling ranged from it being almost completely ineffective through to
marginally effective, and nothing like the optimistic:

  Once rolled out, e-mail authentication is "going to have a major impact" on
  spam, says Miles Libbey, antispam product manager for Yahoo Mail. "That's
  not to say the spammers won't adapt...but it's a critical thing to have in
  place."

in the article.  The protocols mentioned in the article are all some variant
on the "build a big wall around the Internet and only let the good guys in",
which will never work because the Internet doesn't contain any definable
inside and outside, only 800 million Manchurian candidates waiting to
activate.  For example MessageLabs recently reported that *two thirds* of all
the spam it blocks is from infected PCs, with much of it coming from
ADSL/cable modem IP pools.  Given that these "spammers" are legitimate users,
no amount of crypto will solve the problem.  I did a talk on this at the
AusCert 2004 conference where I claimed that various protocols designed to
enforce this (Designated Mailers Protocol, Reverse Mail Exchanger, Sender
Permitted From, etc etc) will buy at most 6-12 months, and the only dissent I
got was from an anti-virus researcher who said it'd buy weeks and not months.

See the cryptography list archives and
http://www.cs.auckland.ac.nz/~pgut001/pubs/dammit.pdf for more on this.
(Continue reading)

The IESG | 14 Jun 21:59 2004
Picon

Protocol Action: 'S/MIME Version 3.1 Certificate Handling' to Proposed Standard


The IESG has approved the following document:

- 'S/MIME Version 3.1 Certificate Handling '
   <draft-ietf-smime-rfc2632bis-07.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document specifies conventions for X.509 certificate usage by
  S/MIME (Secure/Multipurpose Internet Mail Extensions) agents.  S/MIME
  provides a method to send and receive secure MIME messages, and
  certificates are an integral part of S/MIME agent processing.  S/MIME
  agents validate certificates as described in RFC 3280, the Internet
  X.509 Public Key Infrastructure Certificate and CRL Profile.  S/MIME
  agents must meet the certificate processing requirements in this
  document as well as those in RFC 3280.

Working Group Summary

  The S/MIME Working Group came to rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

RFC Editor Note
(Continue reading)

Stefan Santesson | 15 Jun 04:23 2004
Picon

SMIME Capabilities in X.509 Certificates


Stefan Santesson
Program Manager, Windows Security
Principal Consultant, Microsoft Denmark
Please find attached a proposed updated charter which would incorporate
the task to define means to carry SMIME Capabilities in X.509
Certificates.

This revised charter has been reviewed and approved by Russ Hously on
the condition that this WG accept to take on this task.

We had a discussion on this issue in PKIX which some of you may have
noticed where a majority concluded that this was a good thing to do but
the post discussion, especially with Russ, also concluded that SMIME is
probably the best place to do it and not PKIX.

The background of this work item is the need to establish knowledge
about opponents SMIME Capabilities, even before a first message
exchange. We will never escape the fact that a sender of an encrypted
mail some times will have to guess the recipients cryptographic
capabilities. In other situations the sender may have access to multiple
sources of data with conflicting information so the sender should always
be prepared to use the most recent and reliable source of information.
But in absence of any information at all, the sender have to fallback to
default configuration settings.

It would thus improve the situation if CAs, especially enterprise CAs,
that knows or even have the capability to dictate the capabilities of
users, could include the PKCS#9 SMIMECapabilities attribute in
certificates.
(Continue reading)

The IESG | 16 Jun 21:22 2004
Picon

Protocol Action: 'Cryptographic Message Syntax (CMS)' to Proposed Standard


The IESG has approved the following document:

- 'Cryptographic Message Syntax (CMS) '
   <draft-ietf-smime-rfc3369bis-04.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary
 This document is a minor update from RFC 3369.  It corrects some errors, and
makes provision for easy addition of new certificate types.

Working Group Summary

 The changes were uncontroversial.

Protocol Quality

 Steve Bellovin reviewed this document for the IESG.

Stefan Santesson | 18 Jun 17:14 2004
Picon

RE: SMIME Capabilities in X.509 Certificates


Yes,

You have summarized this well.

This work will not impact any S/MIME message profiles, but we may
consider addressing this new extension in the Certificate Handling
document (or future version of it).

/Stefan

> -----Original Message-----
> From: Blake Ramsdell [mailto:blake <at> brutesquadlabs.com]
> Sent: den 17 juni 2004 21:24
> To: Stefan Santesson; 'smime mailing list'
> Cc: 'smime chair'; 'smime chair'
> Subject: RE: SMIME Capabilities in X.509 Certificates
> 
> > -----Original Message-----
> > From: owner-ietf-smime <at> mail.imc.org
> > [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Stefan Santesson
> > Sent: Monday, June 14, 2004 7:24 PM
> > To: smime mailing list
> > Cc: smime chair; smime chair
> > Subject: SMIME Capabilities in X.509 Certificates
> >
> > It would thus improve the situation if CAs, especially enterprise
CAs,
> > that knows or even have the capability to dictate the capabilities
of
(Continue reading)

Craig McGregor | 22 Jun 05:12 2004
Picon
Picon

RE: Anti-spam news article / S/MIME Gateways


>Tumbleweed Chief Executive Jeff Smith says there's a lot of
misunderstanding about 
>S/MIME, because it was created as a desktop encryption technology. He
argues it's
> also simple and cost-effective to use as a gateway authentication
technology, and
> that its quality advantages make it the best choice. Tumbleweed would
like to work
> with Yahoo to merge their technologies.

S/MIME gateway software in the context of a 'closed-community' is a
proven method of authenticating the sending domains of e-mail messages
and has been effective at blocking increased volumes of spoofed e-mail
messages (providing they were sent from a participating domain). And of
cause using S/MIME encryption protects one from in-transit eavesdropping
too! 

Applying what is quite managable in a 'closed-community' for an
Internet-wide deployment would be somewhat more challenging though.
Particularly around certificate deployment, trust-chains and
auto-discovery (assume DNS for internet-wide; a 'closed-community' could
use LDAP). I think that is why domain keys proposes to trust DNS data as
being authorative without any further validation.

Craig.

Matt Bertapelle | 22 Jun 20:08 2004

v2.4 S/MIME Freeware Library (SFL) Now Available

All, DigitalNet Government Solutions has delivered the Version 2.4 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at <http://www.digitalnet.com/knowledge/sfl_home.htm>. The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0 Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.4 SFL uses the v2.4 Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. The v2.4 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers; and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.8. The SFL has been successfully used to exchange signedData and envelopedData messages with the MS Internet Explorer Outlook Express v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products. Signed messages have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 3369, 3370, 2631 and 2634. This testing included the RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms. We used the SFL to successfully process the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to generate S/MIME v3 sample messages that were included in the "Examples" document. The use of the v2.4 SFL is described in the v2.4 SFL Application Programming Interface (API) and v2.4 SFL Software Design Description documents. The use of the v2.4 CTIL API is described in the v2.4 CTIL API document. v2.4 SFL includes the following enhancements (compared to v2.3 SFL and CTIL releases):
1) Added support for the creation and processing of the RFC 3161-compliant Time Stamp Token content type.

2) Enhanced API to accomodate reciept hash.

3) Enhanced ASN.1 encode/decode functions with "Certificate Management Messages over CMS".

v2.4 CTILs include the following enhancements (compared to v2.3 release): 1) Added PKCS#11 interface for Crypto++. 2) Added key generation library for generating public/private key pairs, wrapping the private keys, and generating PKCS#12 files. 3) Added support for RFC 2437 PKCS #1 Optimal Asymetric Encryption Padding (RSAES-OAEP) key transport method of key management. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.8, we may port the SFL to other operating systems. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. DigitalNet is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License". On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy <http://www.bxa.doc.gov/Encryption/Default.htm>. In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. The SFL uses the CML and eSNACC ASN.1 Library to encode/decode certificates, ACs, CRLs and components thereof. The CML is freely available at: <http://www.DigitalNet.com/knowledge/cml_home.htm>. The SFL has been successfully tested in conjunction with the Access Control Library (ACL) that is freely available to everyone from: <http://www.DigitalNet.com/knowledge/acl_home.htm>. The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by DigitalNet) at <http://csrc.nist.gov/pki/testing/x509paths.html>. DigitalNet used the SFL to successfully process the NIST test data. NIST is using the SFL and CML as part of the NIST S/MIME Test Facility (NSMTF) that they are planning to host (see <http://csrc.ncsl.nist.gov/pki/smime/>). Vendors will be able to use the NSMTF to help determine if their products comply with the IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. The SFL has been integrated into many applications to provide CMS/ESS security services. For example, the SFL was integrated into a security plug-in for a commercial e-mail application that enabled the application to meet the Bridge Certification Authority Demonstration Phase II requirements including implementing ESS features such as security labels. The Internet Mail Consortium (IMC) has established an SFL web page <http://www.imc.org/imc-sfl>. The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. -- -- Matthew J. Bertapelle DigitalNet Government Solutions, LLC www.DigitalNet.com
Hallam-Baker, Phillip | 22 Jun 20:13 2004
Picon

RE: Anti-spam news article / S/MIME Gateways


> S/MIME gateway software in the context of a 'closed-community' is a
> proven method of authenticating the sending domains of e-mail messages
> and has been effective at blocking increased volumes of spoofed e-mail
> messages (providing they were sent from a participating 
> domain). And of
> cause using S/MIME encryption protects one from in-transit 
> eavesdropping
> too! 

Quite, and don't forget that TLS can add value.

> Applying what is quite managable in a 'closed-community' for an
> Internet-wide deployment would be somewhat more challenging though.
> Particularly around certificate deployment, trust-chains and
> auto-discovery (assume DNS for internet-wide; a 
> 'closed-community' could
> use LDAP). I think that is why domain keys proposes to trust 
> DNS data as
> being authorative without any further validation.

Storing keys in the DNS has its place, any technique to obtain
a rough authentication of a domain key is worthwhile. I do not
think the technique works when you get down to the user level.

I entirely disagree on the LDAP issue. I think that LDAP has
had its chance as an Internet protocol and the use that it has
found will never pass beyond the firewall (which contrary to
some thought will not go away).

LDAP is a BAD certificate discovery protocol. It provides none
of the support that is really needed, except in the simplest
trust models where support is unnecessary. XKMS does the job much
better. SCVP might prove to be of use, but the time for deploying
new ASN.1 based protocols has gone. We have seen the future and
it has angle brackets arround it.


Gmane