|
|
|
|
|
|
|
|
|
|
| Last Update: Jun 9, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2311
03/1998
(37 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC2312
03/1998
(20 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC2631
06/1999
(13 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2634
06/1999
(58 p.)
pdf(2p)
|
P. Hoffman |
|
Enhanced Security Services for S/MIME |
This document describes four optional security service extensions for
S/MIME. The services are:
- signed receipts
- security labels
- secure mailing lists
- signing certificates
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC2876
07/2000
(13 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC2984
10/2000
(6 p.)
pdf(2p)
|
C. Adams |
|
Use of the CAST-128 Encryption Algorithm in CMS |
|
This document specifies how to incorporate CAST-128 (RFC2144) into
the S/MIME 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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3058
02/2001
(8 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC3125
09/2001
(44 p.)
pdf(2p)
|
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).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3183
10/2001
(24 p.)
pdf(2p)
|
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.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3217
12/2001
(9 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC3274
06/2002
(6 p.)
pdf(2p)
|
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).
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3370
08/2002
(24 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3394
09/2002
(41 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3560
07/2003
(18 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4010
02/2005
(13 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4134
07/2005
(136 p.)
pdf(2p)
|
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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5083
11/2007
(10 p.)
pdf(2p)
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5126
02/2008
(141 p.)
pdf(2p)
|
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 RFC3852 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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC5275
06/2008
(89 p.)
pdf(2p)
|
S. Turner |
|
CMS Symmetric Key Management and Distribution |
|
This document describes a mechanism to manage (i.e., set up,
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 and Certificate
Management over CMS (CMC) protocol 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 Secure/Multipurpose Internet
Mail Extensions (S/MIME) Mail List Agents (MLAs).
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Draft Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5750
01/2010
(21 p.)
pdf(2p)
|
B. Ramsdell
S. Turner |
|
S/MIME Version 3.2 Certificate Handling |
|
This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 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 5280, 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 5280. This document obsoletes
RFC 3850.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5751
01/2010
(45 p.)
pdf(2p)
|
B. Ramsdell
S. Turner |
|
S/MIME Version 3.2 Message Specification |
|
This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.2. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin.
Encryption provides data confidentiality. Compression can be used to
reduce data size. This document obsoletes RFC 3851.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5752
01/2010
(17 p.)
pdf(2p)
|
S. Turner
J. Schaad |
|
Multiple Signatures in CMS |
|
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo
structure to convey per-signer information. SignedData supports
multiple signers and multiple signature algorithms per signer with
multiple SignerInfo structures. If a signer attaches more than one
SignerInfo, there are concerns that an attacker could perform a
downgrade attack by removing the SignerInfo(s) with the 'strong'
algorithm(s). This document defines the multiple-signatures
attribute, its generation rules, and its processing rules to allow
signers to convey multiple SignerInfo objects while protecting against
downgrade attacks. Additionally, this attribute may assist during
periods of algorithm migration.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5753
01/2010
(61 p.)
pdf(2p)
|
S. Turner
D. Brown |
|
Use of Elliptic Curve Cryptography (ECC) Algorithms in 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 NIST FIPS 186-3 for
digital signature, NIST SP800-56A and SEC1 for key agreement, RFC
3370 and RFC 3565 for key wrap and content encryption, NIST FIPS
180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC
4231 for message authentication code standards. This document
obsoletes RFC 3278.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC5754
01/2010
(10 p.)
pdf(2p)
|
S. Turner |
|
Using SHA2 Algorithms with CMS |
|
This document describes the conventions for using the Secure Hash
Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384,
SHA-512) with the Cryptographic Message Syntax (CMS). It also
describes the conventions for using these algorithms with the CMS
and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman
(RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further,
it provides SMIMECapabilities attribute values for each algorithm.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5911
06/2010
(59 p.)
pdf(2p)
|
P. Hoffman
J. Schaad |
|
New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME |
|
The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules
conform to the 1988 version of ASN.1. This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1. There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
