rfc2634.txt

<VC++网络游戏建摸与实现>源代码

    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}

   The contentDescription field may be used to provide information that
   the recipient may use to select protected messages for processing,
   such as a message subject. If this field is set, then the attribute
   is expected to appear on the signedData object enclosing an
   envelopedData object and not on the inner signedData object. The
   (SIZE (1..MAX)) construct constrains the sequence to have at least
   one entry. MAX indicates the upper bound is unspecified.
   Implementations are free to choose an upper bound that suits their
   environment.

   Messages which contain a signedData object wrapped around an
   envelopedData object, thus masking the inner content type of the
   message, SHOULD include a contentHints attribute, except for the case
   of the data content type. Specific message content types may either
   force or preclude the inclusion of the contentHints attribute. For
   example, when a signedData/Receipt is encrypted within an
   envelopedData object, an outer signedData object MUST be created that
   encapsulates the envelopedData object and a contentHints attribute
   with contentType set to the id-ct-receipt object identifier MUST be
   included in the outer signedData SignerInfo signedAttributes.















Hoffman                     Standards Track                    [Page 23]

RFC 2634         Enhanced Security Services for S/MIME         June 1999


2.10  Message Signature Digest Attribute

   The msgSigDigest attribute can only be used in the signed attributes
   of a signed receipt. It contains the digest of the ASN.1 DER encoded
   signedAttributes included in the original signedData that requested
   the signed receipt. Only one msgSigDigest attribute can appear in a
   signed attributes set. It is defined as follows:

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}

2.11 Signed Content Reference Attribute

   The contentReference attribute is a link from one SignedData to
   another. It may be used to link a reply to the original message to
   which it refers, or to incorporate by reference one SignedData into
   another. The first SignedData MUST include a contentIdentifier signed
   attribute, which SHOULD be constructed as specified in section 2.7.
   The second SignedData links to the first by including a
   ContentReference signed attribute containing the content type,
   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.






Hoffman                     Standards Track                    [Page 24]

RFC 2634         Enhanced Security Services for S/MIME         June 1999


   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



Hoffman                     Standards Track                    [Page 25]

RFC 2634         Enhanced Security Services for S/MIME         June 1999


   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.









Hoffman                     Standards Track                    [Page 26]

RFC 2634         Enhanced Security Services for S/MIME         June 1999


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:



Hoffman                     Standards Track                    [Page 27]

RFC 2634         Enhanced Security Services for S/MIME         June 1999


--
--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 organizatio