PKCS 7: Cryptographic Message Syntax Version 1.5 (RFC2315)
Original Publication Date: 1998-Mar-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
Status of this Memo
Network Working Group B. Kaliski
Request for Comments: 2315 RSA Laboratories, East
Category: Informational March 1998
PKCS #7: Cryptographic Message Syntax
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 (C) The Internet Society (1998). All Rights Reserved.
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.
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.
The values produced according to this document are intended to be
BER-encoded, which means that the values would typically be
represented as octet strings. While many systems are capable of
transmitting arbitrary octet strings reliably, it is well known that
many electronic-mail systems are not. This document does not address
mechanisms for encoding octet strings as (say) strings of ASCII
characters or other techniques for enabling reliable transmission by
re-encoding the octet strin...