Enhanced Security Services for S/MIME
updated by
- rfc-5035 — Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
Extracted elements (28)
The mlExpansionHistory attribute serves dual purposes: it allows an MLA to detect mail loops by checking for its own identifier in the list, and it allows the receipt processing logic to distinguish first-tier recipients (no history present) from downstream mailing-list recipients.
Triple wrapping (sign, then encrypt, then sign again) is used when a message must have signed attributes bound to an encrypted body. The inner signature provides content integrity and non-repudiation; the outer signature provides hop-by-hop authentication for intermediate entities such as mail list agents without exposing the inner content.
Some ESS extensions cause messages created by an S/MIME version 3 sender to be unreadable by an S/MIME version 2 recipient, though they will not prevent an S/MIME v3 recipient from reading messages from an S/MIME v2 sender.
A ReceiptRequest attribute MUST NOT be included in the attributes of a SignerInfo in a SignedData object that encapsulates a Receipt content — the receiving agent MUST NOT request a signed receipt for a signed receipt.
A recipient MUST verify the signature covering mlExpansionHistory before processing it. If multiple verified SignerInfos contain mlExpansionHistory attributes that are not all identical, the receiving agent MUST stop processing the message and SHOULD notify the user or MLA administrator.
A security label MUST be placed in the signedAttributes field of a SignerInfo block and MUST NOT be in unsigned attributes, ensuring integrity and authentication are applied. A SignerInfo MUST NOT have more than one security label signed attribute.
A signerInfo MUST NOT include multiple instances of any ESS-defined attribute type. Furthermore, if an ESS attribute type is present in a signerInfo, its attrValues SET MUST contain exactly one AttributeValue — zero or multiple instances are not permitted.
All receiving agents MUST be able to interpret either multipart/signed or application/pkcs7-mime signature structures, because many sending agents always use multipart/signed.
Attributes contentReference, equivalentLabel, eSSSecurityLabel, and mlExpansionHistory MUST be carried in SignedAttributes or AuthAttributes and MUST NOT appear in UnsignedAttributes, UnauthAttributes, or UnprotectedAttributes. msgSigDigest, receiptRequest, and signingCertificate MUST be in SignedAttributes only.
Before creating a signedData/Receipt, the signature of the original signedData signerInfo that includes the receiptRequest attribute MUST be successfully verified. If the messageDigest comparison or signature verification fails, the signedData/Receipt MUST NOT be created.
Before processing a receiptRequest signedAttribute, the receiving agent MUST verify the signature of the covering SignerInfo. A recipient MUST NOT process a receiptRequest attribute that has not been verified. If verified ReceiptRequest attributes in a SignedData are not identical, the agent MUST NOT return any signed receipt.
Before processing an eSSSecurityLabel signedAttribute, the receiving agent MUST verify the signature of the covering SignerInfo. A recipient MUST NOT process an eSSSecurityLabel that has not been verified.
For a triple wrapped message, a receipt request MUST be placed in the inside signature, not in the outside signature. An eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned attributes; it must appear only in a signedAttributes block.
If a gateway or processor adds a signerInfo to an existing signedData block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes from the other signerInfos, to ensure recipients can process those attributes from a verified signerInfo.
If a signedData/Receipt is encrypted within an envelopedData, an outer signedData MUST encapsulate the envelopedData and a contentHints attribute with contentType set to id-ct-receipt MUST be included in the outer signedData SignerInfo signedAttributes.
If any SignerInfo in a SignedData includes an eSSSecurityLabel, then all SignerInfos in that SignedData MUST include an eSSSecurityLabel and the value of each MUST be identical. Non-identical labels MUST cause the receiving agent to warn the user.
Receiving agents MUST NOT process an equivalentLabels attribute unless the signer is trusted to translate the original eSSSecurityLabel values to the security policy in the equivalentLabels. If the ESSSecurityLabel policy is recognized, the agent MUST process that label and MUST ignore all EquivalentLabels.
The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING. The id-ct-receipt OID MUST be in eContentType. The Data content type MUST NOT be used, and Receipt MUST NOT be encapsulated in a MIME header before encoding.
The message originator MUST populate the receiptsTo field with a GeneralNames for each entity to whom the recipient should send the signed receipt. If the originator wants a receipt itself, it MUST include a GeneralNames for itself in the receiptsTo field.
The MLA MUST add an MLData record (identification, date/time, optional receipt policy) to the end of the mlExpansionHistory sequence each time it expands a message. If the attribute is absent it MUST be created; if present the new entry MUST be appended. Only one mlExpansionHistory can appear per SignerInfo.
The MLA MUST parse all layers of a received message to find any eSSSecurityLabel signedAttributes, including decrypting EnvelopedData layers if necessary, and MUST fully process each label (including access control) before distributing to ML members.
The security-classification value MUST be accompanied by a security-policy-identifier to define the rules for its use, since classifications like 'secret' have organization-specific meanings. A security policy SHOULD NOT use integers 0–5 for other than their X.411 meanings.
If the original signedData was sent encrypted within an envelopedData and the ESS signed receipt is returned unencrypted, the message digest value of the original encrypted content is exposed in plaintext. Implementors should consider encrypting the signed receipt in this case to avoid leaking the digest value.
Receipt processing follows a decision tree: check for mlReceiptPolicy (none → MUST NOT create; insteadOf/inAdditionTo → examine receiptsFrom); then check allOrFirstTier (allReceipts → SHOULD create; firstTierRecipients → MUST NOT create if mlExpansionHistory present); then check receiptList membership (present → SHOULD create; absent → MUST NOT create).
ContentHints encodes as a SEQUENCE containing an optional contentDescription (UTF8String SIZE 1..MAX) and a required contentType (ContentType OID). OID: id-aa-contentHint. Used to describe the innermost content type on an outer signature layer.
ESSSecurityLabel encodes as a SET containing: security-policy-identifier (OID, required), security-classification (INTEGER 0–256, optional), privacy-mark (CHOICE of PrintableString or UTF8String, optional), and security-categories (SET of SecurityCategory, optional). OID: id-aa-securityLabel.
Receipt encodes as a SEQUENCE containing: version ESSVersion (INTEGER v1(1)), contentType ContentType, signedContentIdentifier ContentIdentifier (OCTET STRING), and originatorSignatureValue (OCTET STRING). OID: id-ct-receipt. Must be encapsulated within a SignedData.
ReceiptRequest encodes as a SEQUENCE containing: signedContentIdentifier (ContentIdentifier, an OCTET STRING), receiptsFrom (CHOICE of allOrFirstTier INTEGER or receiptList SEQUENCE OF GeneralNames), and receiptsTo (SEQUENCE SIZE 1..16 OF GeneralNames). OID: id-aa-receiptRequest.