draft-ietf-smime-ess-06.txt   draft-ietf-smime-ess-07.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-06.txt Internet Mail Consortium draft-ietf-smime-ess-07.txt Internet Mail Consortium
May 29, 1998 August 5, 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 307 skipping to change at line 306
counterSignature |id-countersignature [CMS] |either |MUST NOT counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |MUST messageDigest |id-messageDigest [CMS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingTime |id-signingTime [CMS] |either |MUST signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption- sMIMEEncryption-
KeyPreference |id-TBD [MSG] |either |MUST KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF SignedAttributes and defines CMS defines signedAttrs as a SET OF Attributes and defines
unsignedAttributes as a SET OF UnsignedAttributes. ESS defines the unsignedAttributes as a SET OF Attributes. ESS defines the contentHints,
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest, contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
mlExpansionHistory and receiptRequest attribute types. A signerInfo MUST receiptRequest, contentReference and equivalentLabels attribute types. A
NOT include multiple instances of any of the attribute types defined in signerInfo MUST NOT include multiple instances of any of the attribute
ESS. Later sections of ESS specify further restrictions that apply to the types defined in ESS. Later sections of ESS specify further restrictions
receiptRequest, mlExpansionHistory and eSSecurityLabel attribute types. that apply to the 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 defined
in ESS, if the attribute type is present in a signerInfo, then it MUST only in ESS, if the attribute type is present in a signerInfo, then it MUST only
include a single instance of AttributeValue. In other words, there MUST NOT include a single instance of AttributeValue. In other words, there MUST NOT
be zero or multiple instances of AttributeValue present in the attrValues be zero or multiple instances of AttributeValue present in the attrValues
SET OF AttributeValue. 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 in the
unsigned attributes. It MUST NOT be included in the signed attributes. The unsigned attributes. It MUST NOT be included in the signed attributes. The
only attributes that are allowed in a counterSignature attribute are only attributes that are allowed in a counterSignature attribute are
counterSignature, messageDigest, signingTime, and signingCertificate. counterSignature, messageDigest, signingTime, and signingCertificate.
Note that the inner and outer signatures are for different senders, so that Note that the inner and outer signatures are usually for different senders.
the same attribute in the two signatures could lead to very different The same attribute in the two signatures could lead to very different
consequences. consequences.
The macValue attribute is only used in authenticatedData, never in The macValue attribute is only used in authenticatedData, never in
signedData. signedData.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
identifier assigned to the message. identifier assigned to the message.
1.4 Required and Optional Attributes 1.4 Required and Optional Attributes
skipping to change at line 454 skipping to change at line 454
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 to
the signedContentIdentifier field. The signedContentIdentifier is used to the signedContentIdentifier field. The signedContentIdentifier is used to
associate the signed receipt with the message requesting the signed associate the signed receipt with the message requesting the signed
receipt. 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 signed
receipt. If the message originator wants the recipient to 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 receipt to the originator, then the originator MUST include a GeneralNames
for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
GeneralNames represents an entity. There may be multiple GeneralName GeneralNames represents an entity. There may be multiple GeneralName
instances in each GeneralNames. At a minimum, the message originator MUST instances in each GeneralNames. At a minimum, the message originator MUST
populate each entity's GeneralNames with the address to which the signed populate each entity's GeneralNames with the address to which the signed
receipt should be sent. Optionally, the message originator MAY also receipt should be sent. Optionally, the message originator MAY also
populate each entity's GeneralNames with other GeneralName instances (such populate each entity's GeneralNames with other GeneralName instances (such
as directoryName). as directoryName).
5. The completed receiptRequest attribute is placed in the signedAttributes 5. The completed receiptRequest attribute is placed in the signedAttributes
field of the SignerInfo object. 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 each
SignerInfo may include signedAttributes. Therefore, a single SignedData SignerInfo may include signedAttributes. Therefore, a single SignedData
skipping to change at line 898 skipping to change at line 898
-- formerly "allOrNone [0]AllOrNone" -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames } receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0), allReceipts (0),
firstTierRecipients (1) } firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to The receiptsTo field is used by the originator to identify the user(s) to
whom the identified recipient should send signed receipts. The message whom the identified recipient should send signed receipts. The message
originator MUST populate the receiptsTo field with a GeneralNames for each originator MUST populate the receiptsTo field with a GeneralNames for each
entity to whom the recipient should send the signed receipt. If the message 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 wants the recipient to send the signed receipt to the
originator, then the originator MUST include a GeneralNames for itself in originator, then the originator MUST include a GeneralNames for itself in
the receiptsTo field. 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 Receipt
content type shall have ASN.1 type Receipt. Receipts must be encapsulated content type shall have ASN.1 type Receipt. Receipts must be encapsulated
within a SignedData message. within a SignedData message.
skipping to change at line 931 skipping to change at line 931
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 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 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. The SIZE (1..MAX) construct constrains the
sequence to have at least one entry. MAX indicates the upper bound is sequence to have at least one entry. MAX indicates the upper bound is
skipping to change at line 956 skipping to change at line 956
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 signedAttributes. 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 of a
signed receipt. It contains the digest of the ASN.1 DER encoded 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 the
signed receipt. Only one msgSigDigest attribute can appear in an signed signed receipt. Only one msgSigDigest attribute can appear in an signed
attributes set. It is defined as follows: 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 another. It
skipping to change at line 1115 skipping to change at line 1115
unmarked (0), unmarked (0),
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)     utf8String   UTF8String SIZE (1..MAX)
} }
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 1252 skipping to change at line 1252
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 policies,
many different security policies will exist. Some organizations may wish to many different security policies will exist. Some organizations may wish to
create equivalencies between their security policies with the security create equivalencies between their security policies with the security
policies of other organizations. For example, the Acme Company and the policies of other organizations. For example, the Acme Company and the
Widget Corporation may reach a bilateral agreement that the "Acme private" Widget Corporation may reach a bilateral agreement that the "Acme private"
security-classification value is equivalent to the "Widget sensitive" security-classification value is equivalent to the "Widget sensitive"
security-classification value. security-classification value.
Receiving agents will not process an equivalent label in a message if the Receiving agents MUST NOT process an equivalentLabels attribute in a
agent does not trust the signer of that attribute to specify an equivalent message if the agent does not trust the signer of that attribute to
security policy. Some receiving agents will not process any equivalent translate the original eSSSecurityLabel values to the security policy
labels at all, and will only process eSSSecurityLabels. All receiving included in the equivalentLabels attribute. Receiving agents have the
agents SHOULD recognize equivalent labels even if they do not process them. option to process equivalentLabels attributes but do not have to. It is
acceptable for a receiving agent to only process eSSSecurityLabels. All
receiving agents SHOULD recognize 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}
skipping to change at line 1302 skipping to change at line 1305
Note that equivalentLabels MUST NOT be used to convey security labels that Note that equivalentLabels MUST NOT be used to convey security labels that
are semantically different from the ESSSecurityLabel included in the are semantically different from the ESSSecurityLabel included in the
signerInfos in the signedData. If an entity needs to apply a security label signerInfos in the signedData. If an entity needs to apply a security label
that is semantically different from the ESSSecurityLabel, then it MUST that is semantically different from the ESSSecurityLabel, then it MUST
include the sematically different security label in an outer signedData include the sematically different security label in an outer signedData
object that encapsulates the signedData object that includes the object that encapsulates the signedData object that includes the
ESSSecurityLabel. ESSSecurityLabel.
If present, the equivalentLabels attribute MUST be an signed attribute; it If present, the equivalentLabels attribute MUST be an signed attribute; it
MUST NOT be an unsigned attribute. CMS defines signedAttributes as a SET OF MUST NOT be an unsigned attribute. CMS defines signedAttributes as a SET OF
SignedAttribute. A signerInfo MUST NOT include multiple instances of the Attribute. A signerInfo MUST NOT include multiple instances of the
equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed
attributes to include attrValues SET OF AttributeValue. A equivalentLabels attributes to include attrValues SET OF AttributeValue. A equivalentLabels
attribute MUST only include a single instance of AttributeValue. There MUST attribute MUST only include a single instance of AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present in the NOT be zero or multiple instances of AttributeValue present in the
attrValues SET OF AttributeValue. 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 processing any
EquivalentLabels. If the policy in the ESSSecurityLabel is understood by EquivalentLabels. If the policy in the ESSSecurityLabel is understood by
the receiving agent, it MUST process that label and MUST ignore all the receiving agent, it MUST process that label and MUST ignore all
EquivalentLabels. EquivalentLabels.
When processing an EquivalentLabels attribute, the receiving agent MUST When processing an EquivalentLabels attribute, the receiving agent MUST
validate the signature on the EquivalentLabels attribute. A receiving agent validate the signature on the EquivalentLabels attribute. A receiving agent
MUST NOT act on an EquivalentLabels attribute for which the signature could MUST NOT act on an equivalentLabels attribute for which the signature could
not be validated, and MUST NOT act on an EquivalentLabels attribute unless not be validated, and MUST NOT act on an equivalentLabels attribute unless
that attribute is signed by an entity trusted to add or change access that attribute is signed by an entity trusted to to translate the original
policies. Determining who is allowed to specify equivalence mappings is a eSSSecurityLabel values to to the security policy included in the
local policy. If a message has more than one EquivalentLabels attribute, equivalentLabels attribute. Determining who is allowed to specify
the receiving agent SHOULD process the first one that it reads and equivalence mappings is a local policy. If a message has more than one
validates. EquivalentLabels attribute, the receiving agent SHOULD process the first
one that it reads and 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 each
recipient of an encrypted message. This process can impair performance for recipient of an encrypted message. This process can impair performance for
messages sent to a large number of recipients. Thus, Mail List Agents messages sent to a large number of recipients. Thus, Mail List Agents
(MLAs) that can take a single message and perform the recipient-specific (MLAs) that can take a single message and perform the recipient-specific
encryption for every recipient are often desired. 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 recipient, but
skipping to change at line 1647 skipping to change at line 1652
remembering the value of the mlExpansionHistory and all other remembering the value of the mlExpansionHistory and all other
signed attributes in that layer, if present. 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), the MLA
encapsulates the expanded encrypted message in a new outermost encapsulates the expanded encrypted message in a new outermost
SignedData layer. On the other hand, if the signed data is SignedData layer. On the other hand, if the signed data is
SignedData (from step 3.2), the MLA encapsulates the signed data in SignedData (from step 3.2), the MLA encapsulates the signed data in
a new outermost SignedData layer. 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 replaces
the original outermost signedData layer. The MLA MUST create an the original outermost signedData layer. The MLA MUST create an
signed attribute list for the new outermost signedData layer which signed attribute list for the new outermost signedData layer which
MUST include each signed attribute present in the original MUST include each signed attribute present in the original
outermost signedData layer, unless the MLA explicitly replaces one outermost signedData layer, unless the MLA explicitly replaces one
or more particular attributes with new value. A special case is the or more particular attributes with new value. A special case is the
mlExpansionHistory attribute. The MLA MUST add an mlExpansionHistory attribute. The MLA MUST add an
mlExpansionHistory signed attribute to the outer signedData layer mlExpansionHistory signed attribute to the outer signedData layer
as follows: as follows:
3.2.3.1. If the original outermost SignedData layer included an 3.2.3.1. If the original outermost SignedData layer included an
mlExpansionHistory attribute, the attribute's value is copied mlExpansionHistory attribute, the attribute's value is copied
and updated with the current ML expansion information as and updated with the current ML expansion information as
described in the "Mail List Expansion" section. 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 not
include an mlExpansionHistory attribute, a new attribute value include an mlExpansionHistory attribute, a new attribute value
skipping to change at line 1740 skipping to change at line 1745
missing | none insteadOf(B) inAdditionTo(B) missing 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 MLExpansionHistory. If
there are more than ub-ml-expansion-history mailing lists in the sequence, there are more than ub-ml-expansion-history mailing lists in the sequence,
the processing agent should provide notification of the error to a human the processing agent should provide notification of the error to a human
mail list administrator. The mail list administrator is responsible for mail list administrator. The mail list administrator is responsible for
correcting the overflow condition. 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
skipping to change at line 1857 skipping to change at line 1862
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 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}
-- 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}
skipping to change at line 1904 skipping to change at line 1909
unmarked (0), unmarked (0),
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)     utf8String   UTF8String SIZE (1..MAX)
} }
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 2014 skipping to change at line 2019
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
David Kemp David Kemp
Jim Schaad Jim Schaad
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Open Issues D. Open Issues
Still need an OID for sMIMEEncryptionKeyPreference in 1.3.4. None.
E. Changes from draft-ietf-smime-ess-05 to draft-ietf-smime-ess-06
General: Replaced most instances of "authenticated" with "signed"
because of the change in CMS.
1.3.4: Changed the last column to be clearer on requirements. Added
information about counterSignature and macValue attributes.
Added the two paragraphs after the table. Also added:
contentReference |id-aa-contentReference [ESS] |either |MUST
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
Removed:
signingCertificate|id-ToBeDetermined [CMS] |either |MUST
so that it will appear in whatever document that defines it.
2.11: Added this section for the ContentReference attribute.
2.4: Added the paragraph after step 11.
3.2: Removed the version from ESSSecurityLabel. E. Changes from draft-ietf-smime-ess-06 to draft-ietf-smime-ess-07
3.4: Added this section and its subsections for equivalent security labels. 1.3.4: Reworded second and fifth paragraphs a bit. Also added
OID for sMIMEEncryptionKeyPreference.
4.1: Changed two sentences in last paragraph to make it clear 3.4: Clarified intention in second paragraph. Also slightly updated wording
that one is only looking at the verifyable signerInfos. in fifth paragraph.
4.4: Added a sentence saying that an MLA may tell a sender 3.4.2: Clarified intention in second paragraph.
that their request for signed receipts has been squashed.
A: Moved the definition of UTF8String down a few lines. F: Changed my area code
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 (831) 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/