draft-ietf-smime-ess-03.txt   draft-ietf-smime-ess-04.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-03.txt Internet Mail Consortium draft-ietf-smime-ess-04.txt Internet Mail Consortium
March 1, 1998 March 12, 1998
Expires in six months Expires in six months
Enhanced Security Services for S/MIME Enhanced Security Services for S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 44 skipping to change at line 44
- security labels - security labels
- secure mailing lists - secure mailing lists
The services described here are extensions to S/MIME version 3 [SMIME3], The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The 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 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 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 of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient. to be unreadable by an S/MIME version 2 recipient.
The format of the messages are described in ASN.1:1988 [ASN1-1988] with the The format of the messages are described in ASN.1:1988 [ASN1-1988].
modification that UTF8String from ASN.1:1994 [ASN1-1994] is used in the
descriptions.
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
1.1 Triple Wrapping 1.1 Triple Wrapping
skipping to change at line 92 skipping to change at line 89
The encrypted body provides confidentiality, including confidentiality of The encrypted body provides confidentiality, including confidentiality of
the attributes that are carried in the inside signature. 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 information
that is processed hop-by-hop, where each hop is an intermediate entity such that is processed hop-by-hop, where each hop is an intermediate entity such
as a mail list agent. The outer signature binds attributes (such as a as a mail list agent. The outer signature binds attributes (such as a
security label) to the encrypted body. These attributes can be used for security label) to the encrypted body. These attributes can be used for
access control and routing decisions. 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 Content-type
headers, such as "Content-type: text/plain". An exception to this MIME headers, such as "Content-type: text/plain". An exception to this MIME
encapsulation rule is that a signed receipt is not put in MIME headers. 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 structure is encapsulated by a ContentInfo content). The SignedData encapContentInfo eContentType object identifier
SEQUENCE with a contentType of data. If the structure you create in step 4 MUST be id-data. If the structure you create in step 4 is multipart/signed,
is multipart/signed, the eContent is missing; if the structure you create then the SignedData encapContentInfo eContent MUST be absent. If the
in step 4 is application/pkcs7-mime, the eContent is the result of step 2 structure you create in step 4 is application/pkcs7-mime, then the
above. SignedData encapContentInfo eContent MUST contain the result of step 2
above. The 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 3 as
defined in [SMIME3]. The resulting message is called the "inside defined in [SMIME3]. The resulting message is called the "inside
signature". signature".
- If you are signing using multipart/signed, the MIME construct added - If you are signing using multipart/signed, the MIME construct added
consists of a Content-type of multipart/signed with parameters, the consists of a Content-type of multipart/signed with parameters, the
boundary, the result of step 2 above, the boundary, a Content-type of boundary, the result of step 2 above, the boundary, a Content-type of
application/pkcs7-signature, optional MIME headers (such as application/pkcs7-signature, optional MIME headers (such as
Content-transfer-encoding and Content-disposition), and a body part that is Content-transfer-encoding and Content-disposition), and a body part that is
the result of step 3 above. 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 with construct added consists of a Content-type of application/pkcs7-mime with
parameters, optional MIME headers (such as Content-transfer-encoding and parameters, optional MIME headers (such as Content-transfer-encoding and
Content-disposition), and the result of step 3 above. Content-disposition), and 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 structure is encapsulated application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
by a ContentInfo SEQUENCE with a contentType of data. This is called the contentType MUST be id-data. The EnvelopedData structure is encapsulated by
"encrypted body". a ContentInfo 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 such as
Content-transfer-encoding and Content-disposition. 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 (the
MIME headers and the encrypted body) as a single block 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 is
skipping to change at line 179 skipping to change at line 180
[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 2] % | )
[step 1] Original content % | ) [step 1] Original content % | )
[step 4] | ) [step 4] | )
[step 4] --innerboundary | ) [step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | ) [step 4] Content-type: application/pkcs7-signature | )
[step 4] | ) [step 4] | )
[step 3] SignedData block (eContent is missing) | ) [step 3] inner signedData block (eContent is missing) | )
[step 6] [step 4] | )
[step 4] --innerboundary | )
[step 8]
[step 8] --outerboundary [step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature [step 8] Content-type: application/pkcs7-signature
[step 8] [step 8]
[step 7] SignedData block [step 7] outer signedData block
[step 8]
[step 8] --outerboundary
% = These lines are what the inner signature is computed over. % = These lines are what the inner signature is computed over.
| = These lines are what is encrypted in step 5. This encrypted result | = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block. is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over. ) = These lines are what the outer signature is computed over.
The format of a triple wrapped message that uses application/pkcs7-mime for The format of a triple wrapped message that uses application/pkcs7-mime for
the outer signature is: the both signatures is:
[step 8] Content-type: application/pkcs7-mime; [step 8] Content-type: application/pkcs7-mime;
[step 8] smime-type=signed-data [step 8] smime-type=signed-data
[step 8] [step 8]
[step 6] Content-type: application/pkcs7-mime; ) [step 7] outer SignedData block (eContent is present) O
[step 6] smime-type=enveloped-data; ) [step 6] Content-type: application/pkcs7-mime; ) O
[step 6] ) [step 6] smime-type=enveloped-data; ) O
[step 4] Content-type: application/pkcs7-mime; | ) [step 6] ) O
[step 4] smime-type=signed-data | ) [step 4] Content-type: application/pkcs7-mime; | ) O
[step 4] | ) [step 4] smime-type=signed-data | ) O
[step 3] SignedData block (eContent is present) $ | ) [step 4] | ) O
[step 6] [step 3] inner SignedData block (eContent is present) I | ) O
[step 2] Content-type: text/plain I | ) O
[step 7] SignedData block ! [step 2] I | ) O
[step 1] Original content I | ) O
$ = This SignedData block is opaque and contains the ASN.1 encoded result I = These lines are the inner SignedData block, which is opaque and
of step 2 as well as control information. 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 | = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block. is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over. ) = These lines are what the outer signature is computed over.
! = This SignedData block is opaque and contains the ASN.1 encoded result O = These lines are the outer SignedData block, which is opaque and
of step 6 as well as control information. 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 three security services described in this document are used with triple
wrapped messages in different ways. This section briefly describes the wrapped messages in different ways. This section briefly describes the
relationship of each service with triple wrapping; the other sections of relationship of each service with triple wrapping; the other sections of
the document go into greater detail. the document go into greater detail.
1.3.1 Signed Receipts and Triple Wrapping 1.3.1 Signed Receipts and Triple Wrapping
skipping to change at line 520 skipping to change at line 524
2. If the receiptsFrom value of the receiptRequest attribute is 2. If the receiptsFrom value of the receiptRequest attribute is
allOrFirstTier, do one of the following two steps based on the value of allOrFirstTier, do one of the following two steps based on the value of
allOrFirstTier. 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 one of
the following two steps based on the presence of an mlExpansionHistory the following two steps based on the presence of an mlExpansionHistory
attribute: 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 this
recipient is not a first tier recipient and a signed receipt MUST recipient is not a first tier recipient and a signed receipt MUST
NOT be created. 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, then a
signed receipt SHOULD be created. 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:
skipping to change at line 544 skipping to change at line 548
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 the
recipient, then a signed receipt MUST NOT be created. 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 for
which the receiving agent verifies the signature would be: 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? 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. Use ML's policy, then -> 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 created,
create it if required, send it to recipients designated by create it if required, send it to recipients designated by
mlReceiptPolicy, then -> STOP. 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? 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.
skipping to change at line 586 skipping to change at line 590
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 content
(also called a "signedData/Receipt"). Signed receipts are created as (also called a "signedData/Receipt"). Signed receipts are created as
follows: follows:
1. The signature of the original signedData signerInfo that includes the 1. The signature of the original signedData signerInfo that includes the
receiptRequest authenticated attribute MUST be successfully verified before receiptRequest authenticated attribute MUST be successfully verified before
creating the signedData/Receipt. creating the signedData/Receipt.
1.1. The ASN.1 DER encoded content of the original signedData object is 1.1. The content of the original signedData object is digested as
digested as described in [CMS]. The resulting digest value is then described in [CMS]. The resulting digest value is then compared with
compared with the value of the messageDigest attribute included in the the value of the messageDigest attribute included in the
authenticatedAttributes of the original signedData signerInfo. If these authenticatedAttributes of the original signedData signerInfo. If these
digest values are different, then the signature verification process digest values are different, then the signature verification process
fails and the signedData/Receipt MUST NOT be created. fails and the signedData/Receipt MUST NOT be created.
1.2. The ASN.1 DER encoded authenticatedAttributes (including 1.2. The ASN.1 DER encoded authenticatedAttributes (including
messageDigest, receiptRequest and, possibly, other authenticated messageDigest, receiptRequest and, possibly, other authenticated
attributes) in the original signedData signerInfo are digested as attributes) in the original signedData signerInfo are digested as
described in [CMS]. The resulting digest value, called msgSigDigest, is described in [CMS]. The resulting digest value, called msgSigDigest, is
then used to verify the signature of the original signedData then used to verify the signature of the original signedData
signerInfo. If the signature verification fails, then the signerInfo. If the signature verification fails, then the
signedData/Receipt MUST NOT be created. 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 original signedData encapContentInfo eContentType object 2.2. The object identifier from the contentType attribute included in
identifier is copied into the Receipt contentType. the original signedData signerInfo that 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
includes the receiptRequest attribute is copied into 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 authenticatedAttributes of the signerInfo messageDigest attribute in the authenticatedAttributes of the signerInfo
which 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 authenticatedAttributes of the signerInfo msgSigDigest attribute in the authenticatedAttributes of the signerInfo
which will eventually contain the signedData/Receipt signature value. which will eventually contain the signedData/Receipt signature value.
skipping to change at line 642 skipping to change at line 651
8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType 8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
as described in CMS, Section 5.3. The resulting digest value is used to as described in CMS, Section 5.3. The resulting digest value is used to
calculate the signature value which is then included in the calculate the signature value which is then included in the
signedData/Receipt 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 within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
id-ct-receipt object identifier MUST be included in the signedData id-ct-receipt object identifier MUST be included in the signedData
encapContentInfo eContent. This results in a single ASN.1 encoded object encapContentInfo eContentType. This results in a single ASN.1 encoded
composed of a signedData including the Receipt content. The Data content object composed of a signedData including the Receipt content. The Data
type MUST NOT be used. The Receipt content MUST NOT be encapsulated in a content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
MIME header or any other header prior to being encoded as part of the in a MIME header or any other header prior to being encoded as part of the
signedData object. signedData object.
10. If the signedData/Receipt is to be encrypted within an envelopedData 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME
wrapper with the smime-type parameter set to "signed-receipt". This will
allow for identification of signed receipts without having to crack the
ASN.1 body. The smime-type 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
object, then an outer signedData object MUST be created that encapsulates object, then an outer signedData object MUST be created that encapsulates
the envelopedData object, and a contentHints attribute with contentType set the envelopedData object, and a contentHints attribute with contentType set
to the id-ct-receipt object identifier MUST be included in the outer to the id-ct-receipt object identifier MUST be included in the outer
signedData SignerInfo authenticatedAttributes. When a receiving agent signedData SignerInfo authenticatedAttributes. When a receiving agent
processes the outer signedData object, the presence of the id-ct-receipt processes the outer signedData object, the presence of the id-ct-receipt
OID in the contentHints contentType indicates that a signedData/Receipt is OID in the contentHints contentType indicates that a signedData/Receipt is
encrypted within the envelopedData object encapsulated by the outer encrypted within the envelopedData object encapsulated by the outer
signedData. signedData.
2.4.1 MLExpansionHistory Attributes and Receipts 2.4.1 MLExpansionHistory Attributes and Receipts
skipping to change at line 807 skipping to change at line 821
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 when
creating a receipt request. To ensure global uniqueness, the minimal creating a receipt request. To ensure global uniqueness, the minimal
signedContentIdentifier SHOULD contain a concatenation of user-specific signedContentIdentifier SHOULD contain a concatenation of user-specific
identification information (such as a user name or public keying material identification information (such as a user name or public keying material
identification information), a GeneralizedTime string, and a random number. identification information), a GeneralizedTime string, and a random number.
A contentType attribute including the id-ct-receipt object identifier
must be part of the receipt request.
The receiptsFrom field is used by the originator to specify the recipients The receiptsFrom field is used by the originator to specify the recipients
requested to return a signed receipt. A CHOICE is provided to allow requested to return a signed receipt. A CHOICE is provided to allow
specification of: specification of:
- receipts from all recipients are requested - receipts from all recipients are requested
- receipts from first tier (recipients that did not receive the - receipts from first tier (recipients that did not receive the
message as members of a mailing list) recipients are requested message as members of a mailing list) recipients are requested
- receipts from a specific list of recipients are requested - receipts from a specific list of recipients are requested
ReceiptsFrom ::= CHOICE { ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier, allOrFirstTier [0] AllOrFirstTier,
skipping to change at line 854 skipping to change at line 865
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}
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 this
version of the standard. 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 the
innermost signed content of a multi-layer message available on the innermost signed content of a multi-layer message available on the
outermost signature layer. The contentHints attribute provides such outermost signature layer. The contentHints attribute provides such
information. 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 [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL,
-- If contentDescription is used, its contents MUST be in UTF8 format
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 the
recipient may use to select protected messages for processing, such as a recipient may use to select protected messages for processing, such as a
message subject. If this field is set, then the attribute is expected to message subject. If this field is set, then the attribute is expected to
appear on the signedData object enclosing an envelopedData object and not appear on the signedData object enclosing an envelopedData object and not
on the inner signedData object. The SIZE (1..MAX) construct constrains the on the inner signedData object. If a contentDescription is present, it MUST
sequence to have at least one entry. MAX indicates the upper bound is be in UTF8 format, as described in [UTF8]. The SIZE (1..MAX) construct
constrains the sequence to have at least one entry. MAX indicates the upper
unspecified. Implementations are free to choose an upper bound that suits bound is unspecified. Implementations are free to choose an upper bound
their environment. that suits their environment.
Messages which contain a signedData object wrapped around an envelopedData Messages which contain a signedData object wrapped around an envelopedData
object, thus masking the inner content type of the message, SHOULD include object, thus masking the inner content type of the message, SHOULD include
a contentHints attribute, except for the case of the data content type. a contentHints attribute, except for the case of the data content type.
Specific message content types may either force or preclude the inclusion Specific message content types may either force or preclude the inclusion
of the contentHints attribute. For example, when a signedData/Receipt is of the contentHints attribute. For example, when a signedData/Receipt is
encrypted within an envelopedData object, an outer signedData object MUST encrypted within an envelopedData object, an outer signedData object MUST
be created that encapsulates the envelopedData object and a contentHints be created that encapsulates the envelopedData object and a contentHints
attribute with contentType set to the id-ct-receipt object identifier MUST attribute with contentType set to the id-ct-receipt object identifier MUST
be included in the outer signedData SignerInfo authenticatedAttributes. be included in the outer signedData SignerInfo authenticatedAttributes.
skipping to change at line 967 skipping to change at line 979
A security label authenticated attribute may also be included in a A security label authenticated attribute may also be included in a
authenticatedAttributes field within the outer SignedData block. The outer authenticatedAttributes 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 message and
will be used for access control decisions related to the encrypted message will be used for access control decisions related to the encrypted message
and for routing decisions. The outer signature provides authentication of and for routing decisions. The outer signature provides authentication of
the outer security label (as well as for the encapsulated content which may the outer security label (as well as for the encapsulated content which may
include nested S/MIME messages). 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 each
SignerInfo may include authenticatedAttributes. Therefore, a single SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple security labels, each SignerInfo SignedData object may include multiple eSSSecurityLabels, each SignerInfo
having an eSSSecurityLabel attribute. For example, an originator can send a having an eSSSecurityLabel attribute. For example, an originator can send a
signed message with two SignerInfos, one containing a DSS signature, the signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. Not all of the SignerInfos need to other containing an RSA signature. If any of the SignerInfos included in a
include security labels, but in all of the SignerInfos that do contain SignedData object include an eSSSecurityLabel attribute, then all of the
security labels, the security labels MUST be identical. SignerInfos in that SignedData object MUST include an eSSSecurityLabel
attribute and the value of each MUST be identical.
A recipient SHOULD process an eSSSecurityLabel attribute only if the
recipient can verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient SHOULD NOT use a security label
that the recipient cannot authenticate. Local security policies should
exist for handling of messages which contain an eSSSecurityLabel attribute
only in SignerInfos which cannot be validated, or which contain multiple
valid SignerInfos where the security labels are not identical.
3.1.2 Processing Security Labels 3.1.2 Processing Security Labels
A receiving agent that processes security labels MUST process the Before processing an eSSSecurityLabel authenticatedAttribute, the receiving
eSSSecurityLabel attribute, if present, in each SignerInfo in the agent MUST verify the signature of the SignerInfo which covers the
SignedData object for which it verifies the signature. This may result in eSSSecurityLabel attribute. A recipient MUST NOT process an
the receiving agent processing multiple security labels included in a eSSSecurityLabel attribute that has not been verified.
single SignedData object. Because all security labels in a SignedData
object must be identical, the receiving application processes (such as
performing access control) on the first eSSSecurityLabel that it encounters
in a SignerInfo that it can verify, and then ensures that all other
eSSSecurityLabels are identical to the first one encountered.
A receiving agent that processes security labels SHOULD have a local policy A receiving agent MUST process the eSSSecurityLabel attribute, if present,
about whether or not to show the inner content of an incoming messages that in each SignerInfo in the SignedData object for which it verifies the
has a security label with a security policy identifier that the processing signature. This may result in the receiving agent processing multiple
software does not recognize. If the receiving agent does not recognize the eSSSecurityLabels included in a single SignedData object. Because all
eSSSecurityLabel security-policy-identifier value, it SHOULD stop eSSSecurityLabels in a SignedData object must be identical, the receiving
processing the message and indicate an error. agent processes (such as performing access control) on the first
eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
then ensures that all other eSSSecurityLabels in signerInfos that it
verifies are identical to the first one encountered. If the
eSSSecurityLabels in the signerInfos that it verifies are not all
identical, then the receiving agent MUST warn the user of this condition.
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 module.
(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
::=".) Further, the eSSSecurityLabel syntax is compatible with that used in ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
[MSP4]. [MSP4].
The eSSSecurityLabel MUST be marked as critical. The eSSSecurityLabel MUST be marked as critical. This means that any
message with an eSSSecurityLabel will be unreadable to S/MIME v2 clients.
Because of this, a sending agent SHOULD apply an eSSSecurityLabel only if
it needs the services this attribute provides.
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
version Version DEFAULT v1,
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
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}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
skipping to change at line 1034 skipping to change at line 1042
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)), pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String SIZE (1..MAX) -- If pString is used, the ESSSecurityLabel version is set to v1
utf8String [0] IMPLICIT OCTET STRING SIZE (1..MAX)
-- If utf8String is used, its contents MUST be in UTF8 format, and
-- the ESSSecurityLabel version is set to v2
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
skipping to change at line 1256 skipping to change at line 1267
Expansion loops are detected by examining the mailListIdentifier field of Expansion loops are detected by examining the mailListIdentifier field of
each MLData entry found in the mail list expansion history. If an MLA finds each MLData entry found in the mail list expansion history. If an MLA finds
its own identification information, then the MLA must discontinue expansion its own identification information, then the MLA must discontinue expansion
processing and should provide warning of an expansion loop to a human mail processing and should provide warning of an expansion loop to a human mail
list administrator. The mail list administrator is responsible for list administrator. The mail list administrator is responsible for
correcting the loop condition. correcting the loop condition.
4.2 Mail List Agent Processing 4.2 Mail List Agent Processing
MLA message processing depends on the structure of S/MIME layers found in The first few paragraphs of this section provide a high-level description
the processed message. In all cases, the MLA ultimately signs the message of MLA processing. The rest of the section provides a detailed description
and adds or updates an mlExpansionHistory attribute to document MLA of MLA processing.
processing. In all cases, the MLA may need to perform access control before
distributing the message to mail list members if the message contains a
SignedData block and an associated eSSSecurityLabel attribute. If a
eSSSecurityLabel authenticated attribute is used for access control, then
the signature of the signerInfo block including the eSSSecurityLabel MLA message processing depends on the structure of the S/MIME layers in the
authenticated attribute MUST be verified before using the security label. message sent to the MLA for expansion. In addition to sending triple
The MLA should continue parsing the MIME-encapsulated message to determine wrapped messages to an MLA, an entity can send other types of messages to
if there is a security label associated with an encapsulated SignedData an MLA, such as:
object. This may include decrypting an EnvelopedData object to determine if
an encapsulated SignedData object includes a eSSSecurityLabel attribute.
Each MLA that processes the message creates its own mlExpansionHistory and - a single wrapped signedData or envelopedData message
adds it to the sequence of mlExpansionHistory attributes already in the - a double wrapped message (such as signed and enveloped, enveloped and
message. An MLA MUST NOT modify the mlExpansionHistory created by a MLA signed, or signed and signed, and so on)
that previously processed the message. Each MLA copies the sequence of - a quadruple-wrapped message (such as if a well-formed triple wrapped
mlExpansionHistory attributes created by the MLAs that previously processed message was sent through a gateway that added an outer SignedData layer)
the message into the newly constructed expanded message, and adds its own
mlExpansionHistory as the last element of the sequence. Section 4.3 In all cases, the MLA MUST parse all layers of the received message to
provides more details regarding adding information to an existing determine if there are any signedData layers that include an
mLExpansionHistory attribute. eSSSecurityLabel authenticatedAttribute. This may include decrypting an
EnvelopedData layer to determine if an encapsulated SignedData layer
includes an eSSSecurityLabel attribute. The MLA MUST fully process each
eSSSecurityLabel attribute found in the various signedData layers,
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
a new "outer" signedData layer. The MLA MUST add or update an
mlExpansionHistory attribute in the "outer" signedData that it creates to
document MLA processing. If there was an "outer" signedData layer included
in the original message received by the MLA, then the MLA-created "outer"
signedData layer MUST include each authenticated attribute present in the
original "outer" signedData layer, unless the MLA explicitly replaces an
attribute (such as signingTime or mlExpansionHistory) with a new value.
When an S/MIME message is received by the MLA, the MLA MUST first determine
which received signedData layer, if any, is the "outer" signedData layer.
To identify the received "outer" signedData layer, the MLA MUST verify the
signature and fully process the authenticatedAttributes in each of the
outer signedData layers (working from the outside in) to determine if any
of them either include an mlExpansionHistory attribute or encapsulate an
envelopedData object.
The MLA's search for the "outer" signedData layer is completed when it
finds one of the following:
- the "outer" signedData layer that includes an mlExpansionHistory
attribute or encapsulates an envelopedData object
- an envelopedData layer
- the original content (that is, a layer that is neither envelopedData nor
signedData).
If the MLA finds an "outer" signedData layer, then the MLA MUST perform
the following steps:
1. Strip off all of the signedData layers that encapsulated the "outer"
signedData layer
2. Strip off the "outer" signedData layer itself (after remembering the
included authenticatedAttributes)
3. Expand the envelopedData (if present)
4. Sign the message to be sent to the ML members in a new "outer"
signedData layer that includes the authenticatedAttributes (unless
explicitly replaced) from the original, received "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 authenticatedAttributes (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
The following examples help explain the rules above:
1) A message (S1(Original Content)) (where S = SignedData) is sent to the
MLA in which the signedData layer does not include an MLExpansionHistory
attribute. The MLA verifies and fully processes the authenticatedAttributes
in S1. The MLA decides that there is not an original, received "outer"
signedData layer since it finds the original content, but never finds an
envelopedData and never finds an mlExpansionHistory attribute. The MLA
calculates a new signedData layer, S2, resulting in the following message
sent to 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
none of the signedData layers includes an MLExpansionHistory attribute.
The MLA verifies and fully processes the authenticatedAttributes in S3, S2
and S1. The MLA decides that there is not an original, received "outer"
signedData layer since it finds the original content, but never finds an
envelopedData and never finds an mlExpansionHistory attribute. The MLA
calculates a new signedData layer, S4, resulting in the following 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
to the MLA in which S1 does not include an MLExpansionHistory attribute.
The MLA decides that there is not an original, received "outer" signedData
layer since it finds the E1 as the outer layer. The MLA expands the
recipientInformation in E1. The MLA calculates a new signedData layer, S2,
resulting in the following message sent to the ML recipients:
(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
includes an MLExpansionHistory attribute. The MLA verifies the signature
and fully processes the authenticatedAttributes in S2. The MLA finds the
mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
signedData. The MLA remembers the authenticatedAttributes included in S2
for later inclusion in the new outer signedData that it applies to the
message. The MLA strips off S2. The MLA then expands the
recipientInformation in E1 (this invalidates the signature in S2 which is
why it was stripped). The MLA calculates a new signedData layer, S3,
resulting in the following message sent to the ML recipients:
(S3(E1(S1(Original 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
none of the signedData layers include an MLExpansionHistory attribute. The
MLA verifies the signature and fully processes the authenticatedAttributes
in S3 and S2. When the MLA encounters E1, then it decides that S2 is the
"outer" signedData since S2 encapsulates E1. The MLA remembers the
authenticatedAttributes included in S2 for later inclusion in the new outer
signedData that it applies to the message. The MLA strips off S3 and S2.
The MLA then expands the recipientInformation in E1 (this invalidates the
signatures in S3 and S2 which is why they were stripped). The MLA calculates
a new signedData layer, S4, resulting in the following message sent to the
ML recipients: (S4(E1(S1(Original Content)))). The MLA 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
S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
the signature and fully processes the authenticatedAttributes in S3. The MLA
finds the mlExpansionHistory in S3, so it decides that S3 is the "outer"
signedData. The MLA remembers the authenticatedAttributes included in S3
for later inclusion in the new outer signedData that it applies to the
message. The MLA keeps on parsing encapsulated layers because it must
determine if there are any eSSSecurityLabel attributes contained within.
The MLA verifies the signature and fully processes the
authenticatedAttributes in S2. When the MLA encounters E1, then it strips
off S3 and S2. The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))). 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
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 - EnvelopedData
- SignedData - SignedData
- data - data
4.2.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 with a
new recipientInfos value built from RecipientInfo structures created for new recipientInfos value built from RecipientInfo structures created for
each member of the mailing list. The MLA also removes the existing each member of the mailing list. The MLA also removes the existing
originatorInfo field and replaces it with a new originatorInfo value built originatorInfo field and replaces it with a new originatorInfo value built
from information describing the MLA. 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 SignedData
block, adding an mlExpansionHistory attribute as described in the "Mail block, adding an mlExpansionHistory attribute as described in the "Mail
List Expansion" section to document the expansion. 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 mail
list members to complete MLA processing. list members to complete MLA processing.
4.2.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 each
of the layers. Step 3 below specifies that different processing will take of the layers. Step 3 below specifies that different processing will take
place depending on the type of CMS message that has been signed. That place depending on the type of CMS message that has been signed. That
is, it needs to know the type of data at the next inner layer, which may or is, it needs to know the type of data at the next inner layer, which may or
may not be the innermost layer. 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 SignedData
layer associated with the signed data. MLA processing of the message layer associated with the signed data. MLA processing of the message
terminates if the message signature is invalid. terminates if the message signature is invalid.
skipping to change at line 1398 skipping to change at line 1541
EnvelopedData -> 3.1. EnvelopedData -> 3.1.
SignedData -> 3.2. SignedData -> 3.2.
all others -> 3.3. all others -> 3.3.
3.1. Expand the encrypted message, then -> 3.2. 3.1. Expand the encrypted message, then -> 3.2.
3.2. -> 3.2.1. 3.2. -> 3.2.1.
3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
and other authenticated attributes, then -> 3.2.2. and other authenticated attributes, then -> 3.2.2.
3.2.2. Encapsulate in new signature, then -> 3.2.3. 3.2.2. Encapsulate in new signature, then -> 3.2.3.
3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
YES -> copy the old mlExpansionHistory values, then -> 4. YES -> copy the old mlExpansionHistory values, then -> 4.
NO -> create new mlExpansionHistory value, then -> 4. NO -> create new mlExpansionHistory value, then -> 4.
3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
attribute, then -> 4. attribute, then -> 4.
4. Sign message, deliver it, STOP. 4. Sign message, deliver it, STOP.
4.2.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 mail
list members to complete MLA processing. list members to complete MLA processing.
4.3 Mail List Agent Signed Receipt Policy Processing 4.3 Mail List Agent Signed Receipt Policy Processing
skipping to change at line 1492 skipping to change at line 1633
5. Security Considerations 5. Security Considerations
This entire document discusses security. This entire document discusses security.
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
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, EntityIdentifier, SubjectKeyIdentifier, Version ContentType, EntityIdentifier, SubjectKeyIdentifier, Version
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
-- X.509 -- X.509
GeneralNames FROM CertificateExtensions GeneralNames FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services -- Extended Security Services
skipping to change at line 1558 skipping to change at line 1697
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}
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription UTF8String SIZE (1..MAX) OPTIONAL, contentDescription [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL,
contentType OBJECT IDENTIFIER } -- If contentDescription is used, its contents MUST be in UTF8 format
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}
-- Section 2.10 -- Section 2.10
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}
-- Section 3.2 -- Section 3.2
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
version Version DEFAULT v1,
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
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}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
skipping to change at line 1596 skipping to change at line 1737
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)), pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String -- If pString is used, the ESSSecurityLabel version is set to v1
utf8String [0] IMPLICIT OCTET STRING SIZE (1..MAX)
-- If utf8String is used, its contents MUST be in UTF8 format, and
-- the ESSSecurityLabel version is set to v2
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
skipping to change at line 1681 skipping to change at line 1825
[SMIME2] "S/MIME Version 2 Message Specification", Internet Draft [SMIME2] "S/MIME Version 2 Message Specification", Internet Draft
draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling", draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling",
Internet Draft draft-dusse-smime-cert-xx. Internet Draft draft-dusse-smime-cert-xx.
[SMIME3] "S/MIME Version 3 Message Specification", Internet Draft [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling", draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
Internet Draft draft-ietf-smime-cert-xx. Internet Draft draft-ietf-smime-cert-xx.
[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
C. Acknowledgements 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 did a
huge amount of very detailed revision work during the many phases of the huge amount of very detailed revision work during the many phases of the
document. document.
Many other people have contributed hard work to this draft, including: Many other people have contributed hard work to this draft, including:
Bengt Ackzell Bengt Ackzell
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
Jim Schaad Jim Schaad
Phillip Griffin
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Open Issues D. Open Issues
Should contentHints move to the CMS draft? If it is useful in other types There is consensus that contentHints should move to the CMS draft.
of specs, not just ESS, there may be a good reason to have it live in
CMS.
We need to define better how a receiving MLA finds the outer signature that
should have the mlExpansionHistory in it. For instance, a well-formed
triple-wrapped message may pass through a gateway that signs it. We need
wording that says something to the effect of "keep going down through
signatures until you find an mlExpansionHistory attribute, throw away the
higher layers, and process this."
Should mlExpansionHistory have a size of (1..MAX) or should we leave it
as 64?
E. Changes from draft-ietf-smime-ess-02 to draft-ietf-smime-ess-03
Spelled eSSSecurityLabel better in a few places.
Changed "encapsulatedContentType" to "contentType" throughout the document.
Added the OIDs for things that are defined in this draft throughout the text
and added them to Appendix A.
1: Changed the second paragraph to be clearer about how the extensions
affect interoperability.
1.1.1: Replaced the first paragraph with a clearer one.
1.1.2: Completely rewritten.
1.2: Completely rewritten.
1.3.4: In the table, specified contentType MUST be authenticated. Also
added msgSigDigest. Also added the origin of the OID in the table.
1.4: Changed the wording to say where the OIDs are found.
1.5: Added this section on criticality of attributes.
2.2: Removed step 2 and renumbered the rest of the steps. E. Changes from draft-ietf-smime-ess-03 to draft-ietf-smime-ess-04
2.2, bullet 4: Replaced the entire paragraph to describe that the 1. Removed mention of redefining UTF8String.
receiptsTo field MUST be populated.
2.3: In the third paragraph, changed MUST to SHOULD for sending the signed 1.1.2, steps 3 and 5: Reworded these to make them clearer.
receipt.
2.4, bullet 2.2 and 2.3: Revised to no longer include contentType in the 1.2 Changed both examples to be (hopefully) clearer. Also added MIME
Receipt. boundaries that were left out.
2.4, bullet 9: Changed "contentInfo content ANY" with "encapContentInfo 2.3, step 2.2: added "in the outer signedData block". Also added to the
eContent OCTET STRING". flow chart in step 1 and step 2.2.
2.5, bullet 1: Removed wording about what to do if there isn't a 2.3, flow chart: reworded 1.2.1.
receiptsTo.
2.6: Changed "contentInfo content ANY" with "encapContentInfo eContent 2.4, step 1.1: Removed "ASN.1 DER encoded".
OCTET STRING".
2.7: Removed the discussion of what an encapsulatedContentType is. Also 2.4, step 2.2: Reworded this step.
changed the wording about the receiptsTo to show it is mandatory.
Also removed the optional contentType from the ReceiptRequest.
2.8: Made the contentType in the Receipt structure non-optional. 2.4, step 2.4: Added this step.
2.9: Made contentDescription a UTF8String with a SIZE. Updated Appendix A 2.4, step 9: Changed "eContent" to "eContentType".
for these changes. Thus, the DirectoryString is deleted.
2.10: Added this entire section. 2.4, step 10: added this new step, and renumbered the last step.
3.1.1: Added last sentence to last paragraph. 2.7: Removed superfluous sentence in the middle of the section.
3.2: Changed the definition of ESSPrivacy mark to use UTF8String and to not 2.9: Changed definition of contentDescription. Added note about UTF8
include the optional language tag. Also added the length. Also stated format. Also updated Appendix A.
"The eSSSecurityLabel MUST be marked as critical."
4.2: Removed the paragraph that talked about changing attributes. 3.1.1: Changed last paragraph to deal with multiple eSSSecurityLabels.
4.2.1: In step 2, added that the MLA also replaces the originatorInfo. 3.1.2: Change two paragraphs to deal with multiple eSSSecurityLabels.
4.2.2, bullets 3.2.1 and 3.2.3: Replaced the bullets. 3.2: Added words in the second paragraph about use of eSSSecurityLabel and
S/MIME v2 clients.
4.3: Made clarifications in the chart. Added two lengthy items to the 3.2: Changed the second option of the ESSPrivacyMark to be an implicit
chart's legend. octet string. Added version number to ESSSecurityLabel. Made same changes
in Appendix A.
4.4: Changed the sizes insteadOf and inAdditionTo. Also described better 4.2: Replaced much of this section with more information about how to find
what the processing agent does in case of too many lists being listed. the outer wrapper. Also renumbered sub-parts of this section.
A: Added the definition of UTF8String at the beginning of the module. Added A: Removed UNIVERSAL 12 definition from top of module.
ContentType to the list of imports from CMS. Added comment near the
beginning about SIZE (1..MAX). Updated all the changes from above.
F. Editor's Address F. Editor's Address
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
(408) 426-9827 (408) 426-9827
phoffman@imc.org phoffman@imc.org
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/