draft-ietf-smime-ess-07.txt   draft-ietf-smime-ess-08.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-07.txt Internet Mail Consortium draft-ietf-smime-ess-08.txt Internet Mail Consortium
August 5, 1998 September 30, 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 45 skipping to change at line 46
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]. The format of the messages are described in ASN.1:1988 [ASN1-1988].
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
Some of the features of each service use the concept of a "triple wrapped" Some of the features of each service use the concept of a "triple wrapped"
skipping to change at line 303 skipping to change at line 304
contentIdentifier |id-aa-contentIdentifier [ESS]|either |MAY contentIdentifier |id-aa-contentIdentifier [ESS]|either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST contentType |id-contentType [CMS] |either |MUST
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
signingCertificate|id-aa-signingCertificate [ESS]|either |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-aa-encrypKeyPref [MSG] |either |MUST KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF Attributes and defines CMS defines signedAttrs as a SET OF Attributes and defines
unsignedAttributes as a SET OF Attributes. ESS defines the contentHints, unsignedAttributes as a SET OF Attributes. ESS defines the contentHints,
contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
receiptRequest, contentReference and equivalentLabels attribute types. A receiptRequest, contentReference and equivalentLabels attribute types. A
signerInfo MUST NOT include multiple instances of any of the attribute signerInfo MUST NOT include multiple instances of any of the attribute
skipping to change at line 454 skipping to change at line 456
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 900
-- 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 933
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 958
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 1117
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 1323 skipping to change at line 1325
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 to translate the original that attribute is signed by an entity trusted to translate the original
eSSSecurityLabel values to to the security policy included in the eSSSecurityLabel values to the security policy included in the
equivalentLabels attribute. Determining who is allowed to specify equivalentLabels attribute. Determining who is allowed to specify
equivalence mappings is a local policy. If a message has more than one equivalence mappings is a local policy. If a message has more than one
EquivalentLabels attribute, the receiving agent SHOULD process the first EquivalentLabels attribute, the receiving agent SHOULD process the first
one that it reads and validates that contains the security policy of one that it reads and validates that contains the security policy of
interest to the receiving agent. 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
skipping to change at line 1652 skipping to change at line 1654
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 1745 skipping to change at line 1747
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 1767 skipping to change at line 1769
processed a message. As an MLA distributes a message to members of an ML, processed a message. As an MLA distributes a message to members of an ML,
the MLA records its unique identifier, date and time of expansion, and the MLA records its unique identifier, date and time of expansion, and
receipt policy in an MLData structure. receipt policy in an MLData structure.
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS] -- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
The receipt policy of the ML can withdraw the originator's request for the The receipt policy of the ML can withdraw the originator's request for the
return of a signed receipt. However, if the originator of the message has return of a signed receipt. However, if the originator of the message has
not requested a signed receipt, the MLA cannot request a signed receipt. In not requested a signed receipt, the MLA cannot request a signed receipt. In
the event that a ML's signed receipt policy supersedes the originator's the event that a ML's signed receipt policy supersedes the originator's
request for signed receipts, such that the originator will not receive any request for signed receipts, such that the originator will not receive any
signed receipts, then the MLA MAY inform the originator of that fact. signed receipts, then the MLA MAY inform the originator of that fact.
When present, the mlReceiptPolicy specifies a receipt policy that When present, the mlReceiptPolicy specifies a receipt policy that
supersedes the originator's request for signed receipts. The policy can be supersedes the originator's request for signed receipts. The policy can be
one of three possibilities: receipts MUST NOT be returned (none); receipts one of three possibilities: receipts MUST NOT be returned (none); receipts
should be returned to an alternate list of recipients, instead of to the should be returned to an alternate list of recipients, instead of to the
originator (insteadOf); or receipts should be returned to a list of originator (insteadOf); or receipts should be returned to a list of
recipients in addition to the originator (inAdditionTo). recipients in addition to the originator (inAdditionTo).
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
5. Security Considerations 5. Signing Certificate Attribute
Concerns have been raised over the fact that the certificate which the
signer of a [CMS] SignedData object desired to be bound into the
verification process of the SignedData object is not cryptographically
bound into the signature itself. This section addresses this issue by
creating a new attribute to be placed in the signed attributes section of a
SignerInfo object.
This section also presents a description of a set of possible attacks
dealing with the substitution of one certificate to verify the signature
for the desired certificate. A set of ways for preventing or addressing
these attacks is presented to deal with the simplest of the attacks.
Attribute certificates can be used as part of a signature verification
process. There is no way in CMS to include the list of attribute
certificates to be used in the verification process. The set of attribute
certificates used in the signature verification process needs to have the
ability for the signer to restrict the set of certificates. This
information needs to be encoded in a manner that is covered by the
signature on the SignedData object. The methods in this section allows for
the set of attribute certificates to be listed as part of the signing
certificate attribute.
Explicit policies can also be used as part of a signature verification
process. If a signer desires to state an explicit policy that should be
used validating the signature, that policy needs to be cryptographically
bound into the signing process. The methods described in this section
allows for a set of policy statements to be listed as part of the signing
certificate attribute.
5.1. Attack Descriptions
At least three different attacks can be launched against a possible
signature verification process by changing the certificate or certficates
used in the signature verification process.
5.1.1 Substitution Attack Description
The first attack deals with simple substitution of one certificate for
another certificate. In this attack, the issuer and serial number in the
SignerInfo is modified to refer to a new certificate. This new certificate
is used the signature verification process.
The first version of this attack is a simple denial of service attack where
an invalid certificate is substituted for the valid certificate. This
renders the message unverifiable, as the public key in the certificate no
longer matches the private key used to sign the message.
The second version is a substitution of one valid certificate for the
original valid certificate where the public keys in the certificates match.
This allows the signature to be validated under potentially different
certificate constraints than the originator of the message intended.
5.1.2 Reissue of Certificate Description
The second attack deals with a certificate authority (CA) re-issuing the
signing certificate (or potentially one of its certificates). This attack
may start becoming more frequent as Certificate Authorities reissue their
own root certificates, or as certificate authorities change policies in the
certificate while reissuing their root certificates. This problem also
occurs when cross certificates (with potentially different restrictions)
are used in the process of verifying a signature.
5.1.3 Rogue Duplicate CA Description
The third attack deals with a rogue entity setting up a certificate
authority that attempts to duplicate the structure of an existing CA.
Specifically, the rogue entity issues a new certificate with the same
public keys as the signer used, but signed by the rogue entity's private
key.
5.2 Attack Responses
This document does not attempt to solve all of the above attacks; however,
a brief description of responses to each of the attacks is given in this
section.
5.2.1 Substitution Attack Response
The denial of service attack cannot be prevented. After the certificate
identifier has been modified in transit, no verification of the signature
is possible. There is also no way to automatically identify the attack
because it is indistinguishable from a message corruption.
The substitution of a valid certificate can be responded to in two
different manners. The first is to make a blanket statement that the use of
the same public key in two different certificates is bad practice and has
to be avoided. In practice, there is no practical way to prevent users from
getting new certificates with the same public keys, and it should be
assumed that they will do this. Section 5.4 provides a new attribute that
can be included in the SignerInfo signed attributes. This binds the correct
certificate identifier into the signature. This will convert the attack
from a potentially successful one to simply a denial of service attack.
5.2.2 Reissue of Certificate Response
A CA should never reissue a certificate with different attributes.
Certificate Authorities that do so are following poor practices and cannot
be relied on. Using the hash of the certificate as the reference to the
certificate prevents this attach for end-entity certificates.
Preventing the attack based on reissuing of CA certificates would require a
substantial change the attribute presented in section 5.4. It would require
that a sequence of certificate identifiers be included in the attribute.
This presents problems when the relying party is using a cross-certificate
as part of its authentication process, and this certificate does not appear
on the list of certificates. The problems outside of a closed PKI make the
addition of this information prone to error, possibly causing the rejection
of valid chains.
5.2.3 Rogue Duplicate CA Response
The best method of preventing this attack is to avoid trusting the rogue
CA. The use of the hash to identify certificates prevents the use of
end-entity certificates from the rogue authority. However the only true way
to prevent this attack is to never trust the rogue CA.
5.3 Related Signature Verification Context
Some applications require that additional information be used as part of
the signature validation process. In particular, attribute certificates and
policy identifiers provide additional information about the abilities and
intent of the signer. The signing certificate attribute described in
Section 5.4 provides the ability to bind this context information as part
of the signature.
5.3.1 Attribute Certificates
Some applications require that attribute certificates be validated. This
validation requires that the application be able to find the correct
attribute certificates to perform the verification process; however there
is no list of attribute certificates in a SignerInfo object. The sender has
the ability to include a set of attribute certificates in a SignedData
object. The receiver has the ability to retrieve attribute certificates
from a directory service. There are some circumstances where the signer may
wish to limit the set of attribute certificates that may be used in
verifying a signature. It is useful to be able to list the set of attribute
certificates the signer wants the recipient to use in validating the
signature.
5.3.2 Policy Information
A related aspect of the certificate binding is the issue of multiple
certification paths. In some instances, the semantics of a certificate in
its use with a message may depend on the Certificate Authorities and
policies that apply. To address this issue, the signer may also wish to
bind that context under the signature. While this could be done by either
signing the complete certification path or a policy ID, only a binding for
the policy ID is described here.
5.4 Signing Certificate Attribute Definition
The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set of
attribute certificates to be used in verifying a signature.
The following object identifier identifies the encrypted-data content type:
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) <TBD> }
The definition of SigningCertificate is
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF CertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature. The encoding of the
CertID for this certificate SHOULD NOT include the issuerAndSerialNumber
because the issuerAndSerialNumber is already present in the SignerInfo. The
certificate identified is used during the signature verification process.
If the hash of the certificate does not match the certificate used to
decode the signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of CertIDs, the
certificates after the first one limit the set of attribute certificates
that are used during signature validation. The issuerAndSerialNumber SHOULD
be present in these certificates, unless the client who is validating the
signature is expected to have easy access to all the certificates required
for validation. If only the signing certificate is present in the sequence.
there are no restrictions on the set of attribute certificates used in
validating the signature.
The sequence of policy information terms identifies those certificate
policies that the signer asserts apply to the certificate, and under which
the certificate should be relied upon. This value suggests a policy value
to be used in the relying party's certification path validation.
If present, the SigningCertificate attribute MUST be a signed attribute; it
MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF
Attribute. A SignerInfo MUST NOT include multiple instances of the
SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed
attributes to include attrValues SET OF AttributeValue. A
SigningCertificate attribute MUST include only a single instance of
AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue.
5.4.1 Certificate Identification
The best way to identify certificates is an often-discussed issue. [CMS]
has imposed a restriction for SignedData objects that the issuer DN must be
present in all signing certificates. The issuer/serial number pair is
therefore sufficient to identify the correct signing certificate. This
information is already present, as part of the SignerInfo object, and
duplication of this information would be unfortunate. A hash of the entire
certificate serves the same function (allowing the receiver to very the
same certificate is being used), is smaller and permits a detection of the
simple substitution attacks.
Attribute certificates do not have an issuer/serial number pair represented
anywhere in a SignerInfo object. When an attribute certificate is not
included in the SignedData object, it becomes much more difficult to get
the correct set of certificates based only on a hash of the certificate.
For this reason, attribute certificates are identified by the IssuerSerial
object.
This document defines a certificate identifier as:
CertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
When creating a CertID, the certHash is computed over the entire DER
encoded certificate including the signature. The issuerSerial would
normally be present unless the value can be inferred from other
information.
When encoding IssuerSerial, serialNumber is the serial number that uniquely
identifies the certificate. For non-attribute certificates, the issuer MUST
contain only the issuer name from the certificate encoded in the
directoryName choice of GeneralNames. For attribute certificates, the
issuer MUST contain the issuer name field from the attribute certificate.
6. 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
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, EntityIdentifier, SubjectKeyIdentifier, Version ContentType, IssuerAndSerialNumber, 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
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
skipping to change at line 1862 skipping to change at line 2113
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 1909 skipping to change at line 2160
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 1962 skipping to change at line 2213
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS] -- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
END -- of ExtendedSecurityServices END -- of ExtendedSecurityServices
B. References B. References
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
skipping to change at line 2021 skipping to change at line 2276
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
None. None.
E. Changes from draft-ietf-smime-ess-06 to draft-ietf-smime-ess-07 E. Changes from draft-ietf-smime-ess-07 to draft-ietf-smime-ess-08
1.3.4: Reworded second and fifth paragraphs a bit. Also added 3.4.2: Tiny typos.
OID for sMIMEEncryptionKeyPreference.
3.4: Clarified intention in second paragraph. Also slightly updated wording 4.4: Added ASN.1 for EntityIdentifier. Also added this to Appendix A.
in fifth paragraph.
3.4.2: Clarified intention in second paragraph. 5: Added this entire section.
F: Changed my area code A: Removed EntityIdentifier from the imports from CMS, and added
IssuerAndSerialNumber to the imports.
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
(831) 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/