Browse Prior Art Database

PKCS 7: Cryptographic Message Syntax Version 1.5 (RFC2315) Disclosure Number: IPCOM000002881D
Original Publication Date: 1998-Mar-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 26 page(s) / 65K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Kaliski: AUTHOR


Status of this Memo

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 4% of the total text.

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.


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.

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...