|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
## SMIMEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 13, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
## SMIMEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
## SMIMEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the SMIME working group -- updated on May 21, 2007 --
is reported below.
|
|
|
|
The S/MIME WG was established in the winter of 1997 to define MIME
encapsulation techniques of objects whose format was based on PKCS#7
(RFC 2315). These encapsulation techniques can be used to provide
security services for an arbitrary encapsulated content.
Initially the Cryptographic Message Syntax (CMS) (RFC 2630) was not
algorithm independent; however, the 1st revision separated the syntax
(RFC 3369) and the algorithms (RFC 3370)
to allow the two to be
updated without affecting one another. Since this split, other
documents have been written to document the use of CMS with other
algorithms (e.g., ECDSA, AES, GOST). Also since the initial CMS,
additional key management techniques (e.g., password-based and an
extensible type) and encapsulation techniques (e.g., compression) have
been added and other documents have been written to add additional
security services. CMS is also transport independent, and documents
have been written to define a consistent way to transport MIME objects.
The S/MIME specifications, one for the message specification and
another for certificate handling, have been updated to migrate
algorithms over time.
Appropriate WG topics are as follows:
|
|
| - |
Specifications for the use of additional cryptographic algorithms
with CMS.
|
| - |
Specifications that define additional CMS content types.
|
| - |
Specifications to document algorithm migration of S/MIME.
|
| - |
With the approval of the area director, specifications that define
additional CMS security services.
|
|
|
The WG will perform interoperability testing to progress the CMS and
S/MIME Specifications to Draft Standard.
|
|
|
|
|
|
|
|
##
##
## SMIMEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC2311
03/1998
(37 p.)
[html]
[pdf(2)] |
S. Dusse
P. Hoffman
B. Ramsdell
L. Lundblade
L. Repka |
|
S/MIME Version 2 Message Specification |
|
Please note: The information in this document is historical material
being published for the public record. It is not an IETF standard.
The use of the word "standard" in this document indicates a standard
for adopters of S/MIME version 2, not an IETF standard.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2312
03/1998
(20 p.)
[html]
[pdf(2)] |
S. Dusse
P. Hoffman
B. Ramsdell
J. Weinstein |
|
S/MIME Version 2 Certificate Handling |
|
Please note: The information in this document is historical material
being published for the public record. It is not an IETF standard.
The use of the word "standard" in this document indicates a standard
for adopters of S/MIME version 2, not an IETF standard.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2631
06/1999
(13 p.)
[html]
[pdf(2)] |
E. Rescorla |
|
Diffie-Hellman Key Agreement Method |
|
This document standardizes one particular Diffie-Hellman variant,
based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
group. Diffie-Hellman is a key agreement algorithm used by two
parties to agree on a shared secret. An algorithm for converting the
shared secret into an arbitrary amount of keying material is
provided. The resulting keying material is used as a symmetric
encryption key. The Diffie-Hellman variant described requires the
recipient to have a certificate, but the originator may have a static
key pair (with the public key placed in a certificate) or an
ephemeral key pair.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2876
07/2000
(13 p.)
[html]
[pdf(2)] |
J. Pawling |
|
Use of the KEA and SKIPJACK Algorithms in CMS |
|
This document describes the conventions for using the Key Exchange
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with
the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data
content types.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2984
10/2000
(6 p.)
[html]
[pdf(2)] |
C. Adams |
|
Use of the CAST-128 Encryption Algorithm in CMS |
|
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.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3058
02/2001
(8 p.)
[html]
[pdf(2)] |
S. Teiwes
P. Hartmann
D. Kuenzi |
|
Use of the IDEA Encryption Algorithm in CMS |
|
This memo specifies how to incorporate International Data Encryption
Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm
for symmetric encryption. For organizations who make use of IDEA for
data security purposes it is of high interest that IDEA is also
available in S/MIME. The intention of this memo is to provide the
OIDs and algorithms required that IDEA can be included in S/MIME for
symmetric content and key encryption.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3125
09/2001
(44 p.)
[html]
[pdf(2)] |
J. Ross
D. Pinkas
N. Pope |
|
Electronic Signature Policies |
This document defines signature policies for electronic signatures. A
signature policy is a set of rules for the creation and validation of
an electronic signature, under which the validity of signature can be
determined. A given legal/contractual context may recognize a
particular signature policy as meeting its requirements.
A signature policy has a globally unique reference, which is bound to
an electronic signature by the signer as part of the signature
calculation.
The signature policy needs to be available in human readable form so
that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied.
To allow for the automatic processing of an electronic signature
another part of the signature policy specifies the electronic rules
for the creation and validation of the electronic signature in a
computer processable form. In the current document the format of the
signature policy is defined using ASN.1.
The contents of this document is based on the signature policy
defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3126
09/2001
(84 p.)
[html]
[pdf(2)] |
D. Pinkas
J. Ross
N. Pope |
|
Electronic Signature Formats for long term electronic signatures |
This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).
The format can be considered as an extension to RFC 2630 and
RFC 2634, where, when appropriate additional signed and unsigned
attributes have been defined.
The contents of this Informational RFC is technically equivalent to
ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3183
10/2001
(24 p.)
[html]
[pdf(2)] |
T. Dean
W. Ottaway |
|
Domain Security Services using S/MIME |
|
This document describes how the S/MIME (Secure/Multipurpose Internet
Mail Extensions) 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'.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3185
10/2001
(10 p.)
[html]
[pdf(2)] |
S. Farrell
S. Turner |
|
Reuse of CMS Content Encryption Keys |
|
This document describes a way to include a key identifier in a CMS
(Cryptographic Message Syntax) enveloped data structure, so that the
content encryption key can be re-used for further enveloped data
packets.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3217
12/2001
(9 p.)
[html]
[pdf(2)] |
R. Housley |
|
Triple-DES and RC2 Key Wrapping |
|
This document specifies the algorithm for wrapping one Triple-DES key
with another Triple-DES key and the algorithm for wrapping one RC2
key with another RC2 key. These key wrap algorithms were originally
published in section 12.6 of RFC 2630. They are republished since
these key wrap algorithms have been found to be useful in contexts
beyond those supported by RFC 2630.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3274
06/2002
(6 p.)
[html]
[pdf(2)] |
P. Gutmann |
|
Compressed Data Content Type for
Cryptographic Message Syntax (CMS) |
|
This document defines a format for using compressed data as a
Cryptographic Message Syntax (CMS) content type. Compressing data
before transmission provides a number of advantages, including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps (such as signing or encryption), and reducing overall message
size. Although there have been proposals for adding compression at
other levels (for example at the MIME or SSL level), these don't
address the problem of compression of CMS content unless the
compression is supplied by an external means (for example by
intermixing MIME and CMS).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3278
04/2002
(16 p.)
[html]
[pdf(2)] |
S. Blake-Wilson
D. Brown
P. Lambert |
|
Use of Elliptic Curve Cryptography (ECC) Algorithms
in Cryptographic Message Syntax (CMS) |
|
This document describes how to use Elliptic Curve Cryptography (ECC)
public-key algorithms in the Cryptographic Message Syntax (CMS). The
ECC algorithms support the creation of digital signatures and the
exchange of keys to encrypt or authenticate content. The definition
of the algorithm processing is based on the ANSI X9.62 standard,
developed by the ANSI X9F1 working group, the IEEE 1363 standard, and
the SEC 1 standard.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3370
08/2002
(24 p.)
[html]
[pdf(2)] |
R. Housley |
|
Cryptographic Message Syntax (CMS) Algorithms |
|
This document describes the conventions for using several
cryptographic algorithms with the Cryptographic Message Syntax (CMS).
The CMS is used to digitally sign, digest, authenticate, or encrypt
arbitrary message contents.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3394
09/2002
(41 p.)
[html]
[pdf(2)] |
J. Schaad
R. Housley |
|
Advanced Encryption Standard (AES) Key Wrap Algorithm |
|
The purpose of this document is to make the Advanced Encryption
Standard (AES) Key Wrap algorithm conveniently available to the
Internet community. The United States of America has adopted AES as
the new encryption standard. The AES Key Wrap algorithm will
probably be adopted by the USA for encryption of AES keys. The
authors took most of the text in this document from the draft AES Key
Wrap posted by NIST.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3560
07/2003
(18 p.)
[html]
[pdf(2)] |
R. Housley |
|
Use of the RSAES-OAEP Key Transport Algorithm in
the Cryptographic Message Syntax (CMS) |
|
This document describes the conventions for using the RSAES-OAEP key
transport algorithm with the Cryptographic Message Syntax (CMS). The
CMS specifies the enveloped-data content type, which consists of an
encrypted content and encrypted content-encryption keys for one or
more recipients. The RSAES-OAEP key transport algorithm can be used
to encrypt content-encryption keys for intended recipients.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3850
07/2004
(16 p.)
[html]
[pdf(2)] |
B. Ramsdell |
|
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.1 Certificate Handling |
|
This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) 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.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4010
02/2005
(13 p.)
[html]
[pdf(2)] |
J. Park
S. Lee
J. Kim
J. Lee |
|
Use of the SEED Encryption Algorithm
in Cryptographic Message Syntax (CMS) |
|
This document specifies the conventions for using the SEED encryption
algorithm for encryption with the Cryptographic Message Syntax (CMS).
SEED is added to the set of optional symmetric encryption algorithms
in CMS by providing two classes of unique object identifiers (OIDs).
One OID class defines the content encryption algorithms and the other
defines the key encryption algorithms.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4134
07/2005
(136 p.)
[html]
[pdf(2)] |
P. Hoffman |
|
Examples of S/MIME Messages |
|
This document gives examples of message bodies formatted using
S/MIME. Specifically, it has examples of Cryptographic Message
Syntax (CMS) objects and S/MIME messages (including the MIME
formatting). It includes examples of many common CMS formats. The
purpose of this document is to help increase interoperability for
S/MIME and other protocols that rely on CMS.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5083
11/2007
(10 p.)
[html]
[pdf(2)] |
R. Housley |
|
Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type |
|
This document describes an additional content type for the
Cryptographic Message Syntax (CMS). The authenticated-enveloped-data
content type is intended for use with authenticated encryption modes.
All of the various key management techniques that are supported in
the CMS enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5126
02/2008
(141 p.)
[html]
[pdf(2)] |
D. Pinkas
N. Pope
J. Ross |
|
CMS Advanced Electronic Signatures (CAdES) |
This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates) the validity of the signature.
The format can be considered as an extension to RFC 3852 and
RFC 2634,where, when appropriate, additional signed and unsigned
attributes have been defined.
The contents of this Informational RFC amount to a transposition of
the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced
Electronic Signatures -- CAdES) and is technically equivalent to it.
The technical contents of this specification are maintained by ETSI.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
## SMIMEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
smime-
symkeydist-10
RFC Ed Queue (02/03)
Jan 28, 2008
(81 p.)
[pdf(2)]
[html]
|
S. Turner |
|
CMS Symmetric Key Management and Distribution |
|
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users into
groups to support distribution of encrypted content using symmetric
cryptographic algorithms. The mechanism uses the Cryptographic
Message Syntax (CMS) protocol [RFC3852] and Certificate Management
Message over CMS (CMC) protocol [ietf-pkix-2797-bis] to manage the symmetric keys.
Any member of the group can then later use this distributed shared
key to decrypt other CMS encrypted objects with the symmetric key.
This mechanism has been developed to support S/MIME Mail List Agents
(MLAs).
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
## SMIMEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
