SPECIFICATION SDN.701 Revision 3.0 1994-03-21 SDNS Secure Data Network System Message Security Protocol (MSP) Foreword: This document specifies the latest evolution in the Secure Data Network System electronic message security effort. The SDNS Message Security Protocol, and its associated specifications and addenda, were developed as a cooperative project between government and industry. The project was sponsored by the National Security Agency and developed jointly with the SDNS Vendor Participants. The combined efforts of these parties produced the basis for improved security technology, interoperable security standards, and cost-effective security for computers and telecommunications integrated into the X.400 Message Handling System environment. Introductory note: This document specifies the SDNS Message Security Protocol. Table of Contents 0. Introduction 1 1. Scope and Field of Application 2 2. References 3 3. Definitions 4 3.1 Open System Interconnection 4 3.2 Message Handling System 4 3.3 The Directory 4 3.4 Secure Data Network Systems 5 3.5 Message Security 5 4. Symbols and Abbreviations 6 5. Message Security Protocol Overview 7 5.1 MSP Concept 7 5.2 Overview of the Protocol 9 5.2.1 Originator Processing 9 5.2.2 Recipient Processing 10 5.2.3 Forwarding 11 5.2.4 MSP User Certificates and Auxiliary Vectors 12 5.3 MSP Support Features 14 5.3.1 Travelling Users 14 5.3.2 Mail Lists 15 6. Service Elements / Interfaces 16 6.1 User Agent 16 6.2 Message Transfer System 16 6.3 Message Store 16 6.4 Directory User Agent 16 6.5 Directory System Agent 17 6.6 SDNS Key Management System 17 6.7 Local Management Authority 17 6.8 Certification Authority 17 7. MessageSecurityProtocol 18 7.1 OriginatorSecurityData 19 7.1.1 ProtectedAdditionalSecurityInfo 19 7.1.2 MlKeyToken 20 7.1.2.1 MLTag 20 7.1.2.2 Kmid 20 7.2 SignatureBlock 20 7.2.1 ControlInformation 21 7.2.1.1 SignatureInformation 21 7.2.1.1.1 ReceiptsIndicator 21 7.2.1.2 ReceiptInformation 22 7.3 PerRecipientToken 22 7.3.1 Tag 22 7.3.2 ProtectedRecipientKeyToken and RecipientKeyToken 23 7.3.2.1 SecurityLabel 23 7.4 MlControlInformation 24 7.4.1 PerRecipientMLKeyDistributionToken 24 7.4.2 MlData 24 7.4.2.1 MLReceiptPolicy 25 8. Elements of Procedure 26 8.1 Certificate Validation 26 8.1.1 Information Communicated to the User of the MSP UA 26 8.2 Originating a Secure Message 26 8.2.1 Security Service Selection 26 8.2.2 Access Control 27 8.2.3 Per Message Processing 27 8.2.4 Per-recipient Processing 28 8.2.5 MSP Heading Construction 28 8.3 Receiving a Secure Message 29 8.3.1 Security Service Determination 29 8.3.2 Token Selection 29 8.3.3 Partition Rule-Based Access Control 29 8.3.4 Local Rule-Based Access Control 29 8.3.5 Message Processing 30 8.4 Mail List Agent Processing 30 8.4.1 Distributing a Message to Members of a ML 30 8.4.2 Distributing a Mail List Key 31 8.5 Forwarding a Message 31 8.5.1 Support within P772 and P22 Messages 31 8.5.2 Support within P2 Messages 31 8.5.3 Support within RFC-822 Messages 32 8.5.4 6-bit Encoding 32 9. Encoding and Syntactic Conventions 34 9.1 UTCTime 34 9.2 Length Encoding 34 9.3 signedContentIdentifier 34 10. MSP Abstract Syntax 35 11. Object Identifiers 39 Table of Figures Figure 5-1 Placement of MSP Services 7 Figure 5-2 MSP Protocol Encapsulation 8 Figure 5-3 Three Types of X.509 Certificates 12 Figure 5-4 Certificate Options 13 Figure 5-5 Key Management Certificate and Auxiliary Vector 14 Table 8-1 Encoding Table 33 0. Introduction The requirement for secure electronic mail and secure messaging resulted in the development of a security protocol to be used with the CCITT X.400 Message Handling System. This protocol is called the Message Security Protocol (MSP). This document describes additions to the CCITT X.400 Recommendations (either 1984 or 1988) that permit any type of message (including interpersonal messages) to be sent and received securely. For example, the ANSI defined X.400 Message Transfer System conventions for Electronic Data Interchange (EDI) can be exchanged securely. While this specification is oriented around use within an X.400 Message Handling System, MSP may also be used as a secure message encapsulation facility with other messaging environments (such as RFC822/SMTP). 1. Scope and Field of Application This document specifies the message security services and protocol implemented in an MSP User Agent (MSP UA) component. The MSP UA provides these services by encapsulating the message content and adding a Message Security Protocol heading before submission to the Message Transfer System (MTS). MSP is transparent to the X.400 MTS. The Message Security Protocol provides writer-to-reader security services. These security services include confidentiality, integrity, data origin authentication, access control, non- repudiation with proof of origin, and non-repudiation with proof of delivery. 2. References CCITT X.200 Open Systems Interconnection - Basic Reference Model for CCITT Applications. ISO 7498/2 Information Processing Systems - Open Systems Interconnection - Security Architecture. CCITT X.208 Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). CCITT X.209 Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). CCITT X.400 Message Handling: Service and System Overview. CCITT X.411 Message Handling: Message Transfer System [part 1] Abstract Service Definition and Procedures. CCITT X.419 Message Handling: Protocol Specification. CCITT X.420 Message Handling: Interpersonal Messaging System. CCITT X.501 The Directory - Models. CCITT X.509 The Directory - Authentication Framework. RFC821 Simple Mail Transfer Protocol, J. B. Postel, August 1982. RFC822 Standard for the Format of ARPA Internet Text Messages, D. Crocker, 13 August 1982. SDN.702 SDNS Directory Specifications for Utilization with the SDNS Message Security Protocol. SDN.703 SDNS X.400 Rekey Agent Protocol. SDN.801 SDNS Access Control Concept Document. SDN.802 SDNS Access Control Specification. SDN.903 SDNS Key Management Protocol Specification. 3. Definitions 3.1 Open System Interconnection This document uses the following terms contained in the Basic Reference Model for Open Systems Interconnection (ISO 7498), specifically the Security Architecture (ISO 7498/2): Access control Connectionless confidentiality Connectionless integrity Data origin authentication Non-repudiation with proof of delivery Non-repudiation with proof of origin 3.2 Message Handling System This document uses the following terms contained in CCITT X.400, Message Handling: Service and System Overview: Content Content type Distribution List (DL) Interpersonal Messages (IPM) Message Transfer Agent (MTA) Message Transfer System (MTS) O/R Address O/R Name P2 P3 P7 SUBMIT User Agent (UA) 3.3 The Directory This document uses the following terms contained in CCITT X.501, The Directory - Models: Directory Information Base (DIB) This document uses the following terms contained in CCITT X.509, The Directory - Authentication Framework: Certificate Certification Authority (CA) 3.4 Secure Data Network Systems This document use the following terms from the SDNS specifications: Auxiliary Vector (AV) Key Material IDentifier (KMID) Key Management System (KMS) Local Rule-Based Access Control (LRBAC) Partition Rule-Based Access Control (PRBAC) 3.5 Message Security For the purposes of this document the following definition apply: Directory service (DS): A database server containing information (e.g., certificates, auxiliary vectors, and user keying material) corresponding to recipients. Local Management Authority (LMA): The LMA controls a single local access control domain by signing auxiliary vectors for that domain. Mail List (ML): A list or group of recipients which are addressed via a Mailing List Agent with a single O/R Address. Mail List Agent (MLA): An agent which a message originator addresses and which represents a group of recipients. The MLA provides message distribution to that group on behalf of the message originator. Mail List Key (MLK): A token protection key held by all members of a mail list or addressable group. Message Security Protocol (MSP): The SDNS protocol for X.400 message security. MSP is a content protocol and is implemented within the originator and recipient MSP UAs. MSP processing occurs prior to submitting a message to the MTS and after accepting delivery of a message from the MTS. MSP provides security for a content protocol (e.g. IPM, EDI), but MSP is independent of the content protocol. Message Security Protocol User Agent (MSP UA): A user agent which includes an active implementation of the SDNS MSP. Originator UA: The user agent process which originates a message. Recipient UA: The user agent process which receives a message. Travelling User (TU): An MSP user visiting an MSP equipped facility other than the one at which he normally processes messages and who wishes to read, process, and/or originate MSP protected messages. A travelling user does not transport MSP equipment, but makes use of MSP equipment located at the site he is visiting. 4. Symbols and Abbreviations AV Auxiliary Vector CA Certificate Authority DIB Directory Information Base DL Distribution List DSA Directory System Agent DUA Directory User Agent IPM Interpersonal Message KMID Key Material Identifier KMS Key Management System LMA Local Management Authority LRBAC Local Rule-Based Access Control ML Mail List MLA Mail List Agent MLK Mail List Key MS Message Store MSP Message Security Protocol MSP UA Message Security Protocol User Agent MTA Message Transfer Agent MTS Message Transfer System OUA Organizational User Agent PRBAC Partition Rule-Based Access Control RA Release Authority TU Travelling User UA User Agent UKM User Keying Material 5. Message Security Protocol Overview 5.1 MSP Concept The MSP is the protocol in the SDNS family for providing security services for X.400-based electronic messaging. MSP is an application layer protocol which operates between the originator and recipients of messages. As an end-user-to-end-user protocol which does not involve the intermediate message transfer system, MSP provides writer-to-reader security. Figure 5-1 Placement of MSP Services An X.400 message consists of a content and an envelope. MSP defines, for an X.400 message, a new message content type which includes the security heading as well as the protected original content. MSP encapsulates the original (unprotected) content of an X.400 message, performs security processing, and adds a security heading. While figure 5-1 shows the MSP user agent residing between the X.400 user agent and the X.400 message transfer agent, the MSP and X.400 user agents may be either distinct or tightly coupled protocol entities. MSP is independent of the message content being protected, and is independent of the user's message preparation system. The new content type, MSP (figure 5-2), is submitted to the X.400 message transfer system. For message delivery, the recipient user agent may either form a direct association with the MTA or may use a message store. The message store provides a repository for incoming messages when the UA is unavailable and also provides the UA with information on delivered messages to support selective processing. Because MSP constitutes a new content type (different than IPM), the information returned to the UA by the Message Store could be different. Figure 5-2 MSP Protocol Encapsulation The security services provided by this protocol include: * Connectionless Confidentiality, Data Origin Authentication, Connectionless Integrity, and Access Control * Non-repudiation with proof of origin (message signature) * Non-repudiation with proof of delivery (signed receipts) Confidentiality, data origin authentication, and integrity are provided through the encryption of the message content and associated key management mechanisms. Access control within MSP involves rule based access control. Based on the sensitivity of the message and the authorizations of the originator, recipient, and workstation, MSP makes the access control decision. Identity-based access controls are the responsibility of the originator, supported by the strong authentication provided by MSP. Non-repudiation with proof of origin involves the generation of a digital signature which allows a recipient to establish the authenticity of a message and the originator's identity to a third party. Non-repudiation with proof of delivery is provided through the return of a receipt signed by the recipient and allows the originator to establish to a third party that the message was received by the recipient. This receipt is bound to the original message through the signature; consequently, this service may be requested only for signed messages. MSP is designed to provide these services for messages sent to one or more recipients. The facilities in X.400 which support multiple recipients remain essentially unchanged with the addition of MSP. The MSP security services to be applied to a particular message are selected by the user within the constraints of a site policy. As a consequence of the staged delivery nature of electronic messaging, there is no direct, real-time association formed between an originator and a recipient. Therefore, all of the security functions must be performed independently by the originator and by the recipient, based on both originator and recipient information. 5.2 Overview of the Protocol The Message Security Protocol operates by performing security operations on X.400 messages at the originator and recipient UAs. These functions are performed in an independent but consistent fashion at each end of the message exchange based on user security information. This security information includes the user's identity, authorizations, and cryptographic material. MSP processing includes both per-message operations and information and per-recipient operations and information. These operations involve the parsing and generation of elements of the MSP heading based on the services requested by the originator, and the encryption, when requested, of the message content. Per-recipient operations involve the generation of information (known as per-recipient tokens) needed by each recipient to decrypt the message. 5.2.1 Originator Processing MSP processing begins after the message originator has created an X.400 message content and is independent of the content type. This message may be created using any local message preparation system. MSP processing consists of the following logical steps: 1) Security service selection 2) Access control 3) Per-message encryption and signature generation 4) Per-recipient token generation 5) MSP heading construction 6) Message submission Security service selection involves the determination of the MSP services to be provided for the message. This determination may be made through a combination of direct user input, configuration information, and operating system information. The selection information includes the message security label (possibly established by the operating system), whether to encrypt and/or sign the message, confirmation of recipients, determination of receipt request information, and provision of a content description. The content description is information available to a recipient prior to MSP processing. Access control is a determination made concerning the authorization of the originator to send the message and the recipient to receive it. These authorizations are based on the authorization information of the originator, the recipient, and the originator's end system . A user authorization represents a maximum clearance while an end system authorization represents a range. The MSP UA checks that the message security label is dominated by both the originator and recipient authorizations and is within the range of the originator's end system. Access control checks are made for each recipient. A failure in the check for any one recipient results in the rejection of the message. Per-message processing consists of the application of security services to the X.400 content. The processing steps include signature generation and message encryption. If the service selection step requested confidentiality or non-repudiation, the cryptographic functions supporting those services are performed. Non-repudiation (signature generation) is required if receipts are requested. For encrypted messages, per-message processing includes the generation of the message key and message hash. The MSP UA performs per-recipient processing only for encrypted messages. A token is created for each recipient of the X.400 message and for the message originator. The token contains information needed to decrypt and validate the integrity of the message; it also contains sensitivity and control information bound to the message. Per-recipient processing is based on the cryptographic material of the originator and recipient. MSP heading construction is performed by collecting the results of the above steps and creating an MSP heading. Depending on a site policy, the complete protected content (MSP heading and protected content) may then be signed. Message submission involves creating an X.400 submission envelope based on the results of the above processing steps and the information obtained from the original message. The new protected content is then submitted to the X.400 message transfer system. 5.2.2 Recipient Processing MSP recipient processing begins when the user examines a mailbox (possibly containing both MSP protected messages and unprotected X.400 messages) and selects a message for processing. Unprotected messages are processed directly by the X.400 user agent. MSP processing consists of the following logical steps: 1) Security service determination 2) Token selection (for encrypted messages) 3) Partition rule-based access control 4) Local rule-based access control 5) Per-message processing including decryption, signature validation, and receipt generation. 6) Message disposition For protected messages, the MSP UA first determines if the complete content (MSP heading and protected content) is signed. If so, the signature is validated prior to any other MSP processing. The MSP UA then examines the message and determines the security services which have been applied to the content. For encrypted messages, the MSP UA examines the per-recipient information to select the token needed to decrypt the message. A message may include individual recipient tokens and/or a mail list token. If matches for both are found, the MSP UA uses the individual recipient token. Once the token has been selected, the token is processed and the PRBAC part of the access control decision is made. Access control is a determination made concerning the authorization of the recipient to process and receive the message. These authorizations are based on the authorization information of the originator, the recipient, and the recipient's end system. User authorizations represent a maximum clearance while the end system authorization represents a range. The MSP UA checks that the message security label is dominated by both the originator and recipient authorizations and is dominated by the high end of the range of the recipient's end system. If the message security level is below the minimum of the recipient's end system's range, the message would have to be upgraded prior to delivery to the user. For example, this capability allows a user at a TOP SECRET system-high host to receive a SECRET message from a user at a SECRET system high host. If the Partition Rule-Based Access Control (PRBAC) check passes, the Local Rule-Based Access Control (LRBAC) information is extracted from the protected additional security information. An LRBAC check is made and, if that check passes, the message is decrypted. If the message was signed, the MSP UA performs signature validation and receipt request processing. The message signature is checked against the message contents. If the signature is valid, the MSP UA checks the receipt request information to determine if a receipt has been requested from this recipient. Depending upon local configuration information, a receipt may be returned automatically or may be returned upon confirmation by the user . The message is then available for processing by the user agent and the security relevant information concerning the message is provided to the user. The final part of recipient processing is the disposition of the message. An MSP message may be retained in at least three forms: original form (exactly as it arrived prior to any processing), content only (without any MSP heading information), or content with signature (content retaining the message signature information to provide non-repudiation and to support forwarding). 5.2.3 Forwarding One of the characteristics of the non-repudiation service provided by message signatures is the ability to establish the identity of the originator to a third party. Since the forwarding of messages is a standard part of electronic message systems, forwarding signed messages should be a part of these systems also. Messages are forwarded by including them within the content of a new message. An MSP protected message can be forwarded only if the protected content supports forwarding, because the MSP message is forwarded by including it within the new content. Recommendation X.420 defines a Forwarded Interpersonal Message as a message body part, which is used to forward a previously received IPM. Similarly, this document defines a body part, which allows a previously received message, along with its MSP heading which may contains its signature, to be included as part of a new content. This body part is Forwarded-MSP-Message-body-part, which is an extended X.420 body part, and is assigned a registered Object Identifier. Any number of forwarded MSP messages may be conveyed within a new message. Also, forwarded MSP messages may be nested within one another, and signed receipts may be forward. In many cases, the forwarded MSP message only contains the original unencrypted content and the original MSP signature. Encrypted MSP messages may also be forwarded if the recipient possesses the cryptographic material required to decrypt the forwarded MSP message. 5.2.4 MSP User Certificates and Auxiliary Vectors MSP processing is based on message originator and recipient information contained in certificates and associated auxiliary vectors. As in X.400 and X.500, users are identified by their distinguished name. A user's distinguished name and his public cryptographic material are bound together in a X.509 certificate, which is signed by a certification authority (CA) who vouches for the appropriate binding of the user identity and the public cryptographic material. MSP supports three types of X.509 certificates: the first type contains the user's signature public cryptographic material, the second type contains the user's key management public cryptographic material, and the third type contains both the user's signature public cryptographic material and the user's key management public cryptographic material. Figure 5-3 illustrates the relationship of these three certificate types. Figure 5-3 Three Types of X.509 Certificates The signature public cryptographic material is used to validate digital signatures. The key management public cryptographic material is used to generate symmetric cryptographic keys which are used to encrypt and decrypt MSP tokens. The originator addresses messages using the recipient's distinguished name. This distinguished name is also used to identify the recipients certificate. If the originator security service selection includes non-repudiation, then an X.509 certificate which includes the originator's signature public cryptographic material is placed in the MSP signature block. If the originator security service selection includes confidentiality but does not include non-repudiation, then an X.509 certificate which includes the originator's key management public cryptographic material is placed in the MSP originator security data. If the originator security service selection includes both non-repudiation and confidentiality, then either an X.509 certificate which includes the originator's signature public cryptographic material is placed in the MSP signature block and an X.509 certificate which includes the originator's key management public cryptographic material is placed in the MSP originator security data or an X.509 certificate which includes both the originator's signature and key management public cryptographic material is placed in the MSP signature block. Figure 5-4 summarizes these options. Security Service Selection Certificate Choice and Placement MSP signature only Signature certificate is placed in Msp (the heading) Non-repudiation with or without MSP signature Signature or Key management plus signature certificate is placed in the SignatureBlock Confidentiality, Integrity, Data Origin Authentication, and Access Control without MSP signature Key management or Key management plus signature certificate is placed in OriginatorSecurityData Both of the above, with or without MSP signature Signature certificate is placed in the SignatureBlock and Key management certificate is placed in OriginatorSecurityData or Key management plus signature certificate is placed in the SignatureBlock Confidentiality, Integrity, Data Origin Authentication, and Access Control with MSP signature Key management plus signature certificate is placed in OriginatorSecurityData or Key management certificate is placed in OriginatorSecurityData and signature certificate is placed in Msp (the heading) Any of the above when an entity other than the originator generates MSP signature Signature certificate or Key management plus signature certificate is placed in Msp (the heading) Figure 5-4 Certificate Options MSP offers an optional signature, the MSP signature, that the MSP UA applies to the complete MSP content (including the MSP heading and encapsulated content). Additionally, if the message is processed by a Mail List Agent (see 5.3.2), the Mail List Agent calculates this signature again, after it has completed processing the message for distribution. Figure 5-4 lists the placement of the signature public cryptographic material when message signature is applied. This last row of Figure 5-4 addresses when an entity other then the originator of the message (i.e. Mail List Agent) produces the message signature. If the MSP UA applies any security services to the message, then at least one user certificate must be present in the MSP heading. As shown in Figure 5-5, the key management public cryptographic material contains PRBAC authorizations and a unique KMID. The originator MSP UA uses the PRBAC authorizations from the originator's certificate and each recipient's certificate along with the end system authorization to make the PRBAC decision. The recipient MSP UA uses the PRBAC authorizations from the originator's certificate and his own certificate along with the end system authorization to make the PRBAC decision. LRBAC requires information beyond that contained in the key management public cryptographic material or X.509 certificate. This LRBAC information is conveyed in an auxiliary vector (AV). AV is applicable within a single local access control domain. This domain is under the control of a local management authority (LMA) who signs an AV for that domain. An AV is bound to a particular user by the inclusion of the KMID for that user's key management public cryptographic material in the signed AV. A user may have zero, one, or more AVs associated with his key management public cryptographic material depending on the number of domains to which he belongs. Figure 5-5 illustrates the relationship of the X.509 key management certificate, the key management public cryptographic material, and the AV. The key management and signature certificate could also be used because the key management public cryptographic material is included in the subject public key field of the key management and signature certificate. Figure 5-5 Key Management Certificate and Auxiliary Vector The originator MSP UA uses the LRBAC authorizations from the originator's AV and each recipient's AV along with the end system authorization to make the LRBAC decision. The recipient MSP UA uses the LRBAC authorizations from the originator's AV and his own AV along with the end system authorization to make the LRBAC decision. 5.3 MSP Support Features Section 5.2 contains an overview of MSP with respect to the basic services provided for message security. MSP includes features to support operational requirements for electronic messaging which must be preserved for secure messaging. These requirements include support for large distribution lists and the ability to access messages from a remote location. The following sections present an overview of each of these features. The detailed protocol specification and the appendices describe how each feature is provided. 5.3.1 Travelling Users Management information including certificate management, revocation information (CRLs and KRLs), and rekey data are required to support MSP UAs. This information is carried in protected contents. 5.3.2 Mail Lists The description of originator processing indicates that the MSP UA generates a token for each recipient of the message. This process can cause a significant performance impact for messages sent to a large number of recipients. Consequently, MSP includes support for Mail List Agents (MLAs). An MLA appears as normal message recipient which acts as a message expansion point for a Mail List (ML). The administrator of a ML is responsible for establishing rules governing the submission of messages to the list and for ensuring that all members of the ML have appropriate access control authorizations. The originator of a message directs the message to the MLA which then redistributes the message to the members of the ML. This process off loads the per-recipient processing from individual user agents and allows for more efficient management of large MLs. 6. Service Elements / Interfaces This section describes service elements that may be used with MSP implementations. The interface between the MSP UA and the service element is briefly discussed. 6.1 User Agent Originators prepare messages with the assistance of their User Agent (UA). Recipients read messages with the assistance of their UA. UAs are application process that interacts with the Message Transfer System (MTS) or a Message Store (MS) to submit and receive messages on behalf of the user. UAs which include MSP are called MSP UAs. 6.2 Message Transfer System The MTS delivers messages to one or more recipient UAs, access units (AUs), or MSs. The MTS comprises a number of Message Transfer Agents (MTAs). Operating together, in a store-and- forward manner, the MTAs transfer messages and deliver them to the intended recipients. If a message cannot be delivered, the originating UA may be informed. Either UAs and MSP UAs, or MSs on their behalf use the P3 protocol to submit messages to the MTA and to accept delivery of messages from the MTA. CCITT Recommendation X.411 specifies this interface. 6.3 Message Store The message store (MS) is an optional functional entity that acts as an intermediary between the UA and the MTA. The primary purpose of the MS is to store and permit retrieval of delivered messages. The MS also allows the UA to submit messages and alerts the UA when new messages are delivered. UAs and MSP UAs interact with the MS with exactly the same protocol P7. CCITT Recommendation X.413 specifies this interface. Information returned could include the envelope information currently described in the P7 specification plus clear text MSP heading information (such as security services and the content description), but not IPM heading information. 6.4 Directory User Agent Both UAs and MTAs can use the Directory System. The Directory is normally used to obtain recipient O/R Addresses. MSP UAs may use the Directory to obtain recipient certificates, UKMs, CRLs, KRLs and AVs. Each user is represented in accessing the Directory by a Directory User Agent (DUA). Like the UA, the DUA is an application process. The Directory is defined in the CCITT X.500 series of recommendations. The interface between the MSP UA and the DUA is a local matter. Likewise, the interface between the UA and the DUA is a local matter. 6.5 Directory System Agent The DUA interacts with the Directory by communicating with one or more directory system agents (DSAs). A DSA is an application process which is part of the Directory and whose role is to provide access to the directory information base (DIB) to DUAs and other DSAs. A DSA may use information stored in its local database or interact with other DSAs to carry out requests. Alternatively, the DSA may direct a requester to another DSA which can help carry out the request. The interface between the DUA and the DSA is specified in CCITT Recommendation X.511. 6.6 SDNS Key Management System Communication with the SDNS Key Management System (KMS) is required for rekey operations and SDNS Certificate Revocation List (CRL) retrieval. The initial implementation of the SDNS KMS offers only the SDNS Key Management Protocol (KMP) for rekey operations and SDNS CRL retrieval. X.400 Rekey Agents provide the mechanisms for MSP UAs to perform rekey operations and SDNS CRL retrieval, without requiring MSP UAs to implement the SDNS KMP. The X.400 Rekey Agent Protocol permits X.400 Rekey Agents to exist outside the perimeter of the SDNS KMS to serve as an intermediary between the MSP UA and the SDNS KMS. 6.7 Local Management Authority The local management authority (LMA) issues auxiliary vectors (AVs). MSP UAs use AVs to make access control decisions. 6.8 Certification Authority The Certification Authority (CA) is responsible for managing X.509 certificates and CA Certificate Revocation Lists. An X.509 certificate is signed by a CA who vouches for the identity of the user named in the certificate and for the binding between that user and the keying material incorporated within the X.509 certificate. 7. MessageSecurityProtocol MessageSecurityProtocol specifies an X.400 content which encapsulates and protects any content defined for transfer by the MHS. MessageSecurityProtocol is either unsigned (Msp) or signed (SIGNED Msp) by the MSP UA. Msp is a sequence of originatorSecurityData, signatureBlock, recipientSecurityData, contentDescription, mlControlInformation, and a protected message content that appears as an OCTET STRING. If Msp is signed, then Msp contains mspSequenceSignatureAlgorithm and mspSequenceSignatureCertificate. Optionally, the MSP UA may sign MessageSecurityProtocol by calculating a one-way hash on it and then signing the resulting value. The mspSequenceSignatureCertificate is a CertificationPath that is used to verify this resulting signature value included at the end of the sequence Msp. If the message is processed by an MLA, then the MLA must always sign the Msp. The contentDescription contains an unprotected T.61 string, which the recipient may use to select MSP protected messages for processing. If the originator selects message confidentiality then originatorSecurityData and encapsulatedContent must be present. If the originator selects message non-repudiation with proof of origin then the signatureBlock must be present. In addition, if the originator selects request for signed receipt then the signatureBlock must be present. MessageSecurityProtocol ::= CHOICE { msp [0] Msp, signedMsp [1] SIGNED Msp } Msp ::= SEQUENCE { originatorSecurityData [0] OriginatorSecurityData OPTIONAL, signatureBlock [1] SignatureBlock OPTIONAL, recipientSecurityData [2] SET OF PerRecipientToken OPTIONAL (SIZE (1..ub-recipients)), contentDescription [3] TeletexString OPTIONAL (SIZE (1..ub-subject-field)), mlControlInformation MlControlInformation OPTIONAL, mspSequenceSignatureAlgorithm [6] AlgorithmIdentifier OPTIONAL, mspSequenceSignatureCertificate [7] CertificationPath OPTIONAL, encapsulatedContent [8] OCTET STRING OPTIONAL (SIZE (1..ub-content-length)) } 7.1 OriginatorSecurityData OriginatorSecurityData is a sequence of security information pertaining to the originator of the message. It contains the originatorCertificate, originatorUKM, additionalSecurityInfo, confidentialityAlgorithm, integrityAlgorithm, asiProtectionAlgorithm, and tokenProtectionAlgorithm. The originatorCertificate is an X.509 certification path which establishes the binding between the user's Distinguished Name and the user's key management public cryptographic material. The originatorUKM, along with information contained in the originatorCertificate, provides each recipient with information necessary to process his PerRecipientToken. If an MLA is processing the message to deliver it to a ML and if the MLA is using pairwise keys to protect the PerRecipientToken, then the MLA replaces originatorUkm, tokenProtectionAlgorithm, asiProtectionAlgorithm, and originatorCertificate with the MLA's values. The MLA may also replace confidentialityAlgorithm or integrityAlgorithm, if necessary. Within AdditionalSecurityInfo, the MLA changes originatorAuxVector to the MLA's value, but leaves the value lRBAC unchanged. If an MLA is not using pairwise keys, then the MLA omits originatorUkm and includes mlKeyToken, which contains the originator's RecipientKeyToken protected by a single Mail List Key (MLK). OriginatorSecurityData ::= SEQUENCE { confidentialityAlgorithm AlgorithmIdentifier, integrityAlgorithm AlgorithmIdentifier, tokenProtectionAlgorithm AlgorithmIdentifier, asiProtectionAlgorithm AlgorithmIdentifier OPTIONAL, originatorCertificate [0] CertificationPath OPTIONAL, additionalSecurityInfo [1] ProtectedAdditionalSecurityInfo OPTIONAL, originatorUkm [2] OCTET STRING OPTIONAL, mlKeyToken [3] MlKeyToken OPTIONAL } 7.1.1 ProtectedAdditionalSecurityInfo ProtectedAdditionalSecurityInfo contains additional access control information that has been encrypted. Prior to encryption, the structure of the information is AdditionalSecurityInfo, which contains the originator's auxiliary vector and a label corresponding to LRBAC information. The value asiIntegrityCheckValue is a cryptographic function of the lRBAC. Once AdditionalSecurityInfo is encrypted, it is encoded as an OCTET STRING, which is the protected form of AdditionalSecurityInfo. ProtectedAdditionalSecurityInfo ::= OCTET STRING -- Protected form of AdditionalSecurityInfo AdditionalSecurityInfo ::= SEQUENCE { originatorAuxVector OCTET STRING OPTIONAL, lRBAC SEQUENCE OF OCTET STRING, asiIntegrityCheckValue OCTET STRING } 7.1.2 MlKeyToken The MlKeyToken contains the RecipientKeyToken that the originator of the message constructed. Presence of the MlKeyToken indicates that the message has been redistributed by an MLA. The MLA has protected the MlKeyToken with an MLK, which the MLA has previously distributed to the members of the ML. MlKeyToken ::= SEQUENCE { mlTag MLTag, mlProtectedKeyToken ProtectedRecipientKeyToken} 7.1.2.1 MLTag MLTag is generated by an MLA and contains a mlid that is the Kmid of MLA, and an mlKeyDate that is the date the MLA performed redistribution. MLTag ::= SEQUENCE { mlid Kmid, mlKeyDate UTCTime } 7.1.2.2 Kmid The Kmid is a unique identifier associated with the user's key management public cryptographic material. Kmid ::= OCTET STRING 7.2 SignatureBlock The SignatureBlock contains either information used to provide non-repudiation with proof of origin or non-repudiation with proof of delivery. The MSP UA calculates a digital signature, which consists of signing a hash using the originator's signature public cryptographic material. The hash is calculated by first generating a complete hash over the encapsulated content. This hash is the msgHash, which is placed in the RecipientKeyToken. A second hash value is calculated over the concatenation of the msgHash and signatureInformation (i.e., a hash calculated over the value of msgHash prepended to context-specific tag [0] within the ControlInformation CHOICE). This second hash is used as the input to the signature algorithm, which the MSP UA signs and includes as the signatureValue. If the recipient is generating a signed receipt, then a hash value is calculated using the hash value used to compute the signatureValue of the original message prepended to the receiptInformation, (this includes the context-specific tag [1] within the ControlInformation CHOICE) and then signed. The signatureAlgorithm identifies the algorithm used to generate the digital signature including the hash function. The signatureCertificate is an X.509 certification path which establishes the binding between the user's Distinguished Name and the user's digital signature public cryptographic material. SignatureBlock ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue OCTET STRING, controlInformation ControlInformation, signatureCertificate CertificationPath OPTIONAL } 7.2.1 ControlInformation ControlInformation is either SignatureInformation that contains additional information from the originator including receipt requests, or ReceiptInformation that contains information from the recipient used to identify the message for which the recipient has returned the receipt. ControlInformation ::= CHOICE { signatureInformation [0] SignatureInformation, receiptInformation [1] ReceiptInformation } 7.2.1.1 SignatureInformation SignatureInformation is included in a message that has been signed. The Originator may request a signed receipt by placing additional information in SignatureInformation. The encapsulatedContentType specifies the ContentType of the original message. The signedContentIdentifier (see section 9.3) must be generated by the originator of the message and the originator retains it along with the receiptRequests, the hash that was used to compute the signatureValue, and the signatureValue in a local database. The database is used for later processing of signed receipts. The receiptRequests indicates from which recipients the originator requests signed receipts. The originator uses the receiptsTo field to identify the users to whom the receiving UA should send signed receipts. It is used only if signed receipts are to be sent to users other than, or in addition to, the originator. If the receiptsTo field is used to designate recipients in addition to the originator , then the originator's ORName must be included in the receiptsTo list. In receiptsTo, the ORAddress form of ORName should be used when receipts are to be directed to a specific mailbox, otherwise the Distinguished Name form should be used. SignatureInformation ::= SEQUENCE { encapsulatedContentType ContentType OPTIONAL, signedContentIdentifier OCTET STRING, receiptRequests ReceiptsIndicator, receiptsTo ORNameList OPTIONAL (SIZE (1..ub-receiptsTo)) } 7.2.1.1.1 ReceiptsIndicator ReceiptsIndicator allows the Originator to specify either a list of recipients that should send signed receipts (receiptList), or an enumerated value (allOrNone). The value receiptList is a list of ORName(s). AllOrNone can be either noReceipt (0), allReceipts (1), or firstTierRecipients (2). The value noReceipt means no recipient should send a receipt. The value allReceipts means all recipients should send receipts. The value firstTierRecipients means recipients with no information present in the mlExpansionHistory should send receipts; that is the recipient did not receive this message as a result of being a member of a ML. ReceiptsIndicator ::= CHOICE { allOrNone [0] AllOrNone, receiptList [1] ORNameList } AllOrNone ::= INTEGER { noReceipt (0), allReceipts (1), firstTierRecipients (2) } ORNameList ::= SEQUENCE OF ORName 7.2.1.2 ReceiptInformation ReceiptInformation is included in a receipt sent by a recipient of a message in response to the originator's request for signed receipts. The encapsulatedContentType is the content type of the original message. The signedContentIdentifier is the identifier of the original message. The originatorSignatureValue is the digital signature of the original message. ReceiptInformation ::= SEQUENCE { encapsulatedContentType ContentType OPTIONAL, signedContentIdentifier OCTET STRING, originatorSignatureValue OCTET STRING } 7.3 PerRecipientToken Each PerRecipientToken contains information for an intended recipient of the message. There is one of these for each recipient, and it has two parts, the Tag and the ProtectedRecipientKeyToken. The tag is clear text and contains identifying information each recipient uses to select and process his PerRecipientToken. The ProtectedRecipientKeyToken is an OCTET STRING, the value of which the originator encrypted in a pairwise key that only the intended recipient can obtain. If an MLA is processing this message then the ProtectedRecipientKeyToken value is the result of the MLA encrypting the RecipientKeyToken with a pairwise key. PerRecipientToken ::= SEQUENCE { tag Tag, protectedRecipientKeyToken ProtectedRecipientKeyToken } 7.3.1 Tag The Tag is generated by the Originator MSP process and contains information that the recipient uses to identify which of its posted certificates and UKMs the Originator MSP process used to protect the token. The kmid and the edition identify the certificate, and the date, if present, identifies the recipient's UKM. Tag ::= SEQUENCE { kmid Kmid, edition INTEGER (SIZE (1..ub-edition-size)), date UTCTime OPTIONAL } 7.3.2 ProtectedRecipientKeyToken and RecipientKeyToken The ProtectedRecipientKeyToken is the protected form of RecipientKeyToken. The RecipientKeyToken contains the msgKey that is used to protect the message. The msgHash is calculated over the (original unprotected text) message content. The additionalSecurityInfoIndicator is set to true if additionalSecurityInfo is present. The signatureBlockIndicator is set to true if a signatureBlock is present. The encapsulatedContentType is the Content Type of the message that is protected by MSP. ProtectedRecipientKeyToken ::= OCTET STRING -- Protected form of RecipientKeyToken RecipientKeyToken ::= SEQUENCE { msgKey OCTET STRING, msgHash OCTET STRING, signatureBlockIndicator BOOLEAN, additionalSecurityInfoIndicator BOOLEAN, encapsulatedContentType ContentType, securityLabel SecurityLabel } 7.3.2.1 SecurityLabel The SecurityLabel contains information regarding the classification of the original content that is protected by the MSP encapsulation. This definition is consistent with 1988 CCITT Recommendation X.411 and is a conformant subset. The PrivacyMark is carried as provided by the original UA, but it is not used in access control decisions by the MSP UA. SecurityLabel ::= SET { security-policy-identifier OBJECT IDENTIFIER OPTIONAL, security-classification SecurityClassification OPTIONAL, privacy-mark PrivacyMark OPTIONAL, security-categories SecurityCategories OPTIONAL } SecurityClassification ::= INTEGER { unclassified (1), confidential (3), secret (4), top-secret (5), unclassified-but-sensitive (11) } PrivacyMark ::= PrintableString (1..ub-privacy-mark-length) SecurityCategories ::= SET (SIZE (1..ub-categories)) OF SecurityCategory SecurityCategory ::= SEQUENCE { prbacId [0] OBJECT IDENTIFIER, prbac [1] OCTET STRING } 7.4 MlControlInformation MlControlInformation is placed in the MSP heading by an MLA and contains either an MLK (recipientMLKeyDistributionToken), or the ML expansion history. The recipientMLKeyDistributionToken contains cryptographic material (one copy for each ML member) that an MLA distributes to members of an ML. The members of the ML use this information to decrypt tokens processed by the MLA. Each member of a ML receives a separate PerRecipientMLKeyDistributionToken. Subsequently, when a MLA processes a message, all of the recipients can decrypt the message without the MLA constructing separate tokens for each recipient. The mlExpansionHistory is updated each time a message is distributed to members of a ML by an MLA. The history of MLs enables an MLA to detect a loop in the sequence of ML expansions and if absent, a recipient discovers that he is a first tier recipient. MlControlInformation ::= CHOICE { recipientMLKeyDistributionToken [9] SET OF PerRecipientMLKeyDistributionToken, mlExpansionHistory [10] SEQUENCE OF MlData } 7.4.1 PerRecipientMLKeyDistributionToken The PerRecipientMLKeyDistributionToken contains an mlKeyTag (see section 7.3.1) that identifies the intended recipient and the cryptographic material the MLA used to construct the pairwise key. The mlid identifies the ML. The mlKeyToken is an OCTET STRING the value of which has been encrypted with a pairwise key for the intended recipient. ProtectedMLKeyDistributionToken is the protected form of MLKeyDistributionToken. The MLKeyDistributionToken contains the MLK as well as the start and end of the time period during which the MLK is valid. PerRecipientMLKeyDistributionToken ::= SEQUENCE { mlKeyTag Tag, mlid Kmid, mlKeyDistributionToken ProtectedMLKeyDistributionToken } ProtectedMLKeyDistributionToken ::= OCTET STRING -- Protected form of MLKeyDistributionToken MLKeyDistributionToken ::= SEQUENCE { mlKey OCTET STRING, mlKeyNotBefore UTCTime, mlKeyNotAfter UTCTime } 7.4.2 MlData MlData contains the expansion history of MLAs that have processed the message. As each subsequent MLA distributes a message to members of a ML, the MLA records its mlid, date and time of expansion, and its receipt policy in a MlData and appends it to the mlExpansionHistory. MlData ::= SEQUENCE { mlid Kmid, expansionTime UTCTime, mLReceiptPolicy MLReceiptPolicy OPTIONAL } 7.4.2.1 MLReceiptPolicy When present, the MLReceiptPolicy specifies a receipt policy which supersedes the originator's request for signed receipts. The policy can be one of three possibilities. A ML can specify that receipts should not be returned (none). A ML can specify that receipts should be returned to an alternate list of recipients, instead of to the originator (insteadOf). A ML can specify that receipts should be returned to a list of recipients in addition to the originator (inAdditionTo). MLReceiptPolicy ::= CHOICE { none [0] NULL, insteadOf [1] ORNameList (SIZE (1..ub-insteadOf)), inAdditionTo [2] ORNameList (SIZE (1..ub-inAdditionTo)) } 8. Elements of Procedure 8.1 Certificate Validation MSP relies upon X.509 certificates to obtain identification and authorization information for users in support of the security services provided by MSP. The MSP UA must ensure that any certificate used by MSP is valid based on the following criteria: 1) The signature on the user's certificate is valid (based on the public key from the issuer's certificate). 2) The current date falls within the certificate validity interval. 3) The certificate serial number does not appear on the certificate issuer's current CRL. 4) The KMID (if used for that algorithm) does not appear on the current KRL. 5) The certificate issuer is a valid certification authority (based on infrastructure specific requirements). 6) The subject name in the issuer certificate matches the issuer name in the user's certificate. For the CRL and KRL checks, the MSP UA must ensure that the check is made using the current CRL and KRL. This is determined by checking that the next Issue date in the CRL or KRL is later than the current date. The MSP UA must ensure that it has the current CRLs and KRL. These requirements apply to all certificates which make up a certification path. 8.1.1 Information Communicated to the User of the MSP UA The MSP UA establishes verified information about a message as part of its MSP processing and certificate validation. The following information must be communicated unambiguously to the user: 1) The authenticated identity of the message signer if the message was signed. 2) The authenticated identity of the message encryptor (i.e. token generator) if the message was encrypted. 3) The security label of the message if the message was encrypted. 4) Any errors detected during MSP processing. Additional information concerning the full certification path may also be required in certain environments. 8.2 Originating a Secure Message 8.2.1 Security Service Selection The MSP UA processes a message content that is accompanied, implicitly or explicitly, by submission envelope information. In some UA-MTA configurations an explicit submission envelope may not be employed but equivalent information will be present as the message is transferred between the UA and the MTA. From the submit envelope, MSP UA uses the following values: * originator-name * recipient-names * content-type * content The MSP UA determines message-security-label information in one of two ways: implicitly, based on local processing context, or explicitly, based on a message-security-label argument. The user may invoke some or all of the offered security services for every message, or may allow a subset from this list. * Confidentiality, Data Origin Authentication, Connectionless Integrity, and Access Control * Non-repudiation with proof of origin (by message signature) * Non-repudiation with proof of delivery (by signed receipt) 8.2.2 Access Control Access control is a determination made concerning the authorization of the originator to send and the recipient to receive the message. These access control decisions are based on the authorization information of the originator, the recipient, and the system on which the originator's user agent resides. User PRBAC authorization information is determined from the users' key management certificates while the system authorization is determined from local configuration data. LRBAC authorization information is contained in the originator's and recipient's auxiliary vectors. If LRBAC information exists, the MSP UA places the originator's auxiliary vector in originatorAuxVector. The MSP UA then places the label of the message that corresponds to LRBAC information in lRBAC. 8.2.3 Per Message Processing The MSP UA calculates a hash value over the (original unprotected text) message content, and stores this value in msgHash. If confidentiality is invoked, the MSP UA obtains a msgKey , and then uses it to encrypt the message content forming encapsulatedContent . The message content is encrypted as a single string. If additionalSecurityInfo is present, the MSP UA calculates a cryptographic hash function over lRBAC, which it places in asiIntegrityCheckValue. The MSP UA then encrypts the structure AdditionalSecurityInfo, using msgKey. The MSP UA indicates the integrity and confidentiality algorithms it used in asiProtectionAlgorithm, and places any parameters required by the algorithms there as well. If non-repudiation with proof of delivery is invoked, the originator must request that either all recipients send receipts (allOrNone {1}), only Tier One recipients send receipts (allOrNone {2}), or a specific list of recipients should send receipts (receiptList). If non-repudiation with proof of origin is invoked, the MSP UA forms a signedContentIdentifier, which it retains in a local database along with the hash value used to compute the signatureValue, the signatureValue, and receiptRequests associated with this message. Having completed the construction of signatureInformation, a hash value is calculated. The hash is calculated by first generating a complete hash over the encapsulated content. This hash is the msgHash, which is placed in the RecipientKeyToken, if confidentiality is invoked. A second hash value is calculated over the concatenation of the msgHash and signatureInformation (ControlInformation CHOICE including the context-specific tag [0] ); i.e., a hash calculated over the value of msgHash prepended to ControlInformation. This second hash is used as the input to the signature algorithm, which the MSP UA uses to calculate the signatureValue associated with this message. If confidentiality is invoked, the MSP UA constructs the RecipientKeyToken. 8.2.4 Per-recipient Processing If the algorithm requires it, the MSP UA obtains the recipient's UKM, which the recipient has posted to the directory. The MSP UA uses the UKM to form a pairwise key that only this intended recipient can derive. The MSP UA uses this pairwise key to protect the RecipientKeyToken, forming the protectedRecipientKeyToken. This along with the tag, which identifies the recipient's certificate and posted UKM, form the PerRecipientToken. The MSP UA forms one of these for each recipient. If the originator is not already an explicit recipient, then the MSP UA generates a RecipientKeyToken for the originator. This allows the originator to decrypt a message, in case it is returned for non-Delivery. 8.2.5 MSP Heading Construction If local security policy permits, the MSP UA may place unprotected text data into contentDescription. This data may include the IPM Subject field or priority and precedence information. The MSP UA now has sufficient information to encode these structures: originatorSecurityData, signatureBlock, recipientSecurityData, contentDescription, encapsulatedContent. Once the MSP UA has encoded these structures, the MSP UA forms Msp. Depending on the site policy, the MSP UA may then sign the complete protected content, Msp (MSP heading and protected content). Before the MSP UA signs Msp, it places the AlgorithmIdentifier in mspSequenceSignatureAlgorithm and if the MSP UA has not placed its signature certificate in the signatureBlock and if the MSP UA has not placed its key management certificate plus signature certificate in originatorSecurityData, then the MSP UA places either its signature certificate or its key management plus signature certificate into mspSequenceSignatureCertificate. The MSP UA then signs Msp by calculating a hash value over the Msp sequence, and uses this result to calculate a signature value that it appends to the Msp sequence, forming SIGNED Msp. The MSP UA creates an X.400 submission envelope based the results of the preceding processing, and based on information obtained from the original submission envelope, which accompanied the message content. The MSP UA includes in this submission envelope the sequence MessageSecurityProtocol, which is either Msp or SIGNED Msp. The MSP UA submits this envelope to the MTS for transfer and delivery. 8.3 Receiving a Secure Message 8.3.1 Security Service Determination The recipient requests the UA to accept delivery of a message from the MTA, or the UA retrieves a message from an MS. If the ContentType is an OBJECT IDENTIFIER that indicates MSP, then MSP processing commences. The MSP UA first determines if the Msp structure has been signed. If so, the signature is checked. If the signature check fails, then a security error has occurred. Next the MSP UA determines, by processing the Msp structure, which security services have been invoked. If OriginatorSecurityData is present, then the originator invoked confidentiality, data origin authentication, connectionless integrity, and access control services. If SignatureBlock is present then the originator invoked the non-repudiation with proof of origin service. 8.3.2 Token Selection If OriginatorSecurityData is present, then the MSP UA selects the correct PerRecipientToken. If the correct PerRecipientToken is not found, the MSP UA examines originatorSecurityData for mlKeyToken. If the mlKeyToken is present, the MSP UA determines if the recipient is a member of the ML. If OriginatorSecurityData is present and neither a correct PerRecipientToken nor mlKeyToken is present then a security error has occurred. Once the correct token is identified, the MSP UA decrypts the token. The MSP UA then checks if signatureBlockIndicator is true. If it is true and the SignatureBlock is not present, then a security error has occurred. 8.3.3 Partition Rule-Based Access Control Access control is a determination made concerning the authorization of the recipient to process and receive the message. These authorizations are based on the authorization information of the originator (obtained from originatorCertificate), the recipient and the recipient's end system. User authorizations represent a maximum clearance, while the end system authorization represents a range. The MSP UA checks that the securityLabel is dominated by both the originator and recipient authorizations and is dominated by the high end of the range of the recipient's end system. If the message security level is below the minimum of the range of the recipient's end system, the MSP UA upgrades the message prior to delivering it to the user. 8.3.4 Local Rule-Based Access Control The MSP UA then checks if additionalSecurityInfoIndicator is true, and if it is, decrypts additionalSecurityInfo and extracts originatorAuxVector, lRBAC, and asiIntegrityCheckValue. The MSP UA then calculates a cryptographic hash function over lRBAC. The MSP UA continues processing if the calculated hash value is equal to asiIntegrityCheckValue, or reports a security error if not equal. The MSP UA obtains additional originator authorization information from the originatorAuxVector, and checks that the lRBAC is dominated by both the originator and recipient authorizations and is dominated by the high end of the range of the recipient's end system. If the message security level is below the minimum of the range of the recipient's end system, the MSP UA upgrades the message prior to delivering it to the user. 8.3.5 Message Processing From the RecipientKeyToken, the MSP UA obtains the msgKey and then decrypts the message. The MSP UA calculates a hash value as a function of the content, and if the value is equal to the msgHash, the content integrity is verified. If the SignatureBlock is present, the MSP UA calculates the hash value over the content. This hash is the msgHash, which has been previously compared to msgHash contained in the RecipientKeyToken, if confidentiality is invoked. A second hash value is calculated over the concatenation of the msgHash and signatureInformation (ControlInformation CHOICE including the context-specific tag [0] ); i.e., a hash calculated over the value of msgHash prepended to ControlInformation. This second hash is used as the input to the signature algorithm, which the MSP UA uses to validate the signatureValue associated with this message. If the MSP UA determines that the originator has requested this recipient to return a receipt, then a ReceiptInformation structure is generated, which includes a signatureValue that the MSP UA must calculated. This receipt signatureValue is a signed hash value, where the hash value is calculated over the same data as the originator's hash followed by the ReceiptInformation structure. 8.4 Mail List Agent Processing 8.4.1 Distributing a Message to Members of a ML Upon receipt of a message, the MLA verifies the Msp sequence signature, if present. If the signature verification fails, then a security error has occurred. The MLA locates its PerRecipientToken and removes all other PerRecipientTokens. The MLA decrypts this token, obtains the SecurityLabel and determines that the label for this message is within the intersection of originator's and ML's authorizations. The MLA then determines if pairwise keys are required for this ML. If so, the MLA constructs PerRecipientTokens. If the ML uses mlKey, then the MLA constructs an mlKeyToken. The MLA updates (or creates if it is the first MLA) mlExpansionHistory and conveys its receipt policy. The MLA replaces values in OriginatorSecurityData as specified in section 7.1. and completes encoding of Msp. The MLA must sign Msp. 8.4.2 Distributing a Mail List Key To distribute a MLK, an MLA constructed an MLKeyDistributionToken. For each member of the ML, the MLA must determine if the authorizations of each ML member dominates the authorizations of the MLA. This authorization information is contained in the ML members' key management certificate and auxiliary vector and the MLA's key management certificate and auxiliary vector. If the ML member is authorized, then the MLA forms a pairwise key for this member of the ML. The MLA uses this pairwise key to protect the MLKeyDistributionToken, and thus form the PerRecipientMLKeyDistributionToken. This process is repeated for each member of the ML. 8.5 Forwarding a Message MSP supports the forwarding of messages only if the original message content does. To forward a previously received signed message, the originator includes this message as a body part in the new message. If the originator wishes to forward a signed receipt it is contained within the new message as a separate body parts. When forwarding a signed message, the entire original MSP message need not be included. The forwarded message may be a constructed MSP message consisting of an encapsulatedContent and a signatureBlock. 8.5.1 Support within P772 and P22 Messages A 1988 X.400 allows for the registration of new message body parts, within the Interpersonal Message Recommendation. The Forwarded-MSP-Message-Body-Part is a registered body part that has the syntax of MessageSecurityProtocol. To forward a signed receipt, the originator includes the MSP Messages that contained the receipt as a separate body part of the type Forwarded-MSP-Message-Body-Part. The extended body part definition is as follows. Forwarded-MSP-Message-Body-Part EXTENDED-BODY-PART-TYPE DATA MessageSecurityProtocol ::= forwarded-MSP-message-body-part forwarded-MSP-message-body-part ::= id-infosec id-formats 72 8.5.2 Support within P2 Messages Within versions of X.400 that do not support registered body parts, a forwarded signed message is 6-bit encoded (defined in 8.5.4 below) and included as an International Alphabet #5 (IA5) body part within the new message. To forward a signed receipt, the originator includes the MSP Messages that contained the receipt as a separate body part, which is 6-bit encoded and an IA5 body part type. 8.5.3 Support within RFC-822 Messages Other message systems that convey ASCII text messages, such as RFC-822 messages, can also provide for the forwarding of signed messages. In this case the signed message to be forwarded is 6-bit encoded and included within the body of the new message. To forward a signed receipt, the originator includes the MSP Messages that contained the receipt as a separate body part, which is 6-bit encoded. If the message format does not support multi-part bodies, then within the new message, the 6-bit encoded message is preceded with the string: ---------- BEGIN FORWARDED MSP SIGNED MESSAGE And, the 6-bit encoded message is followed with the string: ---------- END FORWARDED MSP SIGNED MESSAGE 8.5.4 6-bit Encoding This encoding assumes the input is an integral multiple of 8 bits, and is 8-bit aligned. A 64- character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (This subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure. To represent an MSP message, the encoding function's output is delimited into text lines (using local conventions), with each line except the last containing exactly 64 printable characters and the final line containing 64 or fewer printable characters. (This line length is easily printable and is guaranteed to satisfy SMTP's 1000-character transmitted line length limit.) The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group extracted from the MSP message, each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. These characters, identified in Table 8-1, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", "", ""). Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y Table 8-1 Encoding Table 9. Encoding and Syntactic Conventions 9.1 UTCTime The Type UTCTime is always encoded using the form year, month, day, hours, minutes followed by a "Z". The time is always expressed in Greenwich Mean Time. 9.2 Length Encoding Only definite length encoding is used; indefinite length encoding is strictly forbidden. If encoding is primitive, it shall include the fewest length octets necessary. 9.3 signedContentIdentifier This value shall be generated by the original UA. In the case that the original content is either P22 (Interpersonal Message) or P772 (Military Message Handling Structure) then this value should be either IPM-id or MM-id, respectively, and should always be present on signed messages. If the original UA cannot generate a content identifier, then the signedContentIdentifier is specified as an OCTET STRING and it must be a twenty-four (24) octet field. However, to assure its global uniqueness this OCTET STRING must contain the concatenation of the KMID from the key management public cryptographic material, followed by a thirteen octet UTCTime with a value of yymmddhhmmssZ (this is different than 9.1), followed by a random number that brings the total to 24 octets. 10. MSP Abstract Syntax MessageSecurityProtocol{id-infosec(joint-iso-ccitt 16 840 1 101 2 1) id-modules(0) id-msp(1)} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X.411 Abstract Services ContentType, ORName FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)} ub-content-length, ub-recipients, ub-privacy-mark-length FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) upper-bounds (3)} -- X.420 Interpersonal Messaging System ub-subject-field FROM IPMSUpperBounds {joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) upper-bounds (10)} -- Directory definitions Certificate, CertificationPath, AlgorithmIdentifier, SIGNED FROM AuthenticationFramework {joint-iso-ccitt ds(5) modules(1) authentication-framework(7)}; MessageSecurityProtocol ::= CHOICE { msp [0] Msp, signedMsp [1] SIGNED Msp } Msp ::= SEQUENCE { originatorSecurityData [0] OriginatorSecurityData OPTIONAL, signatureBlock [1] SignatureBlock OPTIONAL, recipientSecurityData [2] SET OF PerRecipientToken OPTIONAL (SIZE (1..ub-recipients)), contentDescription [3] TeletexString OPTIONAL (SIZE (1..ub-subject-field)), mlControlInformation MlControlInformation OPTIONAL, mspSequenceSignatureAlgorithm [6] AlgorithmIdentifier OPTIONAL, mspSequenceSignatureCertificate [7] CertificationPath OPTIONAL, encapsulatedContent [8] OCTET STRING OPTIONAL (SIZE (1..ub-content-length)) } OriginatorSecurityData ::= SEQUENCE { confidentialityAlgorithm AlgorithmIdentifier, integrityAlgorithm AlgorithmIdentifier, tokenProtectionAlgorithm AlgorithmIdentifier, asiProtectionAlgorithm AlgorithmIdentifier OPTIONAL, originatorCertificate [0] CertificationPath OPTIONAL, additionalSecurityInfo [1] ProtectedAdditionalSecurityInfo OPTIONAL, originatorUkm [2] OCTET STRING OPTIONAL, mlKeyToken [3] MlKeyToken OPTIONAL } ProtectedAdditionalSecurityInfo ::= OCTET STRING -- Protected form of AdditionalSecurityInfo AdditionalSecurityInfo ::= SEQUENCE { originatorAuxVector OCTET STRING OPTIONAL, lRBAC SEQUENCE OF OCTET STRING, asiIntegrityCheckValue OCTET STRING } MlKeyToken ::= SEQUENCE { mlTag MLTag, mlProtectedKeyToken ProtectedRecipientKeyToken} MLTag ::= SEQUENCE { mlid Kmid, mlKeyDate UTCTime } Kmid ::= OCTET STRING SignatureBlock ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue OCTET STRING, controlInformation ControlInformation, signatureCertificate CertificationPath OPTIONAL } ControlInformation ::= CHOICE { signatureInformation [0] SignatureInformation, receiptInformation [1] ReceiptInformation } ReceiptInformation ::= SEQUENCE { encapsulatedContentType ContentType OPTIONAL, signedContentIdentifier OCTET STRING, originatorSignatureValue OCTET STRING } SignatureInformation ::= SEQUENCE { encapsulatedContentType ContentType OPTIONAL, signedContentIdentifier OCTET STRING, receiptRequests ReceiptsIndicator, receiptsTo ORNameList OPTIONAL (SIZE (1..ub-receiptsTo)) } ReceiptsIndicator ::= CHOICE { allOrNone [0] AllOrNone, receiptList [1] ORNameList } AllOrNone ::= INTEGER { noReceipt (0), allReceipts (1), firstTierRecipients (2) } ORNameList ::= SEQUENCE OF ORName PerRecipientToken ::= SEQUENCE { tag Tag, protectedRecipientKeyToken ProtectedRecipientKeyToken } Tag ::= SEQUENCE { kmid Kmid, edition INTEGER (SIZE (1..ub-edition-size)), date UTCTime OPTIONAL } ProtectedRecipientKeyToken ::= OCTET STRING -- Protected form of RecipientKeyToken RecipientKeyToken ::= SEQUENCE { msgKey OCTET STRING, msgHash OCTET STRING, signatureBlockIndicator BOOLEAN, additionalSecurityInfoIndicator BOOLEAN, encapsulatedContentType ContentType, securityLabel SecurityLabel } SecurityLabel ::= SET { security-policy-identifier OBJECT IDENTIFIER OPTIONAL, security-classification SecurityClassification OPTIONAL, privacy-mark PrivacyMark OPTIONAL, security-categories SecurityCategories OPTIONAL } SecurityClassification ::= INTEGER { unclassified (1), confidential (3), secret (4), top-secret (5), unclassified-but-sensitive (11) } PrivacyMark ::= PrintableString (1..ub-privacy-mark-length) SecurityCategories ::= SET (SIZE (1..ub-categories)) OF SecurityCategory SecurityCategory ::= SEQUENCE { prbacId [0] OBJECT IDENTIFIER, prbac [1] OCTET STRING } MlControlInformation ::= CHOICE { recipientMLKeyDistributionToken [9] SET OF PerRecipientMLKeyDistributionToken, mlExpansionHistory [10] SEQUENCE OF MlData } PerRecipientMLKeyDistributionToken ::= SEQUENCE { mlKeyTag Tag, mlid Kmid, mlKeyDistributionToken ProtectedMLKeyDistributionToken } ProtectedMLKeyDistributionToken ::= OCTET STRING -- Protected form of MLKeyDistributionToken MLKeyDistributionToken ::= SEQUENCE { mlKey OCTET STRING, mlKeyNotBefore UTCTime, mlKeyNotAfter UTCTime } MlData ::= SEQUENCE { mlid Kmid, expansionTime UTCTime, mLReceiptPolicy MLReceiptPolicy OPTIONAL } MLReceiptPolicy ::= CHOICE { none [0] NULL, insteadOf [1] ORNameList (SIZE (1..ub-insteadOf)), inAdditionTo [2] ORNameList (SIZE (1..ub-inAdditionTo)) } --Upper Bounds ub-receiptsTo ::= 16 ub-edition-size ::= 2 ub-categories ::= 1 ub-insteadOf ::= 16 ub-inAdditionTo ::= 16 END -- of MSP 11. Object Identifiers This section is for information purposes only. The OBJECT IDENTIFIERS listed below can be found in SDN.702, SDNS Directory Specifications for Utilization with SDNS Message Security Protocol. ID ::= OBJECT IDENTIFIER id-infosec ID ::= {joint-iso-ccitt (2) country (16) us (840) organization (1) u.s. government (101) dod (2) 1} id-modules ID ::= {id-infosec 0} id-algorithms ID ::= {id-infosec 1} id-formats ID ::= {id-infosec 2} id-policy ID ::= {id-infosec 3} id-object-classes ID ::= {id-infosec 4} id-attributes ID ::= {id-infosec 5} id-sdnsSignatureAlgorithm ID ::= {id-algorithms 1} id-mosaicSignatureAlgorithm ID ::= {id-algorithms 2} id-sdnsConfidentialityAlgorithm ID ::= {id-algorithms 3} id-mosaicConfidentialityAlgorithm ID ::= {id-algorithms 4} id-sdnsIntegrityAlgorithm ID ::= {id-algorithms 5} id-mosaicIntegrityAlgorithm ID ::= {id-algorithms 6} id-sdnsTokenProtectionAlgorithm ID ::= {id-algorithms 7} id-mosaicTokenProtectionAlgorithm ID ::= {id-algorithms 8} id-sdnsKeyManagementAlgorithm ID ::= {id-algorithms 9} id-mosaicKeyManagementAlgorithm ID ::= {id-algorithms 10} id-sdnsKMandSigAlgorithms ID ::= {id-algorithms 11} id-mosaicKMandSigAlgorithms ID ::= {id-algorithms 12} id-msp-content-type ID ::= {id-formats 48} id-msp-rev3-content-type ID ::= {id-formats 42} id-msp-rekey-agent-protocol ID ::= {id-formats 49} id-rfc822-message-format ID ::= {id-formats 1} id-empty-content ID ::= {id-formats 2} forwarded-MSP-message-body-part ID ::= {id-formats 72} id-sdns-security-policy-id ID ::= {id-policy 1} id-sdns-prbac-id ID ::= {id-policy 2} id-mosaic-prbac-id ID ::= {id-policy 3} id-msp-user-sdns ID ::= {id-object-classes 1} id-mail-list ID ::= {id-object-classes 2} id-dsa-sdns ID ::= {id-object-classes 3} id-ca-sdns ID ::= {id-object-classes 4} id-crls-sdns ID ::= {id-object-classes 5} id-msp-user-mosaic ID ::= {id-object-classes 6} id-dsa-mosaic ID ::= {id-object-classes 7} id-ca-mosaic ID ::= {id-object-classes 8} id-sdnsKeyManagementCertificate ID ::= {id-attributes 1} id-sdnsUserSignatureCertificate ID ::= {id-attributes 2} id-sdnsKMandSigCertificate ID ::= {id-attributes 3} id-mosaicKeyManagementCertificate ID ::= {id-attributes 4} id-mosaicKMandSigCertificate ID ::= {id-attributes 5} id-mosaicUserSignatureCertificate ID ::= {id-attributes 6} id-mosaicCASignatureCertificate ID ::= {id-attributes 7} id-sdnsCASignatureCertificate ID ::= {id-attributes 8} id-auxiliaryVector ID ::= {id-attributes 10} id-mlReceiptPolicy ID ::= {id-attributes 11} id-mlMembership ID ::= {id-attributes 12} id-mlAdministrators ID ::= {id-attributes 13} id-mlid ID ::= {id-attributes 14} id-janUKMs ID ::= {id-attributes 20} id-febUKMs ID ::= {id-attributes 21} id-marUKMs ID ::= {id-attributes 22} id-aprUKMs ID ::= {id-attributes 23} id-mayUKMs ID ::= {id-attributes 24} id-junUKMs ID ::= {id-attributes 25} id-julUKMs ID ::= {id-attributes 26} id-augUKMs ID ::= {id-attributes 27} id-sepUKMs ID ::= {id-attributes 28} id-octUKMs ID ::= {id-attributes 29} id-novUKMs ID ::= {id-attributes 30} id-decUKMs ID ::= {id-attributes 31} id-metaSDNScrl ID ::= {id-attributes 40} id-sdnsCRL ID ::= {id-attributes 41} id-metaSDNSsignatureCRL ID ::= {id-attributes 42} id-SDNSsignatureCRL ID ::= {id-attributes 43} id-sdnsCertificateRevocationList ID ::= {id-attributes 44} id-mosaicCertificateRevocationList ID ::= {id-attributes 45} id-mosaicKRL ID ::= {id-attributes 46} id-mlExemptedAddressProcessor ID ::= {id-attributes 47} Information returned could include the envelope information currently described in the P7 specification plus cleartext MSP heading information (such as security services and the content description). The end system is the host or workstation in which the user agent resides. If a recipient receives a message which requests a receipt and processes it multiple times, the originator may receive multiple receipts for the same message from a single recipient. The type AlgorithmIdentifier is defined in CCITT Recommendation X.509 and includes an ObjectIdentifier plus any parameters required by the algorithm (such as an initialization vector). This service is offered independently of Delivery Notification. How msgKey is obtained is out of the scope of this document. If confidentiality is not invoked then the message content becomes encapsulatedContent. The value allOrNone is set to {0} if non-repudiation with proof of delivery is not invoked. Non-repudiation with proof of delivery requires the originator to select non-repudiation with proof of origin. MSP 2.0 12/11/92 FOR OFFICIAL USE ONLY