headers
Internet-Drafts | 3 Oct 2000 12:49
Picon
Favicon

I-D ACTION:draft-ietf-smime-seclabel-02.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		: Implementing Company Classification Policy with the 
                          S/MIME Security Label
	Author(s)	: W. Nicolls
	Filename	: draft-ietf-smime-seclabel-02.txt
	Pages		: 10
	Date		: 02-Oct-00
	
This document discusses how company security policy for data classification can be mapped to the S/MIME
security label.  Actual policies from 3 companies are used to provide worked examples.  
Security labels are an optional security service for S/MIME. A security label is a set of security
information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A
security label can be included in the signed attributes of any SignedData object.  A security label
attribute may be included in either the inner signature, outer signature, or both.
The syntax and processing rules for security labels are described in [ESS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-seclabel-02.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-seclabel-02.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
(Continue reading)

Permalink | Reply | 0 comments |
headers
mkicksee | 5 Oct 2000 19:53
Picon

RE: ESS Questions


>4.2.3.2 Processing for SignedData
>
>Q.  Step 2 of this process has been changed from the
>Internet draft version (draft-ietf-smime-ess-09.txt).  It
>seems that now if the "outer" signed data layer is absent
>or does not contain an mlExpansionHistory attribute, the
>MLA simply adds a new outer signed layer, lists itself in
>the mlExpansionHistory attribute, and sends the message to
>the recipients.  It would no longer expand any encrypted
>data for the recipients.  If someone sent a message that
>was encrypted then signed to the MLA, the recipients would
>not be able to decrypt it.  Have I misread this paragraph?
>
>[JSP: You have misinterpreted the paragraph.]

Did I also misinterpret the flowchart (quoted below)?

   1. Has a valid signature?
          YES -> 2.
          NO  -> STOP.
   2. Does outermost SignedData layer contain mlExpansionHistory?
          YES -> Check it, then -> 3.
          NO  -> Sign message (including outermost SignedData that
                 doesn't have mlExpansionHistory), deliver it, STOP.

   It seems clear that the MLA would not expand encrypted data unless the outer
signature is either absent or that of an MLA.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 11 Oct 2000 22:23

Agenda for San Diego

It is time to start putting together the agenda for the S/MIME WG meeting 
in San Diego.  I have requested a two hour slot.  Let me know if you would 
like a portion of that 2 hours.

Russ
Permalink | Reply | 0 comments |
headers
Pawling, John | 11 Oct 2000 23:38
Picon

RE: ESS Questions

All,

It seems that mkicksee has pointed out an error in RFC 2634.  It seems that
the second sentence should be deleted from Section 4.2.3.2 Processing for
SignedData, bullet 2 as follows:

   2. If the outermost SignedData layer includes a signed
      mlExpansionHistory attribute, the MLA checks for an expansion loop
      as described in the "Detecting Mail List Expansion Loops" section,
      then go to step 3. If the outermost SignedData layer does not
      include a signed mlExpansionHistory attribute, the MLA signs the
      whole message (including this outermost SignedData layer that
      doesn't have an mlExpansionHistory attribute), and delivers the
      updated message to mail list members to complete MLA processing.

Example 5 in section 4.2.1 indicates that the MLA would continue processing
the layers of the received message if the outermost SignedData layer does
not include a signed mlExpansionHistory attribute, so that seems to
contradict the second sentence of Section 4.2.3.2, bullet 2.

As best I can remember, the second sentence of Section 4.2.3.2, bullet 2 was
included in RFC 2634 to address the case in which an MLA is processing a
message composed of a single signedData layer.  However, it seems that
section 3.3 addresses this case, so the second sentence of Section 4.2.3.2,
bullet 2 is not needed.

Unless somebody objects, I recommend that the second sentence should be
deleted from Section 4.2.3.2, bullet 2 and that the flow chart should be
updated accordingly.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pawling, John | 12 Oct 2000 19:20
Picon

v1.8 S/MIME Freeware Library Now Available

All,

Getronics Government Solutions (GGS) (formerly Wang Government Services) has
delivered Version 1.8 of the S/MIME Freeware Library (SFL) source code.  The
SFL source code files are freely available to everyone from the Fortezza
Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.  

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ v3.2 freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the MS Windows NT/95/98, Linux and Solaris 2.7
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: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
3DES) 
provided by the Crypto++ v3.2 library; RSA suite of algorithms provided by
the 
RSA BSAFE v4.2 and Crypto++ v3.2 libraries; and Fortezza suite of algorithms

provided by the Fortezza Crypto Card.  The v1.8 SFL uses the v1.3 R4
Enhanced SNACC
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 13 Oct 2000 19:02

FYI: SHA-2, AES

Tim Polk posted this to the IETF Working Group chairs and the PKIX Working 
Group.  I am forwarding it to this list to make sure everyone got the word.

Russ

= = = = = = = = = =

NIST has just posted a white paper that specifies hashing algorithms 
(SHA-256, SHA-384, and SHA-512) that are intended to provide security 
similar to that of the three AES key sizes. Information can be found at 
<http://www.nist.gov/sha/>.

These algorithms "will be proposed in a draft Federal Information 
Processing Standard (FIPS) in 2001. These algorithms are being made 
available for information purposes prior to the publication of the draft 
FIPS. SHA-256 is a 256-bit hash function that is intended to provide 128 
bits of security against collision attacks, and SHA-512 is a 512-bit hash 
function that is intended to provide 256 bits of security. A 384-bit hash 
may be obtained by truncating the SHA-512 output."

The web site has the NIST contact points.

One side note about AES: http://csrc.nist.gov/csor/algorithms.htm contains 
the object identifiers and ASN.1 type definitions for AES parameters for 
protocols built on ASN.1.  The OIDs for the new hash algorithms will follow 
next week.

Thanks,

Tim Polk
(Continue reading)

Permalink | Reply | 0 comments |
headers
RFC Editor | 19 Oct 2000 17:49
Picon
Favicon

RFC 2984 on CAST-128 in CMS


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

        RFC 2984

        Title:	    Use of the CAST-128 Encryption Algorithm in CMS 
        Author(s):  C. Adams
        Status:     Standards Track
	Date:       October 2000
        Mailbox:    cadams <at> entrust.com
        Pages:      6
        Characters: 11591
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-cast-128-02.txt

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

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.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 23 Oct 2000 17:41

Fwd: RE: Use of the IDEA Encryption Algorithm in CMS

This should have been posted to the S/MIME WG list, not the PKIX WG mail list.

Russ

>From: "Teiwes, Stephan (iT_SEC)" <stephan.teiwes <at> it-sec.com>
>To: "'Maxim Masiutin'" <max <at> ritlabs.com>,
>         "Teiwes, Stephan (iT_SEC)"
>         <stephan.teiwes <at> it-sec.com>,
>         "Hartmann, Peter  (iT_SEC)"
>         <peter.hartmann <at> it-sec.com>,
>         diego.kuenzi <at> it-sec.com, ietf-pkix <at> imc.org
>Subject: RE: Use of the IDEA Encryption Algorithm in CMS
>Date: Mon, 23 Oct 2000 16:52:21 +0200
>X-Mailer: Internet Mail Service (5.5.2448.0)
>List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
>List-ID: <ietf-pkix.imc.org>
>List-Unsubscribe: mailto:ietf-pkix-request <at> imc.org?body=unsubscribe
>
>Dear Mr. Masuitin,
>
>thanks a lot. We'll consider your comments and try to improve the draft
>accordingly.
>
>*Stephan Teiwes
>iT_Security AG
>www.it-sec.com
>
>-----Original Message-----
>From: Maxim Masiutin [mailto:max <at> ritlabs.com]
>Sent: Montag, 23. Oktober 2000 16:41
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 24 Oct 2000 12:10
Picon
Favicon

I-D ACTION:draft-ietf-smime-examples-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		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-04.txt
	Pages		: 8
	Date		: 23-Oct-00
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <ietf-smime-request <at> imc.org> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <ietf-smime-request <at> imc.org> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-04.txt
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Hoffman / IMC | 25 Oct 2000 02:06
Picon

Re: I-D ACTION:draft-ietf-smime-examples-04.txt

At 6:10 AM -0400 10/24/00, Internet-Drafts <at> ietf.org wrote:
>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		: Examples of S/MIME Messages
>	Author(s)	: P. Hoffman
>	Filename	: draft-ietf-smime-examples-04.txt
>	Pages		: 8
>	Date		: 23-Oct-00

It's too bad that there is no emoticon for "really embarrassed". I 
put out this draft with essentially no changes from the -03 because 
the -03 expired a long time ago and I have completely ignored it. 
Well, I ignored in between feeling bad about it. But you get the 
picture.

Because I had also lamely filed the comments people had sent me a 
year ago about -03 into different folders, I am not sure what need to 
be fixed. I know that much does need to be fixed, but I am not sure 
what. Please send (or, probably, re-send) all comments to me and the 
ietf-smime-examples <at> imc.org list. And I really, really promise to get 
-05 out before the cutoff for the San Diego IETF.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 0 comments |

Gmane