draft-ietf-smime-ess-11.txt   rfc2634.txt 
Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-11.txt Internet Mail Consortium
February 26, 1999
Expires in six months
Enhanced Security Services for S/MIME Network Working Group P. Hoffman, Editor
Request for Comments: 2634 Internet Mail Consortium
Category: Standards Track June 1999
Status of this memo Enhanced Security Services for S/MIME
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document specifies an Internet standards track protocol for the
months and may be updated, replaced, or obsoleted by other Internet community, and requests discussion and suggestions for
documents at any time. It is inappropriate to use Internet- improvements. Please refer to the current edition of the "Internet
Drafts as reference material or to cite them other than as Official Protocol Standards" (STD 1) for the standardization state
"work in progress." and status of this protocol. Distribution of this memo is unlimited.
To view the list Internet-Draft Shadow Directories, see Copyright Notice
http://www.ietf.org/shadow.html.
This document is an Internet-Draft and is in full conformance Copyright (C) The Internet Society (1999). All Rights Reserved.
with all provisions of Section 10 of RFC2026.
1. Introduction 1. Introduction
This document describes four optional security service extensions for This document describes four optional security service extensions for
S/MIME. The services are: 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 - signed receipts
[CERT]), and some of them can also be added to S/MIME version 2 [SMIME2]. - security labels
The extensions described here will not cause an S/MIME version 3 recipient - secure mailing lists
to be unable to read messages from an S/MIME version 2 sender. However, - signing certificates
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 first three of these services provide functionality that is
the three services. Note that some of the attributes described in this similar to the Message Security Protocol [MSP4], but are useful in
document are quite useful in other contexts and should be considered when many other environments, particularly business and finance. Signing
extending S/MIME or other CMS applications. certificates are useful in any environment where certificates might
be transmitted with signed messages.
The format of the messages are described in ASN.1:1988 [ASN1-1988]. 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document describes both the procedures and the attributes needed
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this for the four services. Note that some of the attributes described in
document are to be interpreted as described in [MUSTSHOULD]. this document are quite useful in other contexts and should be
considered when extending S/MIME or other CMS applications.
This draft is being discussed on the "ietf-smime" mailing list. To The format of the messages are described in ASN.1:1988 [ASN1-1988].
subscribe, send a message to:
ietf-smime-request@imc.org The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
with the single word "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
subscribe document are to be interpreted as described in [MUSTSHOULD].
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.
1.1 Triple Wrapping 1.1 Triple Wrapping
Some of the features of each service use the concept of a "triple wrapped" Some of the features of each service use the concept of a "triple
message. A triple wrapped message is one that has been signed, then wrapped" message. A triple wrapped message is one that has been
encrypted, then signed again. The signers of the inner and outer signatures signed, then encrypted, then signed again. The signers of the inner
may be different entities or the same entity. Note that the S/MIME and outer signatures may be different entities or the same entity.
specification does not limit the number of nested encapsulations, so there Note that the S/MIME specification does not limit the number of
may be more than three wrappings. nested encapsulations, so there may be more than three wrappings.
1.1.1 Purpose of Triple Wrapping 1.1.1 Purpose of Triple Wrapping
Not all messages need to be triple wrapped. Triple wrapping is used when a Not all messages need to be triple wrapped. Triple wrapping is used
message must be signed, then encrypted, and then have signed attributes when a message must be signed, then encrypted, and then have signed
bound to the encrypted body. Outer attributes may be added or removed by attributes bound to the encrypted body. Outer attributes may be added
the message originator or intermediate agents, and may be signed by or removed by the message originator or intermediate agents, and may
intermediate agents or the final recipient. be signed by intermediate agents or the final recipient.
The inside signature is used for content integrity, non-repudiation with The inside signature is used for content integrity, non-repudiation
proof of origin, and binding attributes (such as a security label) to the with proof of origin, and binding attributes (such as a security
original content. These attributes go from the originator to the recipient, label) to the original content. These attributes go from the
regardless of the number of intermediate entities such as mail list agents originator to the recipient, regardless of the number of intermediate
that process the message. The signed attributes can be used for access entities such as mail list agents that process the message. The
control to the inner body. Requests for signed receipts by the originator signed attributes can be used for access control to the inner body.
are carried in the inside signature as well. Requests for signed receipts by the originator are carried in the
inside signature as well.
The encrypted body provides confidentiality, including confidentiality of The encrypted body provides confidentiality, including
the attributes that are carried in the inside signature. confidentiality of the attributes that are carried in the inside
signature.
The outside signature provides authentication and integrity for information The outside signature provides authentication and integrity for
that is processed hop-by-hop, where each hop is an intermediate entity such information that is processed hop-by-hop, where each hop is an
as a mail list agent. The outer signature binds attributes (such as a intermediate entity such as a mail list agent. The outer signature
security label) to the encrypted body. These attributes can be used for binds attributes (such as a security label) to the encrypted body.
access control and routing decisions. These attributes can be used for access control and routing
decisions.
1.1.2 Steps for Triple Wrapping 1.1.2 Steps for Triple Wrapping
The steps to create a triple wrapped message are: The steps to create a triple wrapped message are:
1. Start with a message body, called the "original content". 1. Start with a message body, called the "original content".
2. Encapsulate the original content with the appropriate MIME Content-type 2. Encapsulate the original content with the appropriate MIME
headers, such as "Content-type: text/plain". An exception to this MIME Content-type headers, such as "Content-type: text/plain". An
encapsulation rule is that a signed receipt is not put in MIME headers. exception to this MIME encapsulation rule is that a signed receipt
is not put in MIME headers.
3. Sign the result of step 2 (the inner MIME headers and the original 3. Sign the result of step 2 (the inner MIME headers and the original
content). The SignedData encapContentInfo eContentType object identifier content). The SignedData encapContentInfo eContentType object
MUST be id-data. If the structure you create in step 4 is multipart/signed, identifier MUST be id-data. If the structure you create in step 4
then the SignedData encapContentInfo eContent MUST be absent. If the is multipart/signed, then the SignedData encapContentInfo eContent
structure you create in step 4 is application/pkcs7-mime, then the MUST be absent. If the structure you create in step 4 is
SignedData encapContentInfo eContent MUST contain the result of step 2 application/pkcs7-mime, then the SignedData encapContentInfo
above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE eContent MUST contain the result of step 2 above. The SignedData
with a contentType of id-signedData. structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData.
4. Add an appropriate MIME construct to the signed message from step 3 as 4. Add an appropriate MIME construct to the signed message from step
defined in [MSG]. The resulting message is called the "inside signature". 3 as defined in [MSG]. The resulting message is called the "inside
signature".
- If you are signing using multipart/signed, the MIME construct added - If you are signing using multipart/signed, the MIME construct
consists of a Content-type of multipart/signed with parameters, the added consists of a Content-type of multipart/signed with
boundary, the result of step 2 above, the boundary, a Content-type of parameters, the boundary, the result of step 2 above, the
application/pkcs7-signature, optional MIME headers (such as boundary, a Content-type of application/pkcs7-signature,
Content-transfer-encoding and Content-disposition), and a body part that optional MIME headers (such asContent-transfer-encoding and
is the result of step 3 above. Content-disposition), and a body part that is the result of
step 3 above.
- If you are instead signing using application/pkcs7-mime, the MIME - If you are instead signing using application/pkcs7-mime, the MIME
construct added consists of a Content-type of application/pkcs7-mime construct added consists of a Content-type of
with parameters, optional MIME headers (such as application/pkcs7-mime with parameters, optional MIME headers
Content-transfer-encoding and Content-disposition), and the result of (such as Content-transfer-encoding and Content-disposition), and
step 3 above. the result of step 3 above.
5. Encrypt the result of step 4 as a single block, turning it into an 5. Encrypt the result of step 4 as a single block, turning it into an
application/pkcs7-mime object. The EnvelopedData encryptedContentInfo application/pkcs7-mime object. The EnvelopedData
contentType MUST be id-data. The EnvelopedData structure is encapsulated by encryptedContentInfo contentType MUST be id-data.
a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is The EnvelopedData structure is encapsulated by a ContentInfo
called the "encrypted body". SEQUENCE with a contentType of id-envelopedData. This is called
the "encrypted body".
6. Add the appropriate MIME headers: a Content-type of 6. Add the appropriate MIME headers: a Content-type of
application/pkcs7-mime with parameters, and optional MIME headers such as application/pkcs7-mime with parameters, and optional MIME headers
Content-transfer-encoding and Content-disposition. such as Content-transfer-encoding and Content-disposition.
7. Using the same logic as in step 3 above, sign the result of step 6 (the 7. Using the same logic as in step 3 above, sign the result of step 6
MIME headers and the encrypted body) as a single block (the MIME headers and the encrypted body) as a single block
8. Using the same logic as in step 4 above, add an appropriate MIME 8. Using the same logic as in step 4 above, add an appropriate MIME
construct to the signed message from step 7. The resulting message is construct to the signed message from step 7. The resulting message
called the "outside signature", and is also the triple wrapped message. is called the "outside signature", and is also the triple wrapped
message.
1.2 Format of a Triple Wrapped Message 1.2 Format of a Triple Wrapped Message
A triple wrapped message has many layers of encapsulation. The structure A triple wrapped message has many layers of encapsulation. The
differs based on the choice of format for the signed portions of the structure differs based on the choice of format for the signed
message. Because of the way that MIME encapsulates data, the layers do not portions of the message. Because of the way that MIME encapsulates
appear in order, and the notion of "layers" becomes vague. data, the layers do not appear in order, and the notion of "layers"
becomes vague.
There is no need to use the multipart/signed format in an inner signature There is no need to use the multipart/signed format in an inner
because it is known that the recipient is able to process S/MIME messages signature because it is known that the recipient is able to process
(because they decrypted the middle wrapper). A sending agent might choose S/MIME messages (because they decrypted the middle wrapper). A
to use the multipart/signed format in the outer layer so that a non-S/MIME sending agent might choose to use the multipart/signed format in the
agent could see that the next inner layer is encrypted; however, this is outer layer so that a non-S/MIME agent could see that the next inner
not of great value, since all it shows the recipient is that the rest of layer is encrypted; however, this is not of great value, since all it
the message is unreadable. Because many sending agents always use shows the recipient is that the rest of the message is unreadable.
multipart/signed structures, all receiving agents MUST be able to interpret Because many sending agents always use multipart/signed structures,
either multipart/signed or application/pkcs7-mime signature structures. all receiving agents MUST be able to interpret either
multipart/signed or application/pkcs7-mime signature structures.
The format of a triple wrapped message that uses multipart/signed for both The format of a triple wrapped message that uses multipart/signed for
signatures is: both signatures is:
[step 8] Content-type: multipart/signed; [step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature"; [step 8] protocol="application/pkcs7-signature";
[step 8] boundary=outerboundary [step 8] boundary=outerboundary
[step 8] [step 8]
[step 8] --outerboundary [step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime; ) [step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data ) [step 6] smime-type=enveloped-data )
[step 6] ) [step 6] )
[step 4] Content-type: multipart/signed; | ) [step 4] Content-type: multipart/signed; | )
[step 4] protocol="application/pkcs7-signature"; | ) [step 4] protocol="application/pkcs7-signature"; | )
[step 4] boundary=innerboundary | ) [step 4] boundary=innerboundary | )
[step 4] | ) [step 4] | )
[step 4] --innerboundary | ) [step 4] --innerboundary | )
[step 2] Content-type: text/plain % | ) [step 2] Content-type: text/plain % | )
[step 2] % | )
[step 1] Original content % | )
[step 4] | )
[step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | )
[step 4] | )
[step 3] inner SignedData block (eContent is missing) | )
[step 4] | )
[step 4] --innerboundary-- | )
[step 8]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] outer SignedData block (eContent is missing)
[step 8]
[step 8] --outerboundary--
% = These lines are what the inner signature is computed over. [step 2] % | )
| = These lines are what is encrypted in step 5. This encrypted result [step 1] Original content % | )
is opaque and is a part of an EnvelopedData block. [step 4] | )
) = These lines are what the outer signature is computed over. [step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | )
[step 4] | )
[step 3] inner SignedData block (eContent is missing) | )
[step 4] | )
[step 4] --innerboundary-- | )
[step 8]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] outer SignedData block (eContent is missing)
[step 8]
[step 8] --outerboundary--
The format of a triple wrapped message that uses application/pkcs7-mime for % = These lines are what the inner signature is computed over.
the both signatures is: | = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over.
[step 8] Content-type: application/pkcs7-mime; The format of a triple wrapped message that uses application/pkcs7-
[step 8] smime-type=signed-data mime for the both signatures is:
[step 8]
[step 7] outer SignedData block (eContent is present) O
[step 6] Content-type: application/pkcs7-mime; ) O
[step 6] smime-type=enveloped-data; ) O
[step 6] ) O
[step 4] Content-type: application/pkcs7-mime; | ) O
[step 4] smime-type=signed-data | ) O
[step 4] | ) O
[step 3] inner SignedData block (eContent is present) I | ) O
[step 2] Content-type: text/plain I | ) O
[step 2] I | ) O
[step 1] Original content I | ) O
I = These lines are the inner SignedData block, which is opaque and [step 8] Content-type: application/pkcs7-mime;
contains the ASN.1 encoded result of step 2 as well as control [step 8] smime-type=signed-data
information. [step 8]
| = These lines are what is encrypted in step 5. This encrypted result [step 7] outer SignedData block (eContent is present) O
is opaque and is a part of an EnvelopedData block. [step 6] Content-type: application/pkcs7-mime; ) O
) = These lines are what the outer signature is computed over. [step 6] smime-type=enveloped-data; ) O
O = These lines are the outer SignedData block, which is opaque and [step 6] ) O
contains the ASN.1 encoded result of step 6 as well as control [step 4] Content-type: application/pkcs7-mime; | ) O
information. [step 4] smime-type=signed-data | ) O
[step 4] | ) O
[step 3] inner SignedData block (eContent is present) I | ) O
[step 2] Content-type: text/plain I | ) O
[step 2] I | ) O
[step 1] Original content I | ) O
I = These lines are the inner SignedData block, which is opaque and
contains the ASN.1 encoded result of step 2 as well as control
information.
| = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over.
O = These lines are the outer SignedData block, which is opaque and
contains the ASN.1 encoded result of step 6 as well as control
information.
1.3 Security Services and Triple Wrapping 1.3 Security Services and Triple Wrapping
The three security services described in this document are used with triple The first three security services described in this document are used
wrapped messages in different ways. This section briefly describes the with triple wrapped messages in different ways. This section briefly
relationship of each service with triple wrapping; the other sections of describes the relationship of each service with triple wrapping; the
the document go into greater detail. other sections of the document go into greater detail.
1.3.1 Signed Receipts and Triple Wrapping 1.3.1 Signed Receipts and Triple Wrapping
A signed receipt may be requested in any SignedData object. However, if a A signed receipt may be requested in any SignedData object. However,
signed receipt is requested for a triple wrapped message, the receipt if a signed receipt is requested for a triple wrapped message, the
request MUST be in the inside signature, not in the outside signature. A receipt request MUST be in the inside signature, not in the outside
secure mailing list agent may change the receipt policy in the outside signature. A secure mailing list agent may change the receipt policy
signature of a triple wrapped message when that message is processed by the in the outside signature of a triple wrapped message when that
mailing list. message is processed by the mailing list.
Note: the signed receipts and receipt requests described in this draft Note: the signed receipts and receipt requests described in this memo
differ from those described in the work done by the IETF Receipt differ from those described in the work done by the IETF Receipt
Notification Working Group. The output of that Working Group, when Notification Working Group. The output of that Working Group, when
finished, is not expected to work well with triple wrapped messages as finished, is not expected to work well with triple wrapped messages
described in this document. as described in this document.
1.3.2 Security Labels and Triple Wrapping 1.3.2 Security Labels and Triple Wrapping
A security label may be included in the signed attributes of any SignedData A security label may be included in the signed attributes of any
object. A security label attribute may be included in either the inner SignedData object. A security label attribute may be included in
signature, outer signature, or both. either the inner signature, outer signature, or both.
The inner security label is used for access control decisions related to The inner security label is used for access control decisions related
the plaintext original content. The inner signature provides authentication to the plaintext original content. The inner signature provides
and cryptographically protects the integrity of the original signer's authentication and cryptographically protects the integrity of the
security label that is in the inside body. This strategy facilitates the original signer's security label that is in the inside body. This
forwarding of messages because the original signer's security label is strategy facilitates the forwarding of messages because the original
included in the SignedData block which can be forwarded to a third party signer's security label is included in the SignedData block which can
that can verify the inner signature which will cover the inner security be forwarded to a third party that can verify the inner signature
label. The confidentiality security service can be applied to the inner which will cover the inner security label. The confidentiality
security label by encrypting the entire inner SignedData block within an security service can be applied to the inner security label by
EnvelopedData block. encrypting the entire inner SignedData block within an EnvelopedData
block.
A security label may also be included in the signed attributes of the outer A security label may also be included in the signed attributes of the
SignedData block which will include the sensitivities of the encrypted outer SignedData block which will include the sensitivities of the
message. The outer security label is used for access control and routing encrypted message. The outer security label is used for access
decisions related to the encrypted message. Note that a security label control and routing decisions related to the encrypted message. Note
attribute can only be used in an signedAttributes block. An that a security label attribute can only be used in a
eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned signedAttributes block. An eSSSecurityLabel attribute MUST NOT be
attributes. used in an EnvelopedData or unsigned attributes.
1.3.3 Secure Mailing Lists and Triple Wrapping 1.3.3 Secure Mailing Lists and Triple Wrapping
Secure mail list message processing depends on the structure of S/MIME Secure mail list message processing depends on the structure of
layers present in the message sent to the mail list agent. The mail list S/MIME layers present in the message sent to the mail list agent. The
agent never changes the data that was hashed to form the inner signature, mail list agent never changes the data that was hashed to form the
if such a signature is present. If an outer signature is present, then the inner signature, if such a signature is present. If an outer
agent will modify the data that was hashed to form that outer signature. In signature is present, then the agent will modify the data that was
all cases, the agent adds or updates an mlExpansionHistory attribute to hashed to form that outer signature. In all cases, the agent adds or
document the agent's processing, and ultimately adds or replaces the outer updates an mlExpansionHistory attribute to document the agent's
signature on the message to be distributed. processing, and ultimately adds or replaces the outer signature on
the message to be distributed.
1.3.4 Placement of Attributes 1.3.4 Placement of Attributes
Certain attributes should be placed in the inner or outer SignedData Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be message; some attributes can be in either. Further, some attributes
signed, while signing is optional for others, and some attributes must not must be signed, while signing is optional for others, and some
be signed. ESS defines several types of attributes. ContentHints and attributes must not be signed. ESS defines several types of
ContentIdentifier MAY appear in any list of attributes. contentReference, attributes. ContentHints and ContentIdentifier MAY appear in any
equivalentLabel, eSSSecurityLabel and mlExpansionHistory MUST be carried in list of attributes. contentReference, equivalentLabel,
a SignedAttributes or AuthAttributes type, and MUST NOT be carried in a eSSSecurityLabel and mlExpansionHistory MUST be carried in a
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. SignedAttributes or AuthAttributes type, and MUST NOT be carried in a
msgSigDigest, receiptRequest and signingCertificate MUST be carried in a UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
SignedAttributes, and MUST NOT be carried in a AuthAttributes, msgSigDigest, receiptRequest and signingCertificate MUST be carried
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. in a SignedAttributes, and MUST NOT be carried in a AuthAttributes,
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
The following table summarizes the recommendation of this profile. In the The following table summarizes the recommendation of this profile. In
OID column, [ESS] indicates that the attribute is defined in this document. the OID column, [ESS] indicates that the attribute is defined in this
document.
| |Inner or | | |Inner or |
Attribute |OID |outer |Signed Attribute |OID |outer |Signed
contentHints |id-aa-contentHint [ESS] |either |MAY ------------------|----------------------------- |----------|--------
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY contentHints |id-aa-contentHint [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentType |id-contentType [CMS] |either |MUST contentReference |id-aa-contentReference [ESS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT contentType |id-contentType [CMS] |either |MUST
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST counterSignature |id-countersignature [CMS] |either |MUST NOT
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |MUST eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST messageDigest |id-messageDigest [CMS] |either |MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
signingCertificate|id-aa-signingCertificate [ESS]|either |MUST receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingTime |id-signingTime [CMS] |either |MUST signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST signingTime |id-signingTime [CMS] |either |MUST
sMIMEEncryption- smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST sMIMEEncryption-
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF Attribute and defines unsignedAttrs as CMS defines signedAttrs as a SET OF Attribute and defines
a SET OF Attribute. ESS defines the contentHints, contentIdentifier, unsignedAttrs as a SET OF Attribute. ESS defines the contentHints,
eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest, contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
contentReference, equivalentLabels and signingCertificate attribute types. receiptRequest, contentReference, equivalentLabels and
A signerInfo MUST NOT include multiple instances of any of the attribute signingCertificate attribute types. A signerInfo MUST NOT include
types defined in ESS. Later sections of ESS specify further restrictions multiple instances of any of the attribute types defined in ESS.
that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel Later sections of ESS specify further restrictions that apply to the
attribute types. receiptRequest, mlExpansionHistory and eSSecurityLabel attribute
types.
CMS defines the syntax for the signed and unsigned attributes as CMS defines the syntax for the signed and unsigned attributes as
"attrValues SET OF AttributeValue". For all of the attribute types defined "attrValues SET OF AttributeValue". For all of the attribute types
in ESS, if the attribute type is present in a signerInfo, then it MUST only defined in ESS, if the attribute type is present in a signerInfo,
include a single instance of AttributeValue. In other words, there MUST NOT then it MUST only include a single instance of AttributeValue. In
be zero, or multiple, instances of AttributeValue present in the attrValues other words, there MUST NOT be zero, or multiple, instances of
SET OF AttributeValue. AttributeValue present in the attrValues SET OF AttributeValue.
If a counterSignature attribute is present, then it MUST be included in the If a counterSignature attribute is present, then it MUST be included
unsigned attributes. It MUST NOT be included in the signed attributes. The in the unsigned attributes. It MUST NOT be included in the signed
only attributes that are allowed in a counterSignature attribute are attributes. The only attributes that are allowed in a
counterSignature, messageDigest, signingTime, and signingCertificate. counterSignature attribute are counterSignature, messageDigest,
signingTime, and signingCertificate.
Note that the inner and outer signatures are usually those of different Note that the inner and outer signatures are usually those of
senders. Because of this, the same attribute in the two signatures could different senders. Because of this, the same attribute in the two
lead to very different consequences. signatures could lead to very different consequences.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique ContentIdentifier is an attribute (OCTET STRING) used to carry a
identifier assigned to the message. unique identifier assigned to the message.
1.4 Required and Optional Attributes 1.4 Required and Optional Attributes
Some security gateways sign messages that pass through them. If the message Some security gateways sign messages that pass through them. If the
is any type other than a signedData type, the gateway has only one way to message is any type other than a signedData type, the gateway has
sign the message: by wrapping it with a signedData block and MIME headers. only one way to sign the message: by wrapping it with a signedData
If the message to be signed by the gateway is a signedData message already, block and MIME headers. If the message to be signed by the gateway is
the gateway can sign the message by inserting a signerInfo into the a signedData message already, the gateway can sign the message by
signedData block. inserting a signerInfo into the signedData block.
The main advantage of a gateway adding a signerInfo instead of wrapping the The main advantage of a gateway adding a signerInfo instead of
message in a new signature is that the message doesn't grow as much as if wrapping the message in a new signature is that the message doesn't
the gateway wrapped the message. The main disadvantage is that the gateway grow as much as if the gateway wrapped the message. The main
must check for the presence of certain attributes in the other signerInfos disadvantage is that the gateway must check for the presence of
and either omit or copy those attributes. certain attributes in the other signerInfos and either omit or copy
those attributes.
If a gateway or other processor adds a signerInfo to an existing signedData If a gateway or other processor adds a signerInfo to an existing
block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes signedData block, it MUST copy the mlExpansionHistory and
from other signerInfos. This helps ensure that the recipient will process eSSSecurityLabel attributes from other signerInfos. This helps ensure
those attributes in a signerInfo that it can verify. that the recipient will process those attributes in a signerInfo that
it can verify.
Note that someone may in the future define an attribute that must be Note that someone may in the future define an attribute that must be
present in each signerInfo of a signedData block in order for the signature present in each signerInfo of a signedData block in order for the
to be processed. If that happens, a gateway that inserts signerInfos and signature to be processed. If that happens, a gateway that inserts
doesn't copy that attribute will cause every message with that attribute to signerInfos and doesn't copy that attribute will cause every message
fail when processed by the recipient. For this reason, it is safer to wrap with that attribute to fail when processed by the recipient. For this
messages with new signatures than to insert signerInfos. reason, it is safer to wrap messages with new signatures than to
insert signerInfos.
1.5 Object Identifiers 1.5 Object Identifiers
The object identifiers for many of the objects described in this draft are The object identifiers for many of the objects described in this memo
found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME are found in [CMS], [MSG], and [CERT]. Other object identifiers used
can be found in the registry kept at in S/MIME can be found in the registry kept at
<http://www.imc.org/ietf-smime/oids.html>. When this draft moves to <http://www.imc.org/ietf-smime/oids.html>. When this memo moves to
standards track within the IETF, it is intended that the IANA will maintain standards track within the IETF, it is intended that the IANA will
this registry. maintain this registry.
2. Signed Receipts 2. Signed Receipts
Returning a signed receipt provides to the originator proof of delivery of Returning a signed receipt provides to the originator proof of
a message, and allows the originator to demonstrate to a third party that delivery of a message, and allows the originator to demonstrate to a
the recipient was able to verify the signature of the original message. third party that the recipient was able to verify the signature of
This receipt is bound to the original message through the signature; the original message. This receipt is bound to the original message
consequently, this service may be requested only if a message is signed. through the signature; consequently, this service may be requested
The receipt sender may optionally also encrypt a receipt to provide only if a message is signed. The receipt sender may optionally also
confidentiality between the receipt sender and the receipt recipient. encrypt a receipt to provide confidentiality between the receipt
sender and the receipt recipient.
2.1 Signed Receipt Concepts 2.1 Signed Receipt Concepts
The originator of a message may request a signed receipt from the message's The originator of a message may request a signed receipt from the
recipients. The request is indicated by adding a receiptRequest attribute message's recipients. The request is indicated by adding a
to the signedAttributes field of the SignerInfo object for which the receiptRequest attribute to the signedAttributes field of the
receipt is requested. The receiving user agent software SHOULD SignerInfo object for which the receipt is requested. The receiving
automatically create a signed receipt when requested to do so, and return user agent software SHOULD automatically create a signed receipt when
the receipt in accordance with mailing list expansion options, local requested to do so, and return the receipt in accordance with mailing
security policies, and configuration options. list expansion options, local security policies, and configuration
options.
Because receipts involve the interaction of two parties, the terminology Because receipts involve the interaction of two parties, the
can sometimes be confusing. In this section, the "sender" is the agent that terminology can sometimes be confusing. In this section, the "sender"
sent the original message that included a request for a receipt. The is the agent that sent the original message that included a request
"receiver" is the party that received that message and generated the for a receipt. The "receiver" is the party that received that message
receipt. and generated the receipt.
The steps in a typical transaction are: The steps in a typical transaction are:
1. Sender creates a signed message including a receipt request attribute 1. Sender creates a signed message including a receipt request
(Section 2.2). attribute (Section 2.2).
2. Sender transmits the resulting message to the recipient or recipients. 2. Sender transmits the resulting message to the recipient or
recipients.
3. Recipient receives message and determines if there is a valid signature 3. Recipient receives message and determines if there is a valid
and receipt request in the message (Section 2.3). signature and receipt request in the message (Section 2.3).
4. Recipient creates a signed receipt (Section 2.4). 4. Recipient creates a signed receipt (Section 2.4).
5. Recipient transmits the resulting signed receipt message to the sender 5. Recipient transmits the resulting signed receipt message to the
(Section 2.5). sender (Section 2.5).
6. Sender receives the message and validates that it contains a signed 6. Sender receives the message and validates that it contains a
receipt for the original message (Section 2.6). This validation relies on signed receipt for the original message (Section 2.6). This
the sender having retained either a copy of the original message or validation relies on the sender having retained either a copy of
information extracted from the original message. the original message or information extracted from the original
message.
The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 The ASN.1 syntax for the receipt request is given in Section 2.7; the
syntax for the receipt is given in Section 2.8. ASN.1 syntax for the receipt is given in Section 2.8.
Note that a sending agent SHOULD remember when it has sent a receipt so Note that a sending agent SHOULD remember when it has sent a receipt
that it can avoid re-sending a receipt each time it processes the message. so that it can avoid re-sending a receipt each time it processes the
message.
A receipt request can indicate that receipts be sent to many places, not A receipt request can indicate that receipts be sent to many places,
just to the sender (in fact, the receipt request might indicate that the not just to the sender (in fact, the receipt request might indicate
receipts should not even go to the sender). In order to verify a receipt, that the receipts should not even go to the sender). In order to
the recipient of the receipt must be the originator or a recipient of the verify a receipt, the recipient of the receipt must be the originator
original message. Thus, the sender SHOULD NOT request that receipts be sent or a recipient of the original message. Thus, the sender SHOULD NOT
to anyone who does not have an exact copy of the message. request that receipts be sent to anyone who does not have an exact
copy of the message.
2.2 Receipt Request Creation 2.2 Receipt Request Creation
Multi-layer S/MIME messages may contain multiple SignedData layers. Multi-layer S/MIME messages may contain multiple SignedData layers.
However, receipts may be requested only for the innermost SignedData layer However, receipts may be requested only for the innermost SignedData
in a multi-layer S/MIME message, such as a triple wrapped message. Only one layer in a multi-layer S/MIME message, such as a triple wrapped
receiptRequest attribute can be included in the signedAttributes of a message. Only one receiptRequest attribute can be included in the
SignerInfo. signedAttributes of a SignerInfo.
A ReceiptRequest attribute MUST NOT be included in the attributes of a A ReceiptRequest attribute MUST NOT be included in the attributes of
SignerInfo in a SignedData object that encapsulates a Receipt content. In a SignerInfo in a SignedData object that encapsulates a Receipt
other words, the receiving agent MUST NOT request a signed receipt for a content. In other words, the receiving agent MUST NOT request a
signed receipt. signed receipt for a signed receipt.
A sender requests receipts by placing a receiptRequest attribute in the A sender requests receipts by placing a receiptRequest attribute in
signed attributes of a signerInfo as follows: the signed attributes of a signerInfo as follows:
1. A receiptRequest data structure is created. 1. A receiptRequest data structure is created.
2. A signed content identifier for the message is created and assigned to 2. A signed content identifier for the message is created and assigned
the signedContentIdentifier field. The signedContentIdentifier is used to to the signedContentIdentifier field. The signedContentIdentifier
associate the signed receipt with the message requesting the signed is used to associate the signed receipt with the message requesting
receipt. the signed receipt.
3. The entities requested to return a signed receipt are noted in the 3. The entities requested to return a signed receipt are noted in the
receiptsFrom field. receiptsFrom field.
4. The message originator MUST populate the receiptsTo field with a 4. The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed GeneralNames for each entity to whom the recipient should send the
receipt. If the message originator wants the recipient to send the signed signed receipt. If the message originator wants the recipient to
receipt to the originator, then the originator MUST include a GeneralNames send the signed receipt to the originator, then the originator MUST
for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF include a GeneralNames for itself in the receiptsTo field.
GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each GeneralNames is a SEQUENCE OF GeneralName. receiptsTo is a
GeneralNames represents an entity. There may be multiple GeneralName SEQUENCE OF GeneralNames in which each GeneralNames represents an
instances in each GeneralNames. At a minimum, the message originator MUST entity. There may be multiple GeneralName instances in each
populate each entity's GeneralNames with the address to which the signed GeneralNames. At a minimum, the message originator MUST populate
receipt should be sent. Optionally, the message originator MAY also each entity's GeneralNames with the address to which the signed
populate each entity's GeneralNames with other GeneralName instances (such receipt should be sent. Optionally, the message originator MAY
as directoryName). also populate each entity's GeneralNames with other GeneralName
instances (such as directoryName).
5. The completed receiptRequest attribute is placed in the signedAttributes 5. The completed receiptRequest attribute is placed in the
field of the SignerInfo object. signedAttributes field of the SignerInfo object.
2.2.1 Multiple Receipt Requests 2.2.1 Multiple Receipt Requests
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and
SignerInfo may include signedAttributes. Therefore, a single SignedData each SignerInfo may include signedAttributes. Therefore, a single
object may include multiple SignerInfos, each SignerInfo having a SignedData object may include multiple SignerInfos, each SignerInfo
receiptRequest attribute. For example, an originator can send a signed having a receiptRequest attribute. For example, an originator can
message with two SignerInfos, one containing a DSS signature, the other send a signed message with two SignerInfos, one containing a DSS
containing an RSA signature. signature, the other containing an RSA signature.
Each recipient SHOULD return only one signed receipt. Each recipient SHOULD return only one signed receipt.
Not all of the SignerInfos need to include receipt requests, but in all of Not all of the SignerInfos need to include receipt requests, but in
the SignerInfos that do contain receipt requests, the receipt requests MUST all of the SignerInfos that do contain receipt requests, the receipt
be identical. requests MUST be identical.
2.2.2 Information Needed to Validate Signed Receipts 2.2.2 Information Needed to Validate Signed Receipts
The sending agent MUST retain one or both of the following items to support The sending agent MUST retain one or both of the following items to
the validation of signed receipts returned by the recipients. support the validation of signed receipts returned by the recipients.
- the original signedData object requesting the signed receipt - the original signedData object requesting the signed receipt
- the message signature digest value used to generate the original - the message signature digest value used to generate the original
signedData signerInfo signature value and the digest value of the signedData signerInfo signature value and the digest value of the
Receipt content containing values included in the original signedData Receipt content containing values included in the original
object. If signed receipts are requested from multiple recipients, then signedData object. If signed receipts are requested from multiple
retaining these digest values is a performance enhancement because the recipients, then retaining these digest values is a performance
sending agent can reuse the saved values when verifying each returned enhancement because the sending agent can reuse the saved values
signed receipt. when verifying each returned signed receipt.
2.3 Receipt Request Processing 2.3 Receipt Request Processing
A receiptRequest is associated only with the SignerInfo object to which the A receiptRequest is associated only with the SignerInfo object to
receipt request attribute is directly attached. Receiving software SHOULD which the receipt request attribute is directly attached. Receiving
examine the signedAttributes field of each of the SignerInfos for which it software SHOULD examine the signedAttributes field of each of the
verifies a signature in the innermost signedData object to determine if a SignerInfos for which it verifies a signature in the innermost
receipt is requested. This may result in the receiving agent processing signedData object to determine if a receipt is requested. This may
multiple receiptRequest attributes included in a single SignedData object, result in the receiving agent processing multiple receiptRequest
such as requests made from different people who signed the object in attributes included in a single SignedData object, such as requests
parallel. made from different people who signed the object in parallel.
Before processing a receiptRequest signedAttribute, the receiving agent Before processing a receiptRequest signedAttribute, the receiving
MUST verify the signature of the SignerInfo which covers the receiptRequest agent MUST verify the signature of the SignerInfo which covers the
attribute. A recipient MUST NOT process a receiptRequest attribute that has receiptRequest attribute. A recipient MUST NOT process a
not been verified. Because all receiptRequest attributes in a SignedData receiptRequest attribute that has not been verified. Because all
object must be identical, the receiving application fully processes (as receiptRequest attributes in a SignedData object must be identical,
described in the following paragraphs) the first receiptRequest attribute the receiving application fully processes (as described in the
that it encounters in a SignerInfo that it verifies, and it then ensures following paragraphs) the first receiptRequest attribute that it
that all other receiptRequest attributes in signerInfos that it verifies encounters in a SignerInfo that it verifies, and it then ensures that
are identical to the first one encountered. If there are verified all other receiptRequest attributes in signerInfos that it verifies
ReceiptRequest attributes which are not the same, then the processing are identical to the first one encountered. If there are verified
software MUST NOT return any signed receipt. A signed receipt SHOULD be ReceiptRequest attributes which are not the same, then the processing
returned if any signerInfo containing a receiptRequest attribute can be software MUST NOT return any signed receipt. A signed receipt SHOULD
validated, even if other signerInfos containing the same receiptRequest be returned if any signerInfo containing a receiptRequest attribute
attribute cannot be validated because they are signed using an algorithm can be validated, even if other signerInfos containing the same
not supported by the receiving agent. receiptRequest attribute cannot be validated because they are signed
using an algorithm not supported by the receiving agent.
If a receiptRequest attribute is absent from the signed attributes, then a If a receiptRequest attribute is absent from the signed attributes,
signed receipt has not been requested from any of the message recipients then a signed receipt has not been requested from any of the message
and MUST NOT be created. If a receiptRequest attribute is present in the recipients and MUST NOT be created. If a receiptRequest attribute is
signed attributes, then a signed receipt has been requested from some or present in the signed attributes, then a signed receipt has been
all of the message recipients. Note that in some cases, a receiving agent requested from some or all of the message recipients. Note that in
might receive two almost-identical messages, one with a receipt request and some cases, a receiving agent might receive two almost-identical
the other without one. In this case, the receiving agent SHOULD send a messages, one with a receipt request and the other without one. In
signed receipt for the message that requests a signed receipt. this case, the receiving agent SHOULD send a signed receipt for the
message that requests a signed receipt.
If a receiptRequest attribute is present in the signed attributes, the If a receiptRequest attribute is present in the signed attributes,
following process SHOULD be used to determine if a message recipient has the following process SHOULD be used to determine if a message
been requested to return a signed receipt. recipient has been requested to return a signed receipt.
1. If an mlExpansionHistory attribute is present in the outermost 1. If an mlExpansionHistory attribute is present in the outermost
signedData block, do one of the following two steps, based on the absence signedData block, do one of the following two steps, based on the
or presence of mlReceiptPolicy: absence or presence of mlReceiptPolicy:
1.1. If an mlReceiptPolicy value is absent from the last MLData 1.1. If an mlReceiptPolicy value is absent from the last MLData
element, a Mail List receipt policy has not been specified and the element, a Mail List receipt policy has not been specified
processing software SHOULD examine the receiptRequest attribute value and the processing software SHOULD examine the
to determine if a receipt should be created and returned. receiptRequest attribute value to determine if a receipt
should be created and returned.
1.2. If an mlReceiptPolicy value is present in the last MLData element, 1.2. If an mlReceiptPolicy value is present in the last MLData
do one of the following two steps, based on the value of element, do one of the following two steps, based on the
mlReceiptPolicy: value of mlReceiptPolicy:
1.2.1. If the mlReceiptPolicy value is none, then the receipt 1.2.1. If the mlReceiptPolicy value is none, then the receipt
policy of the Mail List supersedes the originator's request for a policy of the Mail List supersedes the originator's
signed receipt and a signed receipt MUST NOT be created. request for a signed receipt and a signed receipt MUST
NOT be created.
1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo, 1.2.2. If the mlReceiptPolicy value is insteadOf or
the processing software SHOULD examine the receiptsFrom value from inAdditionTo, the processing software SHOULD examine
the receiptRequest attribute to determine if a receipt should be the receiptsFrom value from the receiptRequest
created and returned. If a receipt is created, the insteadOf and attribute to determine if a receipt should be created
inAdditionTo fields identify entities that SHOULD be sent the and returned. If a receipt is created, the insteadOf
receipt instead of or in addition to the originator. and inAdditionTo fields identify entities that SHOULD
be sent the receipt instead of or in addition to the
originator.
2. If the receiptsFrom value of the receiptRequest attribute is 2. If the receiptsFrom value of the receiptRequest attribute
allOrFirstTier, do one of the following two steps based on the value of allOrFirstTier, do one of the following two steps based on the
allOrFirstTier. value of allOrFirstTier.
2.1. If the value of allOrFirstTier is allReceipts, then a signed 2.1. If the value of allOrFirstTier is allReceipts, then a signed
receipt SHOULD be created. receipt SHOULD be created.
2.2. If the value of allOrFirstTier is firstTierRecipients, do one of 2.2. If the value of allOrFirstTier is firstTierRecipients, do
the following two steps based on the presence of an mlExpansionHistory one of the following two steps based on the presence of an
attribute in an outer signedData block: mlExpansionHistory attribute in an outer signedData block:
2.2.1. If an mlExpansionHistory attribute is present, then this 2.2.1. If an mlExpansionHistory attribute is present, then
recipient is not a first tier recipient and a signed receipt MUST this recipient is not a first tier recipient and a
NOT be created. signed receipt MUST NOT be created.
2.2.2. If an mlExpansionHistory attribute is not present, then a 2.2.2. If an mlExpansionHistory attribute is not present,
signed receipt SHOULD be created. then a signed receipt SHOULD be created.
3. If the receiptsFrom value of the receiptRequest attribute is a 3. If the receiptsFrom value of the receiptRequest attribute is a
receiptList: receiptList:
3.1. If receiptList contains one of the GeneralNames of the recipient, 3.1. If receiptList contains one of the GeneralNames of the
then a signed receipt SHOULD be created. recipient, then a signed receipt SHOULD be created.
3.2. If receiptList does not contain one of the GeneralNames of the 3.2. If receiptList does not contain one of the GeneralNames of
recipient, then a signed receipt MUST NOT be created. the recipient, then a signed receipt MUST NOT be created.
A flow chart for the above steps to be executed for each signerInfo for A flow chart for the above steps to be executed for each signerInfo
which the receiving agent verifies the signature would be: for which the receiving agent verifies the signature would be:
0. Receipt Request attribute present? 0. Receipt Request attribute present?
YES -> 1. YES -> 1.
NO -> STOP NO -> STOP
1. Has mlExpansionHistory in outer signedData? 1. Has mlExpansionHistory in outer signedData?
YES -> 1.1. YES -> 1.1.
NO -> 2. NO -> 2.
1.1. mlReceiptPolicy absent? 1.1. mlReceiptPolicy absent?
YES -> 2. YES -> 2.
NO -> 1.2. NO -> 1.2.
1.2. Pick based on value of mlReceiptPolicy. 1.2. Pick based on value of mlReceiptPolicy.
none -> 1.2.1. none -> 1.2.1.
insteadOf or inAdditionTo -> 1.2.2. insteadOf or inAdditionTo -> 1.2.2.
1.2.1. STOP. 1.2.1. STOP.
1.2.2. Examine receiptsFrom to determine if a receipt should be created, 1.2.2. Examine receiptsFrom to determine if a receipt should be
create it if required, send it to recipients designated by created, create it if required, send it to recipients designated
mlReceiptPolicy, then -> STOP. by mlReceiptPolicy, then -> STOP.
2. Is value of receiptsFrom allOrFirstTier? 2. Is value of receiptsFrom allOrFirstTier?
YES -> Pick based on value of allOrFirstTier. YES -> Pick based on value of allOrFirstTier.
allReceipts -> 2.1. allReceipts -> 2.1.
firstTierRecipients -> 2.2. firstTierRecipients -> 2.2.
NO -> 3. NO -> 3.
2.1. Create a receipt, then -> STOP. 2.1. Create a receipt, then -> STOP.
2.2. Has mlExpansionHistory in the outer signedData block? 2.2. Has mlExpansionHistory in the outer signedData block?
YES -> 2.2.1. YES -> 2.2.1.
NO -> 2.2.2. NO -> 2.2.2.
2.2.1. STOP. 2.2.1. STOP.
2.2.2. Create a receipt, then -> STOP. 2.2.2. Create a receipt, then -> STOP.
3. Is receiptsFrom value of receiptRequest a receiptList? 3. Is receiptsFrom value of receiptRequest a receiptList?
YES -> 3.1. YES -> 3.1.
NO -> STOP. NO -> STOP.
3.1. Does receiptList contain the recipient? 3.1. Does receiptList contain the recipient?
YES -> Create a receipt, then -> STOP. YES -> Create a receipt, then -> STOP.
NO -> 3.2. NO -> 3.2.
3.2. STOP. 3.2. STOP.
2.4 Signed Receipt Creation 2.4 Signed Receipt Creation
A signed receipt is a signedData object encapsulating a Receipt content A signed receipt is a signedData object encapsulating a Receipt
(also called a "signedData/Receipt"). Signed receipts are created as content (also called a "signedData/Receipt"). Signed receipts are
follows: created as follows:
1. The signature of the original signedData signerInfo that includes the 1. The signature of the original signedData signerInfo that includes
receiptRequest signed attribute MUST be successfully verified before the receiptRequest signed attribute MUST be successfully verified
creating the signedData/Receipt. before creating the signedData/Receipt.
1.1. The content of the original signedData object is digested as 1.1. The content of the original signedData object is digested as
described in [CMS]. The resulting digest value is then compared with described in [CMS]. The resulting digest value is then
the value of the messageDigest attribute included in the compared with the value of the messageDigest attribute
signedAttributes of the original signedData signerInfo. If these digest included in the signedAttributes of the original signedData
values are different, then the signature verification process fails and signerInfo. If these digest values are different, then the
the signedData/Receipt MUST NOT be created. signature verification process fails and the
signedData/Receipt MUST NOT be created.
1.2. The ASN.1 DER encoded signedAttributes (including messageDigest, 1.2. The ASN.1 DER encoded signedAttributes (including
receiptRequest and, possibly, other signed attributes) in the original messageDigest, receiptRequest and, possibly, other signed
signedData signerInfo are digested as described in [CMS]. The resulting attributes) in the original signedData signerInfo are
digest value, called msgSigDigest, is then used to verify the signature digested as described in [CMS]. The resulting digest
of the original signedData signerInfo. If the signature verification value, called msgSigDigest, is then used to verify the
fails, then the signedData/Receipt MUST NOT be created. signature of the original signedData signerInfo. If the
signature verification fails, then the signedData/Receipt
MUST NOT be created.
2. A Receipt structure is created. 2. A Receipt structure is created.
2.1. The value of the Receipt version field is set to 1. 2.1. The value of the Receipt version field is set to 1.
2.2. The object identifier from the contentType attribute included in 2.2. The object identifier from the contentType attribute
the original signedData signerInfo that includes the receiptRequest included in the original signedData signerInfo that
attribute is copied into the Receipt contentType. includes the receiptRequest attribute is copied into
the Receipt contentType.
2.3. The original signedData signerInfo receiptRequest 2.3. The original signedData signerInfo receiptRequest
signedContentIdentifier is copied into the Receipt signedContentIdentifier is copied into the Receipt
signedContentIdentifier. signedContentIdentifier.
2.4. The signature value from the original signedData signerInfo that 2.4. The signature value from the original signedData signerInfo
includes the receiptRequest attribute is copied into the Receipt that includes the receiptRequest attribute is copied into
originatorSignatureValue. the Receipt originatorSignatureValue.
3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1. 3. The Receipt structure is ASN.1 DER encoded to produce a data
stream, D1.
4. D1 is digested. The resulting digest value is included as the 4. D1 is digested. The resulting digest value is included as the
messageDigest attribute in the signedAttributes of the signerInfo which messageDigest attribute in the signedAttributes of the signerInfo
will eventually contain the signedData/Receipt signature value. which will eventually contain the signedData/Receipt signature
value.
5. The digest value (msgSigDigest) calculated in Step 1 to verify the 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
signature of the original signedData signerInfo is included as the signature of the original signedData signerInfo is included as the
msgSigDigest attribute in the signedAttributes of the signerInfo which will msgSigDigest attribute in the signedAttributes of the signerInfo
eventually contain the signedData/Receipt signature value. which will eventually contain the signedData/Receipt signature
value.
6. A contentType attribute including the id-ct-receipt object identifier 6. A contentType attribute including the id-ct-receipt object
MUST be created and added to the signed attributes of the signerInfo which identifier MUST be created and added to the signed attributes of
will eventually contain the signedData/Receipt signature value. the signerInfo which will eventually contain the
signedData/Receipt signature value.
7. A signingTime attribute indicating the time that the signedData/Receipt 7. A signingTime attribute indicating the time that the
is signed SHOULD be created and added to the signed attributes of the signedData/Receipt is signed SHOULD be created and added to the
signerInfo which will eventually contain the signedData/Receipt signature signed attributes of the signerInfo which will eventually contain
value. Other attributes (except receiptRequest) may be added to the the signedData/Receipt signature value. Other attributes (except
signedAttributes of the signerInfo. receiptRequest) may be added to the signedAttributes of the
signerInfo.
8. The signedAttributes (messageDigest, msgSigDigest, contentType and, 8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
possibly, others) of the signerInfo are ASN.1 DER encoded and digested as possibly, others) of the signerInfo are ASN.1 DER encoded and
described in [CMS]. The resulting digest value is used to calculate the digested as described in [CMS]. The resulting digest value is used
signature value which is then included in the signedData/Receipt to calculate the signature value which is then included in the
signerInfo. signedData/Receipt signerInfo.
9. The ASN.1 DER encoded Receipt content MUST be directly encoded within 9. The ASN.1 DER encoded Receipt content MUST be directly encoded
the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The within the signedData encapContentInfo eContent OCTET STRING
id-ct-receipt object identifier MUST be included in the signedData defined in [CMS]. The id-ct-receipt object identifier MUST be
encapContentInfo eContentType. This results in a single ASN.1 encoded included in the signedData encapContentInfo eContentType. This
object composed of a signedData including the Receipt content. The Data results in a single ASN.1 encoded object composed of a signedData
content type MUST NOT be used. The Receipt content MUST NOT be encapsulated including the Receipt content. The Data content type MUST NOT be
in a MIME header or any other header prior to being encoded as part of the used. The Receipt content MUST NOT be encapsulated in a MIME
signedData object. header or any other header prior to being encoded as part of the
signedData object.
10. The signedData/Receipt is then put in an application/pkcs7-mime MIME 10. The signedData/Receipt is then put in an application/pkcs7-mime
wrapper with the smime-type parameter set to "signed-receipt". This will MIME wrapper with the smime-type parameter set to
allow for identification of signed receipts without having to crack the "signed-receipt". This will allow for identification of signed
ASN.1 body. The smime-type parameter would still be set as normal in any receipts without having to crack the ASN.1 body. The smime-type
layer wrapped around this message. parameter would still be set as normal in any layer wrapped
around this message.
11. If the signedData/Receipt is to be encrypted within an envelopedData 11. If the signedData/Receipt is to be encrypted within an
object, then an outer signedData object MUST be created that encapsulates envelopedData object, then an outer signedData object MUST be
the envelopedData object, and a contentHints attribute with contentType set created that encapsulates the envelopedData object, and a
to the id-ct-receipt object identifier MUST be included in the outer contentHints attribute with contentType set to the id-ct-receipt
signedData SignerInfo signedAttributes. When a receiving agent processes object identifier MUST be included in the outer signedData
the outer signedData object, the presence of the id-ct-receipt OID in the SignerInfo signedAttributes. When a receiving agent processes the
contentHints contentType indicates that a signedData/Receipt is encrypted outer signedData object, the presence of the id-ct-receipt OID in
within the envelopedData object encapsulated by the outer signedData. the contentHints contentType indicates that a signedData/Receipt
is encrypted within the envelopedData object encapsulated by the
outer signedData.
All sending agents that support the generation of ESS signed receipts MUST All sending agents that support the generation of ESS signed receipts
provide the ability to send encrypted signed receipts (that is, a MUST provide the ability to send encrypted signed receipts (that is,
signedData/Receipt encapsulated within an envelopedData). The sending agent a signedData/Receipt encapsulated within an envelopedData). The
MAY send an encrypted signed receipt in response to an sending agent MAY send an encrypted signed receipt in response to an
envelopedData-encapsulated signedData requesting a signed receipt. It is a envelopedData-encapsulated signedData requesting a signed receipt. It
matter of local policy regarding whether or not the signed receipt should is a matter of local policy regarding whether or not the signed
be encrypted. The ESS signed receipt includes the message digest value receipt should be encrypted. The ESS signed receipt includes the
calculated for the original signedData object that requested the signed message digest value calculated for the original signedData object
receipt. If the original signedData object was sent encrypted within an that requested the signed receipt. If the original signedData object
envelopedData object and the ESS signed receipt is sent unencrypted, then was sent encrypted within an envelopedData object and the ESS signed
the message digest value calculated for the original encrypted signedData receipt is sent unencrypted, then the message digest value calculated
object is sent unencrypted. The responder should consider this when for the original encrypted signedData object is sent unencrypted. The
deciding whether or not to encrypt the ESS signed receipt. responder should consider this when deciding whether or not to
encrypt the ESS signed receipt.
2.4.1 MLExpansionHistory Attributes and Receipts 2.4.1 MLExpansionHistory Attributes and Receipts
An MLExpansionHistory attribute MUST NOT be included in the attributes of a An MLExpansionHistory attribute MUST NOT be included in the
SignerInfo in a SignedData object that encapsulates a Receipt content. This attributes of a SignerInfo in a SignedData object that encapsulates a
is true because when a SignedData/Receipt is sent to an MLA for Receipt content. This is true because when a SignedData/Receipt is
distribution, then the MLA must always encapsulate the received sent to an MLA for distribution, then the MLA must always encapsulate
SignedData/Receipt in an outer SignedData in which the MLA will include the the received SignedData/Receipt in an outer SignedData in which the
MLExpansionHistory attribute. The MLA cannot change the signedAttributes of MLA will include the MLExpansionHistory attribute. The MLA cannot
the received SignedData/Receipt object, so it can't add the change the signedAttributes of the received SignedData/Receipt
MLExpansionHistory to the SignedData/Receipt. object, so it can't add the MLExpansionHistory to the
SignedData/Receipt.
2.5 Determining the Recipients of the Signed Receipt 2.5 Determining the Recipients of the Signed Receipt
If a signed receipt was created by the process described in the sections If a signed receipt was created by the process described in the
above, then the software MUST use the following process to determine to sections above, then the software MUST use the following process to
whom the signed receipt should be sent. determine to whom the signed receipt should be sent.
1. The receiptsTo field must be present in the receiptRequest attribute. 1. The receiptsTo field must be present in the receiptRequest
The software initiates the sequence of recipients with the value(s) of attribute. The software initiates the sequence of recipients with
receiptsTo. the value(s) of receiptsTo.
2. If the MlExpansionHistory attribute is present in the outer SignedData 2. If the MlExpansionHistory attribute is present in the outer
block, and the last MLData contains an MLReceiptPolicy value of insteadOf, SignedData block, and the last MLData contains an MLReceiptPolicy
then the software replaces the sequence of recipients with the value(s) of value of insteadOf, then the software replaces the sequence of
insteadOf. recipients with the value(s) of insteadOf.
3. If the MlExpansionHistory attribute is present in the outer SignedData 3. If the MlExpansionHistory attribute is present in the outer
block and the last MLData contains an MLReceiptPolicy value of SignedData block and the last MLData contains an MLReceiptPolicy
inAdditionTo, then the software adds the value(s) of inAdditionTo to the value of inAdditionTo, then the software adds the value(s) of
sequence of recipients. inAdditionTo to the sequence of recipients.
2.6. Signed Receipt Validation 2.6. Signed Receipt Validation
A signed receipt is communicated as a single ASN.1 encoded object composed A signed receipt is communicated as a single ASN.1 encoded object
of a signedData object directly including a Receipt content. It is composed of a signedData object directly including a Receipt content.
identified by the presence of the id-ct-receipt object identifier in the It is identified by the presence of the id-ct-receipt object
encapContentInfo eContentType value of the signedData object including the identifier in the encapContentInfo eContentType value of the
Receipt content. signedData object including the Receipt content.
Although receipients are not supposed to send more than one signed receipt, Although recipients are not supposed to send more than one signed
receiving agents SHOULD be able to accept multiple signed receipts from a receipt, receiving agents SHOULD be able to accept multiple signed
recipient. receipts from a recipient.
A signedData/Receipt is validated as follows: A signedData/Receipt is validated as follows:
1. ASN.1 decode the signedData object including the Receipt content. 1. ASN.1 decode the signedData object including the Receipt content.
2. Extract the contentType, signedContentIdentifier, and 2. Extract the contentType, signedContentIdentifier, and
originatorSignatureValue from the decoded Receipt structure to identify the originatorSignatureValue from the decoded Receipt structure to
original signedData signerInfo that requested the signedData/Receipt. identify the original signedData signerInfo that requested the
signedData/Receipt.
3. Acquire the message signature digest value calculated by the sender to 3. Acquire the message signature digest value calculated by the sender
generate the signature value included in the original signedData signerInfo to generate the signature value included in the original signedData
that requested the signedData/Receipt. signerInfo that requested the signedData/Receipt.
3.1. If the sender-calculated message signature digest value has been 3.1. If the sender-calculated message signature digest value has
saved locally by the sender, it must be located and retrieved. been saved locally by the sender, it must be located and
retrieved.
3.2. If it has not been saved, then it must be re-calculated based on 3.2. If it has not been saved, then it must be re-calculated based
the original signedData content and signedAttributes as described in on the original signedData content and signedAttributes as
[CMS]. described in [CMS].
4. The message signature digest value calculated by the sender is then 4. The message signature digest value calculated by the sender is then
compared with the value of the msgSigDigest signedAttribute included in the compared with the value of the msgSigDigest signedAttribute
signedData/Receipt signerInfo. If these digest values are identical, then included in the signedData/Receipt signerInfo. If these digest
that proves that the message signature digest value calculated by the values are identical, then that proves that the message signature
recipient based on the received original signedData object is the same as digest value calculated by the recipient based on the received
that calculated by the sender. This proves that the recipient received original signedData object is the same as that calculated by the
exactly the same original signedData content and signedAttributes as sent sender. This proves that the recipient received exactly the same
by the sender because that is the only way that the recipient could have original signedData content and signedAttributes as sent by the
calculated the same message signature digest value as calculated by the sender because that is the only way that the recipient could have
sender. If the digest values are different, then the signedData/Receipt calculated the same message signature digest value as calculated by
signature verification process fails. the sender. If the digest values are different, then the
signedData/Receipt signature verification process fails.
5. Acquire the digest value calculated by the sender for the Receipt 5. Acquire the digest value calculated by the sender for the Receipt
content constructed by the sender (including the contentType, content constructed by the sender (including the contentType,
signedContentIdentifier, and signature value that were included in the signedContentIdentifier, and signature value that were included in
original signedData signerInfo that requested the signedData/Receipt). the original signedData signerInfo that requested the
signedData/Receipt).
5.1. If the sender-calculated Receipt content digest value has been 5.1. If the sender-calculated Receipt content digest value has
saved locally by the sender, it must be located and retrieved. been saved locally by the sender, it must be located and
retrieved.
5.2. If it has not been saved, then it must be re-calculated. As 5.2. If it has not been saved, then it must be re-calculated. As
described in section 2.4 above, step 2, create a Receipt structure described in section above, step 2, create a Receipt
including the contentType, signedContentIdentifier and signature value structure including the contentType, signedContentIdentifier
that were included in the original signedData signerInfo that requested and signature value that were included in the original
the signed receipt. The Receipt structure is then ASN.1 DER encoded to signedData signerInfo that requested the signed receipt. The
produce a data stream which is then digested to produce the Receipt Receipt structure is then ASN.1 DER encoded to produce a data
content digest value. stream which is then digested to produce the Receipt content
digest value.
6. The Receipt content digest value calculated by the sender is then 6. The Receipt content digest value calculated by the sender is then
compared with the value of the messageDigest signedAttribute included in compared with the value of the messageDigest signedAttribute
the signedData/Receipt signerInfo. If these digest values are identical, included in the signedData/Receipt signerInfo. If these digest
then that proves that the values included in the Receipt content by the values are identical, then that proves that the values included in
recipient are identical to those that were included in the original the Receipt content by the recipient are identical to those that
signedData signerInfo that requested the signedData/Receipt. This proves were included in the original signedData signerInfo that requested
that the recipient received the original signedData signed by the sender, the signedData/Receipt. This proves that the recipient received the
because that is the only way that the recipient could have obtained the original signedData signed by the sender, because that is the only
original signedData signerInfo signature value for inclusion in the Receipt way that the recipient could have obtained the original signedData
content. If the digest values are different, then the signedData/Receipt signerInfo signature value for inclusion in the Receipt content. If
signature verification process fails. the digest values are different, then the signedData/Receipt
signature verification process fails.
7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
signerInfo are digested as described in [CMS]. signerInfo are digested as described in [CMS].
8. The resulting digest value is then used to verify the signature value 8. The resulting digest value is then used to verify the signature
included in the signedData/Receipt signerInfo. If the signature value included in the signedData/Receipt signerInfo. If the
verification is successful, then that proves the integrity of the signature verification is successful, then that proves the
signedData/receipt signerInfo signedAttributes and authenticates the integrity of the signedData/receipt signerInfo signedAttributes and
identity of the signer of the signedData/Receipt signerInfo. Note that the authenticates the identity of the signer of the signedData/Receipt
signedAttributes include the recipient-calculated Receipt content digest signerInfo. Note that the signedAttributes include the
value (messageDigest attribute) and recipient-calculated message signature recipient-calculated Receipt content digest value (messageDigest
digest value (msgSigDigest attribute). Therefore, the aforementioned attribute) and recipient-calculated message signature digest value
comparison of the sender-generated and recipient-generated digest values (msgSigDigest attribute). Therefore, the aforementioned comparison
combined with the successful signedData/Receipt signature verification of the sender-generated and recipient-generated digest values
proves that the recipient received the exact original signedData content combined with the successful signedData/Receipt signature
and signedAttributes (proven by msgSigDigest attribute) that were signed by verification proves that the recipient received the exact original
the sender of the original signedData object (proven by messageDigest signedData content and signedAttributes (proven by msgSigDigest
attribute). If the signature verification fails, then the attribute) that were signed by the sender of the original
signedData/Receipt signature verification process fails. signedData object (proven by messageDigest attribute). If the
signature verification fails, then the signedData/Receipt signature
verification process fails.
The signature verification process for each signature algorithm that is The signature verification process for each signature algorithm that
used in conjunction with the CMS protocol is specific to the algorithm. is used in conjunction with the CMS protocol is specific to the
These processes are described in documents specific to the algorithms. algorithm. These processes are described in documents specific to
the algorithms.
2.7 Receipt Request Syntax 2. 7 Receipt Request Syntax
A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use
receiptRequest attribute only within the signed attributes associated with the receiptRequest attribute only within the signed attributes
a signed message. associated with a signed message.
ReceiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
A signedContentIdentifier MUST be created by the message originator when A signedContentIdentifier MUST be created by the message originator
creating a receipt request. To ensure global uniqueness, the minimal when creating a receipt request. To ensure global uniqueness, the
signedContentIdentifier SHOULD contain a concatenation of user-specific minimal signedContentIdentifier SHOULD contain a concatenation of
identification information (such as a user name or public keying material user-specific identification information (such as a user name or
identification information), a GeneralizedTime string, and a random number. public keying material identification information), a GeneralizedTime
string, and a random number.
The receiptsFrom field is used by the originator to specify the recipients The receiptsFrom field is used by the originator to specify the
requested to return a signed receipt. A CHOICE is provided to allow recipients requested to return a signed receipt. A CHOICE is provided
specification of: to allow specification of:
- receipts from all recipients are requested
- receipts from first tier (recipients that did not receive the
message as members of a mailing list) recipients are requested
- receipts from a specific list of recipients are requested
ReceiptsFrom ::= CHOICE { - receipts from all recipients are requested
allOrFirstTier [0] AllOrFirstTier, - receipts from first tier (recipients that did not receive the
-- formerly "allOrNone [0]AllOrNone" message as members of a mailing list) recipients are requested
receiptList [1] SEQUENCE OF GeneralNames } - receipts from a specific list of recipients are requested
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone ReceiptsFrom ::= CHOICE {
allReceipts (0), allOrFirstTier [0] AllOrFirstTier,
firstTierRecipients (1) } -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
The receiptsTo field is used by the originator to identify the user(s) to AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
whom the identified recipient should send signed receipts. The message allReceipts (0),
originator MUST populate the receiptsTo field with a GeneralNames for each firstTierRecipients (1) }
entity to whom the recipient should send the signed receipt. If the message
originator wants the recipient to send the signed receipt to the The receiptsTo field is used by the originator to identify the
originator, then the originator MUST include a GeneralNames for itself in user(s) to whom the identified recipient should send signed receipts.
the receiptsTo field. The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the
signed receipt. If the message originator wants the recipient to send
the signed receipt to the originator, then the originator MUST
include a GeneralNames for itself in the receiptsTo field.
2.8 Receipt Syntax 2.8 Receipt Syntax
Receipts are represented using a new content type, Receipt. The Receipt Receipts are represented using a new content type, Receipt. The
content type shall have ASN.1 type Receipt. Receipts must be encapsulated Receipt content type shall have ASN.1 type Receipt. Receipts must be
within a SignedData message. encapsulated within a SignedData message.
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version ESSVersion, version ESSVersion,
contentType ContentType, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
ESSVersion ::= INTEGER { v1(1) } ESSVersion ::= INTEGER { v1(1) }
The version field defines the syntax version number, which is 1 for this The version field defines the syntax version number, which is 1 for
version of the standard. this version of the standard.
2.9 Content Hints 2.9 Content Hints
Many applications find it useful to have information that describes the Many applications find it useful to have information that describes
innermost signed content of a multi-layer message available on the the innermost signed content of a multi-layer message available on
outermost signature layer. The contentHints attribute provides such the outermost signature layer. The contentHints attribute provides
information. such information.
Content-hints attribute values have ASN.1 type contentHints. Content-hints attribute values have ASN.1 type contentHints.
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType } contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that the The contentDescription field may be used to provide information that
recipient may use to select protected messages for processing, such as a the recipient may use to select protected messages for processing,
message subject. If this field is set, then the attribute is expected to such as a message subject. If this field is set, then the attribute
appear on the signedData object enclosing an envelopedData object and not is expected to appear on the signedData object enclosing an
on the inner signedData object. The (SIZE (1..MAX)) construct constrains envelopedData object and not on the inner signedData object. The
the sequence to have at least one entry. MAX indicates the upper bound is (SIZE (1..MAX)) construct constrains the sequence to have at least
unspecified. Implementations are free to choose an upper bound that suits one entry. MAX indicates the upper bound is unspecified.
their environment. Implementations are free to choose an upper bound that suits their
environment.
Messages which contain a signedData object wrapped around an envelopedData Messages which contain a signedData object wrapped around an
object, thus masking the inner content type of the message, SHOULD include envelopedData object, thus masking the inner content type of the
a contentHints attribute, except for the case of the data content type. message, SHOULD include a contentHints attribute, except for the case
Specific message content types may either force or preclude the inclusion of the data content type. Specific message content types may either
of the contentHints attribute. For example, when a signedData/Receipt is force or preclude the inclusion of the contentHints attribute. For
encrypted within an envelopedData object, an outer signedData object MUST example, when a signedData/Receipt is encrypted within an
be created that encapsulates the envelopedData object and a contentHints envelopedData object, an outer signedData object MUST be created that
attribute with contentType set to the id-ct-receipt object identifier MUST encapsulates the envelopedData object and a contentHints attribute
be included in the outer signedData SignerInfo signedAttributes. with contentType set to the id-ct-receipt object identifier MUST be
included in the outer signedData SignerInfo signedAttributes.
2.10 Message Signature Digest Attribute 2.10 Message Signature Digest Attribute
The msgSigDigest attribute can only be used in the signed attributes of a The msgSigDigest attribute can only be used in the signed attributes
signed receipt. It contains the digest of the ASN.1 DER encoded of a signed receipt. It contains the digest of the ASN.1 DER encoded
signedAttributes included in the original signedData that requested the signedAttributes included in the original signedData that requested
signed receipt. Only one msgSigDigest attribute can appear in an signed the signed receipt. Only one msgSigDigest attribute can appear in a
attributes set. It is defined as follows: signed attributes set. It is defined as follows:
msgSigDigest ::= OCTET STRING msgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
2.11 Signed Content Reference Attribute 2.11 Signed Content Reference Attribute
The contentReference attribute is a link from one SignedData to another. It The contentReference attribute is a link from one SignedData to
may be used to link a reply to the original message to which it refers, or another. It may be used to link a reply to the original message to
to incorporate by reference one SignedData into another. The first which it refers, or to incorporate by reference one SignedData into
SignedData MUST include a contentIdentifier signed attribute, which SHOULD another. The first SignedData MUST include a contentIdentifier signed
be constructed as specified in section 2.7. The second SignedData links to attribute, which SHOULD be constructed as specified in section 2.7.
the first by including a ContentReference signed attribute containing the The second SignedData links to the first by including a
content type, content identifier, and signature value from the first ContentReference signed attribute containing the content type,
SignedData. content identifier, and signature value from the first SignedData.
ContentReference ::= SEQUENCE { ContentReference ::= SEQUENCE {
contentType ContentType, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
3. Security Labels 3. Security Labels
This section describes the syntax to be used for security labels that can This section describes the syntax to be used for security labels that
optionally be associated with S/MIME encapsulated data. A security label is can optionally be associated with S/MIME encapsulated data. A
a set of security information regarding the sensitivity of the content that security label is a set of security information regarding the
is protected by S/MIME encapsulation. sensitivity of the content that is protected by S/MIME encapsulation.
"Authorization" is the act of granting rights and/or privileges to users "Authorization" is the act of granting rights and/or privileges to
permitting them access to an object. "Access control" is a means of users permitting them access to an object. "Access control" is a
enforcing these authorizations. The sensitivity information in a security means of enforcing these authorizations. The sensitivity information
label can be compared with a user's authorizations to determine if the user in a security label can be compared with a user's authorizations to
is allowed to access the content that is protected by S/MIME encapsulation. determine if the user is allowed to access the content that is
protected by S/MIME encapsulation.
Security labels may be used for other purposes such as a source of routing Security labels may be used for other purposes such as a source of
information. The labels often describe ranked levels ("secret", routing information. The labels often describe ranked levels
"confidential", "restricted", and so on) or are role-based, describing ("secret", "confidential", "restricted", and so on) or are role-
which kind of people can see the information ("patient's health-care team", based, describing which kind of people can see the information
"medical billing agents", "unrestricted", and so on). ("patient's health-care team", "medical billing agents",
"unrestricted", and so on).
3.1 Security Label Processing Rules 3.1 Security Label Processing Rules
A sending agent may include a security label attribute in the signed A sending agent may include a security label attribute in the signed
attributes of a signedData object. A receiving agent examines the security attributes of a signedData object. A receiving agent examines the
label on a received message and determines whether or not the recipient is security label on a received message and determines whether or not
allowed to see the contents of the message. the recipient is allowed to see the contents of the message.
3.1.1 Adding Security Labels 3.1.1 Adding Security Labels
A sending agent that is using security labels MUST put the security label A sending agent that is using security labels MUST put the security
attribute in the signedAttributes field of a SignerInfo block. The security label attribute in the signedAttributes field of a SignerInfo block.
label attribute MUST NOT be included in the unsigned attributes. Integrity The security label attribute MUST NOT be included in the unsigned
and authentication security services MUST be applied to the security label, attributes. Integrity and authentication security services MUST be
therefore it MUST be included as an signed attribute, if used. This causes applied to the security label, therefore it MUST be included as a
the security label attribute to be part of the data that is hashed to form signed attribute, if used. This causes the security label attribute
the SignerInfo signature value. A SignerInfo block MUST NOT have more than to be part of the data that is hashed to form the SignerInfo
one security label signed attribute. signature value. A SignerInfo block MUST NOT have more than one
security label signed attribute.
When there are multiple SignedData blocks applied to a message, a security When there are multiple SignedData blocks applied to a message, a
label attribute may be included in either the inner signature, outer security label attribute may be included in either the inner
signature, or both. A security label signed attribute may be included in a signature, outer signature, or both. A security label signed
signedAttributes field within the inner SignedData block. The inner attribute may be included in a signedAttributes field within the
security label will include the sensitivities of the original content and inner SignedData block. The inner security label will include the
will be used for access control decisions related to the plaintext sensitivities of the original content and will be used for access
encapsulated content. The inner signature provides authentication of the control decisions related to the plaintext encapsulated content. The
inner security label and cryptographically protects the original signer's inner signature provides authentication of the inner security label
inner security label of the original content. and cryptographically protects the original signer's inner security
label of the original content.
When the originator signs the plaintext content and signed attributes, the When the originator signs the plaintext content and signed
inner security label is bound to the plaintext content. An intermediate attributes, the inner security label is bound to the plaintext
entity cannot change the inner security label without invalidating the content. An intermediate entity cannot change the inner security
inner signature. The confidentiality security service can be applied to the label without invalidating the inner signature. The confidentiality
inner security label by encrypting the entire inner signedData object security service can be applied to the inner security label by
within an EnvelopedData block. encrypting the entire inner signedData object within an EnvelopedData
block.
A security label signed attribute may also be included in a A security label signed attribute may also be included in a
signedAttributes field within the outer SignedData block. The outer signedAttributes field within the outer SignedData block. The outer
security label will include the sensitivities of the encrypted message and security label will include the sensitivities of the encrypted
will be used for access control decisions related to the encrypted message message and will be used for access control decisions related to the
and for routing decisions. The outer signature provides authentication of encrypted message and for routing decisions. The outer signature
the outer security label (as well as for the encapsulated content which may provides authentication of the outer security label (as well as for
include nested S/MIME messages). the encapsulated content which may include nested S/MIME messages).
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and
SignerInfo may include signedAttributes. Therefore, a single SignedData each SignerInfo may include signedAttributes. Therefore, a single
object may include multiple eSSSecurityLabels, each SignerInfo having an SignedData object may include multiple eSSSecurityLabels, each
eSSSecurityLabel attribute. For example, an originator can send a signed SignerInfo having an eSSSecurityLabel attribute. For example, an
message with two SignerInfos, one containing a DSS signature, the other originator can send a signed message with two SignerInfos, one
containing an RSA signature. If any of the SignerInfos included in a containing a DSS signature, the other containing an RSA signature. If
SignedData object include an eSSSecurityLabel attribute, then all of the any of the SignerInfos included in a SignedData object include an
SignerInfos in that SignedData object MUST include an eSSSecurityLabel eSSSecurityLabel attribute, then all of the SignerInfos in that
attribute and the value of each MUST be identical. SignedData object MUST include an eSSSecurityLabel attribute and the
value of each MUST be identical.
3.1.2 Processing Security Labels 3.1.2 Processing Security Labels
Before processing an eSSSecurityLabel signedAttribute, the receiving agent Before processing an eSSSecurityLabel signedAttribute, the receiving
MUST verify the signature of the SignerInfo which covers the agent MUST verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient MUST NOT process an eSSSecurityLabel attribute. A recipient MUST NOT process an
eSSSecurityLabel attribute that has not been verified. eSSSecurityLabel attribute that has not been verified.
A receiving agent MUST process the eSSSecurityLabel attribute, if present, A receiving agent MUST process the eSSSecurityLabel attribute, if
in each SignerInfo in the SignedData object for which it verifies the present, in each SignerInfo in the SignedData object for which it
signature. This may result in the receiving agent processing multiple verifies the signature. This may result in the receiving agent
eSSSecurityLabels included in a single SignedData object. Because all processing multiple eSSSecurityLabels included in a single SignedData
eSSSecurityLabels in a SignedData object must be identical, the receiving object. Because all eSSSecurityLabels in a SignedData object must be
agent processes (such as performing access control) on the first identical, the receiving agent processes (such as performing access
eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and control) on the first eSSSecurityLabel that it encounters in a
then ensures that all other eSSSecurityLabels in signerInfos that it SignerInfo that it verifies, and then ensures that all other
verifies are identical to the first one encountered. If the eSSSecurityLabels in signerInfos that it verifies are identical to
eSSSecurityLabels in the signerInfos that it verifies are not all the first one encountered. If the eSSSecurityLabels in the
identical, then the receiving agent MUST warn the user of this condition. signerInfos that it verifies are not all identical, then the
receiving agent MUST warn the user of this condition.
Receiving agents SHOULD have a local policy regarding whether or not to Receiving agents SHOULD have a local policy regarding whether or not
show the inner content of a signedData object that includes an to show the inner content of a signedData object that includes an
eSSSecurityLabel security-policy-identifier that the processing software eSSSecurityLabel security-policy-identifier that the processing
does not recognize. If the receiving agent does not recognize the software does not recognize. If the receiving agent does not
eSSSecurityLabel security-policy-identifier value, then it SHOULD stop recognize the eSSSecurityLabel security-policy-identifier value, then
processing the message and indicate an error. it SHOULD stop processing the message and indicate an error.
3.2 Syntax of eSSSecurityLabel 3.2 Syntax of eSSSecurityLabel
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module. The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1
(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS module. (The MTSAbstractService module begins with "DEFINITIONS
::=".) Further, the eSSSecurityLabel syntax is compatible with that used in IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
[MSP4]. compatible with that used in [MSP4].
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier, security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL, security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL, privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL } security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
skipping to change at line 1184 skipping to change at page 28, line 18
-- value [1] ANY DEFINED BY type } -- value [1] ANY DEFINED BY type }
-- --
--SECURITY-CATEGORY MACRO ::= --SECURITY-CATEGORY MACRO ::=
--BEGIN --BEGIN
--TYPE NOTATION ::= type | empty --TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END --END
3.3 Security Label Components 3.3 Security Label Components
This section gives more detail on the the various components of the This section gives more detail on the the various components of the
eSSSecurityLabel syntax. eSSSecurityLabel syntax.
3.3.1 Security Policy Identifier 3.3.1 Security Policy Identifier
A security policy is a set of criteria for the provision of security A security policy is a set of criteria for the provision of security
services. The eSSSecurityLabel security-policy-identifier is used to services. The eSSSecurityLabel security-policy-identifier is used to
identify the security policy in force to which the security label relates. identify the security policy in force to which the security label
It indicates the semantics of the other security label components. relates. It indicates the semantics of the other security label
components.
3.3.2 Security Classification 3.3.2 Security Classification
This specification defines the use of the Security Classification field This specification defines the use of the Security Classification
exactly as is specified in the X.411 Recommendation, which states in part: field exactly as is specified in the X.411 Recommendation, which
states in part:
If present, a security-classification may have one of a hierarchical If present, a security-classification may have one of a
list of values. The basic security-classification hierarchy is defined hierarchical list of values. The basic security-classification
in this Recommendation, but the use of these values is defined by the hierarchy is defined in this Recommendation, but the use of these
security-policy in force. Additional values of security-classification, values is defined by the security-policy in force. Additional
and their position in the hierarchy, may also be defined by a values of security-classification, and their position in the
security-policy as a local matter or by bilateral agreement. The basic hierarchy, may also be defined by a security-policy as a local
security-classification hierarchy is, in ascending order: unmarked, matter or by bilateral agreement. The basic security-
unclassified, restricted, confidential, secret, top-secret. classification hierarchy is, in ascending order: unmarked,
unclassified, restricted, confidential, secret, top-secret.
This means that the security policy in force (identified by the This means that the security policy in force (identified by the
eSSSecurityLabel security-policy-identifier) defines the eSSSecurityLabel security-policy-identifier) defines the
SecurityClassification integer values and their meanings. SecurityClassification integer values and their meanings.
An organization can develop its own security policy that defines the An organization can develop its own security policy that defines the
SecurityClassification INTEGER values and their meanings. However, the SecurityClassification INTEGER values and their meanings. However,
general interpretation of the X.411 specification is that the values of 0 the general interpretation of the X.411 specification is that the
through 5 are reserved for the "basic hierarchy" values of unmarked, values of 0 through 5 are reserved for the "basic hierarchy" values
unclassified, restricted, confidential, secret, and top-secret. Note that of unmarked, unclassified, restricted, confidential, secret, and
X.411 does not provide the rules for how these values are used to label top-secret. Note that X.411 does not provide the rules for how these
data and how access control is performed using these values. values are used to label data and how access control is performed
using these values.
There is no universal definition of the rules for using these "basic There is no universal definition of the rules for using these "basic
hierarchy" values. Each organization (or group of organizations) will hierarchy" values. Each organization (or group of organizations) will
define a security policy which documents how the "basic hierarchy" values define a security policy which documents how the "basic hierarchy"
are used (if at all) and how access control is enforced (if at all) within values are used (if at all) and how access control is enforced (if at
their domain. all) within their domain.
Therefore, the security-classification value MUST be accompanied by a Therefore, the security-classification value MUST be accompanied by a
security-policy-identifier value to define the rules for its use. For security-policy-identifier value to define the rules for its use. For
example, a company's "secret" classification may convey a different meaning example, a company's "secret" classification may convey a different
than the US Government "secret" classification. In summary, a security meaning than the US Government "secret" classification. In summary, a
policy SHOULD NOT use integers 0 through 5 for other than their X.411 security policy SHOULD NOT use integers 0 through 5 for other than
meanings, and SHOULD instead use other values in a hierarchical fashion. their X.411 meanings, and SHOULD instead use other values in a
hierarchical fashion.
Note that the set of valid security-classification values MUST be Note that the set of valid security-classification values MUST be
hierarchical, but these values do not necessarily need to be in ascending hierarchical, but these values do not necessarily need to be in
numerical order. Further, the values do not need to be contiguous. ascending numerical order. Further, the values do not need to be
contiguous.
For example, in the Defense Message System 1.0 security policy, the For example, in the Defense Message System 1.0 security policy, the
security-classification value of 11 indicates Sensitive-But-Unclassified security-classification value of 11 indicates Sensitive-But-
and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret Unclassified and 5 indicates top-secret. The hierarchy of sensitivity
as more sensitive than Sensitive-But-Unclassified even though the numerical ranks top-secret as more sensitive than Sensitive-But-Unclassified
value of top-secret is less than Sensitive-But-Unclassified. even though the numerical value of top-secret is less than
Sensitive-But-Unclassified.
(Of course, if security-classification values are both hierarchical and in (Of course, if security-classification values are both hierarchical
ascending order, a casual reader of the security policy is more likely to and in ascending order, a casual reader of the security policy is
understand it.) more likely to understand it.)
An example of a security policy that does not use any of the X.411 values An example of a security policy that does not use any of the X.411
might be: values might be:
10 -- anyone
15 -- Morgan Corporation and its contractors
20 -- Morgan Corporation employees
25 -- Morgan Corporation board of directors
An example of a security policy that uses part of the X.411 hierarchy might 10 -- anyone
be: 15 -- Morgan Corporation and its contractors
0 -- unmarked 20 -- Morgan Corporation employees
1 -- unclassified, can be read by everyone 25 -- Morgan Corporation board of directors
2 -- restricted to Timberwolf Productions staff
6 -- can only be read to Timberwolf Productions executives An example of a security policy that uses part of the X.411 hierarchy
might be:
0 -- unmarked
1 -- unclassified, can be read by everyone
2 -- restricted to Timberwolf Productions staff
6 -- can only be read to Timberwolf Productions executives
3.3.3 Privacy Mark 3.3.3 Privacy Mark
If present, the eSSSecurityLabel privacy-mark is not used for access If present, the eSSSecurityLabel privacy-mark is not used for access
control. The content of the eSSSecurityLabel privacy-mark may be defined by control. The content of the eSSSecurityLabel privacy-mark may be
the security policy in force (identified by the eSSSecurityLabel defined by the security policy in force (identified by the
security-policy-identifier) which may define a list of values to be used. eSSSecurityLabel security-policy-identifier) which may define a list
Alternately, the value may be determined by the originator of the of values to be used. Alternately, the value may be determined by the
security-label. originator of the security-label.
3.3.4 Security Categories 3.3.4 Security Categories
If present, the eSSSecurityLabel security-categories provide further If present, the eSSSecurityLabel security-categories provide further
granularity for the sensitivity of the message. The security policy in granularity for the sensitivity of the message. The security policy
force (identified by the eSSSecurityLabel security-policy-identifier) is in force (identified by the eSSSecurityLabel security-policy-
used to indicate the syntaxes that are allowed to be present in the identifier) is used to indicate the syntaxes that are allowed to be
eSSSecurityLabel security-categories. Alternately, the security-categories present in the eSSSecurityLabel security-categories. Alternately, the
and their values may be defined by bilateral agreement. security-categories and their values may be defined by bilateral
agreement.
3.4 Equivalent Security Labels 3.4 Equivalent Security Labels
Because organizations are allowed to define their own security policies, Because organizations are allowed to define their own security
many different security policies will exist. Some organizations may wish to policies, many different security policies will exist. Some
create equivalencies between their security policies with the security organizations may wish to create equivalencies between their security
policies of other organizations. For example, the Acme Company and the policies with the security policies of other organizations. For
Widget Corporation may reach a bilateral agreement that the "Acme private" example, the Acme Company and the Widget Corporation may reach a
security-classification value is equivalent to the "Widget sensitive" bilateral agreement that the "Acme private" security-classification
security-classification value. value is equivalent to the "Widget sensitive" security-classification
value.
Receiving agents MUST NOT process an equivalentLabels attribute in a Receiving agents MUST NOT process an equivalentLabels attribute in a
message if the agent does not trust the signer of that attribute to message if the agent does not trust the signer of that attribute to
translate the original eSSSecurityLabel values to the security policy translate the original eSSSecurityLabel values to the security policy
included in the equivalentLabels attribute. Receiving agents have the included in the equivalentLabels attribute. Receiving agents have the
option to process equivalentLabels attributes but do not have to. It is option to process equivalentLabels attributes but do not have to. It
acceptable for a receiving agent to only process eSSSecurityLabels. All is acceptable for a receiving agent to only process
receiving agents SHOULD recognize equivalentLabels attributes even if they eSSSecurityLabels. All receiving agents SHOULD recognize
do not process them. equivalentLabels attributes even if they do not process them.
3.4.1 Creating Equivalent Labels 3.4.1 Creating Equivalent Labels
The EquivalentLabels signed attribute is defined as: The EquivalentLabels signed attribute is defined as:
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
As stated earlier, the ESSSecurityLabel contains the sensitivity values As stated earlier, the ESSSecurityLabel contains the sensitivity
selected by the original signer of the signedData. If an ESSSecurityLabel values selected by the original signer of the signedData. If an
is present in a signerInfo, all signerInfos in the signedData MUST contain ESSSecurityLabel is present in a signerInfo, all signerInfos in the
an ESSSecurityLabel and they MUST all be identical. In addition to an signedData MUST contain an ESSSecurityLabel and they MUST all be
ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed identical. In addition to an ESSSecurityLabel, a signerInfo MAY also
attribute. If present, the equivalentLabels attribute MUST include one or include an equivalentLabels signed attribute. If present, the
more security labels that are believed by the signer to be semantically equivalentLabels attribute MUST include one or more security labels
equivalent to the ESSSecurityLabel attribute included in the same that are believed by the signer to be semantically equivalent to the
signerInfo. ESSSecurityLabel attribute included in the same signerInfo.
All security-policy object identifiers MUST be unique in the set of All security-policy object identifiers MUST be unique in the set of
ESSSecurityLabel and EquivalentLabels security labels. Before using an ESSSecurityLabel and EquivalentLabels security labels. Before using
EquivalentLabels attribute, a receiving agent MUST ensure that all an EquivalentLabels attribute, a receiving agent MUST ensure that all
security-policy OIDs are unique in the security label or labels included in security-policy OIDs are unique in the security label or labels
the EquivalentLabels. Once the receiving agent selects the security label included in the EquivalentLabels. Once the receiving agent selects
(within the EquivalentLabels) to be used for processing, then the the security label (within the EquivalentLabels) to be used for
security-policy OID of the selected EquivalentLabels security label MUST be processing, then the security-policy OID of the selected
compared with the ESSSecurityLabel security-policy OID to ensure that they EquivalentLabels security label MUST be compared with the
are unique. ESSSecurityLabel security-policy OID to ensure that they are unique.
In the case that an ESSSecurityLabel attribute is not included in a In the case that an ESSSecurityLabel attribute is not included in a
signerInfo, then an EquivalentLabels attribute may still be included. For signerInfo, then an EquivalentLabels attribute may still be included.
example, in the Acme security policy, the absence of an ESSSecurityLabel For example, in the Acme security policy, the absence of an
could be defined to equate to a security label composed of the Acme ESSSecurityLabel could be defined to equate to a security label
security-policy OID and the "unmarked" security-classification. composed of the Acme security-policy OID and the "unmarked"
security-classification.
Note that equivalentLabels MUST NOT be used to convey security labels that Note that equivalentLabels MUST NOT be used to convey security labels
are semantically different from the ESSSecurityLabel included in the that are semantically different from the ESSSecurityLabel included in
signerInfos in the signedData. If an entity needs to apply a security label the signerInfos in the signedData. If an entity needs to apply a
that is semantically different from the ESSSecurityLabel, then it MUST security label that is semantically different from the
include the sematically different security label in an outer signedData ESSSecurityLabel, then it MUST include the sematically different
object that encapsulates the signedData object that includes the security label in an outer signedData object that encapsulates the
ESSSecurityLabel. signedData object that includes the ESSSecurityLabel.
If present, the equivalentLabels attribute MUST be an signed attribute; it If present, the equivalentLabels attribute MUST be a signed
MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET attribute; it MUST NOT be an unsigned attribute. [CMS] defines
OF Attribute. A signerInfo MUST NOT include multiple instances of the signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include
equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed multiple instances of the equivalentLabels attribute. CMS defines the
attributes to include attrValues SET OF AttributeValue. A equivalentLabels ASN.1 syntax for the signed attributes to include attrValues SET OF
attribute MUST only include a single instance of AttributeValue. There MUST AttributeValue. A equivalentLabels attribute MUST only include a
NOT be zero or multiple instances of AttributeValue present in the single instance of AttributeValue. There MUST NOT be zero or multiple
attrValues SET OF AttributeValue. instances of AttributeValue present in the attrValues SET OF
AttributeValue.
3.4.2 Processing Equivalent Labels 3.4.2 Processing Equivalent Labels
A receiving agent SHOULD process the ESSSecurityLabel before processing any A receiving agent SHOULD process the ESSSecurityLabel before
EquivalentLabels. If the policy in the ESSSecurityLabel is understood by processing any EquivalentLabels. If the policy in the
the receiving agent, it MUST process that label and MUST ignore all ESSSecurityLabel is understood by the receiving agent, it MUST
EquivalentLabels. process that label and MUST ignore all EquivalentLabels.
When processing an EquivalentLabels attribute, the receiving agent MUST When processing an EquivalentLabels attribute, the receiving agent
validate the signature on the EquivalentLabels attribute. A receiving agent MUST validate the signature on the EquivalentLabels attribute. A
MUST NOT act on an equivalentLabels attribute for which the signature could receiving agent MUST NOT act on an equivalentLabels attribute for
not be validated, and MUST NOT act on an equivalentLabels attribute unless which the signature could not be validated, and MUST NOT act on an
that attribute is signed by an entity trusted to translate the original equivalentLabels attribute unless that attribute is signed by an
eSSSecurityLabel values to the security policy included in the entity trusted to translate the original eSSSecurityLabel values to
equivalentLabels attribute. Determining who is allowed to specify the security policy included in the equivalentLabels attribute.
equivalence mappings is a local policy. If a message has more than one Determining who is allowed to specify equivalence mappings is a local
EquivalentLabels attribute, the receiving agent SHOULD process the first policy. If a message has more than one EquivalentLabels attribute,
one that it reads and validates that contains the security policy of the receiving agent SHOULD process the first one that it reads and
interest to the receiving agent. validates that contains the security policy of interest to the
receiving agent.
4. Mail List Management 4. Mail List Management
Sending agents must create recipient-specific data structures for each Sending agents must create recipient-specific data structures for
recipient of an encrypted message. This process can impair performance for each recipient of an encrypted message. This process can impair
messages sent to a large number of recipients. Thus, Mail List Agents performance for messages sent to a large number of recipients. Thus,
(MLAs) that can take a single message and perform the recipient-specific Mail List Agents (MLAs) that can take a single message and perform
encryption for every recipient are often desired. the recipient-specific encryption for every recipient are often
desired.
An MLA appears to the message originator as a normal message recipient, but An MLA appears to the message originator as a normal message
the MLA acts as a message expansion point for a Mail List (ML). The sender recipient, but the MLA acts as a message expansion point for a Mail
of a message directs the message to the MLA, which then redistributes the List (ML). The sender of a message directs the message to the MLA,
message to the members of the ML. This process offloads the per-recipient which then redistributes the message to the members of the ML. This
processing from individual user agents and allows for more efficient process offloads the per-recipient processing from individual user
management of large MLs. MLs are true message recipients served by MLAs agents and allows for more efficient management of large MLs. MLs are
that provide cryptographic and expansion services for the mailing list. true message recipients served by MLAs that provide cryptographic and
expansion services for the mailing list.
In addition to cryptographic handling of messages, secure mailing lists In addition to cryptographic handling of messages, secure mailing
also have to prevent mail loops. A mail loop is where one mailing list is a lists also have to prevent mail loops. A mail loop is where one
member of a second mailing list, and the second mailing list is a member of mailing list is a member of a second mailing list, and the second
the first. A message will go from one list to the other in a mailing list is a member of the first. A message will go from one
rapidly-cascading succession of mail that will be distributed to all other list to the other in a rapidly-cascading succession of mail that will
members of both lists. be distributed to all other members of both lists.
To prevent mail loops, MLAs use the mlExpansionHistory attribute of the To prevent mail loops, MLAs use the mlExpansionHistory attribute of
outer signature of a triple wrapped message. The mlExpansionHistory the outer signature of a triple wrapped message. The
attribute is essentially a list of every MLA that has processed the mlExpansionHistory attribute is essentially a list of every MLA that
message. If an MLA sees its own unique entity identifier in the list, it has processed the message. If an MLA sees its own unique entity
knows that a loop has been formed, and does not send the message to the identifier in the list, it knows that a loop has been formed, and
list again. does not send the message to the list again.
4.1 Mail List Expansion 4.1 Mail List Expansion
Mail list expansion processing is noted in the value of the Mail list expansion processing is noted in the value of the
mlExpansionHistory attribute, located in the signed attributes of the MLA's mlExpansionHistory attribute, located in the signed attributes of the
SignerInfo block. The MLA creates or updates the signed mlExpansionHistory MLA's SignerInfo block. The MLA creates or updates the signed
attribute value each time the MLA expands and signs a message for members mlExpansionHistory attribute value each time the MLA expands and
of a mail list. signs a message for members of a mail list.
The MLA MUST add an MLData record containing the MLA's identification The MLA MUST add an MLData record containing the MLA's identification
information, date and time of expansion, and optional receipt policy to the information, date and time of expansion, and optional receipt policy
end of the mail list expansion history sequence. If the mlExpansionHistory to the end of the mail list expansion history sequence. If the
attribute is absent, then the MLA MUST add the attribute and the current mlExpansionHistory attribute is absent, then the MLA MUST add the
expansion becomes the first element of the sequence. If the attribute and the current expansion becomes the first element of the
mlExpansionHistory attribute is present, then the MLA MUST add the current sequence. If the mlExpansionHistory attribute is present, then the
expansion information to the end of the existing MLExpansionHistory MLA MUST add the current expansion information to the end of the
sequence. Only one mlExpansionHistory attribute can be included in the existing MLExpansionHistory sequence. Only one mlExpansionHistory
signedAttributes of a SignerInfo. attribute can be included in the signedAttributes of a SignerInfo.
Note that if the mlExpansionHistory attribute is absent, then the recipient Note that if the mlExpansionHistory attribute is absent, then the
is a first tier message recipient. recipient is a first tier message recipient.
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and
SignerInfo may include signedAttributes. Therefore, a single SignedData each SignerInfo may include signedAttributes. Therefore, a single
object may include multiple SignerInfos, each SignerInfo having a SignedData object may include multiple SignerInfos, each SignerInfo
mlExpansionHistory attribute. For example, an MLA can send a signed message having a mlExpansionHistory attribute. For example, an MLA can send a
with two SignerInfos, one containing a DSS signature, the other containing signed message with two SignerInfos, one containing a DSS signature,
an RSA signature. the other containing an RSA signature.
If an MLA creates a SignerInfo that includes an mlExpansionHistory If an MLA creates a SignerInfo that includes an mlExpansionHistory
attribute, then all of the SignerInfos created by the MLA for that attribute, then all of the SignerInfos created by the MLA for that
SignedData object MUST include an mlExpansionHistory attribute, and the SignedData object MUST include an mlExpansionHistory attribute, and
value of each MUST be identical. Note that other agents might later add the value of each MUST be identical. Note that other agents might
SignerInfo attributes to the SignedData block, and those additional later add SignerInfo attributes to the SignedData block, and those
SignerInfos might not include mlExpansionHistory attributes. additional SignerInfos might not include mlExpansionHistory
attributes.
A recipient MUST verify the signature of the SignerInfo which covers the A recipient MUST verify the signature of the SignerInfo which covers
mlExpansionHistory attribute before processing the mlExpansionHistory, and the mlExpansionHistory attribute before processing the
MUST NOT process the mlExpansionHistory attribute unless the signature over mlExpansionHistory, and MUST NOT process the mlExpansionHistory
it has been verified. If a SignedData object has more than one SignerInfo attribute unless the signature over it has been verified. If a
that has an mlExpansionHistory attribute, the recipient MUST compare the SignedData object has more than one SignerInfo that has an
mlExpansionHistory attributes in all the SignerInfos that it has verified, mlExpansionHistory attribute, the recipient MUST compare the
and MUST NOT process the mlExpansionHistory attribute unless every verified mlExpansionHistory attributes in all the SignerInfos that it has
mlExpansionHistory attribute in the SignedData block is identical. If the verified, and MUST NOT process the mlExpansionHistory attribute
mlExpansionHistory attributes in the verified signerInfos are not all unless every verified mlExpansionHistory attribute in the SignedData
identical, then the receiving agent MUST stop processing the message and block is identical. If the mlExpansionHistory attributes in the
SHOULD notify the user or MLA administrator of this error condition. In the verified signerInfos are not all identical, then the receiving agent
mlExpansionHistory processing, SignerInfos that do not have an MUST stop processing the message and SHOULD notify the user or MLA
mlExpansionHistory attribute are ignored. administrator of this error condition. In the mlExpansionHistory
processing, SignerInfos that do not have an mlExpansionHistory
attribute are ignored.
4.1.1 Detecting Mail List Expansion Loops 4.1.1 Detecting Mail List Expansion Loops
Prior to expanding a message, the MLA examines the value of any existing Prior to expanding a message, the MLA examines the value of any
mail list expansion history attribute to detect an expansion loop. An existing mail list expansion history attribute to detect an expansion
expansion loop exists when a message expanded by a specific MLA for a loop. An expansion loop exists when a message expanded by a specific
specific mail list is redelivered to the same MLA for the same mail list. MLA for a specific mail list is redelivered to the same MLA for the
same mail list.
Expansion loops are detected by examining the mailListIdentifier field of Expansion loops are detected by examining the mailListIdentifier
each MLData entry found in the mail list expansion history. If an MLA finds field of each MLData entry found in the mail list expansion history.
its own identification information, then the MLA must discontinue expansion If an MLA finds its own identification information, then the MLA must
processing and should provide warning of an expansion loop to a human mail discontinue expansion processing and should provide warning of an
list administrator. The mail list administrator is responsible for expansion loop to a human mail list administrator. The mail list
correcting the loop condition. administrator is responsible for correcting the loop condition.
4.2 Mail List Agent Processing 4.2 Mail List Agent Processing
The first few paragraphs of this section provide a high-level description The first few paragraphs of this section provide a high-level
of MLA processing. The rest of the section provides a detailed description description of MLA processing. The rest of the section provides a
of MLA processing. detailed description of MLA processing.
MLA message processing depends on the structure of the S/MIME layers in the MLA message processing depends on the structure of the S/MIME layers
message sent to the MLA for expansion. In addition to sending triple in the message sent to the MLA for expansion. In addition to sending
wrapped messages to an MLA, an entity can send other types of messages to triple wrapped messages to an MLA, an entity can send other types of
an MLA, such as: messages to an MLA, such as:
- a single wrapped signedData or envelopedData message
- a double wrapped message (such as signed and enveloped, enveloped and
signed, or signed and signed, and so on)
- a quadruple-wrapped message (such as if a well-formed triple wrapped
message was sent through a gateway that added an outer SignedData layer)
In all cases, the MLA MUST parse all layers of the received message to - a single wrapped signedData or envelopedData message
determine if there are any signedData layers that include an - a double wrapped message (such as signed and enveloped, enveloped
eSSSecurityLabel signedAttribute. This may include decrypting an and signed, or signed and signed, and so on)
EnvelopedData layer to determine if an encapsulated SignedData layer - a quadruple-wrapped message (such as if a well-formed triple
includes an eSSSecurityLabel attribute. The MLA MUST fully process each wrapped message was sent through a gateway that added an outer
eSSSecurityLabel attribute found in the various signedData layers, SignedData layer)
including performing access control checks, before distributing the message
to the ML members. The details of the access control checks are beyond the
scope of this document. The MLA MUST verify the signature of the signerInfo
including the eSSSecurityLabel attribute before using it.
In all cases, the MLA MUST sign the message to be sent to the ML members in In all cases, the MLA MUST parse all layers of the received message
a new "outer" signedData layer. The MLA MUST add or update an to determine if there are any signedData layers that include an
mlExpansionHistory attribute in the "outer" signedData that it creates to eSSSecurityLabel signedAttribute. This may include decrypting an
document MLA processing. If there was an "outer" signedData layer included EnvelopedData layer to determine if an encapsulated SignedData layer
in the original message received by the MLA, then the MLA-created "outer" includes an eSSSecurityLabel attribute. The MLA MUST fully process
signedData layer MUST include each signed attribute present in the each eSSSecurityLabel attribute found in the various signedData
original "outer" signedData layer, unless the MLA explicitly replaces an layers, including performing access control checks, before
attribute (such as signingTime or mlExpansionHistory) with a new value. distributing the message to the ML members. The details of the access
control checks are beyond the scope of this document. The MLA MUST
verify the signature of the signerInfo including the eSSSecurityLabel
attribute before using it.
When an S/MIME message is received by the MLA, the MLA MUST first determine In all cases, the MLA MUST sign the message to be sent to the ML
which received signedData layer, if any, is the "outer" signedData layer. members in a new "outer" signedData layer. The MLA MUST add or update
To identify the received "outer" signedData layer, the MLA MUST verify the an mlExpansionHistory attribute in the "outer" signedData that it
signature and fully process the signedAttributes in each of the creates to document MLA processing. If there was an "outer"
outer signedData layers (working from the outside in) to determine if any signedData layer included in the original message received by the
of them either include an mlExpansionHistory attribute or encapsulate an MLA, then the MLA-created "outer" signedData layer MUST include each
envelopedData object. signed attribute present in the original "outer" signedData layer,
unless the MLA explicitly replaces an attribute (such as signingTime
or mlExpansionHistory) with a new value.
The MLA's search for the "outer" signedData layer is completed when it When an S/MIME message is received by the MLA, the MLA MUST first
finds one of the following: determine which received signedData layer, if any, is the "outer"
- the "outer" signedData layer that includes an mlExpansionHistory signedData layer. To identify the received "outer" signedData layer,
attribute or encapsulates an envelopedData object the MLA MUST verify the signature and fully process the
- an envelopedData layer signedAttributes in each of the outer signedData layers (working from
- the original content (that is, a layer that is neither envelopedData nor the outside in) to determine if any of them either include an
signedData). mlExpansionHistory attribute or encapsulate an envelopedData object.
If the MLA finds an "outer" signedData layer, then the MLA MUST perform The MLA's search for the "outer" signedData layer is completed when
the following steps: it finds one of the following:
1. Strip off all of the signedData layers that encapsulated the "outer" - the "outer" signedData layer that includes an mlExpansionHistory
signedData layer attribute or encapsulates an envelopedData object
- an envelopedData layer
- the original content (that is, a layer that is neither
envelopedData nor signedData).
2. Strip off the "outer" signedData layer itself (after remembering the If the MLA finds an "outer" signedData layer, then the MLA MUST
included signedAttributes) perform the following steps:
3. Expand the envelopedData (if present) 1. Strip off all of the signedData layers that encapsulated the
"outer" signedData layer
4. Sign the message to be sent to the ML members in a new "outer" 2. Strip off the "outer" signedData layer itself (after remembering
signedData layer that includes the signedAttributes (unless explicitly the included signedAttributes)
replaced) from the original, received "outer" signedData layer.
If the MLA finds an "outer" signedData layer that includes an 3. Expand the envelopedData (if present)
mlExpansionHistory attribute AND the MLA subsequently finds an
envelopedData layer buried deeper with the layers of the received message,
then the MLA MUST strip off all of the signedData layers down to the
envelopedData layer (including stripping off the original "outer"
signedData layer) and MUST sign the expanded envelopedData in a new "outer"
signedData layer that includes the signedAttributes (unless explicitly
replaced) from the original, received "outer" signedData layer.
If the MLA does not find an "outer" signedData layer AND does not find an 4. Sign the message to be sent to the ML members in a new "outer"
envelopedData layer, then the MLA MUST sign the original, received message signedData layer that includes the signedAttributes (unless
in a new "outer" signedData layer. If the MLA does not find an "outer" explicitly replaced) from the original, received "outer" signedData
signedData AND does find an envelopedData layer then it MUST expand the layer.
envelopedData layer, if present, and sign it in a new "outer" signedData
layer. If the MLA finds an "outer" signedData layer that includes an
mlExpansionHistory attribute AND the MLA subsequently finds an
envelopedData layer buried deeper with the layers of the received
message, then the MLA MUST strip off all of the signedData layers
down to the envelopedData layer (including stripping off the original
"outer" signedData layer) and MUST sign the expanded envelopedData in
a new "outer" signedData layer that includes the signedAttributes
(unless explicitly replaced) from the original, received "outer"
signedData layer.
If the MLA does not find an "outer" signedData layer AND does not
find an envelopedData layer, then the MLA MUST sign the original,
received message in a new "outer" signedData layer. If the MLA does
not find an "outer" signedData AND does find an envelopedData layer
then it MUST expand the envelopedData layer, if present, and sign it
in a new "outer" signedData layer.
4.2.1 Examples of Rule Processing 4.2.1 Examples of Rule Processing
The following examples help explain the rules above: The following examples help explain the rules above:
1) A message (S1(Original Content)) (where S = SignedData) is sent to the 1) A message (S1(Original Content)) (where S = SignedData) is sent to
MLA in which the signedData layer does not include an MLExpansionHistory the MLA in which the signedData layer does not include an
attribute. The MLA verifies and fully processes the signedAttributes in S1. MLExpansionHistory attribute. The MLA verifies and fully processes
The MLA decides that there is not an original, received "outer" signedData the signedAttributes in S1. The MLA decides that there is not an
layer since it finds the original content, but never finds an envelopedData original, received "outer" signedData layer since it finds the
and never finds an mlExpansionHistory attribute. The MLA calculates a new original content, but never finds an envelopedData and never finds
signedData layer, S2, resulting in the following message sent to the ML an mlExpansionHistory attribute. The MLA calculates a new
recipients: (S2(S1(Original Content))). The MLA includes an signedData layer, S2, resulting in the following message sent to
mlExpansionHistory attribute in S2. the ML recipients: (S2(S1(Original Content))). The MLA includes an
mlExpansionHistory attribute in S2.
2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in
none of the signedData layers includes an MLExpansionHistory attribute. The which none of the signedData layers includes an MLExpansionHistory
MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The attribute. The MLA verifies and fully processes the
MLA decides that there is not an original, received "outer" signedData signedAttributes in S3, S2 and S1. The MLA decides that there is
layer since it finds the original content, but never finds an envelopedData not an original, received "outer" signedData layer since it finds
and never finds an mlExpansionHistory attribute. The MLA calculates a new the original content, but never finds an envelopedData and never
signedData layer, S4, resulting in the following message sent to the ML finds an mlExpansionHistory attribute. The MLA calculates a new
recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an signedData layer, S4, resulting in the following
mlExpansionHistory attribute in S4. message sent to the ML recipients:
(S4(S3(S2(S1(Original Content))))). The MLA includes an
mlExpansionHistory attribute in S4.
3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent 3) A message (E1(S1(Original Content))) (where E = envelopedData) is
to the MLA in which S1 does not include an MLExpansionHistory attribute. sent to the MLA in which S1 does not include an MLExpansionHistory
The MLA decides that there is not an original, received "outer" signedData attribute. The MLA decides that there is not an original,
layer since it finds the E1 as the outer layer. The MLA expands the received "outer" signedData layer since it finds the E1 as the
recipientInformation in E1. The MLA calculates a new signedData layer, S2, outer layer. The MLA expands the recipientInformation in E1. The
resulting in the following message sent to the ML recipients: MLA calculates a new signedData layer, S2, resulting in the
(S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory following message sent to the ML recipients:
attribute in S2. (S2(E1(S1(Original Content)))). The MLA includes an
mlExpansionHistory attribute in S2.
4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in
includes an MLExpansionHistory attribute. The MLA verifies the signature which S2 includes an MLExpansionHistory attribute. The MLA verifies
and fully processes the signedAttributes in S2. The MLA finds the the signature and fully processes the signedAttributes in S2. The
mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" MLA finds the mlExpansionHistory attribute in S2, so it decides
signedData. The MLA remembers the signedAttributes included in S2 for later that S2 is the "outer" signedData. The MLA remembers the
inclusion in the new outer signedData that it applies to the message. The signedAttributes included in S2 for later inclusion in the new
MLA strips off S2. The MLA then expands the recipientInformation in E1 outer signedData that it applies to the message. The MLA strips off
(this invalidates the signature in S2 which is why it was stripped). The S2. The MLA then expands the recipientInformation in E1 (this
MLA calculates a new signedData layer, S3, resulting in the following invalidates the signature in S2 which is why it was stripped). The
message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA nMLA calculates a new signedData layer, S3, resulting in the
includes in S3 the attributes from S2 (unless it specifically replaces an following message sent to the ML recipients: (S3(E1(S1(Original
attribute value) including an updated mlExpansionHistory attribute. Content)))). The MLA includes in S3 the attributes from S2 (unless
it specifically replaces an attribute value) including an updated
mlExpansionHistory attribute.
5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
none of the signedData layers include an MLExpansionHistory attribute. The which none of the signedData layers include an MLExpansionHistory
MLA verifies the signature and fully processes the signedAttributes in S3 attribute. The MLA verifies the signature and fully processes the
and S2. When the MLA encounters E1, then it decides that S2 is the "outer" signedAttributes in S3 and S2. When the MLA encounters E1, then it
signedData since S2 encapsulates E1. The MLA remembers the signedAttributes decides that S2 is the "outer" signedData since S2 encapsulates E1.
included in S2 for later inclusion in the new outer signedData that it The MLA remembers the signedAttributes included in S2 for later
applies to the message. The MLA strips off S3 and S2. The MLA then expands inclusion in the new outer signedData that it applies to the
the recipientInformation in E1 (this invalidates the signatures in S3 and message. The MLA strips off S3 and S2. The MLA then expands the
S2 which is why they were stripped). The MLA calculates a new signedData recipientInformation in E1 (this invalidates the signatures in S3
layer, S4, resulting in the following message sent to the ML recipients: and S2 which is why they were stripped). The MLA calculates a new
(S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from signedData layer, S4, resulting in the following message sent to
S2 (unless it specifically replaces an attribute value) and includes a new the ML recipients: (S4(E1(S1(Original Content)))). The MLA
mlExpansionHistory attribute. includes in S4 the attributes from S2 (unless it specifically
replaces an attribute value) and includes a new
mlExpansionHistory attribute.
6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies which S3 includes an MLExpansionHistory attribute. In this case,
the signature and fully processes the signedAttributes in S3. The MLA finds the MLA verifies the signature and fully processes the
the mlExpansionHistory in S3, so it decides that S3 is the "outer" signedAttributes in S3. The MLA finds the mlExpansionHistory in S3,
signedData. The MLA remembers the signedAttributes included in S3 for later so it decides that S3 is the "outer" signedData. The MLA remembers
inclusion in the new outer signedData that it applies to the message. The the signedAttributes included in S3 for later inclusion in the new
MLA keeps on parsing encapsulated layers because it must determine if there outer signedData that it applies to the message. The MLA keeps on
are any eSSSecurityLabel attributes contained within. The MLA verifies the parsing encapsulated layers because it must determine if there are
signature and fully processes the signedAttributes in S2. When the MLA any eSSSecurityLabel attributes contained within. The MLA verifies
encounters E1, then it strips off S3 and S2. The MLA then expands the the signature and fully processes the signedAttributes in S2. When
recipientInformation in E1 (this invalidates the signatures in S3 and S2 the MLA encounters E1, then it strips off S3 and S2. The MLA then
which is why they were stripped). The MLA calculates a new signedData expands the recipientInformation in E1 (this invalidates the
layer, S4, resulting in the following message sent to the ML recipients: signatures in S3 and S2 which is why they were stripped). The MLA
(S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from calculates a new signedData layer, S4, resulting in the following
S3 (unless it specifically replaces an attribute value) including an message sent to the ML recipients: (S4(E1(S1(Original Content)))).
updated mlExpansionHistory attribute. The MLA includes in S4 the attributes from S3 (unless it
specifically replaces an attribute value) including an updated
mlExpansionHistory attribute.
4.2.3 Processing Choices 4.2.3 Processing Choices
The processing used depends on the type of the outermost layer of the The processing used depends on the type of the outermost layer of the
message. There are three cases for the type of the outermost data: message. There are three cases for the type of the outermost data:
- EnvelopedData
- SignedData - EnvelopedData
- data - SignedData
- data
4.2.3.1 Processing for EnvelopedData 4.2.3.1 Processing for EnvelopedData
1. The MLA locates its own RecipientInfo and uses the information it 1. The MLA locates its own RecipientInfo and uses the information it
contains to obtain the message key. contains to obtain the message key.
2. The MLA removes the existing recipientInfos field and replaces it with a 2. The MLA removes the existing recipientInfos field and replaces it
new recipientInfos value built from RecipientInfo structures created for with a new recipientInfos value built from RecipientInfo
each member of the mailing list. The MLA also removes the existing structures
originatorInfo field and replaces it with a new originatorInfo value built created for each member of the mailing list. The MLA also removes
from information describing the MLA. the existing originatorInfo field and replaces it with a new
originatorInfo value built from information describing the MLA.
3. The MLA encapsulates the expanded encrypted message in a SignedData 3. The MLA encapsulates the expanded encrypted message in a
block, adding an mlExpansionHistory attribute as described in the "Mail SignedData block, adding an mlExpansionHistory attribute as
List Expansion" section to document the expansion. described in the "Mail List Expansion" section to document the
expansion.
4. The MLA signs the new message and delivers the updated message to mail 4. The MLA signs the new message and delivers the updated message to
list members to complete MLA processing. mail list members to complete MLA processing.
4.2.3.2 Processing for SignedData 4.2.3.2 Processing for SignedData
MLA processing of multi-layer messages depends on the type of data in each MLA processing of multi-layer messages depends on the type of data in
of the layers. Step 3 below specifies that different processing will take each of the layers. Step 3 below specifies that different processing
place depending on the type of CMS message that has been signed. That is, will take place depending on the type of CMS message that has been
it needs to know the type of data at the next inner layer, which may or may signed. That is, it needs to know the type of data at the next inner
not be the innermost layer. layer, which may or may not be the innermost layer.
1. The MLA verifies the signature value found in the outermost SignedData 1. The MLA verifies the signature value found in the outermost
layer associated with the signed data. MLA processing of the message SignedData layer associated with the signed data. MLA
terminates if the message signature is invalid. processing of the message terminates if the message signature
is invalid.
2. If the outermost SignedData layer includes an signed mlExpansionHistory 2. If the outermost SignedData layer includes a signed
attribute, the MLA checks for an expansion loop as described in the mlExpansionHistory attribute, the MLA checks for an expansion loop
"Detecting Mail List Expansion Loops" section, then go to step 3. If the as described in the "Detecting Mail List Expansion Loops" section,
outermost SignedData layer does not include an signed mlExpansionHistory then go to step 3. If the outermost SignedData layer does not
attribute, the MLA signs the whole message (including this outermost include a signed mlExpansionHistory attribute, the MLA signs the
SignedData layer that doesn't have an mlExpansionHistory attribute), and whole message (including this outermost SignedData layer that
delivers the updated message to mail list members to complete MLA doesn't have an mlExpansionHistory attribute), and delivers the
processing. updated message to mail list members to complete MLA processing.
3. Determine the type of the data that has been signed. That is, look at 3. Determine the type of the data that has been signed. That is, look
the type of data on the layer just below the SignedData, which may or may at the type of data on the layer just below the SignedData, which
not be the "innermost" layer. Based on the type of data, perform either may or may not be the "innermost" layer. Based on the type of data,
step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or
types). step 3.3 (all other types).
3.1. If the signed data is EnvelopedData, the MLA performs expansion 3.1. If the signed data is EnvelopedData, the MLA performs
processing of the encrypted message as described previously. Note that expansion processing of the encrypted message as
this process invalidates the signature value in the outermost described previously. Note that this process invalidates the
SignedData layer associated with the original encrypted message. signature value in the outermost SignedData layer associated
Proceed to section 3.2 with the result of the expansion. with the original encrypted message. Proceed to section 3.2
with the result of the expansion.
3.2. If the signed data is SignedData, or is the result of expanding an 3.2. If the signed data is SignedData, or is the result of
EnvelopedData block in step 3.1: expanding an EnvelopedData block in step 3.1:
3.2.1. The MLA strips the existing outermost SignedData layer after 3.2.1. The MLA strips the existing outermost SignedData layer
remembering the value of the mlExpansionHistory and all other after remembering the value of the mlExpansionHistory
signed attributes in that layer, if present. and all other signed attributes in that layer, if
present.
3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 3.2.2. If the signed data is EnvelopedData (from step 3.1),
encapsulates the expanded encrypted message in a new outermost the MLA encapsulates the expanded encrypted message
SignedData layer. On the other hand, if the signed data is in a new outermost SignedData layer. On the other
SignedData (from step 3.2), the MLA encapsulates the signed data in hand, if the signed data is SignedData (from step
a new outermost SignedData layer. 3.2), the MLA encapsulates the signed data in a new
outermost SignedData layer.
3.2.3. The outermost signedData layer created by the MLA replaces 3.2.3. The outermost signedData layer created by the MLA
the original outermost signedData layer. The MLA MUST create an replaces the original outermost signedData layer. The
signed attribute list for the new outermost signedData layer which MLA MUST create an signed attribute list for the new
MUST include each signed attribute present in the original outermost signedData layer which MUST include each
outermost signedData layer, unless the MLA explicitly replaces one signed attribute present in the original outermost
or more particular attributes with new value. A special case is the signedData layer, unless the MLA explicitly replaces
mlExpansionHistory attribute. The MLA MUST add an one or more particular attributes with new value. A
mlExpansionHistory signed attribute to the outer signedData layer special case is the mlExpansionHistory attribute. The
as follows: MLA MUST add an mlExpansionHistory signed attribute
to the outer signedData layer as follows:
3.2.3.1. If the original outermost SignedData layer included an 3.2.3.1. If the original outermost SignedData layer
mlExpansionHistory attribute, the attribute's value is copied included an mlExpansionHistory attribute, the
and updated with the current ML expansion information as attribute's value is copied and updated with the
described in the "Mail List Expansion" section. current ML expansion information as described in
the "Mail List Expansion" section.
3.2.3.2. If the original outermost SignedData layer did not 3.2.3.2. If the original outermost SignedData layer did
include an mlExpansionHistory attribute, a new attribute value not include an mlExpansionHistory attribute, a
is created with the current ML expansion information as new attribute value is created with the current
described in the "Mail List Expansion" section. ML expansion information as described in the
"Mail List Expansion" section.
3.3. If the signed data is not EnvelopedData or SignedData: 3.3. If the signed data is not EnvelopedData or SignedData:
3.3.1. The MLA encapsulates the received signedData object in an 3.3.1. The MLA encapsulates the received signedData object in
outer SignedData object, and adds an mlExpansionHistory attribute an outer SignedData object, and adds an
to the outer SignedData object containing the current ML expansion mlExpansionHistory attribute to the outer SignedData
information as described in the "Mail List Expansion" section. object containing the current ML expansion information
as described in the "Mail List Expansion" section.
4. The MLA signs the new message and delivers the updated message to mail 4. The MLA signs the new message and delivers the updated message to
list members to complete MLA processing. mail list members to complete MLA processing.
A flow chart for the above steps would be: A flow chart for the above steps would be:
1. Has a valid signature? 1. Has a valid signature?
YES -> 2. YES -> 2.
NO -> STOP. NO -> STOP.
2. Does outermost SignedData layer contain mlExpansionHistory? 2. Does outermost SignedData layer contain mlExpansionHistory?
YES -> Check it, then -> 3. YES -> Check it, then -> 3.
NO -> Sign message (including outermost SignedData that NO -> Sign message (including outermost SignedData that
doesn't have mlExpansionHistory), deliver it, STOP. doesn't have mlExpansionHistory), deliver it, STOP.
3. Check type of data just below outermost SignedData. 3. Check type of data just below outermost SignedData.
EnvelopedData -> 3.1.
SignedData -> 3.2. EnvelopedData -> 3.1.
all others -> 3.3. SignedData -> 3.2.
3.1. Expand the encrypted message, then -> 3.2. all others -> 3.3.
3.2. -> 3.2.1. 3.1. Expand the encrypted message, then -> 3.2.
3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory 3.2. -> 3.2.1.
and other signed attributes, then -> 3.2.2. 3.2.1. Strip outermost SignedData layer, note value of
3.2.2. Encapsulate in new signature, then -> 3.2.3. mlExpansionHistory and other signed attributes, then -> 3.2.2.
3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? 3.2.2. Encapsulate in new signature, then -> 3.2.3.
YES -> copy the old mlExpansionHistory values, then -> 4. 3.2.3. Create new signedData layer. Was there an old
NO -> create new mlExpansionHistory value, then -> 4. mlExpansionHistory?
3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory YES -> copy the old mlExpansionHistory values, then -> 4.
attribute, then -> 4. NO -> create new mlExpansionHistory value, then -> 4.
4. Sign message, deliver it, STOP. 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
attribute, then -> 4.
4. Sign message, deliver it, STOP.
4.2.3.3 Processing for data 4.2.3.3 Processing for data
1. The MLA encapsulates the message in a SignedData layer, and adds an 1. The MLA encapsulates the message in a SignedData layer, and adds an
mlExpansionHistory attribute containing the current ML expansion mlExpansionHistory attribute containing the current ML expansion
information as described in the "Mail List Expansion" section. information as described in the "Mail List Expansion" section.
2. The MLA signs the new message and delivers the updated message to mail 2. The MLA signs the new message and delivers the updated message to
list members to complete MLA processing. mail list members to complete MLA processing.
4.3 Mail List Agent Signed Receipt Policy Processing 4.3 Mail List Agent Signed Receipt Policy Processing
If a mailing list (B) is a member of another mailing list (A), list B often If a mailing list (B) is a member of another mailing list (A), list B
needs to propagate forward the mailing list receipt policy of A. As a often needs to propagate forward the mailing list receipt policy of
general rule, a mailing list should be conservative in propagating forward A. As a general rule, a mailing list should be conservative in
the mailing list receipt policy because the ultimate recipient need only propagating forward the mailing list receipt policy because the
process the last item in the ML expansion history. The MLA builds the ultimate recipient need only process the last item in the ML
expansion history to meet this requirement. expansion history. The MLA builds the expansion history to meet this
requirement.
The following table describes the outcome of the union of mailing list A's The following table describes the outcome of the union of mailing
policy (the rows in the table) and mailing list B's policy (the columns in list A's policy (the rows in the table) and mailing list B's policy
the table). (the columns in the table).
| B's policy | B's policy
A's policy | none insteadOf inAdditionTo missing A's policy | none insteadOf inAdditionTo missing
none | none none none none -----------------------------------------------------------------------
insteadOf | none insteadOf(B) *1 insteadOf(A) none | none none none none
inAdditionTo | none insteadOf(B) *2 inAdditionTo(A) insteadOf | none insteadOf(B) *1 insteadOf(A)
missing | none insteadOf(B) inAdditionTo(B) missing inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
missing | none insteadOf(B) inAdditionTo(B) missing
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
4.4 Mail List Expansion History Syntax 4.4 Mail List Expansion History Syntax
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If An mlExpansionHistory attribute value has ASN.1 type
there are more than ub-ml-expansion-history mailing lists in the sequence, MLExpansionHistory. If there are more than ub-ml-expansion-history
the receiving agent should provide notification of the error to a human mailing lists in the sequence, the receiving agent should provide
mail list administrator. The mail list administrator is responsible for notification of the error to a human mail list administrator. The
correcting the overflow condition. mail list administrator is responsible for correcting the overflow
condition.
MLExpansionHistory ::= SEQUENCE MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData contains the expansion history describing each MLA that has MLData contains the expansion history describing each MLA that has
processed a message. As an MLA distributes a message to members of an ML, processed a message. As an MLA distributes a message to members of an
the MLA records its unique identifier, date and time of expansion, and ML, the MLA records its unique identifier, date and time of
receipt policy in an MLData structure. expansion, and receipt policy in an MLData structure.
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE { EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier } subjectKeyIdentifier SubjectKeyIdentifier }
The receipt policy of the ML can withdraw the originator's request
for the return of a signed receipt. However, if the originator of the
message has not requested a signed receipt, the MLA cannot request a
signed receipt. In the event that a ML's signed receipt policy
supersedes the originator's request for signed receipts, such that
the originator will not receive any signed receipts, then the MLA MAY
inform the originator of that fact.
The receipt policy of the ML can withdraw the originator's request for the When present, the mlReceiptPolicy specifies a receipt policy that
return of a signed receipt. However, if the originator of the message has supersedes the originator's request for signed receipts. The policy
not requested a signed receipt, the MLA cannot request a signed receipt. In can be one of three possibilities: receipts MUST NOT be returned
the event that a ML's signed receipt policy supersedes the originator's (none); receipts should be returned to an alternate list of
request for signed receipts, such that the originator will not receive any recipients, instead of to the originator (insteadOf); or receipts
signed receipts, then the MLA MAY inform the originator of that fact. should be returned to a list of recipients in addition to the
originator (inAdditionTo).
When present, the mlReceiptPolicy specifies a receipt policy that
supersedes the originator's request for signed receipts. The policy can be
one of three possibilities: receipts MUST NOT be returned (none); receipts
should be returned to an alternate list of recipients, instead of to the
originator (insteadOf); or receipts should be returned to a list of
recipients in addition to the originator (inAdditionTo).
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
5. Signing Certificate Attribute 5. Signing Certificate Attribute
Concerns have been raised over the fact that the certificate which the Concerns have been raised over the fact that the certificate which
signer of a CMS SignedData object desired to be bound into the verification the signer of a CMS SignedData object desired to be bound into the
process of the SignedData object is not cryptographically bound into the verification process of the SignedData object is not
signature itself. This section addresses this issue by creating a new cryptographically bound into the signature itself. This section
attribute to be placed in the signed attributes section of a SignerInfo addresses this issue by creating a new attribute to be placed in the
object. signed attributes section of a SignerInfo object.
This section also presents a description of a set of possible attacks This section also presents a description of a set of possible attacks
dealing with the substitution of one certificate to verify the signature dealing with the substitution of one certificate to verify the
for the desired certificate. A set of ways for preventing or addressing signature for the desired certificate. A set of ways for preventing
these attacks is presented to deal with the simplest of the attacks. or addressing these attacks is presented to deal with the simplest of
the attacks.
Attribute certificates can be used as part of a signature verification Authorization information can be used as part of a signature
process. There is no way in CMS to include the list of attribute verification process. This information can be carried in either
certificates to be used in the verification process. The set of attribute attribute certificates and other public key certificates. The signer
certificates used in the signature verification process needs to have the needs to have the ability to restrict the set of certificates used in
ability for the signer to restrict the set of certificates. This the signature verification process, and information needs to be
information needs to be encoded in a manner that is covered by the encoded so that is covered by the signature on the SignedData object.
signature on the SignedData object. The methods in this section allows for The methods in this section allow for the set of authorization
the set of attribute certificates to be listed as part of the signing certificates to be listed as part of the signing certificate
certificate attribute. attribute.
Explicit certificate policies can also be used as part of a signature Explicit certificate policies can also be used as part of a signature
verification process. If a signer desires to state an explicit certificate verification process. If a signer desires to state an explicit
policy that should be used when validating the signature, that policy needs certificate policy that should be used when validating the signature,
to be cryptographically bound into the signing process. The methods that policy needs to be cryptographically bound into the signing
described in this section allows for a set of certificate policy statements process. The methods described in this section allows for a set of
to be listed as part of the signing certificate attribute. certificate policy statements to be listed as part of the signing
certificate attribute.
5.1. Attack Descriptions 5.1. Attack Descriptions
At least three different attacks can be launched against a possible At least three different attacks can be launched against a possible
signature verification process by replacing the certificate or certficates signature verification process by replacing the certificate or
used in the signature verification process. certficates used in the signature verification process.
5.1.1 Substitution Attack Description 5.1.1 Substitution Attack Description
The first attack deals with simple substitution of one certificate for The first attack deals with simple substitution of one certificate
another certificate. In this attack, the issuer and serial number in the for another certificate. In this attack, the issuer and serial number
SignerInfo is modified to refer to a new certificate. This new certificate in the SignerInfo is modified to refer to a new certificate. This new
is used during the signature verification process. certificate is used during the signature verification process.
The first version of this attack is a simple denial of service attack where The first version of this attack is a simple denial of service attack
an invalid certificate is substituted for the valid certificate. This where an invalid certificate is substituted for the valid
renders the message unverifiable, as the public key in the certificate no certificate. This renders the message unverifiable, as the public key
longer matches the private key used to sign the message. in the certificate no longer matches the private key used to sign the
message.
The second version is a substitution of one valid certificate for the The second version is a substitution of one valid certificate for the
original valid certificate where the public keys in the certificates match. original valid certificate where the public keys in the certificates
This allows the signature to be validated under potentially different match. This allows the signature to be validated under potentially
certificate constraints than the originator of the message intended. different certificate constraints than the originator of the message
intended.
5.1.2 Reissue of Certificate Description 5.1.2 Reissue of Certificate Description
The second attack deals with a certificate authority (CA) re-issuing the The second attack deals with a certificate authority (CA) re-issuing
signing certificate (or potentially one of its certificates). This attack the signing certificate (or potentially one of its certificates).
may start becoming more frequent as Certificate Authorities reissue their This attack may start becoming more frequent as Certificate
own root certificates, or as certificate authorities change policies in the Authorities reissue their own root certificates, or as certificate
certificate while reissuing their root certificates. This problem also authorities change policies in the certificate while reissuing their
occurs when cross certificates (with potentially different restrictions) root certificates. This problem also occurs when cross certificates
are used in the process of verifying a signature. (with potentially different restrictions) are used in the process of
verifying a signature.
5.1.3 Rogue Duplicate CA Description 5.1.3 Rogue Duplicate CA Description
The third attack deals with a rogue entity setting up a certificate The third attack deals with a rogue entity setting up a certificate
authority that attempts to duplicate the structure of an existing CA. authority that attempts to duplicate the structure of an existing CA.
Specifically, the rogue entity issues a new certificate with the same Specifically, the rogue entity issues a new certificate with the same
public keys as the signer used, but signed by the rogue entity's private public keys as the signer used, but signed by the rogue entity's
key. private key.
5.2 Attack Responses 5.2 Attack Responses
This document does not attempt to solve all of the above attacks; however, This document does not attempt to solve all of the above attacks;
a brief description of responses to each of the attacks is given in this however, a brief description of responses to each of the attacks is
section. given in this section.
5.2.1 Substitution Attack Response 5.2.1 Substitution Attack Response
The denial of service attack cannot be prevented. After the certificate The denial of service attack cannot be prevented. After the
identifier has been modified in transit, no verification of the signature certificate identifier has been modified in transit, no verification
is possible. There is also no way to automatically identify the attack of the signature is possible. There is also no way to automatically
because it is indistinguishable from a message corruption. identify the attack because it is indistinguishable from a message
corruption.
The substitution of a valid certificate can be responded to in two The substitution of a valid certificate can be responded to in two
different manners. The first is to make a blanket statement that the use of different manners. The first is to make a blanket statement that the
the same public key in two different certificates is bad practice and has use of the same public key in two different certificates is bad
to be avoided. In practice, there is no practical way to prevent users from practice and has to be avoided. In practice, there is no practical
getting new certificates with the same public keys, and it should be way to prevent users from getting new certificates with the same
assumed that they will do this. Section 5.4 provides a new attribute that public keys, and it should be assumed that they will do this. Section
can be included in the SignerInfo signed attributes. This binds the correct 5.4 provides a new attribute that can be included in the SignerInfo
certificate identifier into the signature. This will convert the attack signed attributes. This binds the correct certificate identifier into
from a potentially successful one to simply a denial of service attack. the signature. This will convert the attack from a potentially
successful one to simply a denial of service attack.
5.2.2 Reissue of Certificate Response 5.2.2 Reissue of Certificate Response
A CA should never reissue a certificate with different attributes. A CA should never reissue a certificate with different attributes.
Certificate Authorities that do so are following poor practices and cannot Certificate Authorities that do so are following poor practices and
be relied on. Using the hash of the certificate as the reference to the cannot be relied on. Using the hash of the certificate as the
certificate prevents this attach for end-entity certificates. reference to the certificate prevents this attack for end-entity
certificates.
Preventing the attack based on reissuing of CA certificates would require a Preventing the attack based on reissuing of CA certificates would
substantial change to the usage of the signingCertificate attribute require a substantial change to the usage of the signingCertificate
presented in section 5.4. It would require that ESSCertIDs would need to be attribute presented in section 5.4. It would require that ESSCertIDs
included in the attribute to represent the issuer certificates in the would need to be included in the attribute to represent the issuer
signer's certification path. This presents problems when the relying party certificates in the signer's certification path. This presents
is using a cross-certificate as part of its authentication process, and problems when the relying party is using a cross-certificate as part
this certificate does not appear on the list of certificates. The problems of its authentication process, and this certificate does not appear
outside of a closed PKI make the addition of this information prone to on the list of certificates. The problems outside of a closed PKI
error, possibly causing the rejection of valid chains. make the addition of this information prone to error, possibly
causing the rejection of valid chains.
5.2.3 Rogue Duplicate CA Response 5.2.3 Rogue Duplicate CA Response
The best method of preventing this attack is to avoid trusting the rogue The best method of preventing this attack is to avoid trusting the
CA. The use of the hash to identify certificates prevents the use of rogue CA. The use of the hash to identify certificates prevents the
end-entity certificates from the rogue authority. However the only true way use of end-entity certificates from the rogue authority. However the
to prevent this attack is to never trust the rogue CA. only true way to prevent this attack is to never trust the rogue CA.
5.3 Related Signature Verification Context 5.3 Related Signature Verification Context
Some applications require that additional information be used as part of Some applications require that additional information be used as part
the signature validation process. In particular, attribute certificates and of the signature validation process. In particular, authorization
policy identifiers provide additional information about the abilities and information from attribute certificates and other public key
intent of the signer. The signing certificate attribute described in certificates or policy identifiers provide additional information
Section 5.4 provides the ability to bind this context information as part about the abilities and intent of the signer. The signing certificate
of the signature. attribute described in Section 5.4 provides the ability to bind this
context information as part of the signature.
5.3.1 Attribute Certificates 5.3.1 Authorization Information
Some applications require that attribute certificates be validated. This Some applications require that authorization information found in
validation requires that the application be able to find the correct attribute certificates and/or other public key certificates be
attribute certificates to perform the verification process; however there validated. This validation requires that the application be able to
is no list of attribute certificates in a SignerInfo object. The sender has find the correct certificates to perform the verification process;
the ability to include a set of attribute certificates in a SignedData however there is no list of the certificates to used in a SignerInfo
object. The receiver has the ability to retrieve attribute certificates object. The sender has the ability to include a set of attribute
from a directory service. There are some circumstances where the signer may certificates and public key certificates in a SignedData object. The
wish to limit the set of attribute certificates that may be used in receiver has the ability to retrieve attribute certificates and
verifying a signature. It is useful to be able to list the set of attribute public key certificates from a directory service. There are some
certificates the signer wants the recipient to use in validating the circumstances where the signer may wish to limit the set of
signature. certificates that may be used in verifying a signature. It is useful
to be able to list the set of certificates the signer wants the
recipient to use in validating the signature.
5.3.2 Policy Information 5.3.2 Policy Information
A related aspect of the certificate binding is the issue of multiple A related aspect of the certificate binding is the issue of multiple
certification paths. In some instances, the semantics of a certificate in certification paths. In some instances, the semantics of a
its use with a message may depend on the Certificate Authorities and certificate in its use with a message may depend on the Certificate
policies that apply. To address this issue, the signer may also wish to Authorities and policies that apply. To address this issue, the
bind that context under the signature. While this could be done by either signer may also wish to bind that context under the signature. While
signing the complete certification path or a policy ID, only a binding for this could be done by either signing the complete certification path
the policy ID is described here. or a policy ID, only a binding for the policy ID is described here.
5.4 Signing Certificate Attribute Definition 5.4 Signing Certificate Attribute Definition
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set of substitution and re-issue attacks, and to allow for a restricted set
attribute certificates to be used in verifying a signature. of authorization certificates to be used in verifying a signature.
The definition of SigningCertificate is The definition of SigningCertificate is
SigningCertificate ::= SEQUENCE { SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID, certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 } smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate identifiers The first certificate identified in the sequence of certificate
MUST be the certificate used to verify the signature. The encoding of the identifiers MUST be the certificate used to verify the signature. The
ESSCertID for this certificate SHOULD include the issuerSerial field. If encoding of the ESSCertID for this certificate SHOULD include the
other constraints ensure that issuerAndSerialNumber will be present in the issuerSerial field. If other constraints ensure that
SignerInfo, the issuerSerial field MAY be omitted. The certificate issuerAndSerialNumber will be present in the SignerInfo, the
identified is used during the signature verification process. If the hash issuerSerial field MAY be omitted. The certificate identified is used
of the certificate does not match the certificate used to verify the during the signature verification process. If the hash of the
signature, the signature MUST be considered invalid. certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of ESSCertIDs, the If more than one certificate is present in the sequence of
certificates after the first one limit the set of authorization ESSCertIDs, the certificates after the first one limit the set of
certificates that are used during signature validation. Authorization authorization certificates that are used during signature validation.
certificates can be either attribute certificates or normal certificates. Authorization certificates can be either attribute certificates or
The issuerSerial SHOULD be present in these certificates, unless the client normal certificates. The issuerSerial field (in the ESSCertID
who is validating the signature is expected to have easy access to all the structure) SHOULD be present for these certificates, unless the
certificates required for validation. If only the signing certificate is client who is validating the signature is expected to have easy
present in the sequence, there are no restrictions on the set of access to all the certificates requred for validation. If only the
authorization certificates used in validating the signature. signing certificate is present in the sequence, there are no
restrictions on the set of authorization certificates used in
validating the signature.
The sequence of policy information terms identifies those certificate The sequence of policy information terms identifies those certificate
policies that the signer asserts apply to the certificate, and under which policies that the signer asserts apply to the certificate, and under
the certificate should be relied upon. This value suggests a policy value which the certificate should be relied upon. This value suggests a
to be used in the relying party's certification path validation. policy value to be used in the relying party's certification path
validation.
If present, the SigningCertificate attribute MUST be a signed attribute; it If present, the SigningCertificate attribute MUST be a signed
MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF attribute; it MUST NOT be an unsigned attribute. CMS defines
Attribute. A SignerInfo MUST NOT include multiple instances of the SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include
SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed multiple instances of the SigningCertificate attribute. CMS defines
attributes to include attrValues SET OF AttributeValue. A the ASN.1 syntax for the signed attributes to include attrValues SET
SigningCertificate attribute MUST include only a single instance of OF AttributeValue. A SigningCertificate attribute MUST include only a
AttributeValue. There MUST NOT be zero or multiple instances of single instance of AttributeValue. There MUST NOT be zero or multiple
AttributeValue present in the attrValues SET OF AttributeValue. instances of AttributeValue present in the attrValues SET OF
AttributeValue.
5.4.1 Certificate Identification 5.4.1 Certificate Identification
The best way to identify certificates is an often-discussed issue. [CERT] The best way to identify certificates is an often-discussed issue.
has imposed a restriction for SignedData objects that the issuer DN must be [CERT] has imposed a restriction for SignedData objects that the
present in all signing certificates. The issuer/serial number pair is issuer DN must be present in all signing certificates. The
therefore sufficient to identify the correct signing certificate. This issuer/serial number pair is therefore sufficient to identify the
information is already present, as part of the SignerInfo object, and correct signing certificate. This information is already present, as
duplication of this information would be unfortunate. A hash of the entire part of the SignerInfo object, and duplication of this information
certificate serves the same function (allowing the receiver to verify that would be unfortunate. A hash of the entire certificate serves the
the same certificate is being used as when the message was signed), is same function (allowing the receiver to verify that the same
smaller, and permits a detection of the simple substitution attacks. certificate is being used as when the message was signed), is
smaller, and permits a detection of the simple substitution attacks.
Attribute certificates do not have an issuer/serial number pair represented Attribute certificates and additional public key certificates
anywhere in a SignerInfo object. When an attribute certificate is not containing authorization information do not have an issuer/serial
included in the SignedData object, it becomes much more difficult to get number pair represented anywhere in a SignerInfo object. When an
the correct set of certificates based only on a hash of the certificate. attribute certificate or an additional public key certificate is not
For this reason, attribute certificates are identified by the IssuerSerial included in the SignedData object, it becomes much more difficult to
object. get the correct set of certificates based only on a hash of the
certificate. For this reason, these certificates SHOULD be identified
by the IssuerSerial object.
This document defines a certificate identifier as: This document defines a certificate identifier as:
ESSCertID ::= SEQUENCE { ESSCertID ::= SEQUENCE {
certHash Hash, certHash Hash,
issuerSerial IssuerSerial OPTIONAL issuerSerial IssuerSerial OPTIONAL
} }
Hash ::= OCTET STRING -- SHA1 hash of entire certificate Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
serialNumber CertificateSerialNumber serialNumber CertificateSerialNumber
} }
When creating an ESSCertID, the certHash is computed over the entire DER When creating an ESSCertID, the certHash is computed over the entire
encoded certificate including the signature. The issuerSerial would DER encoded certificate including the signature. The issuerSerial
normally be present unless the value can be inferred from other would normally be present unless the value can be inferred from other
information. information.
When encoding IssuerSerial, serialNumber is the serial number that uniquely When encoding IssuerSerial, serialNumber is the serial number that
identifies the certificate. For non-attribute certificates, the issuer MUST uniquely identifies the certificate. For non-attribute certificates,
contain only the issuer name from the certificate encoded in the the issuer MUST contain only the issuer name from the certificate
directoryName choice of GeneralNames. For attribute certificates, the encoded in the directoryName choice of GeneralNames. For attribute
issuer MUST contain the issuer name field from the attribute certificate. certificates, the issuer MUST contain the issuer name field from the
attribute certificate.
6. Security Considerations 6. Security Considerations
All security considerations from [CMS] and [SMIME3] apply to applications All security considerations from [CMS] and [SMIME3] apply to
that use procedures described in this document. applications that use procedures described in this document.
As stated in Section 2.3, a recipient of a receipt request must not send As stated in Section 2.3, a recipient of a receipt request must not
back a reply if it cannot validate the signature. Similarly, if there send back a reply if it cannot validate the signature. Similarly, if
conflicting receipt requests in a message, the recipient must not send back there conflicting receipt requests in a message, the recipient must
receipts, since an attacker may have inserted the conflicting request. not send back receipts, since an attacker may have inserted the
Sending a signed receipt to an unvalidated sender can expose information conflicting request. Sending a signed receipt to an unvalidated
about the recipient that it may not want to expose to unknown senders. sender can expose information about the recipient that it may not
want to expose to unknown senders.
Senders of receipts should consider encrypting the receipts to prevent a Senders of receipts should consider encrypting the receipts to
passive attacker from gleaning information in the receipts. prevent a passive attacker from gleaning information in the receipts.
Senders must not rely on recipients' processing software to correctly Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that adding a process security labels. That is, the sender cannot assume that
security label to a message will prevent recipients from viewing messages adding a security label to a message will prevent recipients from
the sender doesn't want them to view. It is expected that there will be viewing messages the sender doesn't want them to view. It is expected
many S/MIME clients that will not understand security labels but will still that there will be many S/MIME clients that will not understand
display a labelled message to a recipient. security labels but will still display a labelled message to a
recipient.
A receiving agent that processes security labels must handle the content of A receiving agent that processes security labels must handle the
the messages carefully. If the agent decides not to show the message to the content of the messages carefully. If the agent decides not to show
intended recipient after processing the security label, the agent must take the message to the intended recipient after processing the security
care that the recipient does not accidentally see the content at a later label, the agent must take care that the recipient does not
time. For example, if an error response sent to the originator contains the accidentally see the content at a later time. For example, if an
content that was hidden from the recipient, and that error response bounces error response sent to the originator contains the content that was
back to the sender due to addressing errors, the original recipient can hidden from the recipient, and that error response bounces back to
possibly see the content since it is unlikely that the bounce message will the sender due to addressing errors, the original recipient can
have the proper security labels. possibly see the content since it is unlikely that the bounce message
will have the proper security labels.
A man-in-the-middle attack can cause a recipient to send receipts to an A man-in-the-middle attack can cause a recipient to send receipts to
attacker if that attacker has a signature that can be validated by the an attacker if that attacker has a signature that can be validated by
recipient. The attack consists of intercepting the original message and the recipient. The attack consists of intercepting the original
adding a mLData attribute that says that a receipt should be sent to the message and adding a mLData attribute that says that a receipt should
attacker in addition to whoever else was going to get the receipt. be sent to the attacker in addition to whoever else was going to get
the receipt.
Mailing lists that encrypt their content may be targets for Mailing lists that encrypt their content may be targets for denial-
denial-of-service attacks if they do not use the mailing list management of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is quite described in Section 4. Using simple RFC822 header spoofing, it is
easy to subscribe one encrypted mailing list to another, thereby setting up quite easy to subscribe one encrypted mailing list to another,
an infinite loop. thereby setting up an infinite loop.
Mailing List Agents need to be aware that they can be used as oracles for Mailing List Agents need to be aware that they can be used as oracles
the the adaptive chosen ciphertext attack described in [CMS]. MLAs should for the the adaptive chosen ciphertext attack described in [CMS].
notify an administrator if a large number of undecryptable messages are MLAs should notify an administrator if a large number of
received. undecryptable messages are received.
When verifying a signature using certificates that come with a [CMS] When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates previously message, the recipient should only verify using certificates
known to be valid, or certificates that have come from a signed previously known to be valid, or certificates that have come from a
SigningCertificate attribute. Otherwise, the attacks described in Section 5 signed SigningCertificate attribute. Otherwise, the attacks described
can cause the receiver to possibly think a signature is valid when it is in Section 5 can cause the receiver to possibly think a signature is
not. valid when it is not.
A. ASN.1 Module A. ASN.1 Module
ExtendedSecurityServices ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at line 2345 skipping to change at page 56, line 4
} }
Hash ::= OCTET STRING -- SHA1 hash of entire certificate Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
serialNumber CertificateSerialNumber serialNumber CertificateSerialNumber
} }
END -- of ExtendedSecurityServices END -- of ExtendedSecurityServices
B. References B. References
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
Notation One (ASN.1)" Notation One (ASN.1)".
[ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
Notation One (ASN.1)" Notation One (ASN.1)".
[CERT] "S/MIME Version 3 Certificate Handling", Internet Draft [CERT] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
draft-ietf-smime-cert-xx. Handling", RFC 2632, June 1999.
[CMS] "Cryptographic Message Syntax", Internet Draft [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
draft-ietf-smime-cms-xx. June 1999.
[MSG] "S/MIME Version 3 Message Specification", Internet Draft [MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message
draft-ietf-smime-msg-xx. Specification", RFC 2633, June 1999.
[MUSTSHOULD] "Key Words for Use in RFCs to Indicate Requirement Levels", [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
RFC 2119. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) [MSP4] "Secure Data Network System (SDNS) Message Security
4.0", Specification SDN.701, Revision A, 1997-02-06. Protocol (MSP) 4.0", Specification SDN.701, Revision A,
1997-02-06.
[MTSABS] "1988 International Telecommunication Union (ITU) Data [MTSABS] "1988 International Telecommunication Union (ITU) Data
Communication Networks Message Handling Systems: Message Transfer System: Communication Networks Message Handling Systems: Message
Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, Transfer System: Abstract Service Definition and
Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6) Procedures, Volume VIII, Fascicle VIII.7, Recommendation
mts(3) modules(0) mts-abstract-service(1)} X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)}
[PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315. [PKCS7-1.5] Kaliski, B., "PKCS #7: Cryptographic Message Syntax",
RFC 2315, March 1998.
[SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and [SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
"S/MIME Version 2 Certificate Handling", RFC 2312. L. Repka"S/MIME Version 2 Message Specification", RFC
2311, March 1998, and Dusse, S., Hoffman, P. and B.
Ramsdell,"S/MIME Version 2 Certificate Handling", RFC
2312, March 1998.
[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
C. Acknowledgments C. Acknowledgments
The first draft of this work was prepared by David Solo. John Pawling did a The first draft of this work was prepared by David Solo. John Pawling
huge amount of very detailed revision work during the many phases of the did a huge amount of very detailed revision work during the many
document. phases of the document.
Many other people have contributed hard work to this draft, including:
Andrew Farrell
Bancroft Scott
Bengt Ackzell
Bill Flanigan
Blake Ramsdell
Carlisle Adams
Darren Harter
David Kemp
Denis Pinkas
Jim Schaad
Russ Housley
Scott Hollenbeck
Steve Dusse
D. Changes from draft-ietf-smime-ess-10 to draft-ietf-smime-ess-11
1: Added wording about signing certificates (Section 5) to the
introduction.
1.3.4: Added the sentence at the end of the first paragraph.
1.3.4: Removed the macValue description because it was removed from CMS.
1.4: Second paragraph, replaced second sentence to indicate that some
attributes might have to be omitted.
2.1: Added paragraph at the end of this section saying that you shouldn't
request that receipts be sent to people who don't have the original
message.
2.6: Added paragraph near beginning about accepting more than one signed Many other people have contributed hard work to this memo, including:
receipt.
2.8: Changed Version to ESSVersion and defined it as: Andrew Farrell
Bancroft Scott
Bengt Ackzell
Bill Flanigan
Blake Ramsdell
Carlisle Adams
Darren Harter
David Kemp
Denis Pinkas
Francois Rousseau
Jim Schaad
Russ Housley
Scott Hollenbeck
Steve Dusse
ESSVersion ::= INTEGER { v1(1) } Editor's Address
3: Clarified the last paragraph to indicate ranked levels. Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060
4.2.3.2: Clarified step 2 to show that, if the mlExpansionHistory was EMail: phoffman@imc.org
not found, you sign that whole message and stop.
4.4: Removed the comment "-- EntityIdentifier is imported from [CMS]" Full Copyright Statement
5.1: Changed "changing" to "replacing". Copyright (C) The Internet Society (1999). All Rights Reserved.
5.4: The paragraph beginning "The first certificate..." was changed to This document and translations of it may be copied and furnished to
reflect the addition of the SKI to the SignerInfo. The paragraph beginning others, and derivative works that comment on or otherwise explain it
"If more than..." was changed to allow authorization certificates that are or assist in its implementation may be prepared, copied, published
not attribute certificates. and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
5.4.1: Changed "CMS" to "[CERT]" for the reference. The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
6: Entire section is new. This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
E. Editor's Address Acknowledgement
Paul Hoffman Funding for the RFC Editor function is currently provided by the
Internet Mail Consortium Internet Society.
127 Segre Place
Santa Cruz, CA 95060
(831) 426-9827
phoffman@imc.org
 End of changes. 330 change blocks. 
1650 lines changed or deleted 1793 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/