Enhanced Security Services for S/MIME (RFC2634)
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
P. Hoffman: AUTHOR [+2]
This document describes four optional security service extensions for S/MIME. The services are:
Network Working Group P. Hoffman, Editor
Request for Comments: 2634 Internet Mail Consortium
Category: Standards Track June 1999
Enhanced Security Services for S/MIME
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document describes four optional security service extensions for
S/MIME. The services are:
- signed receipts
- security labels
- secure mailing lists
- signing certificates
The first three of these services provide functionality that is
similar to the Message Security Protocol [MSP4], but are useful in
many other environments, particularly business and finance. Signing
certificates are useful in any environment where certificates might
be transmitted with signed messages.
The services described here are extensions to S/MIME version 3 ([MSG]
and [CERT]), and some of them can also be added to S/MIME version 2
[SMIME2]. The extensions described here will not cause an S/MIME
version 3 recipient to be unable to read messages from an S/MIME
version 2 sender. However, some of the extensions will cause messages
created by an S/MIME version 3 sender to be unreadable by an S/MIME
version 2 recipient.
This document describes both the procedures and the attributes needed
for the four services. Note that some of the attributes described in
this document are quite useful in other contexts and should be
considered when extending S/MIME or other CMS applications.
The format of the messages are described in ASN.1:1988 [ASN1-1988].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD].
1.1 Triple Wrapping
Some of the features of each service use the concept of a "triple
wrapped" message. A triple wrapped message is one that has been
signed, then encrypted, then signed again. The signers of the inner
and outer signatures may be different entities or the same entity.
Note that the S/MIME specification does not limit the number of
nested encapsulations, so there may be more than three wrappings.
1.1.1 Purpose of Triple Wrapping
Not all messages need to be triple wrapped. Triple wrapping is used
when a message must be signed, then encrypted, and then have signed
attributes bound to the encrypted body. Outer attributes may be added
or removed by the message originator or intermediate agents, and may
be signed by intermediate agen...