content identifier, and signature value from the first SignedData.
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 }
3. Security Labels
This section describes the syntax to be used for security labels that
can optionally be associated with S/MIME encapsulated data. A
security label is a set of security information regarding the
sensitivity of the content that is protected by S/MIME encapsulation.
"Authorization" is the act of granting rights and/or privileges to
users permitting them access to an object. "Access control" is a
means of enforcing these authorizations. The sensitivity information
in a security label can be compared with a user's authorizations to
determine if the user is allowed to access the content that is
protected by S/MIME encapsulation.
Security labels may be used for other purposes such as a source of
routing information. The labels often describe ranked levels
("secret", "confidential", "restricted", and so on) or are role-
based, describing which kind of people can see the information
("patient's health-care team", "medical billing agents",
"unrestricted", and so on).
3.1 Security Label Processing Rules
A sending agent may include a security label attribute in the signed
attributes of a signedData object. A receiving agent examines the
security label on a received message and determines whether or not
the recipient is allowed to see the contents of the message.
3.1.1 Adding Security Labels
A sending agent that is using security labels MUST put the security
label attribute in the signedAttributes field of a SignerInfo block.
The security label attribute MUST NOT be included in the unsigned
attributes. Integrity and authentication security services MUST be
applied to the security label, therefore it MUST be included as a
signed attribute, if used. This causes the security label attribute
to be part of the data that is hashed to form the SignerInfo
signature value. A SignerInfo block MUST NOT have more than one
security label signed attribute.
When there are multiple SignedData blocks applied to a message, a
security label attribute may be included in either the inner
signature, outer signature, or both. A security label signed
attribute may be included in a signedAttributes field within the
inner SignedData block. The inner security label will include the
sensitivities of the original content and will be used for access
control decisions related to the plaintext encapsulated content. The
inner signature provides authentication of the inner security label
and cryptographically protects the original signer's inner security
label of the original content.
When the originator signs the plaintext content and signed
attributes, the inner security label is bound to the plaintext
content. An intermediate entity cannot change the inner security
label without invalidating the inner signature. The confidentiality
security service can be applied to the inner security label by
encrypting the entire inner signedData object within an EnvelopedData
block.
A security label signed attribute may also be included in a
signedAttributes field within the outer SignedData block. The outer
security label will include the sensitivities of the encrypted
message and will be used for access control decisions related to the
encrypted message and for routing decisions. The outer signature
provides authentication of the outer security label (as well as for
the encapsulated content which may include nested S/MIME messages).
There can be multiple SignerInfos within a SignedData object, and
each SignerInfo may include signedAttributes. Therefore, a single
SignedData object may include multiple eSSSecurityLabels, each
SignerInfo having an eSSSecurityLabel attribute. For example, an
originator can send a signed message with two SignerInfos, one
containing a DSS signature, the other containing an RSA signature. If
any of the SignerInfos included in a SignedData object include an
eSSSecurityLabel attribute, then all of the SignerInfos in that
SignedData object MUST include an eSSSecurityLabel attribute and the
value of each MUST be identical.
3.1.2 Processing Security Labels
Before processing an eSSSecurityLabel signedAttribute, the receiving
agent MUST verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient MUST NOT process an
eSSSecurityLabel attribute that has not been verified.
A receiving agent MUST process the eSSSecurityLabel attribute, if
present, in each SignerInfo in the SignedData object for which it
verifies the signature. This may result in the receiving agent
processing multiple eSSSecurityLabels included in a single SignedData
object. Because all eSSSecurityLabels in a SignedData object must be
identical, the receiving agent processes (such as performing access
control) on the first eSSSecurityLabel that it encounters in a
SignerInfo that it verifies, and then ensures that all other
eSSSecurityLabels in signerInfos that it verifies are identical to
the first one encountered. If the eSSSecurityLabels in the
signerInfos that it verifies are not all identical, then the
receiving agent MUST warn the user of this condition.
Receiving agents SHOULD have a local policy regarding whether or not
to show the inner content of a signedData object that includes an
eSSSecurityLabel security-policy-identifier that the processing
software does not recognize. If the receiving agent does not
recognize the eSSSecurityLabel security-policy-identifier value, then
it SHOULD stop processing the message and indicate an error.
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:
--
--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
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
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:
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
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
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.
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)
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)
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
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
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.
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
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.
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.
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 }
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.
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.
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
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