SECURING ELECTRONIC MAIL
WITHIN HMG
PART I
INFRASTRUCTURE
AND
PROTOCOL

DRAFT C

21 March 1996

Back to the Public Key Infrastructure Project Pages

TABLE OF CONTENTS

1. INTRODUCTION

1.1 Purpose and Scope
1.2 List of Abbreviations
1.3 Background

2. AUTHENTICATION FRAMEWORK

2.1 Background
2.2 Certification Authorities
2.3 Certificate Revocation List
2.4 Certificate Verification
2.5 User Data Verification

3. CONFIDENTIALITY FRAMEWORK

3.1 Background
3.2 Key Management Scheme
3.3 Key Updates
3.4 Certificate Revocation

4. SECURITY PROTOCOL

4.1 Introduction
4.2 Abstract Syntax Notation One
4.3 Secure Data Packet
4.4 Secure Data Receipt

A. REFERENCES

Back to the Public Key Infrastructure Project Pages

This document is the first part of CESG's recommendations for securing electronic mail within HMG. The main objective of the recommendations is to facilitate pan-government secure inter-operability of electronic mail, by simplifying the implementation of secure electronic mail within government, ensuring secure electronic mail between departments is possible, attempting to facilitate future inter-operability with commercial users, maximising the use of commercial technology in a controlled manner, whilst allowing access to keys for data recovery or law enforcement purposes if required.

This document consists of four sections: Section One (this section) provides some background material; Section Two describes the authentication framework which will enable the authenticity of data objects within a mail system to be verified; Section Three describes the confidentiality framework required to support a user to user confidentiality service; and Section Four describes the security protocol proposed to implement the security services (such as confidentiality) between users.

Future parts of these recommendations will provide implementation guidance to developers building products to protect the various levels of protective marking (including algorithms), and define the operation of parts of the infrastructure required to support both frameworks.

ASN - Abstract Syntax Notation
ASCII - American Standard Code for Information Interchange
BER - Basic Encoding Rules
CESG - Communications Electronics Security Group
CRL - Certificate Revocation List
DER - Distinguished Encoding Rules
EDIFACT - Electronic Data Interchange for Administration, Commerce and Transport
HMG - Her Majesty's Government
ITU - International Telecommunications Union
MSP - Message Security Protocol
TBS - To Be Specified

Over the past few years electronic mail has become the most popular medium for exchanging information within the IT industry. It is used by both people and computer processes to exchange a variety of 'message' formats, from simple ASCII to machine-readable business documents, eg. EDIFACT. Communication systems such as the INTERNET, which support electronic mail, allow users to send mail over vast distances, and to many different countries.

There are currently two main 'standards' for electronic mail in widespread use. The first is based upon the work of the International Telecommunications Union (ITU) and is documented in the X.400 set of recommendations. The second is based upon work carried out by a number of organisations associated with the INTERNET and documented in a series of 'Request For Comment' papers (RFCs). The standards define the various protocols required to transfer mail from one user to another. For example, the protocol used to transfer mail between mail servers or switches is defined in X.400 as the P1 protocol, and for the INTERNET as the Simple Mail Transfer Protocol.

Security (be this for confidentiality, authentication or other aspects) is not a major feature within current implementations of these standards. The INTERNET does not provide its users with any confidentiality or integrity services, however there are a number of 'add-on' products which provide these services - none of which are approved for the protection of HMG protectively marked material. The X.400 recommendations do define a set of security services as part of the protocols, however these are specific to X.400 and few implementations are commercially available. The mail systems and the information they carry are therefore susceptible to component failure, user misuse, and malicious attack, which may result in:

• the disclosure of information,
• the modification of information,
• the impersonation of legitimate users,
• the denial of message generation or receipt,
• the denial of system services.
  

The popularity of electronic mail within government has meant that it has now been adopted for transferring official material within and between departments, and between government and commerce and other outside bodies. As much of this use became established before the new protective marking scheme was introduced in 1994, we have a de facto situation in which a significant proportion of this information now deserves a protective marking. Even where a protective marking is not formally warranted, users seek certain assurances from their electronic mail systems. There assurances can be provided to the user in the form of a number of user to user security services, such as:

• data confidentiality,
• data integrity,
• proof of origin,
• proof of delivery/receipt,
• non-repudiation of origin,
• non-repudiation of receipt
  

The security services are implemented in the form of a security protocol which conveys security information (eg. protective markings, digital signatures, user identities) between users. This document defines the mail-system-independent security protocol used to convey security information between users (Section 4). The services provided by the protocol are based upon public key cryptographic techniques. These techniques require the distribution of key material through trusted channels, and the ability to authenticate material distributed through untrusted channels. An infrastructure is therefore required to generate, authenticate and distribute this key material. This document defines the public key frameworks recommended to support the authentication (Section 2) and confidentiality (Section 3) services provided by the protocol, and to authenticate the key material used by these services.

CESG's policy for the development of products to provide these services is to encourage industry to incorporate CESG approved algorithms into their existing products. This has been done successfully in the past with CESG's RAMBUTAN chip. However it is now recognised that one of the major requirements for electronic mail products is that they should inter-operate with similar products developed by other manufacturers. In order to achieve this, it is no longer practical to provide only the algorithms to industry, and further guidance is now required. The objective of these recommendations is therefore to provide this guidance, and to encourage manufacturers to develop electronic mail products which will be able to inter-operate with similar products from other sources. This should enable a single architecture for secure electronic mail to be implemented within HMG which maximises the use of commercial products, whilst minimising the infrastructure required to support them.

The authentication framework for electronic mail is based upon the ITU's directory authentication framework [509]. The framework employs digital signatures, generated using public key cryptographic techniques, to verify the authenticity of data objects within a mail system. It should be noted that the authentication framework described here is generic and may be used with other applications requiring strong authentication, eg directories. The following are examples of data objects which can be verified within this framework :

• user data (eg. a file, message, or receipt);
• system security data (eg. certificates or other security data such as a user's clearances);

At this time the framework is only intended to provide authentication for protectively marked material and data associated with the confidentiality service, the requirements for legal authentication will require further study. However the framework and security services should provide the necessary mechanisms to meet this requirement once the many issues have been resolved.

A digital signature allows an entity to 'sign' a data object in a way that cannot be easily forged. In this case a signature is generated by first computing a hash or digest of the data object, then enciphering the result using a secret authentication key that is only known to the entity carrying out the signing. Any entity can then verify the authenticity of the data object using the associated public authentication key and parameters. The entity generates a new digest from the data object and uses this, together with the public authentication key and parameters to verify the signature.

The public authentication keys are held within authentication certificates. The certificates are encoded structures (Section 4.2) based upon version three of the X.509 certificate and selected extensions (See [509], [509a] and [509b]). The secret authentication keys are also held within encoded structures, known as secret key tokens. The keys within the tokens may be enciphered with a user code which is distributed to the user via a different channel to the tokens themselves.

A certification authority is responsible for generating and signing authentication certificates. The signatures appended to these certificates are generated from the authority's secret authentication key, and the parameters held within authority's authentication certificate. A certification authority may generate and sign its own authentication certificate, or the authority may be provided with its certificate by a higher level authority, leading to the concept of a hierarchy of authorities. The certification authorities may or may not generate the keys themselves. For example, to provide a non-repudiation service users would generate their own secret and public authentication key pairs, then pass the public part to a certification authority. The certification authority would then satisfy itself that the user had the associated secret key before incorporating it into a certificate which the authority would then sign.

The certification hierarchy for HMG will consist of four types of certifying entity : Top Level Certification Authority, Policy Certification Authority, Certification Authority, and User.

• The Top Level Certification Authority is deemed the 'root' of the hierarchy, and is responsible for signing the certificates used by the Policy Certification Authorities beneath it. The Top Level Certification Authority is also responsible for the management of cross certification, either between its subordinate certification authorities, or between hierarchies.
• A Policy Certification Authority is defined as the top of the certification path within a particular domain. It is responsible for allocating the secret authentication keys and certificates to Certification Authorities, and ensuring that all subordinate authorities conform to the defined security policy for certification, in addition to providing a point of reference for certification outside the domain (cross certification). In order to minimise the depth of the hierarchy a policy certification authority may also register users, and allocate their secret authentication keys and certificates.
  
• A Certification Authority is responsible for registering users, allocating their secret authentication keys and associated certificates. In large organisations it may be necessary to add further layers to the hierarchy, in which case a hierarchy of Certification Authorities may be established. Therefore a Certification Authority may also allocate the secret authentication keys and certificates to authorities below it.
• Users may only sign user data.

A certification path enables an entity to verify the authenticity of a certificate. A certification path is simply an ordered sequence of certificates between the certificate being verified and a point trusted by the verifier. Certification paths can become long and inefficient to process, therefore short paths are encouraged whenever possible.

A certificate must be associated with a uniquely identifiable entity, and the identity of that entity must be cryptographically bound to the key material within it. The method adopted for uniquely identifying entities within the system is based on the distinguished name convention defined in [500]. It should be noted that an entity may be associated with more than one distinguished name. A naming authority is responsible for ensuring that each entity within its jurisdiction is provided with a unique distinguished name. This can only be ensured if the naming authority itself has a unique distinguished name, as all names assigned are subordinate to the authority. Therefore a naming authority must first register with a higher level authority. The highest level authority within the UK is the UK Name Registration Authority, which is part of the British Standards Institute. The certification authority and naming authority must work closely together, and may even be one and the same.

A distinguished name may be constructed from a number of attributes, such as telephone number, international ISDN number, role occupant, street address, house identifier, etc. However in order to simplify the processing of the certificates only a subset of the attributes defined in [520] will be supported within the certificate. Therefore a combination of the following attributes may be used within a certificate to uniquely identify an entity: country name, organisation name, organisational unit name, locality name, surname, given name, initials, common name, and title. A naming authority may use other attributes to identify an entity, however only the above shall be used within certificates. Other attributes defined by [520] will be considered for inclusion, provided proposals are received at CESG by 30 April 1996.

2.3 Certificate Revocation List

The ITU's directory authentication recommendations advocate that certificate revocation lists are used to indicate when a secret key is for some reason revoked. Furthermore they state that it is the issuing authority's responsibility to record this fact in a Certificate Revocation List (CRL). In the event of an authority's secret authentication key being revoked it will be necessary to re-issue the certificates of all the entities below it in the hierarchy. The mechanisms for revoking these keys requires further study, which will involve more than security issues.

All confidentiality and authentication certificates should be successfully verified before the data they hold is used. The process is carried out in three stages. The first stage checks any relevant data within the certificate being verified, such as its validity period. The second stage checks to ensure it has not been revoked, eg. if the associated secret key has been compromised, by checking the revocation list generated by the certificate's issuer. The final stage verifies that the signature is authentic, using information held within its issuer's certificate.

This process must now be carried out on the issuer's certificate, and all the certificates within the certification path until a trusted point is reached, eg the certificate of the Top Level Certification Authority.

Signatures are also applied to user data in order to verify its integrity and origin. The signatures generated are appended to the used data as part of the security protocol used to transfer data between two entities (See section 4). A signature is verified using the public authentication key of the entity which signed the data object. Once the authenticity of the data object has been established, the certificate containing the public authentication key must itself be verified as described in section 2.4.

The confidentiality framework is based upon a proposal by the Royal Holloway College [RHC] for trusted third party services, using the well known Diffie-Hellman public key protocol. The confidentiality framework relies on the authentication framework, defined in the previous section, to ensure that authentic key material is used by the confidentiality service.

The framework has been developed to work with the electronic mail architecture currently evolving within government. The architecture consists of independent domains, corresponding approximately to individual departments. In many cases the domains may be further divided into smaller domains or systems which may be scattered over a wide geographical area. Most domains have a local directory or similar repository for shared information, however this paper does not assume that these are connected. The management of the mail system within a domain is usually the responsibility of the mail system administrator. The administrator's role includes the management of the mail system components, registration of new users, the allocation of user names and addresses, and the management of users' entries within a directory - if one exists.

The confidentiality framework is implemented within a domain by a Certificate Management Authority (analogous to the trusted third party defined in [RHC]). The Certificate Management Authority is subordinate to the Departmental Security Officer (DSO), and responsible to the departments crypto custodian. It will be responsible for registering users of the secure mail system (this may be in addition to the registration of users with the mail system administrator), allocating system privileges, ensuring users have unique distinguished names (but not necessarily allocating them), distributing key material, accounting for key material, and generating key material. As the Certificate Management Authority is responsible for generating the confidentiality keys, it should also take on the role of a certification authority (eg. a Certification Authority or Policy Certification Authority) in order to authenticate them. CESG will initially support the framework through the DSO's and crypto custodians, by generating and signing all the keys used. However in time it is envisaged that this role can be devolved down to those departments who wish to establish their own Certificate Management Authority.

An entity (person or process) within the framework is allocated a public send key and a secret send key as the basis for enciphering data, and a public receive key and a secret receive key as the basis for deciphering data. This implementation differs from the more conventional implementations of the Diffie-Hellman protocol which allocates a single pair of keys. A data object is enciphered with a key generated from the originator's secret send key and the recipient's public receive key, and is deciphered with the same key but generated from the originator's public send key and recipient's secret receive key. For the scheme to operate successfully all keys used in the process must be based upon the same parameters (modulus and base value). For efficiency the generated key is not used to encipher the data object directly. Instead the data object is enciphered with a data key which is placed inside a 'token'. It is the token which is enciphered with the Diffie-Hellman derived key or Token Key (TK). The data object is only enciphered once, whereas the data key may be enciphered a number of times depending on the number of recipients.

The public confidentiality keys are held within confidentiality certificates. The certificates are encoded structures (Section 4.2) based upon version three of the X.509 certificate and selected extensions ([509], [509a] and [509b]). The public send and receive keys are held in Send Certificates and Receive Certificates respectively. The seed keys are also held within encoded structures, known as secret key tokens (Figure 3). The keys within the tokens may be enciphered with a user code which is distributed to the user separately from the token.

Send and receive keys are deterministically generated from top level interoperability keys (IKs). The Certificate Management Authority first generates a seed key from a function of the user's distinguished name and a top level interoperability key. The secret send and receive keys are generated from a function of this seed key and a datestamp. Public keys can then be generated from the secret keys and the domain parameters. The public receive key is stored with the datestamp in a Receive Certificate, the public send key is stored with the datestamp and the domain's parameters in a Send Certificate, and the seed keys distributed to the user within a Secret Key Token, through secure channels to the user. Receive Certificates are always appended to the enciphered token, to allow the recipient to identify the appropriate seed key required to regenerate the secret receive key. The public confidentiality keys and seed keys are linked by a seed key identifier.

Data objects are enciphered within a domain with receive keys derived from the domain's internal top level interoperability key. Data objects are enciphered between domains with receive keys derived from an interoperability key which has been bilaterally established between the Certificate Management Authorities of the communicating domains. It should be noted that send keys are always derived from the domain's internal interoperability key.

Once an interoperability key has been established between two domains, an authority can deterministically generate the public receive keys for members of the other's domain using the distinguished name of that member. The generation (unilateral and bilateral) of these keys and the mechanism by which authorities communicate is beyond the scope of this document. However a detailed description of the generation process is described in detail in [CMA].

Intra-Domain Confidentiality

If User A (IDA) needs to exchange enciphered data objects with User B (IDB) in the same domain (Domain X), they are each allocated the following by Certificate Management Authority X. Item (a) is distributed to each user through a secure channel, item (b) may be distributed to users or posted in the domain's directory, item (c) is only posted in the directory. The initial distribution of secret key tokens is outside the scope of this paper, however subsequent distributions may use the electronic mail system and the confidentiality service provided by the security protocol.

1. A secret key token containing the user's seed key K_XX(ID) from which secret send and receive keys for Domain X can be generated. The seed key is generated from the following function, where IK_XX is the top level interoperability key for Domain X, and f1 is some operation such as a hash function.
   K_XX(ID) = f1(IK_XX, ID)
   
2. A send certificate containing the public send key Spub(ID), datestamp (T_S), and the domain's base (g_X) and modulus (N_X) - written Cert(ID, Spub(ID), T_S, g_X, N_X). The secret and public send keys are related by the following function, where f2 need not equal f1.
   Spub(ID) = g_X^{f2(K_XX(ID), T_S)}mod N_X.
   
3. A receive certificate containing the public receive key Rpub(ID) and datestamp (T_R) - written Cert(ID, Rpub(ID), T_R). The secret and public receive keys are related by the following function, where f2 need not equal f1.

In order for User A to send an enciphered data object to User B, User A enciphers the data object with a data key. User A then generates a token key (TK) for the intended recipient, and uses this to encipher the data key. The token key is derived from User A's seed key K_XX(A), the public receive key from Cert(IDB, Rpub(B), T_R), and the modulus and datestamp from Cert(IDA, Spub(IDA), T_S, g_X, N_X) using the following function.

The certificates containing the keys and parameters used to generate the token key, Cert(IDA, Spub(A), T_S, g_X, N_X) and Cert(IDB, Rpub(B), T_R), are appended to the enciphered data object and token(s) to simplify the recipient's processing.

On receipt of the enciphered data object User B extracts their receive certificate. The seed key identifier contained within the certificate indicates which seed key K_XX(B) is required to regenerate the token key. The token key is used to decipher the data key which was used to encipher the data object. The token key is derived from the seed key, the public send key and modulus from Cert(IDA, Spub(A), T_S, g_X, N_X), and the datestamp from Cert(IDB, Rpub(B), T_R), using the following function.

Inter-Domain Confidentiality

If User A needs to exchange enciphered data objects with User C (IDC) in a different domain (Domain Y), the receive certificate of User C will not be available - unless User C has already received enciphered data objects from a user within the first domain. In this case User A passes User C's distinguished name to Certificate Management Authority X which deterministically generates a public receive key for User C, by the following processing.

1. An interoperability key (IK_XY) is established (if this has not already been done) between Certificate Management Authority X and Certificate Management Authority Y.
2. User C's distinguished name and the top level interoperability key are then used to generate a seed key for User C. The seed key is generated from the following function.
   K_XY(C) = f1(IK_XY, IDC)
3. A public receive key for User C can now be derived from the seed key, a datestamp (T_R), and Domain X's modulus and base value, using the following function.
   Rpub(C) = g_X^{f2(K_XY(C), T_R)}mod N_X
4. The public receive key and datestamp are incorporated into a receive certificate - written Cert(IDC, Rpub(C), T_R), and passed directly to User A or stored within the local directory for User A and other users to access (or both).

User A now enciphers the data object with a data key, which is then itself enciphered with a token key for each of the intended recipient. The token key is derived from User A's seed key K_XX, the public receive key from Cert(IDC, Rpub(C), T_R), and the modulus and datestamp from Cert(IDA, Spub(A), T_S, g_X, N_X), using the following function.

The certificates containing the keys used to generate the token key, Cert(IDA, Spub(A), T_S, g_X, N_X) and Cert(IDC, Rpub(C), T_R), are appended to the enciphered data object and token(s) to simplify the recipient's processing.

On receipt of the enciphered data object User C extracts their receive certificate. The seed key identifier contained within the certificate indicates which seed key K_XY(C) is required to regenerate the token key. In this case User C is unlikely to hold the associated seed key, unless User C has previously received enciphered data objects from a user within the Domain X. Therefore User C passes Cert(IDC, Rpub(C), T_R) and Cert(IDA, Spub(A), T_S, g_X, N_X) to Certificate Management Authority Y. The authority deterministically generates a new seed key for User C, by the following processing:

1. Certificate Management Authority Y identifies the appropriate interoperability key (K_XY) from the distinguished name (Certificate Management Authority X) of the issuer held within the certificate.
2. User C's distinguished name and the top level interoperability key are then used to generate the new seed key using the following function.
   K_XY(C) = f1(IK_XY, IDC)
3. The seed key is then passed through a secure channel to User C.

User C regenerates the token key and uses this to decipher the data key, which in turn is used to decipher the data object. The token key is derived from the seed key, the public send key and modulus from Cert(IDA, Spub(A), T_S, g_X, N_X), and the datestamp from Cert(IDC, Rpub(C), T_R), using the following function.

There is a requirement to periodically update the various keys used within the system. This will be carried out at different intervals depending upon the type of key in question. The interoperability keys and seed keys will have a similar period, whereas the secret keys and associated public receive key will be considerably shorter. The short lifespan of the keys used does not impose a burden on key distribution because the public certificates do not need to be distributed through secure channels. New secret send keys can be computed by their owners using the datestamp contained within the current Send Certificate, new secret receive keys can be computed by their owners using the datestamp contained within the Receive Certificate appended to the enciphered data object and tokens. Both certificates can be posted in a directory or similar and updated on a regular basis by the local certificate management authority.

When an interoperability key is updated a user will no longer have an appropriate seed key. In this case the user (or user's workstation) must pass the receive certificate to their local Certificate Management Authority. The authority can then generate and distribute a new seed key, via a secure channel to the user. This is effectively the same process which is carried out when a user receives an enciphered data object from an unknown domain.

See Section 2.2.6.

The security protocol is based upon the US Message Security Protocol [MSP]. The protocol defined here has a number of differences with that defined in [MSP], however they are still fundamentally identical. The Message Security Protocol, as the name suggests was developed specifically for securing electronic mail systems. This paper expands the scope of the protocol in order that it can be applied to other applications such as file encryptors. However, it should be noted that the services which are supported will depend on the environment in which the protocol is being implemented. For example, the proof of receipt service may not be relevant to a file encryption application, unless the resulting encapsulated object is used as an attachment to an electronic mail message.

The security protocol is made up of a secure data packet and a secure data receipt. The secure data packet provides a secure means of transferring information from one location to another, where the information may be any form of data object processed by an IT system, eg. mail message (P772, P22, proprietary, etc.), data files (wordprocessor data, spreadsheet data, database data, etc.), etc. It supports a number of security services on a writer-to-reader basis, however this does not prevent intermediate devices, such as guards and gateways operating on the protocol. The following security services are supported by the protocol

1. Content Integrity provides assurance that any modification to a data object can be detected.
2. Content Confidentiality prevents a data object being disclosed to an unauthorised entity.
3. Proof of origin enables an entity to authenticate the origin of a data object.
4. Non-repudiation of origin enables an entity to prove the origin of a data object to a third party .
5. Proof of receipt enables an entity to verify that a data object has been delivered to its intended recipient.
6. Non-repudiation of receipt enables an entity to prove that a data object had been received by its intended recipient to a third party.
7. Security Labelling enables a security label to be associated with a data object.
8. Protected Security Labelling enables a security label to be associated with a data object in such a way that ensures it can only be accessed by authorised entities.

The structure of the protocol has been defined using Abstract Syntax Notation - One (ASN.1). ASN.1 was developed during the heady days of the seven layer Open Systems Interconnection (OSI) Reference Model, of which it forms part of layer 6 - the presentation layer. The aim of this layer was to determine how data should be represented whilst in transit between applications within different computing environments. The requirement for such a service grew from the wide variety of computer architectures evolving and the different ways in which they internally represent their information. For example, IBM 370 series computers used EBCDIC whilst most other used ASCII. Today the use of different word lengths and the ordering of bytes within words can cause equal confusion. As the security protocol is intended to be implemented on a wide variety of platforms, a workstation independent method of defining its structure is required, hence the use of ASN.1.

ASN.1 is very similar to a high level programming language without the executable statements, ie. it is merely a collection of type and value constructs. These constructs are used in conjunction with encoding rules which translate these into a form which can be communicated unambiguously between computing environments. There are a number of encoding rules which can be used with ASN.1, which include BER (Basic Encoding Rules) and DER (Distinguished Encoding Rules). Only Distinguished Encoding Rules will be used to implement the security protocol and the certificates. This section is only intended to provide a brief overview of ASN.1, further information can be found within [680] and associated references.

A Secure Data Packet may contain the following fields and structures, originatorSecurityData, signatureBlock, recipientSecurityData, contentDescription, dlControlInformation, extensions, sequenceSignatureAlgorithm, sequenceSignatureCertificate, and encapsulatedDataObject.

The originatorSecurityData is made up of the following fields :

1. confidentialityAlgorithm contains the object identifier of the algorithm, used to encipher the data object held in the encapsulatedDataObject field, together with any parameters.
2. integrityAlgorithm contains the object identifier of the algorithm used to generate the contents of the dataObjectHash field within the RecipientKeyToken.
3. tokenProtectionAlgorithm contains the object identifier of the algorithm used to encipher the RecipientKeyToken structure, together with any parameters.
4. sdProtectionAlgorithm contains the object identifier of the algorithm used to encipher the SecurityData structure, together with any parameters.
5. originatorCertificate contains the receive certificate, required by the recipient to regenerate the token key. It may also contain any authentication certificates required to validate the authenticity of that certificate.
6. encipheredSecurityData is the enciphered form of the SecurityData structure. This structure is made up of the following :
   1. label contains a SecurityLabel structure, containing a policy identifier, classification, privacy mark, and a set of categories.
   2. attrCerts contains an attribute certificate relating to the security clearances of the originator, together with any authentication certificates required to validate the authenticity of that certificate. The attribute certificate is defined within [501c].
7. originatorUkm is part of the US key management scheme, and will not be used within UK implementations.
8. DlKeyToken contains the RecipientKeyToken constructed by the originator, which has been deciphered at a distribution list, then re-enciphered using a distribution list key. The presence of the DlKeyToken indicates that the data object has been redistributed by a distribution list.

The signatureBlock within the Secure Data Packet is made up of the following fields and structures:

1. signatureAlgorithm contains the object identifier of algorithm(s) used to generate the digital signature in (b) below, together with any parameters.
2. SignatureValue may contain sigVal or encSigVal.
   1. sigVal contains a digital signature.
   2. encSigVal is made up of a structure and a field:
      • encSigAlgorithm contains the object identifier of the algorithm used to encrypt the signature, together with any parameters.
      • encSigValue contains the enciphered form of a digital signature.
3. ControlInformation contains the signatureInformation structure which consists of the following fields and structures:
   1. encapsulatedContentType contains an integer or object identifier relating to the data object within the encapsulatedDataObject field.
   2. signedContentIdentifier contains a value which can uniquely identify the secure data packet.
   3. ReceiptRequests is made up of allOrNone or recipientList. The allOrNone structure allows the originator to specify that no recipients return receipts, all recipients return receipts, or only first tier recipients return receipts. The recipientList structure contains the list of recipient from whom a receipt is expected. First tier recipients are those specified by the originator, and not those who receive a Secure Data Packet from a distribution list.
   4. receiptsTo identifies the entity(s) to whom a receipt should be returned.
4. signatureCertificate contains the certificate with the public key needed to verify the digital signature in (b) above. It may also contain any certificates required to validate that certificate.

The recipientSecurityData is made up of a set of PerRecipientToken - one for each of the intended recipients plus one for the originator (in case the data object needs to be deciphered by the originator at a later date). A PerRecipientToken is made up of tag and protectedRecipientKeyToken.

1. tag consists of a number of fields which allow each recipient to identify their token and process it accordingly. The tag is made up of the following fields :
   1. kmid is used by a recipient to identify their PerRecipientToken.
   2. edition is part of the US key management scheme, and will not be used within UK implementations.
      
   3. date is also used by the recipient to identify their PerRecipientToken
2. protectedRecipientKeyToken is the enciphered form of the RecipientKeyToken structure. The RecipientKeyToken is made up of the following fields :
   1. dataKey contains the data key used to encipher the data obejct held in the encapsulatedDataObject field. The data key may itself be wrapped by the same key which was used to encipher the RecipientKeyToken, this will depend on the environment into which an implementation is aimed.
   2. dataObjectHash contains a digest calculated over the original data object
   3. signatureBlockIndicator contains a boolean value which is set to true if a SignatureBlock is present, and contains false otherwise
   4. encapsulatedContentType contains an integer or object identifier relating to the data object within the encapsulatedDataObject field.
   5. sdHash which contains a digest calculated over the SecurityData field (if present) of the OriginatorSecurityData structure.

The contentDescription is a string describing the secure data packet or the data object it contains. This string is unprotected and can therefore be used by an entity to decide whether they wish to continue processing.

The dlExpansionHistory contains a record of any distribution lists through which the Secure Data Packet has passed. This field is updated each time a data object is distributed to members of such a list, and enables each list to detect a loop. If absent it allows a recipient to detect whether or not they are a first tier recipient. The dlExpansionHistory field is a sequence of DlData structures each consisting arguments listed below.

1. dlid contains the identity of the distribution list.
2. expansionTime contains the date and time at which the secure data packet was processed by a distribution list.
3. dLReceiptPolicy specifies a receipt policy which supersedes the originator's request for signed receipts. The policy can be one of three possibilities. A distridution list can specify that receipts should not be returned (none), that receipts should be returned to an alternate list of recipients (ORNameList) instead of to the originator (insteadOf), or it can specify that receipts should be returned to a list of recipients in addition to the originator (inAdditionTo), for which an ORNameList structure is defined.

As each distribution point processes a secure data packet it generates a DlData structure and appends it to the dlExpansionHistory.

The extensions structure contains the following fields and structures, others may be added with the agreement of CESG. It should be noted that the presence of an extension may impact interoperability, in that an entity may not understand it. Therefore the following guidelines should be followed. All non-critical extensions not recognised by the recipient should be ignored. Any critical extensions not recognised by the recipient will result in the termination of processing.

1. clearSecurityLabel is a structure as defined in the originatorSecurityData section above, however this security label will not be protected by the confidentiality service. This extension is not critical.
2. receiveCertificate contains a set of receive certificate, from which a recipient can choose the appropriate one for deciphering the ProtectedRecipientKeyToken. This extension is critical.
3. contentType contains an integer or object identifier relating to the type of data being protected. This extension is not critical.
4. SimpleMoac is a structure containing the following fields and structures. This extension is not critical.
   1. moacAlgorithm contains the object identifier of algorithm(s) used to generate the digital signature in (ii).
   2. moac contains a digital signature.
   3. moacCertificate contains the authentication certificate needed to verify the above digital signature. It may also contain any certificates required to validate that certificate.

The sequenceSignatureAlgorithm contains the object identifier of the algorithm used in the SIGNED{SecurityProtocol} operation.

The sequenceSignatureCertificate argument contains the authentication certificate needed to verify the signature generated by the SIGNED{SecurityProtocol} operation. It may also contain any certificates required to validate that certificate.

The encapsulatedDataObject will be the data object if confidentiality is not requested, or the enciphered form of the data object if confidentiality is requested.

The Secure Data Receipt may be made up of signatureBlock, contentDescription and extension, and is generated in response to an Secure Data Packet.

The signatureBlock within the receipt is made up of the following fields and structure :

1. signatureAlgorithm contains the object identifier of the hash and signature algorithms used to generate the digital signature in (b).
2. SignatureValue contains the sigVal containing a digital signature.
3. ControlInformation contains the receiptInformation structure consisting of the following fields and structures :
   1. encapsulatedContentType contains an integer or object identifier relating to the data object contained in the original secure data packet
   2. signedContentIdentifier contains the value of the signedContentIdentifier received within the original secure data packet.
4. signatureCertificate contains the authentication certificate needed to verify the digital signature in (b). It may also contain any certificates required to validate that certificate.

The extension may contain a clearSecurityLabel structure, if required.

[RES] Securing Electronic Mail Within HMG Part II, An Implementor's Guide for Restricted Systems.

[CMA] Securing Electronic Mail Within HMG Part III, Concept of Operation for a Certificate Management Authority

[MSP] Message Security Protocol, Version 4.1.

[RHC] A Proposed Architecture for Trusted Third Party Services, Information Security Group, Royal Holloway, University of London.

[500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1: 1993, Information Technology - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Services.

[501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models.

[501a] Draft Amendment 1 to ITU Rec. X.501 (1993) | ISO/IEC 9594-2: 1993

[501b] Draft Amendment 4 to ITU Rec. X.501 (1993) | ISO/IEC 9594-2: 1993

[501c] Proposed Draft Amendment to ITU Rec. X.501 (1993) | ISO/IEC 9594-2: 1995

[509] ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8: 1993, Information Technology - Open Systems Interconnection - The Directory : Authentication Framework.

[509a] Technical Corrigendum 2 to X.509 ('90 & '93) | ISO/IEC 9594-8 ('90 & '93)

[509b] Draft Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1993

[520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6: 1993, Information Technology - Open Systems Interconnection - The Directory: Selected Attribute Types.

[520a] Draft Amendment 2 to ITU Rec. X.520 (1993) | ISO/IEC 9594-6: 1995.

[521] ITU-T Recommendation X.521 (1993) | ISO/IEC 9594-7: 1993, Information Technology - Open Systems Interconnection - Selected Object Classes.

[521a] Draft Amendment 1 to ITU Rec. X.521 (1993) | ISO/IEC 9594-7: 1995.

[680] ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1 : 1994, Information Technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):Specification of Basic Notation.

[681] ITU-T Recommendation X.681 (1994) | ISO/IEC 8824-2 : 1994, Information Technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):Information Object Specification.

[682] ITU-T Recommendation X.682 (1994) | ISO/IEC 8824-3 : 1994, Information Technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):Constraint Specification.

[683] ITU-T Recommendation X.683 (1994) | ISO/IEC 8824-4 : 1994, Information Technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1):Parameterization of ASN.1 Specifications.

[690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1 : 1994, Information Technology - Open Systems Interconnection - Specification of ASN.1 encoding rules : Basic, Canonical and Distinguished Encoding Rules.