Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 2634

Enhanced Security Services for S/MIME

Pages: 58
Proposed Standard
Updated by:  5035
Part 2 of 2 – Pages 27 to 58
First   Prev   None

ToP   noToC   RFC2634 - Page 27   prevText

3.2 Syntax of eSSSecurityLabel

The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module. (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in [MSP4]. ESSSecurityLabel ::= SET { security-policy-identifier SecurityPolicyIdentifier, security-classification SecurityClassification OPTIONAL, privacy-mark ESSPrivacyMark OPTIONAL, security-categories SecurityCategories OPTIONAL } id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} SecurityPolicyIdentifier ::= OBJECT IDENTIFIER SecurityClassification ::= INTEGER { unmarked (0), unclassified (1), restricted (2), confidential (3), secret (4), top-secret (5) } (0..ub-integer-options) ub-integer-options INTEGER ::= 256 ESSPrivacyMark ::= CHOICE { pString PrintableString (SIZE (1..ub-privacy-mark-length)), utf8String UTF8String (SIZE (1..MAX)) } ub-privacy-mark-length INTEGER ::= 128 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategory ub-security-categories INTEGER ::= 64 SecurityCategory ::= SEQUENCE { type [0] OBJECT IDENTIFIER, value [1] ANY DEFINED BY type -- defined by type } --Note: The aforementioned SecurityCategory syntax produces identical --hex encodings as the following SecurityCategory syntax that is --documented in the X.411 specification:
ToP   noToC   RFC2634 - Page 28
--
--SecurityCategory ::= SEQUENCE {
--     type  [0]  SECURITY-CATEGORY,
--     value [1]  ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END

3.3 Security Label Components

This section gives more detail on the the various components of the eSSSecurityLabel syntax.

3.3.1 Security Policy Identifier

A security policy is a set of criteria for the provision of security services. The eSSSecurityLabel security-policy-identifier is used to identify the security policy in force to which the security label relates. It indicates the semantics of the other security label components.

3.3.2 Security Classification

This specification defines the use of the Security Classification field exactly as is specified in the X.411 Recommendation, which states in part: If present, a security-classification may have one of a hierarchical list of values. The basic security-classification hierarchy is defined in this Recommendation, but the use of these values is defined by the security-policy in force. Additional values of security-classification, and their position in the hierarchy, may also be defined by a security-policy as a local matter or by bilateral agreement. The basic security- classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, top-secret. This means that the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) defines the SecurityClassification integer values and their meanings. An organization can develop its own security policy that defines the SecurityClassification INTEGER values and their meanings. However, the general interpretation of the X.411 specification is that the values of 0 through 5 are reserved for the "basic hierarchy" values
ToP   noToC   RFC2634 - Page 29
   of unmarked, unclassified, restricted, confidential, secret, and
   top-secret. Note that X.411 does not provide the rules for how these
   values are used to label data and how access control is performed
   using these values.

   There is no universal definition of the rules for using these "basic
   hierarchy" values. Each organization (or group of organizations) will
   define a security policy which documents how the "basic hierarchy"
   values are used (if at all) and how access control is enforced (if at
   all) within their domain.

   Therefore, the security-classification value MUST be accompanied by a
   security-policy-identifier value to define the rules for its use. For
   example, a company's "secret" classification may convey a different
   meaning than the US Government "secret" classification. In summary, a
   security policy SHOULD NOT use integers 0 through 5 for other than
   their X.411 meanings, and SHOULD instead use other values in a
   hierarchical fashion.

   Note that the set of valid security-classification values MUST be
   hierarchical, but these values do not necessarily need to be in
   ascending numerical order. Further, the values do not need to be
   contiguous.

   For example, in the Defense Message System 1.0 security policy, the
   security-classification value of 11 indicates Sensitive-But-
   Unclassified and 5 indicates top-secret. The hierarchy of sensitivity
   ranks top-secret as more sensitive than Sensitive-But-Unclassified
   even though the numerical value of top-secret is less than
   Sensitive-But-Unclassified.

   (Of course, if security-classification values are both hierarchical
   and in ascending order, a casual reader of the security policy is
   more likely to understand it.)

   An example of a security policy that does not use any of the X.411
   values might be:

   10 -- anyone
   15 -- Morgan Corporation and its contractors
   20 -- Morgan Corporation employees
   25 -- Morgan Corporation board of directors

   An example of a security policy that uses part of the X.411 hierarchy
   might be:

   0 -- unmarked
   1 -- unclassified, can be read by everyone
ToP   noToC   RFC2634 - Page 30
   2 -- restricted to Timberwolf Productions staff
   6 -- can only be read to Timberwolf Productions executives

3.3.3 Privacy Mark

If present, the eSSSecurityLabel privacy-mark is not used for access control. The content of the eSSSecurityLabel privacy-mark may be defined by the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) which may define a list of values to be used. Alternately, the value may be determined by the originator of the security-label.

3.3.4 Security Categories

If present, the eSSSecurityLabel security-categories provide further granularity for the sensitivity of the message. The security policy in force (identified by the eSSSecurityLabel security-policy- identifier) is used to indicate the syntaxes that are allowed to be present in the eSSSecurityLabel security-categories. Alternately, the security-categories and their values may be defined by bilateral agreement.

3.4 Equivalent Security Labels

Because organizations are allowed to define their own security policies, many different security policies will exist. Some organizations may wish to create equivalencies between their security policies with the security policies of other organizations. For example, the Acme Company and the Widget Corporation may reach a bilateral agreement that the "Acme private" security-classification value is equivalent to the "Widget sensitive" security-classification value. Receiving agents MUST NOT process an equivalentLabels attribute in a message if the agent does not trust the signer of that attribute to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Receiving agents have the option to process equivalentLabels attributes but do not have to. It is acceptable for a receiving agent to only process eSSSecurityLabels. All receiving agents SHOULD recognize equivalentLabels attributes even if they do not process them.

3.4.1 Creating Equivalent Labels

The EquivalentLabels signed attribute is defined as:
ToP   noToC   RFC2634 - Page 31
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel

id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}

   As stated earlier, the ESSSecurityLabel contains the sensitivity
   values selected by the original signer of the signedData. If an
   ESSSecurityLabel is present in a signerInfo, all signerInfos in the
   signedData MUST contain an ESSSecurityLabel and they MUST all be
   identical. In addition to an ESSSecurityLabel, a signerInfo MAY also
   include an equivalentLabels signed attribute. If present, the
   equivalentLabels attribute MUST include one or more security labels
   that are believed by the signer to be semantically equivalent to the
   ESSSecurityLabel attribute included in the same signerInfo.

   All security-policy object identifiers MUST be unique in the set of
   ESSSecurityLabel and EquivalentLabels security labels. Before using
   an EquivalentLabels attribute, a receiving agent MUST ensure that all
   security-policy OIDs are unique in the security label or labels
   included in the EquivalentLabels. Once the receiving agent selects
   the security label (within the EquivalentLabels) to be used for
   processing, then the security-policy OID of the selected
   EquivalentLabels security label MUST be compared with the
   ESSSecurityLabel security-policy OID to ensure that they are unique.

   In the case that an ESSSecurityLabel attribute is not included in a
   signerInfo, then an EquivalentLabels attribute may still be included.
   For example, in the Acme security policy, the absence of an
   ESSSecurityLabel could be defined to equate to a security label
   composed of the Acme security-policy OID and the "unmarked"
   security-classification.

   Note that equivalentLabels MUST NOT be used to convey security labels
   that are semantically different from the ESSSecurityLabel included in
   the signerInfos in the signedData. If an entity needs to apply a
   security label that is semantically different from the
   ESSSecurityLabel, then it MUST include the sematically different
   security label in an outer signedData object that encapsulates the
   signedData object that includes the ESSSecurityLabel.

   If present, the equivalentLabels attribute MUST be a signed
   attribute; it MUST NOT be an unsigned attribute. [CMS] defines
   signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include
   multiple instances of the equivalentLabels attribute. CMS defines the
   ASN.1 syntax for the signed attributes to include attrValues SET OF
ToP   noToC   RFC2634 - Page 32
   AttributeValue. A equivalentLabels attribute MUST only include a
   single instance of AttributeValue. There MUST NOT be zero or multiple
   instances of AttributeValue present in the attrValues SET OF
   AttributeValue.

3.4.2 Processing Equivalent Labels

A receiving agent SHOULD process the ESSSecurityLabel before processing any EquivalentLabels. If the policy in the ESSSecurityLabel is understood by the receiving agent, it MUST process that label and MUST ignore all EquivalentLabels. When processing an EquivalentLabels attribute, the receiving agent MUST validate the signature on the EquivalentLabels attribute. A receiving agent MUST NOT act on an equivalentLabels attribute for which the signature could not be validated, and MUST NOT act on an equivalentLabels attribute unless that attribute is signed by an entity trusted to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Determining who is allowed to specify equivalence mappings is a local policy. If a message has more than one EquivalentLabels attribute, the receiving agent SHOULD process the first one that it reads and validates that contains the security policy of interest to the receiving agent.

4. Mail List Management

Sending agents must create recipient-specific data structures for each recipient of an encrypted message. This process can impair performance for messages sent to a large number of recipients. Thus, Mail List Agents (MLAs) that can take a single message and perform the recipient-specific encryption for every recipient are often desired. An MLA appears to the message originator as a normal message recipient, but the MLA acts as a message expansion point for a Mail List (ML). The sender of a message directs the message to the MLA, which then redistributes the message to the members of the ML. This process offloads the per-recipient processing from individual user agents and allows for more efficient management of large MLs. MLs are true message recipients served by MLAs that provide cryptographic and expansion services for the mailing list. In addition to cryptographic handling of messages, secure mailing lists also have to prevent mail loops. A mail loop is where one mailing list is a member of a second mailing list, and the second
ToP   noToC   RFC2634 - Page 33
   mailing list is a member of the first. A message will go from one
   list to the other in a rapidly-cascading succession of mail that will
   be distributed to all other members of both lists.

   To prevent mail loops, MLAs use the mlExpansionHistory attribute of
   the outer signature of a triple wrapped message. The
   mlExpansionHistory attribute is essentially a list of every MLA that
   has processed the message. If an MLA sees its own unique entity
   identifier in the list, it knows that a loop has been formed, and
   does not send the message to the list again.

4.1 Mail List Expansion

Mail list expansion processing is noted in the value of the mlExpansionHistory attribute, located in the signed attributes of the MLA's SignerInfo block. The MLA creates or updates the signed mlExpansionHistory attribute value each time the MLA expands and signs a message for members of a mail list. The MLA MUST add an MLData record containing the MLA's identification information, date and time of expansion, and optional receipt policy to the end of the mail list expansion history sequence. If the mlExpansionHistory attribute is absent, then the MLA MUST add the attribute and the current expansion becomes the first element of the sequence. If the mlExpansionHistory attribute is present, then the MLA MUST add the current expansion information to the end of the existing MLExpansionHistory sequence. Only one mlExpansionHistory attribute can be included in the signedAttributes of a SignerInfo. Note that if the mlExpansionHistory attribute is absent, then the recipient is a first tier message recipient. There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a mlExpansionHistory attribute. For example, an MLA can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. If an MLA creates a SignerInfo that includes an mlExpansionHistory attribute, then all of the SignerInfos created by the MLA for that SignedData object MUST include an mlExpansionHistory attribute, and the value of each MUST be identical. Note that other agents might later add SignerInfo attributes to the SignedData block, and those additional SignerInfos might not include mlExpansionHistory attributes.
ToP   noToC   RFC2634 - Page 34
   A recipient MUST verify the signature of the SignerInfo which covers
   the mlExpansionHistory attribute before processing the
   mlExpansionHistory, and MUST NOT process the mlExpansionHistory
   attribute unless the signature over it has been verified. If a
   SignedData object has more than one SignerInfo that has an
   mlExpansionHistory attribute, the recipient MUST compare the
   mlExpansionHistory attributes in all the SignerInfos that it has
   verified, and MUST NOT process the mlExpansionHistory attribute
   unless every verified mlExpansionHistory attribute in the SignedData
   block is identical. If the mlExpansionHistory attributes in the
   verified signerInfos are not all identical, then the receiving agent
   MUST stop processing the message and SHOULD notify the user or MLA
   administrator of this error condition. In the mlExpansionHistory
   processing, SignerInfos that do not have an mlExpansionHistory
   attribute are ignored.

4.1.1 Detecting Mail List Expansion Loops

Prior to expanding a message, the MLA examines the value of any existing mail list expansion history attribute to detect an expansion loop. An expansion loop exists when a message expanded by a specific MLA for a specific mail list is redelivered to the same MLA for the same mail list. Expansion loops are detected by examining the mailListIdentifier field of each MLData entry found in the mail list expansion history. If an MLA finds its own identification information, then the MLA must discontinue expansion processing and should provide warning of an expansion loop to a human mail list administrator. The mail list administrator is responsible for correcting the loop condition.

4.2 Mail List Agent Processing

The first few paragraphs of this section provide a high-level description of MLA processing. The rest of the section provides a detailed description of MLA processing. MLA message processing depends on the structure of the S/MIME layers in the message sent to the MLA for expansion. In addition to sending triple wrapped messages to an MLA, an entity can send other types of messages to an MLA, such as: - a single wrapped signedData or envelopedData message - a double wrapped message (such as signed and enveloped, enveloped and signed, or signed and signed, and so on) - a quadruple-wrapped message (such as if a well-formed triple wrapped message was sent through a gateway that added an outer SignedData layer)
ToP   noToC   RFC2634 - Page 35
   In all cases, the MLA MUST parse all layers of the received message
   to determine if there are any signedData layers that include an
   eSSSecurityLabel signedAttribute. This may include decrypting an
   EnvelopedData layer to determine if an encapsulated SignedData layer
   includes an eSSSecurityLabel attribute. The MLA MUST fully process
   each eSSSecurityLabel attribute found in the various signedData
   layers, including performing access control checks, before
   distributing the message to the ML members. The details of the access
   control checks are beyond the scope of this document. The MLA MUST
   verify the signature of the signerInfo including the eSSSecurityLabel
   attribute before using it.

   In all cases, the MLA MUST sign the message to be sent to the ML
   members in a new "outer" signedData layer. The MLA MUST add or update
   an mlExpansionHistory attribute in the "outer" signedData that it
   creates to document MLA processing. If there was an "outer"
   signedData layer included in the original message received by the
   MLA, then the MLA-created "outer" signedData layer MUST include each
   signed attribute present in the original "outer" signedData layer,
   unless the MLA explicitly replaces an attribute (such as signingTime
   or mlExpansionHistory) with a new value.

   When an S/MIME message is received by the MLA, the MLA MUST first
   determine which received signedData layer, if any, is the "outer"
   signedData layer.  To identify the received "outer" signedData layer,
   the MLA MUST verify the signature and fully process the
   signedAttributes in each of the outer signedData layers (working from
   the outside in) to determine if any of them either include an
   mlExpansionHistory attribute or encapsulate an envelopedData object.

   The MLA's search for the "outer" signedData layer is completed when
   it finds one of the following:

    - the "outer" signedData layer that includes an mlExpansionHistory
      attribute or encapsulates an envelopedData object
    - an envelopedData layer
    - the original content (that is, a layer that is neither
      envelopedData nor signedData).

   If the MLA finds an "outer" signedData layer, then the MLA MUST
   perform the following steps:

   1. Strip off all of the signedData layers that encapsulated the
      "outer" signedData layer

   2. Strip off the "outer" signedData layer itself (after remembering
      the included signedAttributes)
ToP   noToC   RFC2634 - Page 36
   3. Expand the envelopedData (if present)

   4. Sign the message to be sent to the ML members in a new "outer"
      signedData layer that includes the signedAttributes (unless
      explicitly replaced) from the original, received "outer" signedData
      layer.

   If the MLA finds an "outer" signedData layer that includes an
   mlExpansionHistory attribute AND the MLA subsequently finds an
   envelopedData layer buried deeper with the layers of the received
   message, then the MLA MUST strip off all of the signedData layers
   down to the envelopedData layer (including stripping off the original
   "outer" signedData layer) and MUST sign the expanded envelopedData in
   a new "outer" signedData layer that includes the signedAttributes
   (unless explicitly replaced) from the original, received "outer"
   signedData layer.

   If the MLA does not find an "outer" signedData layer AND does not
   find an envelopedData layer, then the MLA MUST sign the original,
   received message in a new "outer" signedData layer. If the MLA does
   not find an "outer" signedData AND does find an envelopedData layer
   then it MUST expand the envelopedData layer, if present, and sign it
   in a new "outer" signedData layer.

4.2.1 Examples of Rule Processing

The following examples help explain the rules above: 1) A message (S1(Original Content)) (where S = SignedData) is sent to the MLA in which the signedData layer does not include an MLExpansionHistory attribute. The MLA verifies and fully processes the signedAttributes in S1. The MLA decides that there is not an original, received "outer" signedData layer since it finds the original content, but never finds an envelopedData and never finds an mlExpansionHistory attribute. The MLA calculates a new signedData layer, S2, resulting in the following message sent to the ML recipients: (S2(S1(Original Content))). The MLA includes an mlExpansionHistory attribute in S2. 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which none of the signedData layers includes an MLExpansionHistory attribute. The MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The MLA decides that there is not an original, received "outer" signedData layer since it finds the original content, but never finds an envelopedData and never finds an mlExpansionHistory attribute. The MLA calculates a new signedData layer, S4, resulting in the following
ToP   noToC   RFC2634 - Page 37
      message sent to the ML recipients:
      (S4(S3(S2(S1(Original Content))))). The MLA includes an
      mlExpansionHistory attribute in S4.

   3) A message (E1(S1(Original Content))) (where E = envelopedData) is
      sent to the MLA in which S1 does not include an MLExpansionHistory
      attribute.  The MLA decides that there is not an original,
      received "outer" signedData layer since it finds the E1 as the
      outer layer.  The MLA expands the recipientInformation in E1. The
      MLA calculates a new signedData layer, S2, resulting in the
      following message sent to the ML recipients:
      (S2(E1(S1(Original Content)))). The MLA includes an
      mlExpansionHistory attribute in S2.

   4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in
      which S2 includes an MLExpansionHistory attribute. The MLA verifies
      the signature and fully processes the signedAttributes in S2. The
      MLA finds the mlExpansionHistory attribute in S2, so it decides
      that S2 is the "outer" signedData. The MLA remembers the
      signedAttributes included in S2 for later inclusion in the new
      outer signedData that it applies to the message. The MLA strips off
      S2. The MLA then expands the recipientInformation in E1 (this
      invalidates the signature in S2 which is why it was stripped). The
      nMLA calculates a new signedData layer, S3, resulting in the
      following message sent to the ML recipients: (S3(E1(S1(Original
      Content)))). The MLA includes in S3 the attributes from S2 (unless
      it specifically replaces an attribute value) including an updated
      mlExpansionHistory attribute.

   5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
      which none of the signedData layers include an MLExpansionHistory
      attribute. The MLA verifies the signature and fully processes the
      signedAttributes in S3 and S2. When the MLA encounters E1, then it
      decides that S2 is the "outer" signedData since S2 encapsulates E1.
      The MLA remembers the signedAttributes included in S2 for later
      inclusion in the new outer signedData that it applies to the
      message.  The MLA strips off S3 and S2. The MLA then expands the
      recipientInformation in E1 (this invalidates the signatures in S3
      and S2 which is why they were stripped). The MLA calculates a new
      signedData layer, S4, resulting in the following message sent to
      the ML recipients: (S4(E1(S1(Original Content)))). The MLA
      includes in S4 the attributes from S2 (unless it specifically
      replaces an attribute value) and includes a new
      mlExpansionHistory attribute.

   6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
      which S3 includes an MLExpansionHistory attribute. In this case,
      the MLA verifies the signature and fully processes the
ToP   noToC   RFC2634 - Page 38
      signedAttributes in S3. The MLA finds the mlExpansionHistory in S3,
      so it decides that S3 is the "outer" signedData. The MLA remembers
      the signedAttributes included in S3 for later inclusion in the new
      outer signedData that it applies to the message. The MLA keeps on
      parsing encapsulated layers because it must determine if there are
      any eSSSecurityLabel attributes contained within. The MLA verifies
      the signature and fully processes the signedAttributes in S2. When
      the MLA encounters E1, then it strips off S3 and S2. The MLA then
      expands the recipientInformation in E1 (this invalidates the
      signatures in S3 and S2 which is why they were stripped). The MLA
      calculates a new signedData layer, S4, resulting in the following
      message sent to the ML recipients: (S4(E1(S1(Original Content)))).
      The MLA includes in S4 the attributes from S3 (unless it
      specifically replaces an attribute value) including an updated
      mlExpansionHistory attribute.

4.2.3 Processing Choices

The processing used depends on the type of the outermost layer of the message. There are three cases for the type of the outermost data: - EnvelopedData - SignedData - data
4.2.3.1 Processing for EnvelopedData
1. The MLA locates its own RecipientInfo and uses the information it contains to obtain the message key. 2. The MLA removes the existing recipientInfos field and replaces it with a new recipientInfos value built from RecipientInfo structures created for each member of the mailing list. The MLA also removes the existing originatorInfo field and replaces it with a new originatorInfo value built from information describing the MLA. 3. The MLA encapsulates the expanded encrypted message in a SignedData block, adding an mlExpansionHistory attribute as described in the "Mail List Expansion" section to document the expansion. 4. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
ToP   noToC   RFC2634 - Page 39
4.2.3.2 Processing for SignedData
MLA processing of multi-layer messages depends on the type of data in each of the layers. Step 3 below specifies that different processing will take place depending on the type of CMS message that has been signed. That is, it needs to know the type of data at the next inner layer, which may or may not be the innermost layer. 1. The MLA verifies the signature value found in the outermost SignedData layer associated with the signed data. MLA processing of the message terminates if the message signature is invalid. 2. If the outermost SignedData layer includes a signed mlExpansionHistory attribute, the MLA checks for an expansion loop as described in the "Detecting Mail List Expansion Loops" section, then go to step 3. If the outermost SignedData layer does not include a signed mlExpansionHistory attribute, the MLA signs the whole message (including this outermost SignedData layer that doesn't have an mlExpansionHistory attribute), and delivers the updated message to mail list members to complete MLA processing. 3. Determine the type of the data that has been signed. That is, look at the type of data on the layer just below the SignedData, which may or may not be the "innermost" layer. Based on the type of data, perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other types). 3.1. If the signed data is EnvelopedData, the MLA performs expansion processing of the encrypted message as described previously. Note that this process invalidates the signature value in the outermost SignedData layer associated with the original encrypted message. Proceed to section 3.2 with the result of the expansion. 3.2. If the signed data is SignedData, or is the result of expanding an EnvelopedData block in step 3.1: 3.2.1. The MLA strips the existing outermost SignedData layer after remembering the value of the mlExpansionHistory and all other signed attributes in that layer, if present. 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA encapsulates the expanded encrypted message in a new outermost SignedData layer. On the other
ToP   noToC   RFC2634 - Page 40
                   hand, if the signed data is SignedData (from step
                   3.2), the MLA encapsulates the signed data in a new
                   outermost SignedData layer.

           3.2.3.  The outermost signedData layer created by the MLA
                   replaces the original outermost signedData layer. The
                   MLA MUST create an signed attribute list for the new
                   outermost signedData layer which MUST include each
                   signed attribute present in the original outermost
                   signedData layer, unless the MLA explicitly replaces
                   one or more particular attributes with new value. A
                   special case is the mlExpansionHistory attribute. The
                   MLA MUST add an mlExpansionHistory signed attribute
                   to the outer signedData layer as follows:

               3.2.3.1. If the original outermost SignedData layer
                        included an mlExpansionHistory attribute, the
                        attribute's value is copied and updated with the
                        current ML expansion information as described in
                        the "Mail List Expansion" section.

               3.2.3.2. If the original outermost SignedData layer did
                        not include an mlExpansionHistory attribute, a
                        new attribute value is created with the current
                        ML expansion information as described in the
                        "Mail List Expansion" section.

       3.3. If the signed data is not EnvelopedData or SignedData:

           3.3.1.  The MLA encapsulates the received signedData object in
                   an outer SignedData object, and adds an
                   mlExpansionHistory attribute to the outer SignedData
                   object containing the current ML expansion information
                   as described in the "Mail List Expansion" section.

   4. The MLA signs the new message and delivers the updated message to
      mail list members to complete MLA processing.

   A flow chart for the above steps would be:

   1. Has a valid signature?
          YES -> 2.
          NO  -> STOP.
   2. Does outermost SignedData layer contain mlExpansionHistory?
          YES -> Check it, then -> 3.
          NO  -> Sign message (including outermost SignedData that
                 doesn't have mlExpansionHistory), deliver it, STOP.
   3. Check type of data just below outermost SignedData.
ToP   noToC   RFC2634 - Page 41
          EnvelopedData -> 3.1.
          SignedData -> 3.2.
          all others -> 3.3.
   3.1. Expand the encrypted message, then -> 3.2.
   3.2. -> 3.2.1.
   3.2.1. Strip outermost SignedData layer, note value of
          mlExpansionHistory and other signed attributes, then -> 3.2.2.
   3.2.2. Encapsulate in new signature, then -> 3.2.3.
   3.2.3. Create new signedData layer. Was there an old
          mlExpansionHistory?
          YES -> copy the old mlExpansionHistory values, then -> 4.
          NO  -> create new mlExpansionHistory value, then -> 4.
   3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
          attribute, then -> 4.
   4. Sign message, deliver it, STOP.

4.2.3.3 Processing for data
1. The MLA encapsulates the message in a SignedData layer, and adds an mlExpansionHistory attribute containing the current ML expansion information as described in the "Mail List Expansion" section. 2. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing. 4.3 Mail List Agent Signed Receipt Policy Processing If a mailing list (B) is a member of another mailing list (A), list B often needs to propagate forward the mailing list receipt policy of A. As a general rule, a mailing list should be conservative in propagating forward the mailing list receipt policy because the ultimate recipient need only process the last item in the ML expansion history. The MLA builds the expansion history to meet this requirement.
ToP   noToC   RFC2634 - Page 42
   The following table describes the outcome of the union of mailing
   list A's policy (the rows in the table) and mailing list B's policy
   (the columns in the table).

             |                    B's policy
A's policy   | none   insteadOf        inAdditionTo      missing
-----------------------------------------------------------------------
none         | none   none             none              none
insteadOf    | none   insteadOf(B)     *1                insteadOf(A)
inAdditionTo | none   insteadOf(B)     *2                inAdditionTo(A)
missing      | none   insteadOf(B)     inAdditionTo(B)   missing

*1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))

4.4 Mail List Expansion History Syntax

An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If there are more than ub-ml-expansion-history mailing lists in the sequence, the receiving agent should provide notification of the error to a human mail list administrator. The mail list administrator is responsible for correcting the overflow condition. MLExpansionHistory ::= SEQUENCE SIZE (1..ub-ml-expansion-history) OF MLData id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} ub-ml-expansion-history INTEGER ::= 64 MLData contains the expansion history describing each MLA that has processed a message. As an MLA distributes a message to members of an ML, the MLA records its unique identifier, date and time of expansion, and receipt policy in an MLData structure. MLData ::= SEQUENCE { mailListIdentifier EntityIdentifier, expansionTime GeneralizedTime, mlReceiptPolicy MLReceiptPolicy OPTIONAL } EntityIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier SubjectKeyIdentifier }
ToP   noToC   RFC2634 - Page 43
   The receipt policy of the ML can withdraw the originator's request
   for the return of a signed receipt. However, if the originator of the
   message has not requested a signed receipt, the MLA cannot request a
   signed receipt. In the event that a ML's signed receipt policy
   supersedes the originator's request for signed receipts, such that
   the originator will not receive any signed receipts, then the MLA MAY
   inform the originator of that fact.

   When present, the mlReceiptPolicy specifies a receipt policy that
   supersedes the originator's request for signed receipts. The policy
   can be one of three possibilities: receipts MUST NOT be returned
   (none); receipts should be returned to an alternate list of
   recipients, instead of to the originator (insteadOf); or receipts
   should be returned to a list of recipients in addition to the
   originator (inAdditionTo).

   MLReceiptPolicy ::= CHOICE {
     none [0] NULL,
     insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
     inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }

5. Signing Certificate Attribute

Concerns have been raised over the fact that the certificate which the signer of a CMS SignedData object desired to be bound into the verification process of the SignedData object is not cryptographically bound into the signature itself. This section addresses this issue by creating a new attribute to be placed in the signed attributes section of a SignerInfo object. This section also presents a description of a set of possible attacks dealing with the substitution of one certificate to verify the signature for the desired certificate. A set of ways for preventing or addressing these attacks is presented to deal with the simplest of the attacks. Authorization information can be used as part of a signature verification process. This information can be carried in either attribute certificates and other public key certificates. The signer needs to have the ability to restrict the set of certificates used in the signature verification process, and information needs to be encoded so that is covered by the signature on the SignedData object. The methods in this section allow for the set of authorization certificates to be listed as part of the signing certificate attribute.
ToP   noToC   RFC2634 - Page 44
   Explicit certificate policies can also be used as part of a signature
   verification process. If a signer desires to state an explicit
   certificate policy that should be used when validating the signature,
   that policy needs to be cryptographically bound into the signing
   process. The methods described in this section allows for a set of
   certificate policy statements to be listed as part of the signing
   certificate attribute.

5.1. Attack Descriptions

At least three different attacks can be launched against a possible signature verification process by replacing the certificate or certficates used in the signature verification process.

5.1.1 Substitution Attack Description

The first attack deals with simple substitution of one certificate for another certificate. In this attack, the issuer and serial number in the SignerInfo is modified to refer to a new certificate. This new certificate is used during the signature verification process. The first version of this attack is a simple denial of service attack where an invalid certificate is substituted for the valid certificate. This renders the message unverifiable, as the public key in the certificate no longer matches the private key used to sign the message. The second version is a substitution of one valid certificate for the original valid certificate where the public keys in the certificates match. This allows the signature to be validated under potentially different certificate constraints than the originator of the message intended.

5.1.2 Reissue of Certificate Description

The second attack deals with a certificate authority (CA) re-issuing the signing certificate (or potentially one of its certificates). This attack may start becoming more frequent as Certificate Authorities reissue their own root certificates, or as certificate authorities change policies in the certificate while reissuing their root certificates. This problem also occurs when cross certificates (with potentially different restrictions) are used in the process of verifying a signature.
ToP   noToC   RFC2634 - Page 45

5.1.3 Rogue Duplicate CA Description

The third attack deals with a rogue entity setting up a certificate authority that attempts to duplicate the structure of an existing CA. Specifically, the rogue entity issues a new certificate with the same public keys as the signer used, but signed by the rogue entity's private key.

5.2 Attack Responses

This document does not attempt to solve all of the above attacks; however, a brief description of responses to each of the attacks is given in this section.

5.2.1 Substitution Attack Response

The denial of service attack cannot be prevented. After the certificate identifier has been modified in transit, no verification of the signature is possible. There is also no way to automatically identify the attack because it is indistinguishable from a message corruption. The substitution of a valid certificate can be responded to in two different manners. The first is to make a blanket statement that the use of the same public key in two different certificates is bad practice and has to be avoided. In practice, there is no practical way to prevent users from getting new certificates with the same public keys, and it should be assumed that they will do this. Section 5.4 provides a new attribute that can be included in the SignerInfo signed attributes. This binds the correct certificate identifier into the signature. This will convert the attack from a potentially successful one to simply a denial of service attack.

5.2.2 Reissue of Certificate Response

A CA should never reissue a certificate with different attributes. Certificate Authorities that do so are following poor practices and cannot be relied on. Using the hash of the certificate as the reference to the certificate prevents this attack for end-entity certificates. Preventing the attack based on reissuing of CA certificates would require a substantial change to the usage of the signingCertificate attribute presented in section 5.4. It would require that ESSCertIDs would need to be included in the attribute to represent the issuer certificates in the signer's certification path. This presents problems when the relying party is using a cross-certificate as part of its authentication process, and this certificate does not appear
ToP   noToC   RFC2634 - Page 46
   on the list of certificates. The problems outside of a closed PKI
   make the addition of this information prone to error, possibly
   causing the rejection of valid chains.

5.2.3 Rogue Duplicate CA Response

The best method of preventing this attack is to avoid trusting the rogue CA. The use of the hash to identify certificates prevents the use of end-entity certificates from the rogue authority. However the only true way to prevent this attack is to never trust the rogue CA.

5.3 Related Signature Verification Context

Some applications require that additional information be used as part of the signature validation process. In particular, authorization information from attribute certificates and other public key certificates or policy identifiers provide additional information about the abilities and intent of the signer. The signing certificate attribute described in Section 5.4 provides the ability to bind this context information as part of the signature.

5.3.1 Authorization Information

Some applications require that authorization information found in attribute certificates and/or other public key certificates be validated. This validation requires that the application be able to find the correct certificates to perform the verification process; however there is no list of the certificates to used in a SignerInfo object. The sender has the ability to include a set of attribute certificates and public key certificates in a SignedData object. The receiver has the ability to retrieve attribute certificates and public key certificates from a directory service. There are some circumstances where the signer may wish to limit the set of certificates that may be used in verifying a signature. It is useful to be able to list the set of certificates the signer wants the recipient to use in validating the signature.

5.3.2 Policy Information

A related aspect of the certificate binding is the issue of multiple certification paths. In some instances, the semantics of a certificate in its use with a message may depend on the Certificate Authorities and policies that apply. To address this issue, the signer may also wish to bind that context under the signature. While this could be done by either signing the complete certification path or a policy ID, only a binding for the policy ID is described here.
ToP   noToC   RFC2634 - Page 47

5.4 Signing Certificate Attribute Definition

The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature. The definition of SigningCertificate is SigningCertificate ::= SEQUENCE { certs SEQUENCE OF ESSCertID, policies SEQUENCE OF PolicyInformation OPTIONAL } id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 12 } The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertID for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid. If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of authorization certificates that are used during signature validation. Authorization certificates can be either attribute certificates or normal certificates. The issuerSerial field (in the ESSCertID structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates requred for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of authorization certificates used in validating the signature. The sequence of policy information terms identifies those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation. If present, the SigningCertificate attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include
ToP   noToC   RFC2634 - Page 48
   multiple instances of the SigningCertificate attribute. CMS defines
   the ASN.1 syntax for the signed attributes to include attrValues SET
   OF AttributeValue. A SigningCertificate attribute MUST include only a
   single instance of AttributeValue. There MUST NOT be zero or multiple
   instances of AttributeValue present in the attrValues SET OF
   AttributeValue.

5.4.1 Certificate Identification

The best way to identify certificates is an often-discussed issue. [CERT] has imposed a restriction for SignedData objects that the issuer DN must be present in all signing certificates. The issuer/serial number pair is therefore sufficient to identify the correct signing certificate. This information is already present, as part of the SignerInfo object, and duplication of this information would be unfortunate. A hash of the entire certificate serves the same function (allowing the receiver to verify that the same certificate is being used as when the message was signed), is smaller, and permits a detection of the simple substitution attacks. Attribute certificates and additional public key certificates containing authorization information do not have an issuer/serial number pair represented anywhere in a SignerInfo object. When an attribute certificate or an additional public key certificate is not included in the SignedData object, it becomes much more difficult to get the correct set of certificates based only on a hash of the certificate. For this reason, these certificates SHOULD be identified by the IssuerSerial object. This document defines a certificate identifier as: ESSCertID ::= SEQUENCE { certHash Hash, issuerSerial IssuerSerial OPTIONAL } Hash ::= OCTET STRING -- SHA1 hash of entire certificate IssuerSerial ::= SEQUENCE { issuer GeneralNames, serialNumber CertificateSerialNumber } When creating an ESSCertID, the certHash is computed over the entire DER encoded certificate including the signature. The issuerSerial would normally be present unless the value can be inferred from other information.
ToP   noToC   RFC2634 - Page 49
   When encoding IssuerSerial, serialNumber is the serial number that
   uniquely identifies the certificate. For non-attribute certificates,
   the issuer MUST contain only the issuer name from the certificate
   encoded in the directoryName choice of GeneralNames. For attribute
   certificates, the issuer MUST contain the issuer name field from the
   attribute certificate.

6. Security Considerations

All security considerations from [CMS] and [SMIME3] apply to applications that use procedures described in this document. As stated in Section 2.3, a recipient of a receipt request must not send back a reply if it cannot validate the signature. Similarly, if there conflicting receipt requests in a message, the recipient must not send back receipts, since an attacker may have inserted the conflicting request. Sending a signed receipt to an unvalidated sender can expose information about the recipient that it may not want to expose to unknown senders. Senders of receipts should consider encrypting the receipts to prevent a passive attacker from gleaning information in the receipts. Senders must not rely on recipients' processing software to correctly process security labels. That is, the sender cannot assume that adding a security label to a message will prevent recipients from viewing messages the sender doesn't want them to view. It is expected that there will be many S/MIME clients that will not understand security labels but will still display a labelled message to a recipient. A receiving agent that processes security labels must handle the content of the messages carefully. If the agent decides not to show the message to the intended recipient after processing the security label, the agent must take care that the recipient does not accidentally see the content at a later time. For example, if an error response sent to the originator contains the content that was hidden from the recipient, and that error response bounces back to the sender due to addressing errors, the original recipient can possibly see the content since it is unlikely that the bounce message will have the proper security labels. A man-in-the-middle attack can cause a recipient to send receipts to an attacker if that attacker has a signature that can be validated by the recipient. The attack consists of intercepting the original message and adding a mLData attribute that says that a receipt should be sent to the attacker in addition to whoever else was going to get the receipt.
ToP   noToC   RFC2634 - Page 50
   Mailing lists that encrypt their content may be targets for denial-
   of-service attacks if they do not use the mailing list management
   described in Section 4. Using simple RFC822 header spoofing, it is
   quite easy to subscribe one encrypted mailing list to another,
   thereby setting up an infinite loop.

   Mailing List Agents need to be aware that they can be used as oracles
   for the the adaptive chosen ciphertext attack described in [CMS].
   MLAs should notify an administrator if a large number of
   undecryptable messages are received.

   When verifying a signature using certificates that come with a [CMS]
   message, the recipient should only verify using certificates
   previously known to be valid, or certificates that have come from a
   signed SigningCertificate attribute. Otherwise, the attacks described
   in Section 5 can cause the receiver to possibly think a signature is
   valid when it is not.
ToP   noToC   RFC2634 - Page 51

A. ASN.1 Module

ExtendedSecurityServices { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- Cryptographic Message Syntax (CMS) ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, -- 1988 Syntax PolicyInformation FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)} -- X.509 GeneralNames, CertificateSerialNumber FROM CertificateExtensions {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; -- Extended Security Services -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to -- have at least one entry. MAX indicates the upper bound is unspecified. -- Implementations are free to choose an upper bound that suits their -- environment. UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- The contents are formatted as described in [UTF8] -- Section 2.7 ReceiptRequest ::= SEQUENCE { signedContentIdentifier ContentIdentifier, receiptsFrom ReceiptsFrom, receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } ub-receiptsTo INTEGER ::= 16
ToP   noToC   RFC2634 - Page 52
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}

ContentIdentifier ::= OCTET STRING

id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}

ReceiptsFrom ::= CHOICE {
  allOrFirstTier [0] AllOrFirstTier,
  -- formerly "allOrNone [0]AllOrNone"
  receiptList [1] SEQUENCE OF GeneralNames }

AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
  allReceipts (0),
  firstTierRecipients (1) }


-- Section 2.8

Receipt ::= SEQUENCE {
  version ESSVersion,
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }

id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}

ESSVersion ::= INTEGER  { v1(1) }

-- Section 2.9

ContentHints ::= SEQUENCE {
  contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  contentType ContentType }

id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}

-- Section 2.10

MsgSigDigest ::= OCTET STRING

id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}

-- Section 2.11
ToP   noToC   RFC2634 - Page 53
ContentReference ::= SEQUENCE {
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }

id-aa-contentReference   OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }


-- Section 3.2

ESSSecurityLabel ::= SET {
  security-policy-identifier SecurityPolicyIdentifier,
  security-classification SecurityClassification OPTIONAL,
  privacy-mark ESSPrivacyMark OPTIONAL,
  security-categories SecurityCategories OPTIONAL }

id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}

SecurityPolicyIdentifier ::= OBJECT IDENTIFIER

SecurityClassification ::= INTEGER {
  unmarked (0),
  unclassified (1),
  restricted (2),
  confidential (3),
  secret (4),
  top-secret (5) } (0..ub-integer-options)

ub-integer-options INTEGER ::= 256

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   UTF8String (SIZE (1..MAX))
}

ub-privacy-mark-length INTEGER ::= 128

SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
        SecurityCategory

ub-security-categories INTEGER ::= 64

SecurityCategory ::= SEQUENCE {
  type  [0] OBJECT IDENTIFIER,
  value [1] ANY DEFINED BY type -- defined by type
}
ToP   noToC   RFC2634 - Page 54
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
--     type  [0]  SECURITY-CATEGORY,
--     value [1]  ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END

-- Section 3.4

EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel

id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}


-- Section 4.4

MLExpansionHistory ::= SEQUENCE
        SIZE (1..ub-ml-expansion-history) OF MLData

id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}

ub-ml-expansion-history INTEGER ::= 64

MLData ::= SEQUENCE {
  mailListIdentifier EntityIdentifier,
  expansionTime GeneralizedTime,
  mlReceiptPolicy MLReceiptPolicy OPTIONAL }

EntityIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier SubjectKeyIdentifier }

MLReceiptPolicy ::= CHOICE {
  none [0] NULL,
  insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }


-- Section 5.4
ToP   noToC   RFC2634 - Page 55
SigningCertificate ::=  SEQUENCE {
    certs        SEQUENCE OF ESSCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
}

id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 12 }

ESSCertID ::=  SEQUENCE {
     certHash                 Hash,
     issuerSerial             IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {
     issuer                   GeneralNames,
     serialNumber             CertificateSerialNumber
}

END -- of ExtendedSecurityServices
ToP   noToC   RFC2634 - Page 56

B. References

[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)". [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax Notation One (ASN.1)". [CERT] Ramsdell, B., Editor, "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) 4.0", Specification SDN.701, Revision A, 1997-02-06. [MTSABS] "1988 International Telecommunication Union (ITU) Data Communication Networks Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)} [PKCS7-1.5] Kaliski, B., "PKCS #7: Cryptographic Message Syntax", RFC 2315, March 1998. [SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka"S/MIME Version 2 Message Specification", RFC 2311, March 1998, and Dusse, S., Hoffman, P. and B. Ramsdell,"S/MIME Version 2 Certificate Handling", RFC 2312, March 1998. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

C. Acknowledgments

The first draft of this work was prepared by David Solo. John Pawling did a huge amount of very detailed revision work during the many phases of the document.
ToP   noToC   RFC2634 - Page 57
   Many other people have contributed hard work to this memo, including:

   Andrew Farrell
   Bancroft Scott
   Bengt Ackzell
   Bill Flanigan
   Blake Ramsdell
   Carlisle Adams
   Darren Harter
   David Kemp
   Denis Pinkas
   Francois Rousseau
   Jim Schaad
   Russ Housley
   Scott Hollenbeck
   Steve Dusse

Editor's Address

Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 EMail: phoffman@imc.org
ToP   noToC   RFC2634 - Page 58
Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.