home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2634.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  131.3 KB  |  3,252 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                P. Hoffman, Editor
  8. Request for Comments: 2634                     Internet Mail Consortium
  9. Category: Standards Track                                     June 1999
  10.  
  11.  
  12.                  Enhanced Security Services for S/MIME
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  25.  
  26. 1. Introduction
  27.  
  28.    This document describes four optional security service extensions for
  29.    S/MIME. The services are:
  30.  
  31.     - signed receipts
  32.     - security labels
  33.     - secure mailing lists
  34.     - signing certificates
  35.  
  36.    The first three of these services provide functionality that is
  37.    similar to the Message Security Protocol [MSP4], but are useful in
  38.    many other environments, particularly business and finance. Signing
  39.    certificates are useful in any environment where certificates might
  40.    be transmitted with signed messages.
  41.  
  42.    The services described here are extensions to S/MIME version 3 ([MSG]
  43.    and [CERT]), and some of them can also be added to S/MIME version 2
  44.    [SMIME2]. The extensions described here will not cause an S/MIME
  45.    version 3 recipient to be unable to read messages from an S/MIME
  46.    version 2 sender. However, some of the extensions will cause messages
  47.    created by an S/MIME version 3 sender to be unreadable by an S/MIME
  48.    version 2 recipient.
  49.  
  50.    This document describes both the procedures and the attributes needed
  51.    for the four services. Note that some of the attributes described in
  52.    this document are quite useful in other contexts and should be
  53.    considered when extending S/MIME or other CMS applications.
  54.  
  55.  
  56.  
  57.  
  58. Hoffman                     Standards Track                     [Page 1]
  59.  
  60. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  61.  
  62.  
  63.    The format of the messages are described in ASN.1:1988 [ASN1-1988].
  64.  
  65.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  66.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  67.    document are to be interpreted as described in [MUSTSHOULD].
  68.  
  69. 1.1 Triple Wrapping
  70.  
  71.    Some of the features of each service use the concept of a "triple
  72.    wrapped" message. A triple wrapped message is one that has been
  73.    signed, then encrypted, then signed again. The signers of the inner
  74.    and outer signatures may be different entities or the same entity.
  75.    Note that the S/MIME specification does not limit the number of
  76.    nested encapsulations, so there may be more than three wrappings.
  77.  
  78. 1.1.1 Purpose of Triple Wrapping
  79.  
  80.    Not all messages need to be triple wrapped. Triple wrapping is used
  81.    when a message must be signed, then encrypted, and then have signed
  82.    attributes bound to the encrypted body. Outer attributes may be added
  83.    or removed by the message originator or intermediate agents, and may
  84.    be signed by intermediate agents or the final recipient.
  85.  
  86.    The inside signature is used for content integrity, non-repudiation
  87.    with proof of origin, and binding attributes (such as a security
  88.    label) to the original content. These attributes go from the
  89.    originator to the recipient, regardless of the number of intermediate
  90.    entities such as mail list agents that process the message. The
  91.    signed attributes can be used for access control to the inner body.
  92.    Requests for signed receipts by the originator are carried in the
  93.    inside signature as well.
  94.  
  95.    The encrypted body provides confidentiality, including
  96.    confidentiality of the attributes that are carried in the inside
  97.    signature.
  98.  
  99.    The outside signature provides authentication and integrity for
  100.    information that is processed hop-by-hop, where each hop is an
  101.    intermediate entity such as a mail list agent. The outer signature
  102.    binds attributes (such as a security label) to the encrypted body.
  103.    These attributes can be used for access control and routing
  104.    decisions.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Hoffman                     Standards Track                     [Page 2]
  115.  
  116. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  117.  
  118.  
  119. 1.1.2 Steps for Triple Wrapping
  120.  
  121.    The steps to create a triple wrapped message are:
  122.  
  123.    1. Start with a message body, called the "original content".
  124.  
  125.    2. Encapsulate the original content with the appropriate MIME
  126.       Content-type headers, such as "Content-type: text/plain". An
  127.       exception to this MIME encapsulation rule is that a signed receipt
  128.       is not put in MIME headers.
  129.  
  130.    3. Sign the result of step 2 (the inner MIME headers and the original
  131.       content). The SignedData encapContentInfo eContentType object
  132.       identifier MUST be id-data. If the structure you create in step 4
  133.       is multipart/signed, then the SignedData encapContentInfo eContent
  134.       MUST be absent. If the structure you create in step 4 is
  135.       application/pkcs7-mime, then the SignedData encapContentInfo
  136.       eContent MUST contain the result of step 2 above. The SignedData
  137.       structure is encapsulated by a ContentInfo SEQUENCE with a
  138.       contentType of id-signedData.
  139.  
  140.    4. Add an appropriate MIME construct to the signed message from step
  141.       3 as defined in [MSG]. The resulting message is called the "inside
  142.       signature".
  143.  
  144.     - If you are signing using multipart/signed, the MIME construct
  145.       added consists of a Content-type of multipart/signed with
  146.       parameters, the boundary, the result of step 2 above, the
  147.       boundary, a Content-type of application/pkcs7-signature,
  148.       optional MIME headers (such asContent-transfer-encoding and
  149.       Content-disposition), and a body part that is the result of
  150.       step 3 above.
  151.  
  152.     - If you are instead signing using application/pkcs7-mime, the MIME
  153.       construct added consists of a Content-type of
  154.       application/pkcs7-mime with parameters, optional MIME headers
  155.       (such as Content-transfer-encoding and Content-disposition), and
  156.       the result of step 3 above.
  157.  
  158.    5. Encrypt the result of step 4 as a single block, turning it into an
  159.       application/pkcs7-mime object. The EnvelopedData
  160.       encryptedContentInfo contentType MUST be id-data.
  161.       The EnvelopedData structure is encapsulated by a ContentInfo
  162.       SEQUENCE with a contentType of id-envelopedData. This is called
  163.       the "encrypted body".
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Hoffman                     Standards Track                     [Page 3]
  171.  
  172. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  173.  
  174.  
  175.    6. Add the appropriate MIME headers: a Content-type of
  176.       application/pkcs7-mime with parameters, and optional MIME headers
  177.       such as Content-transfer-encoding and Content-disposition.
  178.  
  179.    7. Using the same logic as in step 3 above, sign the result of step 6
  180.       (the MIME headers and the encrypted body) as a single block
  181.  
  182.    8. Using the same logic as in step 4 above, add an appropriate MIME
  183.       construct to the signed message from step 7. The resulting message
  184.       is called the "outside signature", and is also the triple wrapped
  185.       message.
  186.  
  187. 1.2 Format of a Triple Wrapped Message
  188.  
  189.    A triple wrapped message has many layers of encapsulation. The
  190.    structure differs based on the choice of format for the signed
  191.    portions of the message. Because of the way that MIME encapsulates
  192.    data, the layers do not appear in order, and the notion of "layers"
  193.    becomes vague.
  194.  
  195.    There is no need to use the multipart/signed format in an inner
  196.    signature because it is known that the recipient is able to process
  197.    S/MIME messages (because they decrypted the middle wrapper). A
  198.    sending agent might choose to use the multipart/signed format in the
  199.    outer layer so that a non-S/MIME agent could see that the next inner
  200.    layer is encrypted; however, this is not of great value, since all it
  201.    shows the recipient is that the rest of the message is unreadable.
  202.    Because many sending agents always use multipart/signed structures,
  203.    all receiving agents MUST be able to interpret either
  204.    multipart/signed or application/pkcs7-mime signature structures.
  205.  
  206.    The format of a triple wrapped message that uses multipart/signed for
  207.    both signatures is:
  208.  
  209.    [step 8] Content-type: multipart/signed;
  210.    [step 8]    protocol="application/pkcs7-signature";
  211.    [step 8]    boundary=outerboundary
  212.    [step 8]
  213.    [step 8] --outerboundary
  214.    [step 6] Content-type: application/pkcs7-mime;             )
  215.    [step 6]    smime-type=enveloped-data                      )
  216.    [step 6]                                                   )
  217.    [step 4] Content-type: multipart/signed;                 | )
  218.    [step 4]    protocol="application/pkcs7-signature";      | )
  219.    [step 4]    boundary=innerboundary                       | )
  220.    [step 4]                                                 | )
  221.    [step 4] --innerboundary                                 | )
  222.    [step 2] Content-type: text/plain                      % | )
  223.  
  224.  
  225.  
  226. Hoffman                     Standards Track                     [Page 4]
  227.  
  228. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  229.  
  230.  
  231.    [step 2]                                               % | )
  232.    [step 1] Original content                              % | )
  233.    [step 4]                                                 | )
  234.    [step 4] --innerboundary                                 | )
  235.    [step 4] Content-type: application/pkcs7-signature       | )
  236.    [step 4]                                                 | )
  237.    [step 3] inner SignedData block (eContent is missing)    | )
  238.    [step 4]                                                 | )
  239.    [step 4] --innerboundary--                               | )
  240.    [step 8]
  241.    [step 8] --outerboundary
  242.    [step 8] Content-type: application/pkcs7-signature
  243.    [step 8]
  244.    [step 7] outer SignedData block (eContent is missing)
  245.    [step 8]
  246.    [step 8] --outerboundary--
  247.  
  248.    % = These lines are what the inner signature is computed over.
  249.    | = These lines are what is encrypted in step 5. This encrypted result
  250.        is opaque and is a part of an EnvelopedData block.
  251.    ) = These lines are what the outer signature is computed over.
  252.  
  253.    The format of a triple wrapped message that uses application/pkcs7-
  254.    mime for the both signatures is:
  255.  
  256.    [step 8] Content-type: application/pkcs7-mime;
  257.    [step 8]    smime-type=signed-data
  258.    [step 8]
  259.    [step 7] outer SignedData block (eContent is present)        O
  260.    [step 6] Content-type: application/pkcs7-mime;             ) O
  261.    [step 6]    smime-type=enveloped-data;                     ) O
  262.    [step 6]                                                   ) O
  263.    [step 4] Content-type: application/pkcs7-mime;           | ) O
  264.    [step 4]    smime-type=signed-data                       | ) O
  265.    [step 4]                                                 | ) O
  266.    [step 3] inner SignedData block (eContent is present)  I | ) O
  267.    [step 2] Content-type: text/plain                      I | ) O
  268.    [step 2]                                               I | ) O
  269.    [step 1] Original content                              I | ) O
  270.  
  271.    I = These lines are the inner SignedData block, which is opaque and
  272.        contains the ASN.1 encoded result of step 2 as well as control
  273.        information.
  274.    | = These lines are what is encrypted in step 5. This encrypted result
  275.        is opaque and is a part of an EnvelopedData block.
  276.    ) = These lines are what the outer signature is computed over.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Hoffman                     Standards Track                     [Page 5]
  283.  
  284. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  285.  
  286.  
  287.    O = These lines are the outer SignedData block, which is opaque and
  288.        contains the ASN.1 encoded result of step 6 as well as control
  289.        information.
  290.  
  291. 1.3 Security Services and Triple Wrapping
  292.  
  293.    The first three security services described in this document are used
  294.    with triple wrapped messages in different ways. This section briefly
  295.    describes the relationship of each service with triple wrapping; the
  296.    other sections of the document go into greater detail.
  297.  
  298. 1.3.1 Signed Receipts and Triple Wrapping
  299.  
  300.    A signed receipt may be requested in any SignedData object. However,
  301.    if a signed receipt is requested for a triple wrapped message, the
  302.    receipt request MUST be in the inside signature, not in the outside
  303.    signature.  A secure mailing list agent may change the receipt policy
  304.    in the outside signature of a triple wrapped message when that
  305.    message is processed by the mailing list.
  306.  
  307.    Note: the signed receipts and receipt requests described in this memo
  308.    differ from those described in the work done by the IETF Receipt
  309.    Notification Working Group. The output of that Working Group, when
  310.    finished, is not expected to work well with triple wrapped messages
  311.    as described in this document.
  312.  
  313. 1.3.2 Security Labels and Triple Wrapping
  314.  
  315.    A security label may be included in the signed attributes of any
  316.    SignedData object. A security label attribute may be included in
  317.    either the inner signature, outer signature, or both.
  318.  
  319.    The inner security label is used for access control decisions related
  320.    to the plaintext original content. The inner signature provides
  321.    authentication and cryptographically protects the integrity of the
  322.    original signer's security label that is in the inside body. This
  323.    strategy facilitates the forwarding of messages because the original
  324.    signer's security label is included in the SignedData block which can
  325.    be forwarded to a third party that can verify the inner signature
  326.    which will cover the inner security label. The confidentiality
  327.    security service can be applied to the inner security label by
  328.    encrypting the entire inner SignedData block within an EnvelopedData
  329.    block.
  330.  
  331.    A security label may also be included in the signed attributes of the
  332.    outer SignedData block which will include the sensitivities of the
  333.    encrypted message. The outer security label is used for access
  334.    control and routing decisions related to the encrypted message. Note
  335.  
  336.  
  337.  
  338. Hoffman                     Standards Track                     [Page 6]
  339.  
  340. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  341.  
  342.  
  343.    that a security label attribute can only be used in a
  344.    signedAttributes block.  An eSSSecurityLabel attribute MUST NOT be
  345.    used in an EnvelopedData or unsigned attributes.
  346.  
  347. 1.3.3 Secure Mailing Lists and Triple Wrapping
  348.  
  349.    Secure mail list message processing depends on the structure of
  350.    S/MIME layers present in the message sent to the mail list agent. The
  351.    mail list agent never changes the data that was hashed to form the
  352.    inner signature, if such a signature is present. If an outer
  353.    signature is present, then the agent will modify the data that was
  354.    hashed to form that outer signature. In all cases, the agent adds or
  355.    updates an mlExpansionHistory attribute to document the agent's
  356.    processing, and ultimately adds or replaces the outer signature on
  357.    the message to be distributed.
  358.  
  359. 1.3.4 Placement of Attributes
  360.  
  361.    Certain attributes should be placed in the inner or outer SignedData
  362.    message; some attributes can be in either. Further, some attributes
  363.    must be signed, while signing is optional for others, and some
  364.    attributes must not be signed. ESS defines several types of
  365.    attributes.  ContentHints and ContentIdentifier MAY appear in any
  366.    list of attributes. contentReference, equivalentLabel,
  367.    eSSSecurityLabel and mlExpansionHistory MUST be carried in a
  368.    SignedAttributes or AuthAttributes type, and MUST NOT be carried in a
  369.    UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
  370.    msgSigDigest, receiptRequest and signingCertificate MUST be carried
  371.    in a SignedAttributes, and MUST NOT be carried in a AuthAttributes,
  372.    UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Hoffman                     Standards Track                     [Page 7]
  395.  
  396. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  397.  
  398.  
  399.    The following table summarizes the recommendation of this profile. In
  400.    the OID column, [ESS] indicates that the attribute is defined in this
  401.    document.
  402.  
  403.                      |                              |Inner or  |
  404.    Attribute         |OID                           |outer     |Signed
  405.    ------------------|----------------------------- |----------|--------
  406.    contentHints      |id-aa-contentHint [ESS]       |either    |MAY
  407.    contentIdentifier |id-aa-contentIdentifier [ESS] |either    |MAY
  408.    contentReference  |id-aa-contentReference [ESS]  |either    |MUST
  409.    contentType       |id-contentType [CMS]          |either    |MUST
  410.    counterSignature  |id-countersignature [CMS]     |either    |MUST NOT
  411.    equivalentLabel   |id-aa-equivalentLabels [ESS]  |either    |MUST
  412.    eSSSecurityLabel  |id-aa-securityLabel [ESS]     |either    |MUST
  413.    messageDigest     |id-messageDigest [CMS]        |either    |MUST
  414.    msgSigDigest      |id-aa-msgSigDigest [ESS]      |inner only|MUST
  415.    mlExpansionHistory|id-aa-mlExpandHistory [ESS]   |outer only|MUST
  416.    receiptRequest    |id-aa-receiptRequest [ESS]    |inner only|MUST
  417.    signingCertificate|id-aa-signingCertificate [ESS]|either    |MUST
  418.    signingTime       |id-signingTime [CMS]          |either    |MUST
  419.    smimeCapabilities |sMIMECapabilities [MSG]       |either    |MUST
  420.    sMIMEEncryption-
  421.      KeyPreference   |id-aa-encrypKeyPref [MSG]     |either    |MUST
  422.  
  423.    CMS defines signedAttrs as a SET OF Attribute and defines
  424.    unsignedAttrs as a SET OF Attribute. ESS defines the contentHints,
  425.    contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
  426.    receiptRequest, contentReference, equivalentLabels and
  427.    signingCertificate attribute types. A signerInfo MUST NOT include
  428.    multiple instances of any of the attribute types defined in ESS.
  429.    Later sections of ESS specify further restrictions that apply to the
  430.    receiptRequest, mlExpansionHistory and eSSecurityLabel attribute
  431.    types.
  432.  
  433.    CMS defines the syntax for the signed and unsigned attributes as
  434.    "attrValues SET OF AttributeValue". For all of the attribute types
  435.    defined in ESS, if the attribute type is present in a signerInfo,
  436.    then it MUST only include a single instance of AttributeValue. In
  437.    other words, there MUST NOT be zero, or multiple, instances of
  438.    AttributeValue present in the attrValues SET OF AttributeValue.
  439.  
  440.    If a counterSignature attribute is present, then it MUST be included
  441.    in the unsigned attributes. It MUST NOT be included in the signed
  442.    attributes. The only attributes that are allowed in a
  443.    counterSignature attribute are counterSignature, messageDigest,
  444.    signingTime, and signingCertificate.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Hoffman                     Standards Track                     [Page 8]
  451.  
  452. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  453.  
  454.  
  455.    Note that the inner and outer signatures are usually those of
  456.    different senders. Because of this, the same attribute in the two
  457.    signatures could lead to very different consequences.
  458.  
  459.    ContentIdentifier is an attribute (OCTET STRING) used to carry a
  460.    unique identifier assigned to the message.
  461.  
  462. 1.4 Required and Optional Attributes
  463.  
  464.    Some security gateways sign messages that pass through them. If the
  465.    message is any type other than a signedData type, the gateway has
  466.    only one way to sign the message: by wrapping it with a signedData
  467.    block and MIME headers. If the message to be signed by the gateway is
  468.    a signedData message already, the gateway can sign the message by
  469.    inserting a signerInfo into the signedData block.
  470.  
  471.    The main advantage of a gateway adding a signerInfo instead of
  472.    wrapping the message in a new signature is that the message doesn't
  473.    grow as much as if the gateway wrapped the message. The main
  474.    disadvantage is that the gateway must check for the presence of
  475.    certain attributes in the other signerInfos and either omit or copy
  476.    those attributes.
  477.  
  478.    If a gateway or other processor adds a signerInfo to an existing
  479.    signedData block, it MUST copy the mlExpansionHistory and
  480.    eSSSecurityLabel attributes from other signerInfos. This helps ensure
  481.    that the recipient will process those attributes in a signerInfo that
  482.    it can verify.
  483.  
  484.    Note that someone may in the future define an attribute that must be
  485.    present in each signerInfo of a signedData block in order for the
  486.    signature to be processed. If that happens, a gateway that inserts
  487.    signerInfos and doesn't copy that attribute will cause every message
  488.    with that attribute to fail when processed by the recipient. For this
  489.    reason, it is safer to wrap messages with new signatures than to
  490.    insert signerInfos.
  491.  
  492. 1.5 Object Identifiers
  493.  
  494.    The object identifiers for many of the objects described in this memo
  495.    are found in [CMS], [MSG], and [CERT]. Other object identifiers used
  496.    in S/MIME can be found in the registry kept at
  497.    <http://www.imc.org/ietf-smime/oids.html>. When this memo moves to
  498.    standards track within the IETF, it is intended that the IANA will
  499.    maintain this registry.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Hoffman                     Standards Track                     [Page 9]
  507.  
  508. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  509.  
  510.  
  511. 2. Signed Receipts
  512.  
  513.    Returning a signed receipt provides to the originator proof of
  514.    delivery of a message, and allows the originator to demonstrate to a
  515.    third party that the recipient was able to verify the signature of
  516.    the original message. This receipt is bound to the original message
  517.    through the signature; consequently, this service may be requested
  518.    only if a message is signed. The receipt sender may optionally also
  519.    encrypt a receipt to provide confidentiality between the receipt
  520.    sender and the receipt recipient.
  521.  
  522. 2.1 Signed Receipt Concepts
  523.  
  524.    The originator of a message may request a signed receipt from the
  525.    message's recipients. The request is indicated by adding a
  526.    receiptRequest attribute to the signedAttributes field of the
  527.    SignerInfo object for which the receipt is requested. The receiving
  528.    user agent software SHOULD automatically create a signed receipt when
  529.    requested to do so, and return the receipt in accordance with mailing
  530.    list expansion options, local security policies, and configuration
  531.    options.
  532.  
  533.    Because receipts involve the interaction of two parties, the
  534.    terminology can sometimes be confusing. In this section, the "sender"
  535.    is the agent that sent the original message that included a request
  536.    for a receipt. The "receiver" is the party that received that message
  537.    and generated the receipt.
  538.  
  539.    The steps in a typical transaction are:
  540.  
  541.    1. Sender creates a signed message including a receipt request
  542.       attribute (Section 2.2).
  543.  
  544.    2. Sender transmits the resulting message to the recipient or
  545.       recipients.
  546.  
  547.    3. Recipient receives message and determines if there is a valid
  548.       signature and receipt request in the message (Section 2.3).
  549.  
  550.    4. Recipient creates a signed receipt (Section 2.4).
  551.  
  552.    5. Recipient transmits the resulting signed receipt message to the
  553.       sender (Section 2.5).
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Hoffman                     Standards Track                    [Page 10]
  563.  
  564. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  565.  
  566.  
  567.    6. Sender receives the message and validates that it contains a
  568.       signed receipt for the original message (Section 2.6). This
  569.       validation relies on the sender having retained either a copy of
  570.       the original message or information extracted from the original
  571.       message.
  572.  
  573.    The ASN.1 syntax for the receipt request is given in Section 2.7; the
  574.    ASN.1 syntax for the receipt is given in Section 2.8.
  575.  
  576.    Note that a sending agent SHOULD remember when it has sent a receipt
  577.    so that it can avoid re-sending a receipt each time it processes the
  578.    message.
  579.  
  580.    A receipt request can indicate that receipts be sent to many places,
  581.    not just to the sender (in fact, the receipt request might indicate
  582.    that the receipts should not even go to the sender). In order to
  583.    verify a receipt, the recipient of the receipt must be the originator
  584.    or a recipient of the original message. Thus, the sender SHOULD NOT
  585.    request that receipts be sent to anyone who does not have an exact
  586.    copy of the message.
  587.  
  588. 2.2 Receipt Request Creation
  589.  
  590.    Multi-layer S/MIME messages may contain multiple SignedData layers.
  591.    However, receipts may be requested only for the innermost SignedData
  592.    layer in a multi-layer S/MIME message, such as a triple wrapped
  593.    message. Only one receiptRequest attribute can be included in the
  594.    signedAttributes of a SignerInfo.
  595.  
  596.    A ReceiptRequest attribute MUST NOT be included in the attributes of
  597.    a SignerInfo in a SignedData object that encapsulates a Receipt
  598.    content.  In other words, the receiving agent MUST NOT request a
  599.    signed receipt for a signed receipt.
  600.  
  601.    A sender requests receipts by placing a receiptRequest attribute in
  602.    the signed attributes of a signerInfo as follows:
  603.  
  604.    1. A receiptRequest data structure is created.
  605.  
  606.    2. A signed content identifier for the message is created and assigned
  607.       to the signedContentIdentifier field. The signedContentIdentifier
  608.       is used to associate the signed receipt with the message requesting
  609.       the signed receipt.
  610.  
  611.    3. The entities requested to return a signed receipt are noted in the
  612.       receiptsFrom field.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Hoffman                     Standards Track                    [Page 11]
  619.  
  620. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  621.  
  622.  
  623.    4. The message originator MUST populate the receiptsTo field with a
  624.       GeneralNames for each entity to whom the recipient should send the
  625.       signed receipt. If the message originator wants the recipient to
  626.       send the signed receipt to the originator, then the originator MUST
  627.       include a GeneralNames for itself in the receiptsTo field.
  628.       GeneralNames is a SEQUENCE OF GeneralName. receiptsTo is a
  629.       SEQUENCE OF GeneralNames in which each GeneralNames represents an
  630.       entity.  There may be multiple GeneralName instances in each
  631.       GeneralNames.  At a minimum, the message originator MUST populate
  632.       each entity's GeneralNames with the address to which the signed
  633.       receipt should be sent. Optionally, the message originator MAY
  634.       also populate each entity's GeneralNames with other GeneralName
  635.       instances (such as directoryName).
  636.  
  637.    5. The completed receiptRequest attribute is placed in the
  638.       signedAttributes field of the SignerInfo object.
  639.  
  640. 2.2.1 Multiple Receipt Requests
  641.  
  642.    There can be multiple SignerInfos within a SignedData object, and
  643.    each SignerInfo may include signedAttributes. Therefore, a single
  644.    SignedData object may include multiple SignerInfos, each SignerInfo
  645.    having a receiptRequest attribute. For example, an originator can
  646.    send a signed message with two SignerInfos, one containing a DSS
  647.    signature, the other containing an RSA signature.
  648.  
  649.    Each recipient SHOULD return only one signed receipt.
  650.  
  651.    Not all of the SignerInfos need to include receipt requests, but in
  652.    all of the SignerInfos that do contain receipt requests, the receipt
  653.    requests MUST be identical.
  654.  
  655. 2.2.2 Information Needed to Validate Signed Receipts
  656.  
  657.    The sending agent MUST retain one or both of the following items to
  658.    support the validation of signed receipts returned by the recipients.
  659.  
  660.     - the original signedData object requesting the signed receipt
  661.  
  662.     - the message signature digest value used to generate the original
  663.       signedData signerInfo signature value and the digest value of the
  664.       Receipt content containing values included in the original
  665.       signedData object. If signed receipts are requested from multiple
  666.       recipients, then retaining these digest values is a performance
  667.       enhancement because the sending agent can reuse the saved values
  668.       when verifying each returned signed receipt.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Hoffman                     Standards Track                    [Page 12]
  675.  
  676. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  677.  
  678.  
  679. 2.3 Receipt Request Processing
  680.  
  681.    A receiptRequest is associated only with the SignerInfo object to
  682.    which the receipt request attribute is directly attached. Receiving
  683.    software SHOULD examine the signedAttributes field of each of the
  684.    SignerInfos for which it verifies a signature in the innermost
  685.    signedData object to determine if a receipt is requested. This may
  686.    result in the receiving agent processing multiple receiptRequest
  687.    attributes included in a single SignedData object, such as requests
  688.    made from different people who signed the object in parallel.
  689.  
  690.    Before processing a receiptRequest signedAttribute, the receiving
  691.    agent MUST verify the signature of the SignerInfo which covers the
  692.    receiptRequest attribute. A recipient MUST NOT process a
  693.    receiptRequest attribute that has not been verified. Because all
  694.    receiptRequest attributes in a SignedData object must be identical,
  695.    the receiving application fully processes (as described in the
  696.    following paragraphs) the first receiptRequest attribute that it
  697.    encounters in a SignerInfo that it verifies, and it then ensures that
  698.    all other receiptRequest attributes in signerInfos that it verifies
  699.    are identical to the first one encountered. If there are verified
  700.    ReceiptRequest attributes which are not the same, then the processing
  701.    software MUST NOT return any signed receipt. A signed receipt SHOULD
  702.    be returned if any signerInfo containing a receiptRequest attribute
  703.    can be validated, even if other signerInfos containing the same
  704.    receiptRequest attribute cannot be validated because they are signed
  705.    using an algorithm not supported by the receiving agent.
  706.  
  707.    If a receiptRequest attribute is absent from the signed attributes,
  708.    then a signed receipt has not been requested from any of the message
  709.    recipients and MUST NOT be created. If a receiptRequest attribute is
  710.    present in the signed attributes, then a signed receipt has been
  711.    requested from some or all of the message recipients. Note that in
  712.    some cases, a receiving agent might receive two almost-identical
  713.    messages, one with a receipt request and the other without one. In
  714.    this case, the receiving agent SHOULD send a signed receipt for the
  715.    message that requests a signed receipt.
  716.  
  717.    If a receiptRequest attribute is present in the signed attributes,
  718.    the following process SHOULD be used to determine if a message
  719.    recipient has been requested to return a signed receipt.
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Hoffman                     Standards Track                    [Page 13]
  731.  
  732. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  733.  
  734.  
  735.    1. If an mlExpansionHistory attribute is present in the outermost
  736.       signedData block, do one of the following two steps, based on the
  737.       absence or presence of mlReceiptPolicy:
  738.  
  739.        1.1. If an mlReceiptPolicy value is absent from the last MLData
  740.             element, a Mail List receipt policy has not been specified
  741.             and the processing software SHOULD examine the
  742.             receiptRequest attribute value to determine if a receipt
  743.             should be created and returned.
  744.  
  745.        1.2. If an mlReceiptPolicy value is present in the last MLData
  746.             element, do one of the following two steps, based on the
  747.             value of mlReceiptPolicy:
  748.  
  749.            1.2.1. If the mlReceiptPolicy value is none, then the receipt
  750.                   policy of the Mail List supersedes the originator's
  751.                   request for a signed receipt and a signed receipt MUST
  752.                   NOT be created.
  753.  
  754.            1.2.2. If the mlReceiptPolicy value is insteadOf or
  755.                   inAdditionTo, the processing software SHOULD examine
  756.                   the receiptsFrom value from the receiptRequest
  757.                   attribute to determine if a receipt should be created
  758.                   and returned. If a receipt is created, the insteadOf
  759.                   and inAdditionTo fields identify entities that SHOULD
  760.                   be sent the receipt instead of or in addition to the
  761.                   originator.
  762.  
  763.    2. If the receiptsFrom value of the receiptRequest attribute
  764.       allOrFirstTier, do one of the following two steps based on the
  765.       value of allOrFirstTier.
  766.  
  767.        2.1. If the value of allOrFirstTier is allReceipts, then a signed
  768.             receipt SHOULD be created.
  769.  
  770.        2.2. If the value of allOrFirstTier is firstTierRecipients, do
  771.             one of the following two steps based on the presence of an
  772.             mlExpansionHistory attribute in an outer signedData block:
  773.  
  774.            2.2.1. If an mlExpansionHistory attribute is present, then
  775.                   this recipient is not a first tier recipient and a
  776.                   signed receipt MUST NOT be created.
  777.  
  778.            2.2.2. If an mlExpansionHistory attribute is not present,
  779.                   then a signed receipt SHOULD be created.
  780.  
  781.    3. If the receiptsFrom value of the receiptRequest attribute is a
  782.       receiptList:
  783.  
  784.  
  785.  
  786. Hoffman                     Standards Track                    [Page 14]
  787.  
  788. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  789.  
  790.  
  791.  
  792.        3.1. If receiptList contains one of the GeneralNames of the
  793.             recipient, then a signed receipt SHOULD be created.
  794.  
  795.        3.2. If receiptList does not contain one of the GeneralNames of
  796.             the recipient, then a signed receipt MUST NOT be created.
  797.  
  798.    A flow chart for the above steps to be executed for each signerInfo
  799.    for which the receiving agent verifies the signature would be:
  800.  
  801.    0. Receipt Request attribute present?
  802.           YES -> 1.
  803.           NO  -> STOP
  804.    1. Has mlExpansionHistory in outer signedData?
  805.           YES -> 1.1.
  806.           NO  -> 2.
  807.    1.1. mlReceiptPolicy absent?
  808.           YES -> 2.
  809.           NO  -> 1.2.
  810.    1.2. Pick based on value of mlReceiptPolicy.
  811.           none -> 1.2.1.
  812.           insteadOf or inAdditionTo -> 1.2.2.
  813.    1.2.1. STOP.
  814.    1.2.2. Examine receiptsFrom to determine if a receipt should be
  815.        created, create it if required, send it to recipients designated
  816.        by mlReceiptPolicy, then -> STOP.
  817.    2. Is value of receiptsFrom allOrFirstTier?
  818.           YES -> Pick based on value of allOrFirstTier.
  819.                 allReceipts -> 2.1.
  820.                 firstTierRecipients -> 2.2.
  821.           NO  -> 3.
  822.    2.1. Create a receipt, then -> STOP.
  823.    2.2. Has mlExpansionHistory in the outer signedData block?
  824.           YES -> 2.2.1.
  825.           NO  -> 2.2.2.
  826.    2.2.1. STOP.
  827.    2.2.2. Create a receipt, then -> STOP.
  828.    3. Is receiptsFrom value of receiptRequest a receiptList?
  829.           YES -> 3.1.
  830.           NO  -> STOP.
  831.    3.1. Does receiptList contain the recipient?
  832.           YES -> Create a receipt, then -> STOP.
  833.           NO  -> 3.2.
  834.    3.2. STOP.
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Hoffman                     Standards Track                    [Page 15]
  843.  
  844. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  845.  
  846.  
  847. 2.4 Signed Receipt Creation
  848.  
  849.    A signed receipt is a signedData object encapsulating a Receipt
  850.    content (also called a "signedData/Receipt"). Signed receipts are
  851.    created as follows:
  852.  
  853.    1. The signature of the original signedData signerInfo that includes
  854.       the receiptRequest signed attribute MUST be successfully verified
  855.       before creating the signedData/Receipt.
  856.  
  857.        1.1. The content of the original signedData object is digested as
  858.             described in [CMS]. The resulting digest value is then
  859.             compared with the value of the messageDigest attribute
  860.             included in the signedAttributes of the original signedData
  861.             signerInfo. If these digest values are different, then the
  862.             signature verification process fails and the
  863.             signedData/Receipt MUST NOT be created.
  864.  
  865.        1.2. The ASN.1 DER encoded signedAttributes (including
  866.             messageDigest, receiptRequest and, possibly, other signed
  867.             attributes) in the original signedData signerInfo are
  868.             digested as described in [CMS]. The resulting digest
  869.             value, called msgSigDigest, is then used to verify the
  870.             signature of the original signedData signerInfo. If the
  871.             signature verification fails, then the signedData/Receipt
  872.             MUST NOT be created.
  873.  
  874.    2. A Receipt structure is created.
  875.  
  876.        2.1. The value of the Receipt version field is set to 1.
  877.  
  878.        2.2. The object identifier from the contentType attribute
  879.             included in the original signedData signerInfo that
  880.             includes the receiptRequest attribute is copied into
  881.             the Receipt contentType.
  882.  
  883.        2.3. The original signedData signerInfo receiptRequest
  884.             signedContentIdentifier is copied into the Receipt
  885.             signedContentIdentifier.
  886.  
  887.        2.4. The signature value from the original signedData signerInfo
  888.             that includes the receiptRequest attribute is copied into
  889.             the Receipt originatorSignatureValue.
  890.  
  891.    3. The Receipt structure is ASN.1 DER encoded to produce a data
  892.       stream, D1.
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Hoffman                     Standards Track                    [Page 16]
  899.  
  900. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  901.  
  902.  
  903.    4. D1 is digested. The resulting digest value is included as the
  904.       messageDigest attribute in the signedAttributes of the signerInfo
  905.       which will eventually contain the signedData/Receipt signature
  906.       value.
  907.  
  908.    5. The digest value (msgSigDigest) calculated in Step 1 to verify the
  909.       signature of the original signedData signerInfo is included as the
  910.       msgSigDigest attribute in the signedAttributes of the signerInfo
  911.       which will eventually contain the signedData/Receipt signature
  912.       value.
  913.  
  914.    6. A contentType attribute including the id-ct-receipt object
  915.       identifier MUST be created and added to the signed attributes of
  916.       the signerInfo which will eventually contain the
  917.       signedData/Receipt signature value.
  918.  
  919.    7. A signingTime attribute indicating the time that the
  920.       signedData/Receipt is signed SHOULD be created and added to the
  921.       signed attributes of the signerInfo which will eventually contain
  922.       the signedData/Receipt signature value. Other attributes (except
  923.       receiptRequest) may be added to the signedAttributes of the
  924.       signerInfo.
  925.  
  926.    8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
  927.       possibly, others) of the signerInfo are ASN.1 DER encoded and
  928.       digested as described in [CMS]. The resulting digest value is used
  929.       to calculate the signature value which is then included in the
  930.       signedData/Receipt signerInfo.
  931.  
  932.    9. The ASN.1 DER encoded Receipt content MUST be directly encoded
  933.       within the signedData encapContentInfo eContent OCTET STRING
  934.       defined in [CMS]. The id-ct-receipt object identifier MUST be
  935.       included in the signedData encapContentInfo eContentType. This
  936.       results in a single ASN.1 encoded object composed of a signedData
  937.       including the Receipt content. The Data content type MUST NOT be
  938.       used.  The Receipt content MUST NOT be encapsulated in a MIME
  939.       header or any other header prior to being encoded as part of the
  940.       signedData object.
  941.  
  942.    10. The signedData/Receipt is then put in an application/pkcs7-mime
  943.        MIME wrapper with the smime-type parameter set to
  944.        "signed-receipt".  This will allow for identification of signed
  945.        receipts without having to crack the ASN.1 body. The smime-type
  946.        parameter would still be set as normal in any layer wrapped
  947.        around this message.
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Hoffman                     Standards Track                    [Page 17]
  955.  
  956. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  957.  
  958.  
  959.    11. If the signedData/Receipt is to be encrypted within an
  960.        envelopedData object, then an outer signedData object MUST be
  961.        created that encapsulates the envelopedData object, and a
  962.        contentHints attribute with contentType set to the id-ct-receipt
  963.        object identifier MUST be included in the outer signedData
  964.        SignerInfo signedAttributes.  When a receiving agent processes the
  965.        outer signedData object, the presence of the id-ct-receipt OID in
  966.        the contentHints contentType indicates that a signedData/Receipt
  967.        is encrypted within the envelopedData object encapsulated by the
  968.        outer signedData.
  969.  
  970.    All sending agents that support the generation of ESS signed receipts
  971.    MUST provide the ability to send encrypted signed receipts (that is,
  972.    a signedData/Receipt encapsulated within an envelopedData). The
  973.    sending agent MAY send an encrypted signed receipt in response to an
  974.    envelopedData-encapsulated signedData requesting a signed receipt. It
  975.    is a matter of local policy regarding whether or not the signed
  976.    receipt should be encrypted.  The ESS signed receipt includes the
  977.    message digest value calculated for the original signedData object
  978.    that requested the signed receipt. If the original signedData object
  979.    was sent encrypted within an envelopedData object and the ESS signed
  980.    receipt is sent unencrypted, then the message digest value calculated
  981.    for the original encrypted signedData object is sent unencrypted. The
  982.    responder should consider this when deciding whether or not to
  983.    encrypt the ESS signed receipt.
  984.  
  985. 2.4.1 MLExpansionHistory Attributes and Receipts
  986.  
  987.    An MLExpansionHistory attribute MUST NOT be included in the
  988.    attributes of a SignerInfo in a SignedData object that encapsulates a
  989.    Receipt content. This is true because when a SignedData/Receipt is
  990.    sent to an MLA for distribution, then the MLA must always encapsulate
  991.    the received SignedData/Receipt in an outer SignedData in which the
  992.    MLA will include the MLExpansionHistory attribute. The MLA cannot
  993.    change the signedAttributes of the received SignedData/Receipt
  994.    object, so it can't add the MLExpansionHistory to the
  995.    SignedData/Receipt.
  996.  
  997. 2.5 Determining the Recipients of the Signed Receipt
  998.  
  999.    If a signed receipt was created by the process described in the
  1000.    sections above, then the software MUST use the following process to
  1001.    determine to whom the signed receipt should be sent.
  1002.  
  1003.    1. The receiptsTo field must be present in the receiptRequest
  1004.       attribute. The software initiates the sequence of recipients with
  1005.       the value(s) of receiptsTo.
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Hoffman                     Standards Track                    [Page 18]
  1011.  
  1012. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1013.  
  1014.  
  1015.    2. If the MlExpansionHistory attribute is present in the outer
  1016.       SignedData block, and the last MLData contains an MLReceiptPolicy
  1017.       value of insteadOf, then the software replaces the sequence of
  1018.       recipients with the value(s) of insteadOf.
  1019.  
  1020.    3. If the MlExpansionHistory attribute is present in the outer
  1021.       SignedData block and the last MLData contains an MLReceiptPolicy
  1022.       value of inAdditionTo, then the software adds the value(s) of
  1023.       inAdditionTo to the sequence of recipients.
  1024.  
  1025. 2.6. Signed Receipt Validation
  1026.  
  1027.    A signed receipt is communicated as a single ASN.1 encoded object
  1028.    composed of a signedData object directly including a Receipt content.
  1029.    It is identified by the presence of the id-ct-receipt object
  1030.    identifier in the encapContentInfo eContentType value of the
  1031.    signedData object including the Receipt content.
  1032.  
  1033.    Although recipients are not supposed to send more than one signed
  1034.    receipt, receiving agents SHOULD be able to accept multiple signed
  1035.    receipts from a recipient.
  1036.  
  1037.    A signedData/Receipt is validated as follows:
  1038.  
  1039.    1. ASN.1 decode the signedData object including the Receipt content.
  1040.  
  1041.    2. Extract the contentType, signedContentIdentifier, and
  1042.       originatorSignatureValue from the decoded Receipt structure to
  1043.       identify the original signedData signerInfo that requested the
  1044.       signedData/Receipt.
  1045.  
  1046.    3. Acquire the message signature digest value calculated by the sender
  1047.       to generate the signature value included in the original signedData
  1048.       signerInfo that requested the signedData/Receipt.
  1049.  
  1050.        3.1. If the sender-calculated message signature digest value has
  1051.             been saved locally by the sender, it must be located and
  1052.             retrieved.
  1053.  
  1054.        3.2. If it has not been saved, then it must be re-calculated based
  1055.             on the original signedData content and signedAttributes as
  1056.             described in [CMS].
  1057.  
  1058.    4. The message signature digest value calculated by the sender is then
  1059.       compared with the value of the msgSigDigest signedAttribute
  1060.       included in the signedData/Receipt signerInfo. If these digest
  1061.       values are identical, then that proves that the message signature
  1062.       digest value calculated by the recipient based on the received
  1063.  
  1064.  
  1065.  
  1066. Hoffman                     Standards Track                    [Page 19]
  1067.  
  1068. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1069.  
  1070.  
  1071.       original signedData object is the same as that calculated by the
  1072.       sender. This proves that the recipient received exactly the same
  1073.       original signedData content and signedAttributes as sent by the
  1074.       sender because that is the only way that the recipient could have
  1075.       calculated the same message signature digest value as calculated by
  1076.       the sender.  If the digest values are different, then the
  1077.       signedData/Receipt signature verification process fails.
  1078.  
  1079.    5. Acquire the digest value calculated by the sender for the Receipt
  1080.       content constructed by the sender (including the contentType,
  1081.       signedContentIdentifier, and signature value that were included in
  1082.       the original signedData signerInfo that requested the
  1083.       signedData/Receipt).
  1084.  
  1085.        5.1. If the sender-calculated Receipt content digest value has
  1086.             been  saved locally by the sender, it must be located and
  1087.             retrieved.
  1088.  
  1089.        5.2. If it has not been saved, then it must be re-calculated. As
  1090.             described in section above, step 2, create a Receipt
  1091.             structure including the contentType, signedContentIdentifier
  1092.             and signature value that were included in the original
  1093.             signedData signerInfo that requested the signed receipt. The
  1094.             Receipt structure is then ASN.1 DER encoded to produce a data
  1095.             stream which is then digested to produce the Receipt content
  1096.             digest value.
  1097.  
  1098.    6. The Receipt content digest value calculated by the sender is then
  1099.       compared with the value of the messageDigest signedAttribute
  1100.       included in the signedData/Receipt signerInfo. If these digest
  1101.       values are identical, then that proves that the values included in
  1102.       the Receipt content by the recipient are identical to those that
  1103.       were included in the original signedData signerInfo that requested
  1104.       the signedData/Receipt. This proves that the recipient received the
  1105.       original signedData signed by the sender, because that is the only
  1106.       way that the recipient could have obtained the original signedData
  1107.       signerInfo signature value for inclusion in the Receipt content. If
  1108.       the digest values are different, then the signedData/Receipt
  1109.       signature verification process fails.
  1110.  
  1111.    7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
  1112.       signerInfo are digested as described in [CMS].
  1113.  
  1114.    8. The resulting digest value is then used to verify the signature
  1115.       value included in the signedData/Receipt signerInfo. If the
  1116.       signature verification is successful, then that proves the
  1117.       integrity of the signedData/receipt signerInfo signedAttributes and
  1118.       authenticates the identity of the signer of the signedData/Receipt
  1119.  
  1120.  
  1121.  
  1122. Hoffman                     Standards Track                    [Page 20]
  1123.  
  1124. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1125.  
  1126.  
  1127.       signerInfo. Note that the signedAttributes include the
  1128.       recipient-calculated Receipt content digest value (messageDigest
  1129.       attribute) and recipient-calculated message signature digest value
  1130.       (msgSigDigest attribute). Therefore, the aforementioned comparison
  1131.       of the sender-generated and recipient-generated digest values
  1132.       combined with the successful signedData/Receipt signature
  1133.       verification proves that the recipient received the exact original
  1134.       signedData content and signedAttributes (proven by msgSigDigest
  1135.       attribute) that were signed by the sender of the original
  1136.       signedData object (proven by messageDigest attribute). If the
  1137.       signature verification fails, then the signedData/Receipt signature
  1138.       verification process fails.
  1139.  
  1140.    The signature verification process for each signature algorithm that
  1141.    is used in conjunction with the CMS protocol is specific to the
  1142.    algorithm.  These processes are described in documents specific to
  1143.    the algorithms.
  1144.  
  1145. 2. 7 Receipt Request Syntax
  1146.  
  1147.    A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use
  1148.    the receiptRequest attribute only within the signed attributes
  1149.    associated with a signed message.
  1150.  
  1151. ReceiptRequest ::= SEQUENCE {
  1152.   signedContentIdentifier ContentIdentifier,
  1153.   receiptsFrom ReceiptsFrom,
  1154.   receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
  1155.  
  1156. ub-receiptsTo INTEGER ::= 16
  1157.  
  1158. id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  1159.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
  1160.  
  1161. ContentIdentifier ::= OCTET STRING
  1162.  
  1163. id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  1164.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
  1165.  
  1166.    A signedContentIdentifier MUST be created by the message originator
  1167.    when creating a receipt request. To ensure global uniqueness, the
  1168.    minimal signedContentIdentifier SHOULD contain a concatenation of
  1169.    user-specific identification information (such as a user name or
  1170.    public keying material identification information), a GeneralizedTime
  1171.    string, and a random number.
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Hoffman                     Standards Track                    [Page 21]
  1179.  
  1180. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1181.  
  1182.  
  1183.    The receiptsFrom field is used by the originator to specify the
  1184.    recipients requested to return a signed receipt. A CHOICE is provided
  1185.    to allow specification of:
  1186.  
  1187.     - receipts from all recipients are requested
  1188.     - receipts from first tier (recipients that did not receive the
  1189.       message as members of a mailing list) recipients are requested
  1190.     - receipts from a specific list of recipients are requested
  1191.  
  1192.    ReceiptsFrom ::= CHOICE {
  1193.      allOrFirstTier [0] AllOrFirstTier,
  1194.      -- formerly "allOrNone [0]AllOrNone"
  1195.      receiptList [1] SEQUENCE OF GeneralNames }
  1196.  
  1197.    AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
  1198.      allReceipts (0),
  1199.      firstTierRecipients (1) }
  1200.  
  1201.    The receiptsTo field is used by the originator to identify the
  1202.    user(s) to whom the identified recipient should send signed receipts.
  1203.    The message originator MUST populate the receiptsTo field with a
  1204.    GeneralNames for each entity to whom the recipient should send the
  1205.    signed receipt. If the message originator wants the recipient to send
  1206.    the signed receipt to the originator, then the originator MUST
  1207.    include a GeneralNames for itself in the receiptsTo field.
  1208.  
  1209. 2.8 Receipt Syntax
  1210.  
  1211.    Receipts are represented using a new content type, Receipt. The
  1212.    Receipt content type shall have ASN.1 type Receipt. Receipts must be
  1213.    encapsulated within a SignedData message.
  1214.  
  1215. Receipt ::= SEQUENCE {
  1216.   version ESSVersion,
  1217.   contentType ContentType,
  1218.   signedContentIdentifier ContentIdentifier,
  1219.   originatorSignatureValue OCTET STRING }
  1220.  
  1221. id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  1222.    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
  1223.  
  1224. ESSVersion ::= INTEGER  { v1(1) }
  1225.  
  1226.    The version field defines the syntax version number, which is 1 for
  1227.    this version of the standard.
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Hoffman                     Standards Track                    [Page 22]
  1235.  
  1236. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1237.  
  1238.  
  1239. 2.9 Content Hints
  1240.  
  1241.    Many applications find it useful to have information that describes
  1242.    the innermost signed content of a multi-layer message available on
  1243.    the outermost signature layer. The contentHints attribute provides
  1244.    such information.
  1245.  
  1246. Content-hints attribute values have ASN.1 type contentHints.
  1247.  
  1248. ContentHints ::= SEQUENCE {
  1249.   contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  1250.   contentType ContentType }
  1251.  
  1252. id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  1253.     rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
  1254.  
  1255.    The contentDescription field may be used to provide information that
  1256.    the recipient may use to select protected messages for processing,
  1257.    such as a message subject. If this field is set, then the attribute
  1258.    is expected to appear on the signedData object enclosing an
  1259.    envelopedData object and not on the inner signedData object. The
  1260.    (SIZE (1..MAX)) construct constrains the sequence to have at least
  1261.    one entry. MAX indicates the upper bound is unspecified.
  1262.    Implementations are free to choose an upper bound that suits their
  1263.    environment.
  1264.  
  1265.    Messages which contain a signedData object wrapped around an
  1266.    envelopedData object, thus masking the inner content type of the
  1267.    message, SHOULD include a contentHints attribute, except for the case
  1268.    of the data content type. Specific message content types may either
  1269.    force or preclude the inclusion of the contentHints attribute. For
  1270.    example, when a signedData/Receipt is encrypted within an
  1271.    envelopedData object, an outer signedData object MUST be created that
  1272.    encapsulates the envelopedData object and a contentHints attribute
  1273.    with contentType set to the id-ct-receipt object identifier MUST be
  1274.    included in the outer signedData SignerInfo signedAttributes.
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Hoffman                     Standards Track                    [Page 23]
  1291.  
  1292. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1293.  
  1294.  
  1295. 2.10  Message Signature Digest Attribute
  1296.  
  1297.    The msgSigDigest attribute can only be used in the signed attributes
  1298.    of a signed receipt. It contains the digest of the ASN.1 DER encoded
  1299.    signedAttributes included in the original signedData that requested
  1300.    the signed receipt. Only one msgSigDigest attribute can appear in a
  1301.    signed attributes set. It is defined as follows:
  1302.  
  1303. msgSigDigest ::= OCTET STRING
  1304.  
  1305. id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  1306.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
  1307.  
  1308. 2.11 Signed Content Reference Attribute
  1309.  
  1310.    The contentReference attribute is a link from one SignedData to
  1311.    another. It may be used to link a reply to the original message to
  1312.    which it refers, or to incorporate by reference one SignedData into
  1313.    another. The first SignedData MUST include a contentIdentifier signed
  1314.    attribute, which SHOULD be constructed as specified in section 2.7.
  1315.    The second SignedData links to the first by including a
  1316.    ContentReference signed attribute containing the content type,
  1317.    content identifier, and signature value from the first SignedData.
  1318.  
  1319. ContentReference ::= SEQUENCE {
  1320.   contentType ContentType,
  1321.   signedContentIdentifier ContentIdentifier,
  1322.   originatorSignatureValue OCTET STRING }
  1323.  
  1324. id-aa-contentReference   OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  1325.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
  1326.  
  1327. 3. Security Labels
  1328.  
  1329.    This section describes the syntax to be used for security labels that
  1330.    can optionally be associated with S/MIME encapsulated data. A
  1331.    security label is a set of security information regarding the
  1332.    sensitivity of the content that is protected by S/MIME encapsulation.
  1333.  
  1334.    "Authorization" is the act of granting rights and/or privileges to
  1335.    users permitting them access to an object. "Access control" is a
  1336.    means of enforcing these authorizations. The sensitivity information
  1337.    in a security label can be compared with a user's authorizations to
  1338.    determine if the user is allowed to access the content that is
  1339.    protected by S/MIME encapsulation.
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Hoffman                     Standards Track                    [Page 24]
  1347.  
  1348. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1349.  
  1350.  
  1351.    Security labels may be used for other purposes such as a source of
  1352.    routing information. The labels often describe ranked levels
  1353.    ("secret", "confidential", "restricted", and so on) or are role-
  1354.    based, describing which kind of people can see the information
  1355.    ("patient's health-care team", "medical billing agents",
  1356.    "unrestricted", and so on).
  1357.  
  1358. 3.1 Security Label Processing Rules
  1359.  
  1360.    A sending agent may include a security label attribute in the signed
  1361.    attributes of a signedData object. A receiving agent examines the
  1362.    security label on a received message and determines whether or not
  1363.    the recipient is allowed to see the contents of the message.
  1364.  
  1365. 3.1.1 Adding Security Labels
  1366.  
  1367.    A sending agent that is using security labels MUST put the security
  1368.    label attribute in the signedAttributes field of a SignerInfo block.
  1369.    The security label attribute MUST NOT be included in the unsigned
  1370.    attributes. Integrity and authentication security services MUST be
  1371.    applied to the security label, therefore it MUST be included as a
  1372.    signed attribute, if used. This causes the security label attribute
  1373.    to be part of the data that is hashed to form the SignerInfo
  1374.    signature value. A SignerInfo block MUST NOT have more than one
  1375.    security label signed attribute.
  1376.  
  1377.    When there are multiple SignedData blocks applied to a message, a
  1378.    security label attribute may be included in either the inner
  1379.    signature, outer signature, or both. A security label signed
  1380.    attribute may be included in a signedAttributes field within the
  1381.    inner SignedData block.  The inner security label will include the
  1382.    sensitivities of the original content and will be used for access
  1383.    control decisions related to the plaintext encapsulated content. The
  1384.    inner signature provides authentication of the inner security label
  1385.    and cryptographically protects the original signer's inner security
  1386.    label of the original content.
  1387.  
  1388.    When the originator signs the plaintext content and signed
  1389.    attributes, the inner security label is bound to the plaintext
  1390.    content. An intermediate entity cannot change the inner security
  1391.    label without invalidating the inner signature. The confidentiality
  1392.    security service can be applied to the inner security label by
  1393.    encrypting the entire inner signedData object within an EnvelopedData
  1394.    block.
  1395.  
  1396.    A security label signed attribute may also be included in a
  1397.    signedAttributes field within the outer SignedData block. The outer
  1398.    security label will include the sensitivities of the encrypted
  1399.  
  1400.  
  1401.  
  1402. Hoffman                     Standards Track                    [Page 25]
  1403.  
  1404. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1405.  
  1406.  
  1407.    message and will be used for access control decisions related to the
  1408.    encrypted message and for routing decisions. The outer signature
  1409.    provides authentication of the outer security label (as well as for
  1410.    the encapsulated content which may include nested S/MIME messages).
  1411.  
  1412.    There can be multiple SignerInfos within a SignedData object, and
  1413.    each SignerInfo may include signedAttributes. Therefore, a single
  1414.    SignedData object may include multiple eSSSecurityLabels, each
  1415.    SignerInfo having an eSSSecurityLabel attribute. For example, an
  1416.    originator can send a signed message with two SignerInfos, one
  1417.    containing a DSS signature, the other containing an RSA signature. If
  1418.    any of the SignerInfos included in a SignedData object include an
  1419.    eSSSecurityLabel attribute, then all of the SignerInfos in that
  1420.    SignedData object MUST include an eSSSecurityLabel attribute and the
  1421.    value of each MUST be identical.
  1422.  
  1423. 3.1.2 Processing Security Labels
  1424.  
  1425.    Before processing an eSSSecurityLabel signedAttribute, the receiving
  1426.    agent MUST verify the signature of the SignerInfo which covers the
  1427.    eSSSecurityLabel attribute. A recipient MUST NOT process an
  1428.    eSSSecurityLabel attribute that has not been verified.
  1429.  
  1430.    A receiving agent MUST process the eSSSecurityLabel attribute, if
  1431.    present, in each SignerInfo in the SignedData object for which it
  1432.    verifies the signature. This may result in the receiving agent
  1433.    processing multiple eSSSecurityLabels included in a single SignedData
  1434.    object. Because all eSSSecurityLabels in a SignedData object must be
  1435.    identical, the receiving agent processes (such as performing access
  1436.    control) on the first eSSSecurityLabel that it encounters in a
  1437.    SignerInfo that it verifies, and then ensures that all other
  1438.    eSSSecurityLabels in signerInfos that it verifies are identical to
  1439.    the first one encountered. If the eSSSecurityLabels in the
  1440.    signerInfos that it verifies are not all identical, then the
  1441.    receiving agent MUST warn the user of this condition.
  1442.  
  1443.    Receiving agents SHOULD have a local policy regarding whether or not
  1444.    to show the inner content of a signedData object that includes an
  1445.    eSSSecurityLabel security-policy-identifier that the processing
  1446.    software does not recognize. If the receiving agent does not
  1447.    recognize the eSSSecurityLabel security-policy-identifier value, then
  1448.    it SHOULD stop processing the message and indicate an error.
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Hoffman                     Standards Track                    [Page 26]
  1459.  
  1460. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1461.  
  1462.  
  1463. 3.2 Syntax of eSSSecurityLabel
  1464.  
  1465.    The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1
  1466.    module. (The MTSAbstractService module begins with "DEFINITIONS
  1467.    IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
  1468.    compatible with that used in [MSP4].
  1469.  
  1470. ESSSecurityLabel ::= SET {
  1471.   security-policy-identifier SecurityPolicyIdentifier,
  1472.   security-classification SecurityClassification OPTIONAL,
  1473.   privacy-mark ESSPrivacyMark OPTIONAL,
  1474.   security-categories SecurityCategories OPTIONAL }
  1475.  
  1476. id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  1477.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
  1478.  
  1479. SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
  1480.  
  1481. SecurityClassification ::= INTEGER {
  1482.   unmarked (0),
  1483.   unclassified (1),
  1484.   restricted (2),
  1485.   confidential (3),
  1486.   secret (4),
  1487.   top-secret (5) } (0..ub-integer-options)
  1488.  
  1489. ub-integer-options INTEGER ::= 256
  1490.  
  1491. ESSPrivacyMark ::= CHOICE {
  1492.     pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
  1493.     utf8String   UTF8String (SIZE (1..MAX))
  1494. }
  1495.  
  1496. ub-privacy-mark-length INTEGER ::= 128
  1497.  
  1498. SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
  1499.         SecurityCategory
  1500.  
  1501. ub-security-categories INTEGER ::= 64
  1502.  
  1503. SecurityCategory ::= SEQUENCE {
  1504.   type  [0] OBJECT IDENTIFIER,
  1505.   value [1] ANY DEFINED BY type -- defined by type
  1506. }
  1507.  
  1508. --Note: The aforementioned SecurityCategory syntax produces identical
  1509. --hex encodings as the following SecurityCategory syntax that is
  1510. --documented in the X.411 specification:
  1511.  
  1512.  
  1513.  
  1514. Hoffman                     Standards Track                    [Page 27]
  1515.  
  1516. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1517.  
  1518.  
  1519. --
  1520. --SecurityCategory ::= SEQUENCE {
  1521. --     type  [0]  SECURITY-CATEGORY,
  1522. --     value [1]  ANY DEFINED BY type }
  1523. --
  1524. --SECURITY-CATEGORY MACRO ::=
  1525. --BEGIN
  1526. --TYPE NOTATION ::= type | empty
  1527. --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
  1528. --END
  1529.  
  1530. 3.3  Security Label Components
  1531.  
  1532.    This section gives more detail on the the various components of the
  1533.    eSSSecurityLabel syntax.
  1534.  
  1535. 3.3.1 Security Policy Identifier
  1536.  
  1537.    A security policy is a set of criteria for the provision of security
  1538.    services. The eSSSecurityLabel security-policy-identifier is used to
  1539.    identify the security policy in force to which the security label
  1540.    relates. It indicates the semantics of the other security label
  1541.    components.
  1542.  
  1543. 3.3.2 Security Classification
  1544.  
  1545.    This specification defines the use of the Security Classification
  1546.    field exactly as is specified in the X.411 Recommendation, which
  1547.    states in part:
  1548.  
  1549.       If present, a security-classification may have one of a
  1550.       hierarchical list of values. The basic security-classification
  1551.       hierarchy is defined in this Recommendation, but the use of these
  1552.       values is defined by the security-policy in force. Additional
  1553.       values of security-classification, and their position in the
  1554.       hierarchy, may also be defined by a security-policy as a local
  1555.       matter or by bilateral agreement. The basic security-
  1556.       classification hierarchy is, in ascending order: unmarked,
  1557.       unclassified, restricted, confidential, secret, top-secret.
  1558.  
  1559.    This means that the security policy in force (identified by the
  1560.    eSSSecurityLabel security-policy-identifier) defines the
  1561.    SecurityClassification integer values and their meanings.
  1562.  
  1563.    An organization can develop its own security policy that defines the
  1564.    SecurityClassification INTEGER values and their meanings. However,
  1565.    the general interpretation of the X.411 specification is that the
  1566.    values of 0 through 5 are reserved for the "basic hierarchy" values
  1567.  
  1568.  
  1569.  
  1570. Hoffman                     Standards Track                    [Page 28]
  1571.  
  1572. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1573.  
  1574.  
  1575.    of unmarked, unclassified, restricted, confidential, secret, and
  1576.    top-secret. Note that X.411 does not provide the rules for how these
  1577.    values are used to label data and how access control is performed
  1578.    using these values.
  1579.  
  1580.    There is no universal definition of the rules for using these "basic
  1581.    hierarchy" values. Each organization (or group of organizations) will
  1582.    define a security policy which documents how the "basic hierarchy"
  1583.    values are used (if at all) and how access control is enforced (if at
  1584.    all) within their domain.
  1585.  
  1586.    Therefore, the security-classification value MUST be accompanied by a
  1587.    security-policy-identifier value to define the rules for its use. For
  1588.    example, a company's "secret" classification may convey a different
  1589.    meaning than the US Government "secret" classification. In summary, a
  1590.    security policy SHOULD NOT use integers 0 through 5 for other than
  1591.    their X.411 meanings, and SHOULD instead use other values in a
  1592.    hierarchical fashion.
  1593.  
  1594.    Note that the set of valid security-classification values MUST be
  1595.    hierarchical, but these values do not necessarily need to be in
  1596.    ascending numerical order. Further, the values do not need to be
  1597.    contiguous.
  1598.  
  1599.    For example, in the Defense Message System 1.0 security policy, the
  1600.    security-classification value of 11 indicates Sensitive-But-
  1601.    Unclassified and 5 indicates top-secret. The hierarchy of sensitivity
  1602.    ranks top-secret as more sensitive than Sensitive-But-Unclassified
  1603.    even though the numerical value of top-secret is less than
  1604.    Sensitive-But-Unclassified.
  1605.  
  1606.    (Of course, if security-classification values are both hierarchical
  1607.    and in ascending order, a casual reader of the security policy is
  1608.    more likely to understand it.)
  1609.  
  1610.    An example of a security policy that does not use any of the X.411
  1611.    values might be:
  1612.  
  1613.    10 -- anyone
  1614.    15 -- Morgan Corporation and its contractors
  1615.    20 -- Morgan Corporation employees
  1616.    25 -- Morgan Corporation board of directors
  1617.  
  1618.    An example of a security policy that uses part of the X.411 hierarchy
  1619.    might be:
  1620.  
  1621.    0 -- unmarked
  1622.    1 -- unclassified, can be read by everyone
  1623.  
  1624.  
  1625.  
  1626. Hoffman                     Standards Track                    [Page 29]
  1627.  
  1628. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1629.  
  1630.  
  1631.    2 -- restricted to Timberwolf Productions staff
  1632.    6 -- can only be read to Timberwolf Productions executives
  1633.  
  1634. 3.3.3 Privacy Mark
  1635.  
  1636.    If present, the eSSSecurityLabel privacy-mark is not used for access
  1637.    control. The content of the eSSSecurityLabel privacy-mark may be
  1638.    defined by the security policy in force (identified by the
  1639.    eSSSecurityLabel security-policy-identifier) which may define a list
  1640.    of values to be used. Alternately, the value may be determined by the
  1641.    originator of the security-label.
  1642.  
  1643. 3.3.4 Security Categories
  1644.  
  1645.    If present, the eSSSecurityLabel security-categories provide further
  1646.    granularity for the sensitivity of the message. The security policy
  1647.    in force (identified by the eSSSecurityLabel security-policy-
  1648.    identifier) is used to indicate the syntaxes that are allowed to be
  1649.    present in the eSSSecurityLabel security-categories. Alternately, the
  1650.    security-categories and their values may be defined by bilateral
  1651.    agreement.
  1652.  
  1653. 3.4  Equivalent Security Labels
  1654.  
  1655.    Because organizations are allowed to define their own security
  1656.    policies, many different security policies will exist. Some
  1657.    organizations may wish to create equivalencies between their security
  1658.    policies with the security policies of other organizations. For
  1659.    example, the Acme Company and the Widget Corporation may reach a
  1660.    bilateral agreement that the "Acme private" security-classification
  1661.    value is equivalent to the "Widget sensitive" security-classification
  1662.    value.
  1663.  
  1664.    Receiving agents MUST NOT process an equivalentLabels attribute in a
  1665.    message if the agent does not trust the signer of that attribute to
  1666.    translate the original eSSSecurityLabel values to the security policy
  1667.    included in the equivalentLabels attribute. Receiving agents have the
  1668.    option to process equivalentLabels attributes but do not have to. It
  1669.    is acceptable for a receiving agent to only process
  1670.    eSSSecurityLabels. All receiving agents SHOULD recognize
  1671.    equivalentLabels attributes even if they do not process them.
  1672.  
  1673. 3.4.1 Creating Equivalent Labels
  1674.  
  1675.    The EquivalentLabels signed attribute is defined as:
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Hoffman                     Standards Track                    [Page 30]
  1683.  
  1684. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1685.  
  1686.  
  1687. EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
  1688.  
  1689. id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  1690.         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
  1691.  
  1692.    As stated earlier, the ESSSecurityLabel contains the sensitivity
  1693.    values selected by the original signer of the signedData. If an
  1694.    ESSSecurityLabel is present in a signerInfo, all signerInfos in the
  1695.    signedData MUST contain an ESSSecurityLabel and they MUST all be
  1696.    identical. In addition to an ESSSecurityLabel, a signerInfo MAY also
  1697.    include an equivalentLabels signed attribute. If present, the
  1698.    equivalentLabels attribute MUST include one or more security labels
  1699.    that are believed by the signer to be semantically equivalent to the
  1700.    ESSSecurityLabel attribute included in the same signerInfo.
  1701.  
  1702.    All security-policy object identifiers MUST be unique in the set of
  1703.    ESSSecurityLabel and EquivalentLabels security labels. Before using
  1704.    an EquivalentLabels attribute, a receiving agent MUST ensure that all
  1705.    security-policy OIDs are unique in the security label or labels
  1706.    included in the EquivalentLabels. Once the receiving agent selects
  1707.    the security label (within the EquivalentLabels) to be used for
  1708.    processing, then the security-policy OID of the selected
  1709.    EquivalentLabels security label MUST be compared with the
  1710.    ESSSecurityLabel security-policy OID to ensure that they are unique.
  1711.  
  1712.    In the case that an ESSSecurityLabel attribute is not included in a
  1713.    signerInfo, then an EquivalentLabels attribute may still be included.
  1714.    For example, in the Acme security policy, the absence of an
  1715.    ESSSecurityLabel could be defined to equate to a security label
  1716.    composed of the Acme security-policy OID and the "unmarked"
  1717.    security-classification.
  1718.  
  1719.    Note that equivalentLabels MUST NOT be used to convey security labels
  1720.    that are semantically different from the ESSSecurityLabel included in
  1721.    the signerInfos in the signedData. If an entity needs to apply a
  1722.    security label that is semantically different from the
  1723.    ESSSecurityLabel, then it MUST include the sematically different
  1724.    security label in an outer signedData object that encapsulates the
  1725.    signedData object that includes the ESSSecurityLabel.
  1726.  
  1727.    If present, the equivalentLabels attribute MUST be a signed
  1728.    attribute; it MUST NOT be an unsigned attribute. [CMS] defines
  1729.    signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include
  1730.    multiple instances of the equivalentLabels attribute. CMS defines the
  1731.    ASN.1 syntax for the signed attributes to include attrValues SET OF
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Hoffman                     Standards Track                    [Page 31]
  1739.  
  1740. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1741.  
  1742.  
  1743.    AttributeValue. A equivalentLabels attribute MUST only include a
  1744.    single instance of AttributeValue. There MUST NOT be zero or multiple
  1745.    instances of AttributeValue present in the attrValues SET OF
  1746.    AttributeValue.
  1747.  
  1748. 3.4.2 Processing Equivalent Labels
  1749.  
  1750.    A receiving agent SHOULD process the ESSSecurityLabel before
  1751.    processing any EquivalentLabels. If the policy in the
  1752.    ESSSecurityLabel is understood by the receiving agent, it MUST
  1753.    process that label and MUST ignore all EquivalentLabels.
  1754.  
  1755.    When processing an EquivalentLabels attribute, the receiving agent
  1756.    MUST validate the signature on the EquivalentLabels attribute. A
  1757.    receiving agent MUST NOT act on an equivalentLabels attribute for
  1758.    which the signature could not be validated, and MUST NOT act on an
  1759.    equivalentLabels attribute unless that attribute is signed by an
  1760.    entity trusted to translate the original eSSSecurityLabel values to
  1761.    the security policy included in the equivalentLabels attribute.
  1762.    Determining who is allowed to specify equivalence mappings is a local
  1763.    policy. If a message has more than one EquivalentLabels attribute,
  1764.    the receiving agent SHOULD process the first one that it reads and
  1765.    validates that contains the security policy of interest to the
  1766.    receiving agent.
  1767.  
  1768. 4. Mail List Management
  1769.  
  1770.    Sending agents must create recipient-specific data structures for
  1771.    each recipient of an encrypted message. This process can impair
  1772.    performance for messages sent to a large number of recipients. Thus,
  1773.    Mail List Agents (MLAs) that can take a single message and perform
  1774.    the recipient-specific encryption for every recipient are often
  1775.    desired.
  1776.  
  1777.    An MLA appears to the message originator as a normal message
  1778.    recipient, but the MLA acts as a message expansion point for a Mail
  1779.    List (ML). The sender of a message directs the message to the MLA,
  1780.    which then redistributes the message to the members of the ML. This
  1781.    process offloads the per-recipient processing from individual user
  1782.    agents and allows for more efficient management of large MLs. MLs are
  1783.    true message recipients served by MLAs that provide cryptographic and
  1784.    expansion services for the mailing list.
  1785.  
  1786.    In addition to cryptographic handling of messages, secure mailing
  1787.    lists also have to prevent mail loops. A mail loop is where one
  1788.    mailing list is a member of a second mailing list, and the second
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Hoffman                     Standards Track                    [Page 32]
  1795.  
  1796. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1797.  
  1798.  
  1799.    mailing list is a member of the first. A message will go from one
  1800.    list to the other in a rapidly-cascading succession of mail that will
  1801.    be distributed to all other members of both lists.
  1802.  
  1803.    To prevent mail loops, MLAs use the mlExpansionHistory attribute of
  1804.    the outer signature of a triple wrapped message. The
  1805.    mlExpansionHistory attribute is essentially a list of every MLA that
  1806.    has processed the message. If an MLA sees its own unique entity
  1807.    identifier in the list, it knows that a loop has been formed, and
  1808.    does not send the message to the list again.
  1809.  
  1810. 4.1 Mail List Expansion
  1811.  
  1812.    Mail list expansion processing is noted in the value of the
  1813.    mlExpansionHistory attribute, located in the signed attributes of the
  1814.    MLA's SignerInfo block. The MLA creates or updates the signed
  1815.    mlExpansionHistory attribute value each time the MLA expands and
  1816.    signs a message for members of a mail list.
  1817.  
  1818.    The MLA MUST add an MLData record containing the MLA's identification
  1819.    information, date and time of expansion, and optional receipt policy
  1820.    to the end of the mail list expansion history sequence. If the
  1821.    mlExpansionHistory attribute is absent, then the MLA MUST add the
  1822.    attribute and the current expansion becomes the first element of the
  1823.    sequence. If the mlExpansionHistory attribute is present, then the
  1824.    MLA MUST add the current expansion information to the end of the
  1825.    existing MLExpansionHistory sequence. Only one mlExpansionHistory
  1826.    attribute can be included in the signedAttributes of a SignerInfo.
  1827.  
  1828.    Note that if the mlExpansionHistory attribute is absent, then the
  1829.    recipient is a first tier message recipient.
  1830.  
  1831.    There can be multiple SignerInfos within a SignedData object, and
  1832.    each SignerInfo may include signedAttributes. Therefore, a single
  1833.    SignedData object may include multiple SignerInfos, each SignerInfo
  1834.    having a mlExpansionHistory attribute. For example, an MLA can send a
  1835.    signed message with two SignerInfos, one containing a DSS signature,
  1836.    the other containing an RSA signature.
  1837.  
  1838.    If an MLA creates a SignerInfo that includes an mlExpansionHistory
  1839.    attribute, then all of the SignerInfos created by the MLA for that
  1840.    SignedData object MUST include an mlExpansionHistory attribute, and
  1841.    the value of each MUST be identical. Note that other agents might
  1842.    later add SignerInfo attributes to the SignedData block, and those
  1843.    additional SignerInfos might not include mlExpansionHistory
  1844.    attributes.
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Hoffman                     Standards Track                    [Page 33]
  1851.  
  1852. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1853.  
  1854.  
  1855.    A recipient MUST verify the signature of the SignerInfo which covers
  1856.    the mlExpansionHistory attribute before processing the
  1857.    mlExpansionHistory, and MUST NOT process the mlExpansionHistory
  1858.    attribute unless the signature over it has been verified. If a
  1859.    SignedData object has more than one SignerInfo that has an
  1860.    mlExpansionHistory attribute, the recipient MUST compare the
  1861.    mlExpansionHistory attributes in all the SignerInfos that it has
  1862.    verified, and MUST NOT process the mlExpansionHistory attribute
  1863.    unless every verified mlExpansionHistory attribute in the SignedData
  1864.    block is identical. If the mlExpansionHistory attributes in the
  1865.    verified signerInfos are not all identical, then the receiving agent
  1866.    MUST stop processing the message and SHOULD notify the user or MLA
  1867.    administrator of this error condition. In the mlExpansionHistory
  1868.    processing, SignerInfos that do not have an mlExpansionHistory
  1869.    attribute are ignored.
  1870.  
  1871. 4.1.1 Detecting Mail List Expansion Loops
  1872.  
  1873.    Prior to expanding a message, the MLA examines the value of any
  1874.    existing mail list expansion history attribute to detect an expansion
  1875.    loop. An expansion loop exists when a message expanded by a specific
  1876.    MLA for a specific mail list is redelivered to the same MLA for the
  1877.    same mail list.
  1878.  
  1879.    Expansion loops are detected by examining the mailListIdentifier
  1880.    field of each MLData entry found in the mail list expansion history.
  1881.    If an MLA finds its own identification information, then the MLA must
  1882.    discontinue expansion processing and should provide warning of an
  1883.    expansion loop to a human mail list administrator. The mail list
  1884.    administrator is responsible for correcting the loop condition.
  1885.  
  1886. 4.2 Mail List Agent Processing
  1887.  
  1888.    The first few paragraphs of this section provide a high-level
  1889.    description of MLA processing. The rest of the section provides a
  1890.    detailed description of MLA processing.
  1891.  
  1892.    MLA message processing depends on the structure of the S/MIME layers
  1893.    in the message sent to the MLA for expansion. In addition to sending
  1894.    triple wrapped messages to an MLA, an entity can send other types of
  1895.    messages to an MLA, such as:
  1896.  
  1897.     - a single wrapped signedData or envelopedData message
  1898.     - a double wrapped message (such as signed and enveloped, enveloped
  1899.       and signed, or signed and signed, and so on)
  1900.     - a quadruple-wrapped message (such as if a well-formed triple
  1901.       wrapped message was sent through a gateway that added an outer
  1902.       SignedData layer)
  1903.  
  1904.  
  1905.  
  1906. Hoffman                     Standards Track                    [Page 34]
  1907.  
  1908. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1909.  
  1910.  
  1911.    In all cases, the MLA MUST parse all layers of the received message
  1912.    to determine if there are any signedData layers that include an
  1913.    eSSSecurityLabel signedAttribute. This may include decrypting an
  1914.    EnvelopedData layer to determine if an encapsulated SignedData layer
  1915.    includes an eSSSecurityLabel attribute. The MLA MUST fully process
  1916.    each eSSSecurityLabel attribute found in the various signedData
  1917.    layers, including performing access control checks, before
  1918.    distributing the message to the ML members. The details of the access
  1919.    control checks are beyond the scope of this document. The MLA MUST
  1920.    verify the signature of the signerInfo including the eSSSecurityLabel
  1921.    attribute before using it.
  1922.  
  1923.    In all cases, the MLA MUST sign the message to be sent to the ML
  1924.    members in a new "outer" signedData layer. The MLA MUST add or update
  1925.    an mlExpansionHistory attribute in the "outer" signedData that it
  1926.    creates to document MLA processing. If there was an "outer"
  1927.    signedData layer included in the original message received by the
  1928.    MLA, then the MLA-created "outer" signedData layer MUST include each
  1929.    signed attribute present in the original "outer" signedData layer,
  1930.    unless the MLA explicitly replaces an attribute (such as signingTime
  1931.    or mlExpansionHistory) with a new value.
  1932.  
  1933.    When an S/MIME message is received by the MLA, the MLA MUST first
  1934.    determine which received signedData layer, if any, is the "outer"
  1935.    signedData layer.  To identify the received "outer" signedData layer,
  1936.    the MLA MUST verify the signature and fully process the
  1937.    signedAttributes in each of the outer signedData layers (working from
  1938.    the outside in) to determine if any of them either include an
  1939.    mlExpansionHistory attribute or encapsulate an envelopedData object.
  1940.  
  1941.    The MLA's search for the "outer" signedData layer is completed when
  1942.    it finds one of the following:
  1943.  
  1944.     - the "outer" signedData layer that includes an mlExpansionHistory
  1945.       attribute or encapsulates an envelopedData object
  1946.     - an envelopedData layer
  1947.     - the original content (that is, a layer that is neither
  1948.       envelopedData nor signedData).
  1949.  
  1950.    If the MLA finds an "outer" signedData layer, then the MLA MUST
  1951.    perform the following steps:
  1952.  
  1953.    1. Strip off all of the signedData layers that encapsulated the
  1954.       "outer" signedData layer
  1955.  
  1956.    2. Strip off the "outer" signedData layer itself (after remembering
  1957.       the included signedAttributes)
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Hoffman                     Standards Track                    [Page 35]
  1963.  
  1964. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  1965.  
  1966.  
  1967.    3. Expand the envelopedData (if present)
  1968.  
  1969.    4. Sign the message to be sent to the ML members in a new "outer"
  1970.       signedData layer that includes the signedAttributes (unless
  1971.       explicitly replaced) from the original, received "outer" signedData
  1972.       layer.
  1973.  
  1974.    If the MLA finds an "outer" signedData layer that includes an
  1975.    mlExpansionHistory attribute AND the MLA subsequently finds an
  1976.    envelopedData layer buried deeper with the layers of the received
  1977.    message, then the MLA MUST strip off all of the signedData layers
  1978.    down to the envelopedData layer (including stripping off the original
  1979.    "outer" signedData layer) and MUST sign the expanded envelopedData in
  1980.    a new "outer" signedData layer that includes the signedAttributes
  1981.    (unless explicitly replaced) from the original, received "outer"
  1982.    signedData layer.
  1983.  
  1984.    If the MLA does not find an "outer" signedData layer AND does not
  1985.    find an envelopedData layer, then the MLA MUST sign the original,
  1986.    received message in a new "outer" signedData layer. If the MLA does
  1987.    not find an "outer" signedData AND does find an envelopedData layer
  1988.    then it MUST expand the envelopedData layer, if present, and sign it
  1989.    in a new "outer" signedData layer.
  1990.  
  1991. 4.2.1 Examples of Rule Processing
  1992.  
  1993.    The following examples help explain the rules above:
  1994.  
  1995.    1) A message (S1(Original Content)) (where S = SignedData) is sent to
  1996.       the MLA in which the signedData layer does not include an
  1997.       MLExpansionHistory attribute. The MLA verifies and fully processes
  1998.       the signedAttributes in S1.  The MLA decides that there is not an
  1999.       original, received "outer" signedData layer since it finds the
  2000.       original content, but never finds an envelopedData and never finds
  2001.       an mlExpansionHistory attribute. The MLA calculates a new
  2002.       signedData layer, S2, resulting in the following message sent to
  2003.       the ML recipients: (S2(S1(Original Content))). The MLA includes an
  2004.       mlExpansionHistory attribute in S2.
  2005.  
  2006.    2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in
  2007.       which none of the signedData layers includes an MLExpansionHistory
  2008.       attribute. The MLA verifies and fully processes the
  2009.       signedAttributes in S3, S2 and S1. The MLA decides that there is
  2010.       not an original, received "outer" signedData layer since it finds
  2011.       the original content, but never finds an envelopedData and never
  2012.       finds an mlExpansionHistory attribute. The MLA calculates a new
  2013.       signedData layer, S4, resulting in the following
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Hoffman                     Standards Track                    [Page 36]
  2019.  
  2020. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2021.  
  2022.  
  2023.       message sent to the ML recipients:
  2024.       (S4(S3(S2(S1(Original Content))))). The MLA includes an
  2025.       mlExpansionHistory attribute in S4.
  2026.  
  2027.    3) A message (E1(S1(Original Content))) (where E = envelopedData) is
  2028.       sent to the MLA in which S1 does not include an MLExpansionHistory
  2029.       attribute.  The MLA decides that there is not an original,
  2030.       received "outer" signedData layer since it finds the E1 as the
  2031.       outer layer.  The MLA expands the recipientInformation in E1. The
  2032.       MLA calculates a new signedData layer, S2, resulting in the
  2033.       following message sent to the ML recipients:
  2034.       (S2(E1(S1(Original Content)))). The MLA includes an
  2035.       mlExpansionHistory attribute in S2.
  2036.  
  2037.    4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in
  2038.       which S2 includes an MLExpansionHistory attribute. The MLA verifies
  2039.       the signature and fully processes the signedAttributes in S2. The
  2040.       MLA finds the mlExpansionHistory attribute in S2, so it decides
  2041.       that S2 is the "outer" signedData. The MLA remembers the
  2042.       signedAttributes included in S2 for later inclusion in the new
  2043.       outer signedData that it applies to the message. The MLA strips off
  2044.       S2. The MLA then expands the recipientInformation in E1 (this
  2045.       invalidates the signature in S2 which is why it was stripped). The
  2046.       nMLA calculates a new signedData layer, S3, resulting in the
  2047.       following message sent to the ML recipients: (S3(E1(S1(Original
  2048.       Content)))). The MLA includes in S3 the attributes from S2 (unless
  2049.       it specifically replaces an attribute value) including an updated
  2050.       mlExpansionHistory attribute.
  2051.  
  2052.    5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
  2053.       which none of the signedData layers include an MLExpansionHistory
  2054.       attribute. The MLA verifies the signature and fully processes the
  2055.       signedAttributes in S3 and S2. When the MLA encounters E1, then it
  2056.       decides that S2 is the "outer" signedData since S2 encapsulates E1.
  2057.       The MLA remembers the signedAttributes included in S2 for later
  2058.       inclusion in the new outer signedData that it applies to the
  2059.       message.  The MLA strips off S3 and S2. The MLA then expands the
  2060.       recipientInformation in E1 (this invalidates the signatures in S3
  2061.       and S2 which is why they were stripped). The MLA calculates a new
  2062.       signedData layer, S4, resulting in the following message sent to
  2063.       the ML recipients: (S4(E1(S1(Original Content)))). The MLA
  2064.       includes in S4 the attributes from S2 (unless it specifically
  2065.       replaces an attribute value) and includes a new
  2066.       mlExpansionHistory attribute.
  2067.  
  2068.    6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
  2069.       which S3 includes an MLExpansionHistory attribute. In this case,
  2070.       the MLA verifies the signature and fully processes the
  2071.  
  2072.  
  2073.  
  2074. Hoffman                     Standards Track                    [Page 37]
  2075.  
  2076. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2077.  
  2078.  
  2079.       signedAttributes in S3. The MLA finds the mlExpansionHistory in S3,
  2080.       so it decides that S3 is the "outer" signedData. The MLA remembers
  2081.       the signedAttributes included in S3 for later inclusion in the new
  2082.       outer signedData that it applies to the message. The MLA keeps on
  2083.       parsing encapsulated layers because it must determine if there are
  2084.       any eSSSecurityLabel attributes contained within. The MLA verifies
  2085.       the signature and fully processes the signedAttributes in S2. When
  2086.       the MLA encounters E1, then it strips off S3 and S2. The MLA then
  2087.       expands the recipientInformation in E1 (this invalidates the
  2088.       signatures in S3 and S2 which is why they were stripped). The MLA
  2089.       calculates a new signedData layer, S4, resulting in the following
  2090.       message sent to the ML recipients: (S4(E1(S1(Original Content)))).
  2091.       The MLA includes in S4 the attributes from S3 (unless it
  2092.       specifically replaces an attribute value) including an updated
  2093.       mlExpansionHistory attribute.
  2094.  
  2095. 4.2.3 Processing Choices
  2096.  
  2097.    The processing used depends on the type of the outermost layer of the
  2098.    message. There are three cases for the type of the outermost data:
  2099.  
  2100.     - EnvelopedData
  2101.     - SignedData
  2102.     - data
  2103.  
  2104. 4.2.3.1 Processing for EnvelopedData
  2105.  
  2106.    1. The MLA locates its own RecipientInfo and uses the information it
  2107.       contains to obtain the message key.
  2108.  
  2109.    2. The MLA removes the existing recipientInfos field and replaces it
  2110.       with a new recipientInfos value built from RecipientInfo
  2111.    structures
  2112.       created for each member of the mailing list. The MLA also removes
  2113.       the existing originatorInfo field and replaces it with a new
  2114.       originatorInfo value built from information describing the MLA.
  2115.  
  2116.    3. The MLA encapsulates the expanded encrypted message in a
  2117.       SignedData block, adding an mlExpansionHistory attribute as
  2118.       described in the "Mail List Expansion" section to document the
  2119.       expansion.
  2120.  
  2121.    4. The MLA signs the new message and delivers the updated message to
  2122.       mail list members to complete MLA processing.
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Hoffman                     Standards Track                    [Page 38]
  2131.  
  2132. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2133.  
  2134.  
  2135. 4.2.3.2 Processing for SignedData
  2136.  
  2137.    MLA processing of multi-layer messages depends on the type of data in
  2138.    each of the layers. Step 3 below specifies that different processing
  2139.    will take place depending on the type of CMS message that has been
  2140.    signed. That is, it needs to know the type of data at the next inner
  2141.    layer, which may or may not be the innermost layer.
  2142.  
  2143.    1. The MLA verifies the signature value found in the outermost
  2144.       SignedData layer associated with the signed data. MLA
  2145.       processing of the message terminates if the message signature
  2146.       is invalid.
  2147.  
  2148.    2. If the outermost SignedData layer includes a signed
  2149.       mlExpansionHistory attribute, the MLA checks for an expansion loop
  2150.       as described in the "Detecting Mail List Expansion Loops" section,
  2151.       then go to step 3. If the outermost SignedData layer does not
  2152.       include a signed mlExpansionHistory attribute, the MLA signs the
  2153.       whole message (including this outermost SignedData layer that
  2154.       doesn't have an mlExpansionHistory attribute), and delivers the
  2155.       updated message to mail list members to complete MLA processing.
  2156.  
  2157.    3. Determine the type of the data that has been signed. That is, look
  2158.       at the type of data on the layer just below the SignedData, which
  2159.       may or may not be the "innermost" layer. Based on the type of data,
  2160.       perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or
  2161.       step 3.3 (all other types).
  2162.  
  2163.        3.1. If the signed data is EnvelopedData, the MLA performs
  2164.             expansion processing of the encrypted message as
  2165.             described previously. Note that this process invalidates the
  2166.             signature value in the outermost SignedData layer associated
  2167.             with the original encrypted message.  Proceed to section 3.2
  2168.             with the result of the expansion.
  2169.  
  2170.        3.2. If the signed data is SignedData, or is the result of
  2171.             expanding an EnvelopedData block in step 3.1:
  2172.  
  2173.            3.2.1. The MLA strips the existing outermost SignedData layer
  2174.                   after remembering the value of the mlExpansionHistory
  2175.                   and all other signed attributes in that layer, if
  2176.                   present.
  2177.  
  2178.            3.2.2.  If the signed data is EnvelopedData (from step 3.1),
  2179.                    the MLA encapsulates the expanded encrypted message
  2180.                    in a new outermost SignedData layer. On the other
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Hoffman                     Standards Track                    [Page 39]
  2187.  
  2188. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2189.  
  2190.  
  2191.                    hand, if the signed data is SignedData (from step
  2192.                    3.2), the MLA encapsulates the signed data in a new
  2193.                    outermost SignedData layer.
  2194.  
  2195.            3.2.3.  The outermost signedData layer created by the MLA
  2196.                    replaces the original outermost signedData layer. The
  2197.                    MLA MUST create an signed attribute list for the new
  2198.                    outermost signedData layer which MUST include each
  2199.                    signed attribute present in the original outermost
  2200.                    signedData layer, unless the MLA explicitly replaces
  2201.                    one or more particular attributes with new value. A
  2202.                    special case is the mlExpansionHistory attribute. The
  2203.                    MLA MUST add an mlExpansionHistory signed attribute
  2204.                    to the outer signedData layer as follows:
  2205.  
  2206.                3.2.3.1. If the original outermost SignedData layer
  2207.                         included an mlExpansionHistory attribute, the
  2208.                         attribute's value is copied and updated with the
  2209.                         current ML expansion information as described in
  2210.                         the "Mail List Expansion" section.
  2211.  
  2212.                3.2.3.2. If the original outermost SignedData layer did
  2213.                         not include an mlExpansionHistory attribute, a
  2214.                         new attribute value is created with the current
  2215.                         ML expansion information as described in the
  2216.                         "Mail List Expansion" section.
  2217.  
  2218.        3.3. If the signed data is not EnvelopedData or SignedData:
  2219.  
  2220.            3.3.1.  The MLA encapsulates the received signedData object in
  2221.                    an outer SignedData object, and adds an
  2222.                    mlExpansionHistory attribute to the outer SignedData
  2223.                    object containing the current ML expansion information
  2224.                    as described in the "Mail List Expansion" section.
  2225.  
  2226.    4. The MLA signs the new message and delivers the updated message to
  2227.       mail list members to complete MLA processing.
  2228.  
  2229.    A flow chart for the above steps would be:
  2230.  
  2231.    1. Has a valid signature?
  2232.           YES -> 2.
  2233.           NO  -> STOP.
  2234.    2. Does outermost SignedData layer contain mlExpansionHistory?
  2235.           YES -> Check it, then -> 3.
  2236.           NO  -> Sign message (including outermost SignedData that
  2237.                  doesn't have mlExpansionHistory), deliver it, STOP.
  2238.    3. Check type of data just below outermost SignedData.
  2239.  
  2240.  
  2241.  
  2242. Hoffman                     Standards Track                    [Page 40]
  2243.  
  2244. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2245.  
  2246.  
  2247.           EnvelopedData -> 3.1.
  2248.           SignedData -> 3.2.
  2249.           all others -> 3.3.
  2250.    3.1. Expand the encrypted message, then -> 3.2.
  2251.    3.2. -> 3.2.1.
  2252.    3.2.1. Strip outermost SignedData layer, note value of
  2253.           mlExpansionHistory and other signed attributes, then -> 3.2.2.
  2254.    3.2.2. Encapsulate in new signature, then -> 3.2.3.
  2255.    3.2.3. Create new signedData layer. Was there an old
  2256.           mlExpansionHistory?
  2257.           YES -> copy the old mlExpansionHistory values, then -> 4.
  2258.           NO  -> create new mlExpansionHistory value, then -> 4.
  2259.    3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
  2260.           attribute, then -> 4.
  2261.    4. Sign message, deliver it, STOP.
  2262.  
  2263. 4.2.3.3 Processing for data
  2264.  
  2265.    1. The MLA encapsulates the message in a SignedData layer, and adds an
  2266.       mlExpansionHistory attribute containing the current ML expansion
  2267.       information as described in the "Mail List Expansion" section.
  2268.  
  2269.    2. The MLA signs the new message and delivers the updated message to
  2270.       mail list members to complete MLA processing.
  2271.  
  2272.    4.3 Mail List Agent Signed Receipt Policy Processing
  2273.  
  2274.    If a mailing list (B) is a member of another mailing list (A), list B
  2275.    often needs to propagate forward the mailing list receipt policy of
  2276.    A. As a general rule, a mailing list should be conservative in
  2277.    propagating forward the mailing list receipt policy because the
  2278.    ultimate recipient need only process the last item in the ML
  2279.    expansion history. The MLA builds the expansion history to meet this
  2280.    requirement.
  2281.  
  2282.  
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Hoffman                     Standards Track                    [Page 41]
  2299.  
  2300. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2301.  
  2302.  
  2303.    The following table describes the outcome of the union of mailing
  2304.    list A's policy (the rows in the table) and mailing list B's policy
  2305.    (the columns in the table).
  2306.  
  2307.              |                    B's policy
  2308. A's policy   | none   insteadOf        inAdditionTo      missing
  2309. -----------------------------------------------------------------------
  2310. none         | none   none             none              none
  2311. insteadOf    | none   insteadOf(B)     *1                insteadOf(A)
  2312. inAdditionTo | none   insteadOf(B)     *2                inAdditionTo(A)
  2313. missing      | none   insteadOf(B)     inAdditionTo(B)   missing
  2314.  
  2315. *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
  2316. *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
  2317.  
  2318. 4.4 Mail List Expansion History Syntax
  2319.  
  2320.    An mlExpansionHistory attribute value has ASN.1 type
  2321.    MLExpansionHistory. If there are more than ub-ml-expansion-history
  2322.    mailing lists in the sequence, the receiving agent should provide
  2323.    notification of the error to a human mail list administrator. The
  2324.    mail list administrator is responsible for correcting the overflow
  2325.    condition.
  2326.  
  2327. MLExpansionHistory ::= SEQUENCE
  2328.         SIZE (1..ub-ml-expansion-history) OF MLData
  2329.  
  2330. id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2331.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
  2332.  
  2333. ub-ml-expansion-history INTEGER ::= 64
  2334.  
  2335.    MLData contains the expansion history describing each MLA that has
  2336.    processed a message. As an MLA distributes a message to members of an
  2337.    ML, the MLA records its unique identifier, date and time of
  2338.    expansion, and receipt policy in an MLData structure.
  2339.  
  2340. MLData ::= SEQUENCE {
  2341.   mailListIdentifier EntityIdentifier,
  2342.   expansionTime GeneralizedTime,
  2343.   mlReceiptPolicy MLReceiptPolicy OPTIONAL }
  2344.  
  2345. EntityIdentifier ::= CHOICE {
  2346.   issuerAndSerialNumber IssuerAndSerialNumber,
  2347.   subjectKeyIdentifier SubjectKeyIdentifier }
  2348.  
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Hoffman                     Standards Track                    [Page 42]
  2355.  
  2356. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2357.  
  2358.  
  2359.    The receipt policy of the ML can withdraw the originator's request
  2360.    for the return of a signed receipt. However, if the originator of the
  2361.    message has not requested a signed receipt, the MLA cannot request a
  2362.    signed receipt. In the event that a ML's signed receipt policy
  2363.    supersedes the originator's request for signed receipts, such that
  2364.    the originator will not receive any signed receipts, then the MLA MAY
  2365.    inform the originator of that fact.
  2366.  
  2367.    When present, the mlReceiptPolicy specifies a receipt policy that
  2368.    supersedes the originator's request for signed receipts. The policy
  2369.    can be one of three possibilities: receipts MUST NOT be returned
  2370.    (none); receipts should be returned to an alternate list of
  2371.    recipients, instead of to the originator (insteadOf); or receipts
  2372.    should be returned to a list of recipients in addition to the
  2373.    originator (inAdditionTo).
  2374.  
  2375.    MLReceiptPolicy ::= CHOICE {
  2376.      none [0] NULL,
  2377.      insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  2378.      inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
  2379.  
  2380. 5. Signing Certificate Attribute
  2381.  
  2382.    Concerns have been raised over the fact that the certificate which
  2383.    the signer of a CMS SignedData object desired to be bound into the
  2384.    verification process of the SignedData object is not
  2385.    cryptographically bound into the signature itself. This section
  2386.    addresses this issue by creating a new attribute to be placed in the
  2387.    signed attributes section of a SignerInfo object.
  2388.  
  2389.    This section also presents a description of a set of possible attacks
  2390.    dealing with the substitution of one certificate to verify the
  2391.    signature for the desired certificate. A set of ways for preventing
  2392.    or addressing these attacks is presented to deal with the simplest of
  2393.    the attacks.
  2394.  
  2395.    Authorization information can be used as part of a signature
  2396.    verification process. This information can be carried in either
  2397.    attribute certificates and other public key certificates. The signer
  2398.    needs to have the ability to restrict the set of certificates used in
  2399.    the signature verification process, and information needs to be
  2400.    encoded so that is covered by the signature on the SignedData object.
  2401.    The methods in this section allow for the set of authorization
  2402.    certificates to be listed as part of the signing certificate
  2403.    attribute.
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Hoffman                     Standards Track                    [Page 43]
  2411.  
  2412. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2413.  
  2414.  
  2415.    Explicit certificate policies can also be used as part of a signature
  2416.    verification process. If a signer desires to state an explicit
  2417.    certificate policy that should be used when validating the signature,
  2418.    that policy needs to be cryptographically bound into the signing
  2419.    process. The methods described in this section allows for a set of
  2420.    certificate policy statements to be listed as part of the signing
  2421.    certificate attribute.
  2422.  
  2423. 5.1. Attack Descriptions
  2424.  
  2425.    At least three different attacks can be launched against a possible
  2426.    signature verification process by replacing the certificate or
  2427.    certficates used in the signature verification process.
  2428.  
  2429. 5.1.1 Substitution Attack Description
  2430.  
  2431.    The first attack deals with simple substitution of one certificate
  2432.    for another certificate. In this attack, the issuer and serial number
  2433.    in the SignerInfo is modified to refer to a new certificate. This new
  2434.    certificate is used during the signature verification process.
  2435.  
  2436.    The first version of this attack is a simple denial of service attack
  2437.    where an invalid certificate is substituted for the valid
  2438.    certificate. This renders the message unverifiable, as the public key
  2439.    in the certificate no longer matches the private key used to sign the
  2440.    message.
  2441.  
  2442.    The second version is a substitution of one valid certificate for the
  2443.    original valid certificate where the public keys in the certificates
  2444.    match.  This allows the signature to be validated under potentially
  2445.    different certificate constraints than the originator of the message
  2446.    intended.
  2447.  
  2448. 5.1.2 Reissue of Certificate Description
  2449.  
  2450.    The second attack deals with a certificate authority (CA) re-issuing
  2451.    the signing certificate (or potentially one of its certificates).
  2452.    This attack may start becoming more frequent as Certificate
  2453.    Authorities reissue their own root certificates, or as certificate
  2454.    authorities change policies in the certificate while reissuing their
  2455.    root certificates. This problem also occurs when cross certificates
  2456.    (with potentially different restrictions) are used in the process of
  2457.    verifying a signature.
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Hoffman                     Standards Track                    [Page 44]
  2467.  
  2468. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2469.  
  2470.  
  2471. 5.1.3 Rogue Duplicate CA Description
  2472.  
  2473.    The third attack deals with a rogue entity setting up a certificate
  2474.    authority that attempts to duplicate the structure of an existing CA.
  2475.    Specifically, the rogue entity issues a new certificate with the same
  2476.    public keys as the signer used, but signed by the rogue entity's
  2477.    private key.
  2478.  
  2479. 5.2 Attack Responses
  2480.  
  2481.    This document does not attempt to solve all of the above attacks;
  2482.    however, a brief description of responses to each of the attacks is
  2483.    given in this section.
  2484.  
  2485. 5.2.1 Substitution Attack Response
  2486.  
  2487.    The denial of service attack cannot be prevented. After the
  2488.    certificate identifier has been modified in transit, no verification
  2489.    of the signature is possible. There is also no way to automatically
  2490.    identify the attack because it is indistinguishable from a message
  2491.    corruption.
  2492.  
  2493.    The substitution of a valid certificate can be responded to in two
  2494.    different manners. The first is to make a blanket statement that the
  2495.    use of the same public key in two different certificates is bad
  2496.    practice and has to be avoided. In practice, there is no practical
  2497.    way to prevent users from getting new certificates with the same
  2498.    public keys, and it should be assumed that they will do this. Section
  2499.    5.4 provides a new attribute that can be included in the SignerInfo
  2500.    signed attributes. This binds the correct certificate identifier into
  2501.    the signature. This will convert the attack from a potentially
  2502.    successful one to simply a denial of service attack.
  2503.  
  2504. 5.2.2 Reissue of Certificate Response
  2505.  
  2506.    A CA should never reissue a certificate with different attributes.
  2507.    Certificate Authorities that do so are following poor practices and
  2508.    cannot be relied on. Using the hash of the certificate as the
  2509.    reference to the certificate prevents this attack for end-entity
  2510.    certificates.
  2511.  
  2512.    Preventing the attack based on reissuing of CA certificates would
  2513.    require a substantial change to the usage of the signingCertificate
  2514.    attribute presented in section 5.4. It would require that ESSCertIDs
  2515.    would need to be included in the attribute to represent the issuer
  2516.    certificates in the signer's certification path. This presents
  2517.    problems when the relying party is using a cross-certificate as part
  2518.    of its authentication process, and this certificate does not appear
  2519.  
  2520.  
  2521.  
  2522. Hoffman                     Standards Track                    [Page 45]
  2523.  
  2524. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2525.  
  2526.  
  2527.    on the list of certificates. The problems outside of a closed PKI
  2528.    make the addition of this information prone to error, possibly
  2529.    causing the rejection of valid chains.
  2530.  
  2531. 5.2.3 Rogue Duplicate CA Response
  2532.  
  2533.    The best method of preventing this attack is to avoid trusting the
  2534.    rogue CA. The use of the hash to identify certificates prevents the
  2535.    use of end-entity certificates from the rogue authority. However the
  2536.    only true way to prevent this attack is to never trust the rogue CA.
  2537.  
  2538. 5.3 Related Signature Verification Context
  2539.  
  2540.    Some applications require that additional information be used as part
  2541.    of the signature validation process. In particular, authorization
  2542.    information from attribute certificates and other public key
  2543.    certificates or policy identifiers provide additional information
  2544.    about the abilities and intent of the signer. The signing certificate
  2545.    attribute described in Section 5.4 provides the ability to bind this
  2546.    context information as part of the signature.
  2547.  
  2548. 5.3.1 Authorization Information
  2549.  
  2550.    Some applications require that authorization information found in
  2551.    attribute certificates and/or other public key certificates be
  2552.    validated. This validation requires that the application be able to
  2553.    find the correct certificates to perform the verification process;
  2554.    however there is no list of the certificates to used in a SignerInfo
  2555.    object. The sender has the ability to include a set of attribute
  2556.    certificates and public key certificates in a SignedData object. The
  2557.    receiver has the ability to retrieve attribute certificates and
  2558.    public key certificates from a directory service. There are some
  2559.    circumstances where the signer may wish to limit the set of
  2560.    certificates that may be used in verifying a signature. It is useful
  2561.    to be able to list the set of certificates the signer wants the
  2562.    recipient to use in validating the signature.
  2563.  
  2564. 5.3.2 Policy Information
  2565.  
  2566.    A related aspect of the certificate binding is the issue of multiple
  2567.    certification paths. In some instances, the semantics of a
  2568.    certificate in its use with a message may depend on the Certificate
  2569.    Authorities and policies that apply. To address this issue, the
  2570.    signer may also wish to bind that context under the signature. While
  2571.    this could be done by either signing the complete certification path
  2572.    or a policy ID, only a binding for the policy ID is described here.
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578. Hoffman                     Standards Track                    [Page 46]
  2579.  
  2580. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2581.  
  2582.  
  2583. 5.4 Signing Certificate Attribute Definition
  2584.  
  2585.    The signing certificate attribute is designed to prevent the simple
  2586.    substitution and re-issue attacks, and to allow for a restricted set
  2587.    of authorization certificates to be used in verifying a signature.
  2588.  
  2589.    The definition of SigningCertificate is
  2590.  
  2591.    SigningCertificate ::=  SEQUENCE {
  2592.        certs        SEQUENCE OF ESSCertID,
  2593.        policies     SEQUENCE OF PolicyInformation OPTIONAL
  2594.    }
  2595.  
  2596.    id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
  2597.        member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
  2598.        smime(16) id-aa(2) 12 }
  2599.  
  2600.    The first certificate identified in the sequence of certificate
  2601.    identifiers MUST be the certificate used to verify the signature. The
  2602.    encoding of the ESSCertID for this certificate SHOULD include the
  2603.    issuerSerial field. If other constraints ensure that
  2604.    issuerAndSerialNumber will be present in the SignerInfo, the
  2605.    issuerSerial field MAY be omitted. The certificate identified is used
  2606.    during the signature verification process. If the hash of the
  2607.    certificate does not match the certificate used to verify the
  2608.    signature, the signature MUST be considered invalid.
  2609.  
  2610.    If more than one certificate is present in the sequence of
  2611.    ESSCertIDs, the certificates after the first one limit the set of
  2612.    authorization certificates that are used during signature validation.
  2613.    Authorization certificates can be either attribute certificates or
  2614.    normal certificates. The issuerSerial field (in the ESSCertID
  2615.    structure) SHOULD be present for these certificates, unless the
  2616.    client who is validating the signature is expected to have easy
  2617.    access to all the certificates requred for validation. If only the
  2618.    signing certificate is present in the sequence, there are no
  2619.    restrictions on the set of authorization certificates used in
  2620.    validating the signature.
  2621.  
  2622.    The sequence of policy information terms identifies those certificate
  2623.    policies that the signer asserts apply to the certificate, and under
  2624.    which the certificate should be relied upon. This value suggests a
  2625.    policy value to be used in the relying party's certification path
  2626.    validation.
  2627.  
  2628.    If present, the SigningCertificate attribute MUST be a signed
  2629.    attribute; it MUST NOT be an unsigned attribute. CMS defines
  2630.    SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include
  2631.  
  2632.  
  2633.  
  2634. Hoffman                     Standards Track                    [Page 47]
  2635.  
  2636. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2637.  
  2638.  
  2639.    multiple instances of the SigningCertificate attribute. CMS defines
  2640.    the ASN.1 syntax for the signed attributes to include attrValues SET
  2641.    OF AttributeValue. A SigningCertificate attribute MUST include only a
  2642.    single instance of AttributeValue. There MUST NOT be zero or multiple
  2643.    instances of AttributeValue present in the attrValues SET OF
  2644.    AttributeValue.
  2645.  
  2646. 5.4.1 Certificate Identification
  2647.  
  2648.    The best way to identify certificates is an often-discussed issue.
  2649.    [CERT] has imposed a restriction for SignedData objects that the
  2650.    issuer DN must be present in all signing certificates. The
  2651.    issuer/serial number pair is therefore sufficient to identify the
  2652.    correct signing certificate. This information is already present, as
  2653.    part of the SignerInfo object, and duplication of this information
  2654.    would be unfortunate. A hash of the entire certificate serves the
  2655.    same function (allowing the receiver to verify that the same
  2656.    certificate is being used as when the message was signed), is
  2657.    smaller, and permits a detection of the simple substitution attacks.
  2658.  
  2659.    Attribute certificates and additional public key certificates
  2660.    containing authorization information do not have an issuer/serial
  2661.    number pair represented anywhere in a SignerInfo object. When an
  2662.    attribute certificate or an additional public key certificate is not
  2663.    included in the SignedData object, it becomes much more difficult to
  2664.    get the correct set of certificates based only on a hash of the
  2665.    certificate. For this reason, these certificates SHOULD be identified
  2666.    by the IssuerSerial object.
  2667.  
  2668.    This document defines a certificate identifier as:
  2669.  
  2670.    ESSCertID ::=  SEQUENCE {
  2671.         certHash                 Hash,
  2672.         issuerSerial             IssuerSerial OPTIONAL
  2673.    }
  2674.  
  2675.    Hash ::= OCTET STRING -- SHA1 hash of entire certificate
  2676.  
  2677.    IssuerSerial ::= SEQUENCE {
  2678.         issuer                   GeneralNames,
  2679.         serialNumber             CertificateSerialNumber
  2680.    }
  2681.  
  2682.    When creating an ESSCertID, the certHash is computed over the entire
  2683.    DER encoded certificate including the signature. The issuerSerial
  2684.    would normally be present unless the value can be inferred from other
  2685.    information.
  2686.  
  2687.  
  2688.  
  2689.  
  2690. Hoffman                     Standards Track                    [Page 48]
  2691.  
  2692. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2693.  
  2694.  
  2695.    When encoding IssuerSerial, serialNumber is the serial number that
  2696.    uniquely identifies the certificate. For non-attribute certificates,
  2697.    the issuer MUST contain only the issuer name from the certificate
  2698.    encoded in the directoryName choice of GeneralNames. For attribute
  2699.    certificates, the issuer MUST contain the issuer name field from the
  2700.    attribute certificate.
  2701.  
  2702. 6. Security Considerations
  2703.  
  2704.    All security considerations from [CMS] and [SMIME3] apply to
  2705.    applications that use procedures described in this document.
  2706.  
  2707.    As stated in Section 2.3, a recipient of a receipt request must not
  2708.    send back a reply if it cannot validate the signature. Similarly, if
  2709.    there conflicting receipt requests in a message, the recipient must
  2710.    not send back receipts, since an attacker may have inserted the
  2711.    conflicting request.  Sending a signed receipt to an unvalidated
  2712.    sender can expose information about the recipient that it may not
  2713.    want to expose to unknown senders.
  2714.  
  2715.    Senders of receipts should consider encrypting the receipts to
  2716.    prevent a passive attacker from gleaning information in the receipts.
  2717.  
  2718.    Senders must not rely on recipients' processing software to correctly
  2719.    process security labels. That is, the sender cannot assume that
  2720.    adding a security label to a message will prevent recipients from
  2721.    viewing messages the sender doesn't want them to view. It is expected
  2722.    that there will be many S/MIME clients that will not understand
  2723.    security labels but will still display a labelled message to a
  2724.    recipient.
  2725.  
  2726.    A receiving agent that processes security labels must handle the
  2727.    content of the messages carefully. If the agent decides not to show
  2728.    the message to the intended recipient after processing the security
  2729.    label, the agent must take care that the recipient does not
  2730.    accidentally see the content at a later time. For example, if an
  2731.    error response sent to the originator contains the content that was
  2732.    hidden from the recipient, and that error response bounces back to
  2733.    the sender due to addressing errors, the original recipient can
  2734.    possibly see the content since it is unlikely that the bounce message
  2735.    will have the proper security labels.
  2736.  
  2737.    A man-in-the-middle attack can cause a recipient to send receipts to
  2738.    an attacker if that attacker has a signature that can be validated by
  2739.    the recipient. The attack consists of intercepting the original
  2740.    message and adding a mLData attribute that says that a receipt should
  2741.    be sent to the attacker in addition to whoever else was going to get
  2742.    the receipt.
  2743.  
  2744.  
  2745.  
  2746. Hoffman                     Standards Track                    [Page 49]
  2747.  
  2748. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2749.  
  2750.  
  2751.    Mailing lists that encrypt their content may be targets for denial-
  2752.    of-service attacks if they do not use the mailing list management
  2753.    described in Section 4. Using simple RFC822 header spoofing, it is
  2754.    quite easy to subscribe one encrypted mailing list to another,
  2755.    thereby setting up an infinite loop.
  2756.  
  2757.    Mailing List Agents need to be aware that they can be used as oracles
  2758.    for the the adaptive chosen ciphertext attack described in [CMS].
  2759.    MLAs should notify an administrator if a large number of
  2760.    undecryptable messages are received.
  2761.  
  2762.    When verifying a signature using certificates that come with a [CMS]
  2763.    message, the recipient should only verify using certificates
  2764.    previously known to be valid, or certificates that have come from a
  2765.    signed SigningCertificate attribute. Otherwise, the attacks described
  2766.    in Section 5 can cause the receiver to possibly think a signature is
  2767.    valid when it is not.
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.  
  2777.  
  2778.  
  2779.  
  2780.  
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796.  
  2797.  
  2798.  
  2799.  
  2800.  
  2801.  
  2802. Hoffman                     Standards Track                    [Page 50]
  2803.  
  2804. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2805.  
  2806.  
  2807. A. ASN.1 Module
  2808.  
  2809. ExtendedSecurityServices
  2810.      { iso(1) member-body(2) us(840) rsadsi(113549)
  2811.        pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
  2812.  
  2813. DEFINITIONS IMPLICIT TAGS ::=
  2814. BEGIN
  2815.  
  2816. IMPORTS
  2817.  
  2818. -- Cryptographic Message Syntax (CMS)
  2819.     ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
  2820.     FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
  2821.     rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
  2822.  
  2823. -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
  2824. --  1988 Syntax
  2825.     PolicyInformation FROM PKIX1Implicit88 {iso(1)
  2826.     identified-organization(3) dod(6) internet(1) security(5)
  2827.     mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
  2828.  
  2829. -- X.509
  2830.     GeneralNames, CertificateSerialNumber FROM CertificateExtensions
  2831.     {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
  2832.  
  2833.  
  2834. -- Extended Security Services
  2835.  
  2836. -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
  2837. -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
  2838. -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
  2839. -- have at least one entry. MAX indicates the upper bound is unspecified.
  2840. -- Implementations are free to choose an upper bound that suits their
  2841. -- environment.
  2842.  
  2843. UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
  2844.     -- The contents are formatted as described in [UTF8]
  2845.  
  2846. -- Section 2.7
  2847.  
  2848. ReceiptRequest ::= SEQUENCE {
  2849.   signedContentIdentifier ContentIdentifier,
  2850.   receiptsFrom ReceiptsFrom,
  2851.   receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
  2852.  
  2853. ub-receiptsTo INTEGER ::= 16
  2854.  
  2855.  
  2856.  
  2857.  
  2858. Hoffman                     Standards Track                    [Page 51]
  2859.  
  2860. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2861.  
  2862.  
  2863. id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2864.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
  2865.  
  2866. ContentIdentifier ::= OCTET STRING
  2867.  
  2868. id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2869.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
  2870.  
  2871. ReceiptsFrom ::= CHOICE {
  2872.   allOrFirstTier [0] AllOrFirstTier,
  2873.   -- formerly "allOrNone [0]AllOrNone"
  2874.   receiptList [1] SEQUENCE OF GeneralNames }
  2875.  
  2876. AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
  2877.   allReceipts (0),
  2878.   firstTierRecipients (1) }
  2879.  
  2880.  
  2881. -- Section 2.8
  2882.  
  2883. Receipt ::= SEQUENCE {
  2884.   version ESSVersion,
  2885.   contentType ContentType,
  2886.   signedContentIdentifier ContentIdentifier,
  2887.   originatorSignatureValue OCTET STRING }
  2888.  
  2889. id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  2890.    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
  2891.  
  2892. ESSVersion ::= INTEGER  { v1(1) }
  2893.  
  2894. -- Section 2.9
  2895.  
  2896. ContentHints ::= SEQUENCE {
  2897.   contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  2898.   contentType ContentType }
  2899.  
  2900. id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  2901.     rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
  2902.  
  2903. -- Section 2.10
  2904.  
  2905. MsgSigDigest ::= OCTET STRING
  2906.  
  2907. id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2908.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
  2909.  
  2910. -- Section 2.11
  2911.  
  2912.  
  2913.  
  2914. Hoffman                     Standards Track                    [Page 52]
  2915.  
  2916. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2917.  
  2918.  
  2919. ContentReference ::= SEQUENCE {
  2920.   contentType ContentType,
  2921.   signedContentIdentifier ContentIdentifier,
  2922.   originatorSignatureValue OCTET STRING }
  2923.  
  2924. id-aa-contentReference   OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2925.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
  2926.  
  2927.  
  2928. -- Section 3.2
  2929.  
  2930. ESSSecurityLabel ::= SET {
  2931.   security-policy-identifier SecurityPolicyIdentifier,
  2932.   security-classification SecurityClassification OPTIONAL,
  2933.   privacy-mark ESSPrivacyMark OPTIONAL,
  2934.   security-categories SecurityCategories OPTIONAL }
  2935.  
  2936. id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2937.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
  2938.  
  2939. SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
  2940.  
  2941. SecurityClassification ::= INTEGER {
  2942.   unmarked (0),
  2943.   unclassified (1),
  2944.   restricted (2),
  2945.   confidential (3),
  2946.   secret (4),
  2947.   top-secret (5) } (0..ub-integer-options)
  2948.  
  2949. ub-integer-options INTEGER ::= 256
  2950.  
  2951. ESSPrivacyMark ::= CHOICE {
  2952.     pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
  2953.     utf8String   UTF8String (SIZE (1..MAX))
  2954. }
  2955.  
  2956. ub-privacy-mark-length INTEGER ::= 128
  2957.  
  2958. SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
  2959.         SecurityCategory
  2960.  
  2961. ub-security-categories INTEGER ::= 64
  2962.  
  2963. SecurityCategory ::= SEQUENCE {
  2964.   type  [0] OBJECT IDENTIFIER,
  2965.   value [1] ANY DEFINED BY type -- defined by type
  2966. }
  2967.  
  2968.  
  2969.  
  2970. Hoffman                     Standards Track                    [Page 53]
  2971.  
  2972. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  2973.  
  2974.  
  2975. --Note: The aforementioned SecurityCategory syntax produces identical
  2976. --hex encodings as the following SecurityCategory syntax that is
  2977. --documented in the X.411 specification:
  2978. --
  2979. --SecurityCategory ::= SEQUENCE {
  2980. --     type  [0]  SECURITY-CATEGORY,
  2981. --     value [1]  ANY DEFINED BY type }
  2982. --
  2983. --SECURITY-CATEGORY MACRO ::=
  2984. --BEGIN
  2985. --TYPE NOTATION ::= type | empty
  2986. --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
  2987. --END
  2988.  
  2989. -- Section 3.4
  2990.  
  2991. EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
  2992.  
  2993. id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  2994.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
  2995.  
  2996.  
  2997. -- Section 4.4
  2998.  
  2999. MLExpansionHistory ::= SEQUENCE
  3000.         SIZE (1..ub-ml-expansion-history) OF MLData
  3001.  
  3002. id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
  3003.     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
  3004.  
  3005. ub-ml-expansion-history INTEGER ::= 64
  3006.  
  3007. MLData ::= SEQUENCE {
  3008.   mailListIdentifier EntityIdentifier,
  3009.   expansionTime GeneralizedTime,
  3010.   mlReceiptPolicy MLReceiptPolicy OPTIONAL }
  3011.  
  3012. EntityIdentifier ::= CHOICE {
  3013.   issuerAndSerialNumber IssuerAndSerialNumber,
  3014.   subjectKeyIdentifier SubjectKeyIdentifier }
  3015.  
  3016. MLReceiptPolicy ::= CHOICE {
  3017.   none [0] NULL,
  3018.   insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  3019.   inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
  3020.  
  3021.  
  3022. -- Section 5.4
  3023.  
  3024.  
  3025.  
  3026. Hoffman                     Standards Track                    [Page 54]
  3027.  
  3028. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  3029.  
  3030.  
  3031. SigningCertificate ::=  SEQUENCE {
  3032.     certs        SEQUENCE OF ESSCertID,
  3033.     policies     SEQUENCE OF PolicyInformation OPTIONAL
  3034. }
  3035.  
  3036. id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
  3037.     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
  3038.     smime(16) id-aa(2) 12 }
  3039.  
  3040. ESSCertID ::=  SEQUENCE {
  3041.      certHash                 Hash,
  3042.      issuerSerial             IssuerSerial OPTIONAL
  3043. }
  3044.  
  3045. Hash ::= OCTET STRING -- SHA1 hash of entire certificate
  3046.  
  3047. IssuerSerial ::= SEQUENCE {
  3048.      issuer                   GeneralNames,
  3049.      serialNumber             CertificateSerialNumber
  3050. }
  3051.  
  3052. END -- of ExtendedSecurityServices
  3053.  
  3054.  
  3055.  
  3056.  
  3057.  
  3058.  
  3059.  
  3060.  
  3061.  
  3062.  
  3063.  
  3064.  
  3065.  
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073.  
  3074.  
  3075.  
  3076.  
  3077.  
  3078.  
  3079.  
  3080.  
  3081.  
  3082. Hoffman                     Standards Track                    [Page 55]
  3083.  
  3084. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  3085.  
  3086.  
  3087. B. References
  3088.  
  3089.    [ASN1-1988]  "Recommendation X.208: Specification of Abstract Syntax
  3090.                 Notation One (ASN.1)".
  3091.  
  3092.    [ASN1-1994]  "Recommendation X.680: Specification of Abstract Syntax
  3093.                 Notation One (ASN.1)".
  3094.  
  3095.    [CERT]       Ramsdell, B., Editor, "S/MIME Version 3 Certificate
  3096.                 Handling", RFC 2632, June 1999.
  3097.  
  3098.    [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
  3099.                 June 1999.
  3100.  
  3101.    [MSG]        Ramsdell, B., Editor, "S/MIME Version 3 Message
  3102.                 Specification", RFC 2633, June 1999.
  3103.  
  3104.    [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
  3105.                 Requirement Levels", BCP 14, RFC 2119, March 1997.
  3106.  
  3107.    [MSP4]       "Secure Data Network System (SDNS) Message Security
  3108.                 Protocol (MSP) 4.0", Specification SDN.701, Revision A,
  3109.                 1997-02-06.
  3110.  
  3111.    [MTSABS]     "1988 International Telecommunication Union (ITU) Data
  3112.                 Communication Networks Message Handling Systems: Message
  3113.                 Transfer System:  Abstract Service Definition and
  3114.                 Procedures, Volume VIII, Fascicle VIII.7, Recommendation
  3115.                 X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
  3116.                 mts(3) modules(0) mts-abstract-service(1)}
  3117.  
  3118.    [PKCS7-1.5]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax",
  3119.                 RFC 2315, March 1998.
  3120.  
  3121.    [SMIME2]     Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
  3122.                 L.  Repka"S/MIME Version 2 Message Specification", RFC
  3123.                 2311, March 1998, and Dusse, S., Hoffman, P. and B.
  3124.                 Ramsdell,"S/MIME Version 2 Certificate Handling", RFC
  3125.                 2312, March 1998.
  3126.  
  3127.    [UTF8]       Yergeau, F., "UTF-8, a transformation format of ISO
  3128.                 10646", RFC 2279, January 1998.
  3129.  
  3130. C. Acknowledgments
  3131.  
  3132.    The first draft of this work was prepared by David Solo. John Pawling
  3133.    did a huge amount of very detailed revision work during the many
  3134.    phases of the document.
  3135.  
  3136.  
  3137.  
  3138. Hoffman                     Standards Track                    [Page 56]
  3139.  
  3140. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  3141.  
  3142.  
  3143.    Many other people have contributed hard work to this memo, including:
  3144.  
  3145.    Andrew Farrell
  3146.    Bancroft Scott
  3147.    Bengt Ackzell
  3148.    Bill Flanigan
  3149.    Blake Ramsdell
  3150.    Carlisle Adams
  3151.    Darren Harter
  3152.    David Kemp
  3153.    Denis Pinkas
  3154.    Francois Rousseau
  3155.    Jim Schaad
  3156.    Russ Housley
  3157.    Scott Hollenbeck
  3158.    Steve Dusse
  3159.  
  3160. Editor's Address
  3161.  
  3162.    Paul Hoffman
  3163.    Internet Mail Consortium
  3164.    127 Segre Place
  3165.    Santa Cruz, CA  95060
  3166.  
  3167.    EMail: phoffman@imc.org
  3168.  
  3169.  
  3170.  
  3171.  
  3172.  
  3173.  
  3174.  
  3175.  
  3176.  
  3177.  
  3178.  
  3179.  
  3180.  
  3181.  
  3182.  
  3183.  
  3184.  
  3185.  
  3186.  
  3187.  
  3188.  
  3189.  
  3190.  
  3191.  
  3192.  
  3193.  
  3194. Hoffman                     Standards Track                    [Page 57]
  3195.  
  3196. RFC 2634         Enhanced Security Services for S/MIME         June 1999
  3197.  
  3198.  
  3199. Full Copyright Statement
  3200.  
  3201.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  3202.  
  3203.    This document and translations of it may be copied and furnished to
  3204.    others, and derivative works that comment on or otherwise explain it
  3205.    or assist in its implementation may be prepared, copied, published
  3206.    and distributed, in whole or in part, without restriction of any
  3207.    kind, provided that the above copyright notice and this paragraph are
  3208.    included on all such copies and derivative works.  However, this
  3209.    document itself may not be modified in any way, such as by removing
  3210.    the copyright notice or references to the Internet Society or other
  3211.    Internet organizations, except as needed for the purpose of
  3212.    developing Internet standards in which case the procedures for
  3213.    copyrights defined in the Internet Standards process must be
  3214.    followed, or as required to translate it into languages other than
  3215.    English.
  3216.  
  3217.    The limited permissions granted above are perpetual and will not be
  3218.    revoked by the Internet Society or its successors or assigns.
  3219.  
  3220.    This document and the information contained herein is provided on an
  3221.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  3222.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  3223.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  3224.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  3225.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  3226.  
  3227. Acknowledgement
  3228.  
  3229.    Funding for the RFC Editor function is currently provided by the
  3230.    Internet Society.
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244.  
  3245.  
  3246.  
  3247.  
  3248.  
  3249.  
  3250. Hoffman                     Standards Track                    [Page 58]
  3251.  
  3252.