|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
DoD Secure Data Network System's Message Security
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Secure Data Network System
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 11. Scope and Field of Application 22. References
33. Definitions 43.1 Open System Interconnection 43.2 Message
Handling System 43.3 The Directory 43.4 Secure Data Network
Systems 53.5 Message Security 54. Symbols and Abbreviations 65.
Message Security Protocol Overview 75.1 MSP Concept 75.2
Overview of the Protocol 95.2.1 Originator Processing 95.2.2
Recipient Processing 105.2.3 Forwarding 115.2.4 MSP User
Certificates and Auxiliary Vectors 125.3 MSP Support Features
145.3.1 Travelling Users 145.3.2 Mail Lists 156. Service Elements
/ Interfaces 166.1 User Agent 166.2 Message Transfer System
166.3 Message Store 166.4 Directory User Agent 166.5 Directory
System Agent 176.6 Secure Data Network System Key
Management System 176.7 Local Management Authority 176.8
Certification Authority 177. MessageSecurityProtocol 187.1
OriginatorSecurityData 197.1.1 ProtectedAdditionalSecurityInfo
197.1.2 MlKeyToken 207.1.2.1 MLTag 207.1.2.2 Kmid 207.2
SignatureBlock 207.2.1 ControlInformation 217.2.1.1
SignatureInformation 217.2.1.1.1 ReceiptsIndicator 217.2.1.2
ReceiptInformation 227.3 PerRecipientToken 227.3.1 Tag 227.3.2
ProtectedRecipientKeyToken and RecipientKeyToken 237.3.2.1
SecurityLabel 237.4 MlControlInformation 237.4.1
PerRecipientMLKeyDistributionToken 247.4.2 MlData 247.4.2.1
MLReceiptPolicy 258. Elements of Procedure 268.1 Certificate
Validation 268.1.1 Information Communicated to the User of the
MSP UA 268.2 Originating a Secure Message 278.2.1 Security
Service Selection 278.2.2 Access Control 278.2.3 Per Message
Processing 278.2.4 Per-recipient Processing 288.2.5 MSP Heading
Construction 288.3 Receiving a Secure Message 298.3.1 Security
Service Determination 298.3.2 Token Selection 298.3.3 Partition
Rule-Based Access Control 298.3.4 Local Rule-Based Access
Control 308.3.5 Message Processing 308.4 Mail List Agent
Processing 308.4.1 Distributing a Message to Members of a ML
308.4.2 Distributing a Mail List Key 318.5 Forwarding a Message
318.5.1 Support within P772 and P22 Messages 318.5.2 Support
within P2 Messages 318.5.3 Support within RFC-822 Messages
328.5.4 6-bit Encoding 329. Encoding and Syntactic Conventions
349.1 UTCTime 349.2 Length Encoding 349.3
signedContentIdentifier 3410. MSP Abstract Syntax 3511. Object
Identifiers 39Table of Figures
Figure 5-1 Placement of MSP Services 7Figure 5-2 MSP Protocol
Encapsulation 8Figure 5-3 Three Types of X.509 Certificates
12Figure 5-4 Certificate Options 13Figure 5-5 Key Management
Certificate and Auxiliary Vector 14Table 8-1 Encoding Table 33
1.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.
1.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.
1.Definitions 2.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
1.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)
1.The Directory
This document uses the following term 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)
1.Secure Data Network Systems
This document uses 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)
1.Message Security
For the purposes of this document the following definitions 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.
1.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
1.Message Security Protocol Overview 2.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.
<Picture>
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.
<Picture>
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.
1.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.
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.
1.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).
1.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 contain 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 forwarded. 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.
1.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.
<Picture>
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. The 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.
<Picture>
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.
1.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.
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.
1.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 to the
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.
1.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.
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 processes that interact 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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.Local Management Authority
The local management authority (LMA) issues auxiliary vectors
(AVs). MSP UAs use AVs to make access control decisions.
1.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.
1.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)) }
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 }
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 }
1.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
}
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 }
1.Kmid
The Kmid is a unique identifier associated with the user's key
management public cryptographic material.
Kmid ::= OCTET STRING
1.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
}
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 }
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)) }
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
1.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 }
1.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 }
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 }
1.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 }
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 }
1.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 }
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 }
1.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 }
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)) }
1.Elements of Procedure 2.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.
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.
1.Originating a Secure Message 2.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)
1.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.
1.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.
1.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.
1.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 on 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.
1.Receiving a Secure Message
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.
1.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.
1.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.
1.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.
1.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 the
recipient 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.
1.Mail List Agent Processing
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.
1.Distributing a Mail List Key
To distribute a MLK, an MLA constructs 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.
1.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.
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
1.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.
1.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
1.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., ".", "<CR>",
"<LF>").
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
1.Encoding and Syntactic Conventions 2.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.
1.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.
1.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.
1.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 }
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
ReceiptInformation ::= SEQUENCE {
encapsulatedContentType ContentType OPTIONAL,
signedContentIdentifier OCTET STRING,
originatorSignatureValue OCTET STRING }
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
1.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}
Appendix A of SDN.701
MOSAIC Algorithms
1.0 Overview
The purpose of this appendix is to specify the conventions for use
of the MSP specification with the MOSAIC suite of cryptographic
algorithms. This appendix describes the approaches for data
encryption, hash, signature generation and validation, and token
processing.
2.0 Data Encryption
When message confidentiality is selected as a service, the
encapsulated content is encrypted as a single string. This string is
padded to a multiple of 8 octets and encrypted as a single string.
Encryption is performed using the SKIPJACK algorithm in CBC
mode. The IV for this encryption is placed in the parameters field
of the mosaicConfidentialityAlgorithm algorithm identifier.
Padding shall be performed as follows. The input to the SKIPJACK
CBC encryption process shall be padded to a multiple of 8 octets.
Let n be the length in octets of the input. Pad the input by
appending 8-(n mod 8) octets to the end of the message, each
having the value 8-(n mod 8), the number of octets being added. In
hexadecimal, the possible paddings are: 01, 0202, 030303,
04040404, 0505050505, 060606060606, 07070707070707, and
0808080808080808. All input is padded with 1 to 8 octets to
produce a multiple of 8 octets in length. The padding can be
removed unambiguously after decryption.
3.0 Signatures
Signatures are generated by calculating a hash over the data to be
signed and then calculating a signature based on the resulting hash
value. The hash used throughout this processing shall be the NIST
Secure Hash Algorithm and the signature algorithm shall be the
NIST Digital Signature Algorithm.
The signature value specified in the DSA consists of the values R
and S. Mosaic signature values used in MSP and in certificates
(either a BIT STRING or an OCTET STRING) will carry R and S
encoded as SEQUENCE (INTEGER, INTEGER) in the order R, S.
3.1 Generation
A message signature is generated by calculating a hash on the
encapsulated content, and the signature control information. This
hash is then input to the signature algorithm with the result placed
in the signature value field in the signature block.
The hash is calculated by first generating a complete hash over the
encapsulated content. This hash, the msgHash, is placed in the
token. A second hash value is calculated over the concatenation of
the msgHash and ControlInformation (SignatureInformation
choice) (i.e., a hash calculated over the 160 bit msgHash prepended
to ControlInformation). This second hash is used as the input to the
signature algorithm.
3.2 Validation
A message signature is validated by calculating a hash based on the
encapsulated content, and the signature information. This hash is
calculated in the same manner as specified in section 3.1 and is
used along with the received signature value as input to the DSA
signature validation process which determines the validity of the
signature.
3.3 Receipt Generation
A receipt is generated by calculating a hash based on the
encapsulated content, signature information from the message being
receipted, and the receipt information field. A hash based on the
encapsulated content, and signature control information from the
message being receipted is calculated according to section 3.1. A
hash is then calculated based on the concatenation of this signature
hash and the ControlInformation (ReceiptInformation choice). This
resulting hash is then input to the signature algorithm with the
result placed in the signature value field in the signature block.
3.4 Receipt Validation
A receipt is validated by calculating the hash based on the
encapsulated content, signature information from the message being
receipted, and the receipt information field. This hash is calculated
in the same manner as specified in section 3.3 and is used along
with the received signature value as input to the DSA signature
validation process which determines the validity of the signature.
3.5 Hash Extension
In many cases it is necessary to calculate a hash over different
collections of input involving common elements (e.g. the msg hash
in the token is calculated over the encapsulated content while the
input to the signature value is calculated over the encapsulated
content and the signature information). The SHA used here
specifies appending the length of the signed data at the end of the
data being hashed.
In order to generate complete hashes over a sequence of objects, a
hash is calculated over the first object, and the resulting 160 bit
hash is then prepended to the second object for subsequent hash
calculations. This approach is reflected in the descriptions in
sections 3.1 and 3.3 and in the following diagram.
<Picture>
Figure 1 - Hash Calculation
Figure 1 shows the relationship between the respective hashes
calculated for tokens, message signatures, and signed receipts. All
hash values are complete SHA hashes including the length input.
Each successive hash in the diagram is calculated over the
concatenation of the 160 bit preceding hash and the ASN.1
encoded additional data.
4.0 Tokens
Per-recipient tokens are generated for each recipient of a MSP with
MOSAIC message. The contents of the token are specified in the
MSP specification.
4.1 Token Protection
Individual recipient key tokens are protected for each recipient of a
message. The token is protected using a token protection key
generated by means of the key exchange algorithm. This token
protection key is generated using the KEA material of the
originator and the recipient along with the originator UKM for this
message and the value 01 (see section 4.3).
Note: For the generation of the token protection key to be
successful, the parameters, g, p, and q, for the KEA material of the
originator and the recipient must be the same.
The KMID from the recipient's KEA material is used in the tag for
this token. The Edition field of the tag is set to 0 and the date field
is omitted.
The token protection key is first used to protect the message key.
The message key is protected using the Tessera/Capstone wrapping
function. This function will take the 80 bit message key along with
a 16 bit checkvalue and produce a 96 bit result using the token
protection key. The result of this wrapping operation is the
protected message key.
The protected message key, the msgHash, signatureBlockIndicator,
additionalSecurityInfoIndicator, encapsulatedContentType, and
securityLabel are the contents of the RecipientKeyToken.
The RecipientKeyToken is padded to a multiple of 8 octets using
the pad algorithm specified in section 2.0. An ICV is calculated
over the RecipientKeyToken and pad. The ICV is 64 bits. The first
32 bits are a 1's complement addition of each 32 bit block of the
RecipientKeyToken and pad. The last 32 bits are all 0's.
As an example of the ICV algorithm, for a RecipientKeyToken
(note this sample token is random data)
C517680FA7C01FDA8362342C (hex); it would first be padded to
C517680FA7C01FDA8362342C04040404. The ICV would be
F43DC01A00000000.
The RecipientKeyToken, pad, and ICV are then concatenated and
encrypted with the token protection key, using the SKIPJACK
algorithm in CBC mode, forming a protected token.
An IV is generated for each protected token and is prepended to the
protected token forming a ProtectedRecipientKeyToken.
4.2 Key Generation
The message key for each message is generated locally. This key
shall not be used for any other purpose.
4.3 UKMs
An originator UKM is generated by the originator MSP UA for
each message. This UKM is placed in the originator UKM field and
is used to form each token protection key. A token protection key
is formed for each recipient using the KEA with these inputs:
originator's private key, the recipient's public key, the originator
UKM, and the value 01.
The recipient obtains the token protection key using the KEA with
these inputs: recipient's private key, the originator's public key, the
originator UKM, and the value 01.
An originator UKM is a 1024 bit random number generated by the
originator. The value 01 is also represented as a 1024 bit quantity.
4.4 ML Key Tokens
Not applicable.
4.5 ML Key Generation
Not applicable.
4.6 TU Key Tokens
Not applicable.
5.0 Travelling Users
Not applicable.
6.0 Additional Security Info
If present, the ASI is independently encrypted using the message
key from the RecipientKeyToken. The ASI is padded to a multiple
of 8 octets using the pad algorithm specified in section 2.0 and is
encrypted using the SKIPJACK algorithm in CBC mode. The
asiIntegrityCheckValue is calculated over the lrbac field in the ASI.
The algorithm used for the asiIntegrityCheckValue is the same
algorithm specified for the token ICV in section 4.1. The IV for the
ASI encryption is placed in the parameters field of the
asiProtectionAlgorithm algorithm identifier. This IV must be
different from the IV used for the encryption of the encapsulated
content.
7.0 Algorithm IDs
id-mosaicSignatureAlgorithm DSA with SHA
id-mosaicConfidentialityAlgorithm SKIPJACK in CBC mode
id-mosaicIntegrityAlgorithm SHA
id-mosaicTokenProtectionAlgorithm (see section 4.1)
id-mosaicKeyManagementAlgorithm KEA
id-mosaicKMandSigAlgorithms KEA and DSA with SHA
The id-mosaicKMandSigAlgorithms value is used in X.509
certificates to indicate that both the KEA and DSA keys are
present. This value may be used in either the case where two
bitstrings are present or the case where the same key is used for
both algorithms.
The DSA and KEA algorithms have optional parameters associated
with them. The same parameters may be used for both algorithms.
For Mosaic and MSP, the algorithm parameters are expected to be
carried in the algorithm identifier in the subject public key info
field of the X.509 certificate. If absent, the parameters of the
certificate's issuer apply.
The following structures are used to convey parameters required for
the operation of cryptographic algorithms. These structures are the
individual Type definitions that are included, along with the
appropriate Object Identifier, within the AlgorithmIdentifier
structure.
Kea-Dss-Parms ::= CHOICE {
different-parms [0] Different-Parms
common-parms [1] Common-Parms }
Different-Parms ::= SEQUENCE {
kea-parms Kea-Parms,
dss-parms Dss-Parms }
Kea-Parms ::= SEQUENCE {
p OCTET STRING,
q OCTET STRING,
g OCTET STRING }
Dss-Parms ::= SEQUENCE {
p OCTET STRING,
q OCTET STRING,
g OCTET STRING }
Common-Parms ::= SEQUENCE {
p OCTET STRING,
q OCTET STRING,
g OCTET STRING }
Skipjack-Parm ::= SEQUENCE {
initialization_vector OCTET STRING }
The following table lists the assignment of cryptographic
algorithms, assigned Object Identifiers, and Parameters to Object
Identifier value names for each mosaic algorithm.
Symbolic Object Identifier
Algorithm
Assigned Object Identifier
Parameters
id-mosaicSignatureAlgorithm DSA with SHA2 16 840 1 101 2 1 1
2 Dss-Parmsid-mosaicConfidentialityAlgorithm SKIPJACK in
CBC mode
2 16 840 1 101 2 1 1 4 Skipjack-Parmid-mosaicIntegrityAlgorithm
SHA2 16 840 1 101 2 1 1 6 absentid-
mosaicTokenProtectionAlgorithm see section 4.1 of PMSP
Algorithms Appendix 2 16 840 1 101 2 1 1 8absent id-
mosaicKeyManagementAlgorithm KEA2 16 840 1 101 2 1 1 10
Kea-Parmsid-mosaicKMandSigAlgorithms KEA and DSA with
SHA2 16 840 1 101 2 1 1 12 Kea-Dss-Parms
8.0 Certificate Formats
The Subject Public Key field of the X.509 certificates may contain
the MOSAIC signature material, key management material, or both
elements of MOSAIC keying material. The format and conventions
for carrying MOSAIC information in X.509 certificates are
contained in the MOSAIC Key Management Concept
Document.Appendix B of SDN.701
DMS/MSP/Mosaic Requirements
The following requirements apply to all DMS compliant
MSP/Mosaic User Agent implementations.
1.The MSP UA must implement the MSP Mosaic Algorithm
Appendix dated 1994-03-23. 2.The MSP Security Label must
contain a Security Classification. 3.The MSP UA must determine
whether a message is an organizational message and must
unambiguously communicate this fact to the user. A message is
considered an organizational message if and only if it has been
signed by a user with a certificate designated as an organizational
user certificate. 4.The MSP UA must include as part of certificate
validation a CA check and a name subordination check. The CA
check consists of checking that all issuer certificates contain a
CA/LA authorization. The name subordination check consists of
ensuring that the initial portion of the subject name is equivalent to
the issuer's name, not including the terminal component of the
issuer's name. For example, if the issuer name is C=US, O=DoD,
OU=National Security Agency, CN=NSA LAW; all certificates
signed by that issuer must begin with C=US, O=DoD,
OU=National Security Agency.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
