RFC 2315 (rfc2315) - Page 1 of 32

PKCS #7: Cryptographic Message Syntax Version 1

Alternative Format: Original Text Document
Next >
Network Working Group                                          B. Kaliski
Request for Comments: 2315                         RSA Laboratories, East
Category: Informational                                        March 1998


                 PKCS #7: Cryptographic Message Syntax
                              Version 1.5

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Overview

   This document describes a general syntax for data that may have
   cryptography applied to it, such as digital signatures and digital
   envelopes. The syntax admits recursion, so that, for example, one
   envelope can be nested inside another, or one party can sign some
   previously enveloped digital data.  It also allows arbitrary
   attributes, such as signing time, to be authenticated along with the
   content of a message, and provides for other attributes such as
   countersignatures to be associated with a signature. A degenerate
   case of the syntax provides a means for disseminating certificates
   and certificate-revocation lists.

1. Scope

   This document is compatible with Privacy-Enhanced Mail (PEM) in that
   signed-data and signed-and-enveloped-data content, constructed in a
   PEM-compatible mode, can be converted into PEM messages without any
   cryptographic operations. PEM messages can similarly be converted
   into the signed-data and signed-and-enveloped data content types.

   This document can support a variety of architectures for
   certificate-based key management, such as the one proposed for
   Privacy-Enhanced Mail in RFC 1422. Architectural decisions such as
   what certificate issuers are considered "top-level," what entities
   certificate issuers are authorized to certify, what distinguished
   names are considered acceptable, and what policies certificate
   issuers must follow (such as signing only with secure hardware, or
   requiring entities to present specific forms of identification) are
   left outside the document.



Kaliski                      Informational
Next >