EUROCONTROL

EUROCONTROL Specification for

the Air Traffic Services Message
Handling System (AMHS)

Edition: 2.1
Edition date: 06/09/2018
Reference nr: EUROCONTROL-SPEC-0136
 EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL Specification for

the Air Traffic Services Message
Handling System (AMHS)

DOCUMENT IDENTIFIER : EUROCONTROL-SPEC-0136

Edition Number : 2.1

Edition Date : 06/09/2018
Status : Released Issue
Intended for : General Public
Category : EUROCONTROL Specification
 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

DOCUMENT CHARACTERISTICS

TITLE

EUROCONTROL Specification for the Air Traffic Services

Message Handling System (AMHS)

Publications Reference: SPEC-136

ISBN Number: 978-2-87497-037-5

Document Identifier Edition Number: 2.1

EUROCONTROL-SPEC-0136 Edition Date: 06/09/2018

Abstract
The EUROCONTROL Specification for the ATS Message Handling System (AMHS) has been
developed to provide a means of compliance to the essential requirements of the interoperability
Regulation of the Single European Sky. It ensures the interoperability of AMHS systems and
constituents within the European Air Traffic Management Network (EATMN).
Implementations that comply with the mandatory provisions of this specification will be compliant to
the essential requirements of the interoperability Regulation.
Keywords
AMHS Specification Interoperability
SES

Contact Person(s) e-mail Unit

Boleslaw BARANOWSKI bolek.baranowski NMD/NS/CFC
@eurocontrol.int

STATUS, AUDIENCE AND ACCESSIBILITY

Status Intended for Accessible via
Working Draft  General Public  Intranet 
Draft  EUROCONTROL  Extranet 
Proposed Issue  Restricted  Internet (www.eurocontrol.int) 
Released Issue 

Page ii Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.

EDITION EDITION PAGES

REASON FOR CHANGE
NUMBER DATE AFFECTED

0.1 16/01/08 Initial outline All

0.2 25/01/08 Detail added All

0.3 26/02/08 Further evolution. Input to Drafting Group All

Further evolution. Comments from drafting
0.4 01/04/08 All
group 29/02/08.
0.5 13/06/08 Draft for Review Group All
Updated after informal stakeholder review.
0.6 24/10/08 All
Annex A split into 2 – Basic & Extended
Updated after informal stakeholder review.
1.0 08/12/08 All
Input to formal consultation.
Updated after ENPRM-09/001 formal
1.1 27/07/09 All
consultation.
2.0 18/09/09 Released Issue 1, 3, 4, 48
Update references, align with ICAO &
2.1 06/09/18 ATM Master Plan. See Appendix 4 for All
details.

Publications
EUROCONTROL Headquarters
96 Rue de la Fusée
B-1130 BRUSSELS

Tel: +32 (0)2 729 4715

Fax: +32 (0)2 729 5149
E-mail: [email protected]

Page iv Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CONTENTS

1. INTRODUCTION ................................................................................................... 3
1.1 Document Structure ..................................................................................................................3
1.2 Purpose .....................................................................................................................................4
1.3 Background Context..................................................................................................................5
1.4 Scope ........................................................................................................................................7
1.5 Document Status .......................................................................................................................8
1.6 Applicability ...............................................................................................................................9
1.7 Conventions ............................................................................................................................10
1.8 Abbreviations and Definitions .................................................................................................11
1.9 Interoperability Target .............................................................................................................17

2. AMHS INTEROPERABILITY – BASIC ATSMHS ............................................... 23

2.1 General....................................................................................................................................23
2.2 Standards Baseline .................................................................................................................23
2.3 Network Support .....................................................................................................................23
2.4 Safety and Performance Requirements ..................................................................................24
2.5 Message Transfer Service Interoperability .............................................................................25
2.6 End to End Interoperability of Direct AMHS Users .................................................................25
2.7 Interoperability between AFTN and AMHS .............................................................................26
2.8 Ground Recording of Messages .............................................................................................26
2.9 Naming and Addressing ..........................................................................................................26
2.10 Operational Procedures ..........................................................................................................27
2.11 Interoperability with Military Message Handling Systems .......................................................27
2.12 Interoperability with Systems External to EATMN ..................................................................28

3. EXTENDED ATSMHS......................................................................................... 29
3.1 General....................................................................................................................................29
3.2 Standards Baseline .................................................................................................................29
3.3 Extended ATSMHS Functionality............................................................................................29
3.4 End to End Interoperability of Direct AMHS Users .................................................................31
3.5 Naming and Addressing ..........................................................................................................31

4. USE OF DIRECTORY ......................................................................................... 33

4.1 General....................................................................................................................................33
4.2 Directory Architecture..............................................................................................................33
4.3 Directory System Protocols .....................................................................................................34
4.4 Directory Access .....................................................................................................................35
4.5 Directory Schema....................................................................................................................35
4.6 Versioning and Data Life Cycle ...............................................................................................35
4.7 Use of Directory to determine AMHS Recipient Capabilities ..................................................35

5. AMHS SECURITY .............................................................................................. 37

5.1 General....................................................................................................................................37
5.2 AMHS Security Framework .....................................................................................................38
5.3 Public Key Infrastructure .........................................................................................................39

Edition : 2.1 Released Issue Page v

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

6. ADDITIONAL AMHS REQUIREMENTS ............................................................. 40

6.1 Testing and Verification...........................................................................................................40

7. TRANSITION / COEXISTENCE ISSUES............................................................ 41

7.1 AFTN to AMHS Transition.......................................................................................................41
7.2 Basic ATSMHS to Extended ATSMHS Transition ..................................................................41
7.3 Deployment of Directory..........................................................................................................42

8. TRACEABILITY TO REGULATORY PROVISIONS ........................................... 43

8.1 Implementation Conformance Statements..............................................................................43
8.2 Traceability to SES Essential Requirements ..........................................................................43

9. DOCUMENT UPDATE PROCEDURES.............................................................. 44

10. LIST OF REFERENCES ..................................................................................... 45

10.1 Description of References .......................................................................................................45
10.2 Primary References ................................................................................................................45
10.3 Associated References ...........................................................................................................47

ANNEX A - BASIC SERVICE ................................................................................. A-1

ANNEX B - EXTENDED SERVICE ......................................................................... B-1

ANNEX C - DIRECTORY REQUIREMENTS .......................................................... C-1

ANNEX D – AMHS SECURITY ............................................................................... D-1

APPENDIX 1 – Traceability Matrix between SES Essential Requirements and

EUROCONTROL Specification
APPENDIX 2 – Editions of Referenced Standards
APPENDIX 3 - Specification Update Procedures
APPENDIX 4 - Amendments to Specification

List of Tables
Table 1: Definition of ATSMHS subsets ................................................................................30

List of Figures
Figure 1: Relationship to other documents ............................................................................ 8
Figure 2: Requirement identifier format ................................................................................10
Figure 3: AMHS Interoperability Target ................................................................................18
Figure 4: AMHS Interoperability Target (transitional phase) .................................................20
Figure 5: COM Centre perspective .......................................................................................21
Figure 6: MTA Communication with an External Region using ATN/OSI ..............................28
Figure 7: SEC FG in Base Standards vs. Extended ATSMHS ..............................................31
Figure 8: General Directory Architecture ..............................................................................34
Figure 9: Global AMHS Architecture including CA ................................................................38

Page vi Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

EXECUTIVE SUMMARY

This document is the EUROCONTROL Specification for the Air Traffic Services Message
Handling System (AMHS) in Europe. The objective is to define precise means of compliance
to the essential requirements of the interoperability Regulation to ensure interoperability of
AMHS systems and constituents in the framework of the Single European Sky (SES). In
particular, Edition 2.0 of the EUROCONTROL Specification for AMHS has been recognised
as a Community specification (CS) for the interoperability Regulation of SES (OJEU 2009/C
323/06 and 2010/C 18/16).
The EUROCONTROL Standards development process has been applied to the development
of Edition 2.1 of this EUROCONTROL Specification. It will be proposed to the European
Commission as a new edition of the CS 1.
This EUROCONTROL Specification refines and augments the detailed technical
specifications for AMHS in ICAO Annex 10 and associated ICAO technical manuals, for
deployment in the European Air Traffic Management Network (EATMN). The goal is to
enable EATMN-wide support of a specific profile of the Extended level of service of the ATS
Message Handling Service (ATSMHS), as defined by ICAO. This includes:
a) support for binary information transfer,
b) operation over a network infrastructure based on the internet protocol (IP),
c) use of standard message heading extensions to convey Air Traffic Services (ATS)
header information,
d) use of directory functionality to enhance interoperability,
e) migration to the use of digitally signed secure messages at a future date if required.
An initial transition step supporting migration from the AFTN to the Basic ATSMHS level of
service is also foreseen.
The provisions of this EUROCONTROL Specification are applicable to AMHS implementers.
Specifically, the provisions apply to the parts of an ANSP’s organisation responsible for
providing, directly or by outsourcing, data messaging services to end users both within and
between States.
This EUROCONTROL Specification is organised as a number of chapters and annexes.
Compliance with this EUROCONTROL Specification is achieved once implementations
comply with all requirements of the normative Annexes. As a recognised CS within the SES
framework, full compliance to this EUROCONTROL Specification gives a formal presumption
of conformity with the essential requirements and regulatory provisions identified in Chapter
8 and Appendix 1.
The use of a CS to demonstrate conformity with the essential requirements and regulatory
provisions is voluntary. ANSPs may choose to use other specifications, or part of this
EUROCONTROL Specification. However, ANSPs would then be required to demonstrate

1
This new edition includes necessary updates and reflects the legislation in force at the time of its
publication. A future edition of this specification will address relevant changes in the legislative
frameworks, including those stemming from Regulation (EU) 2018/1139 establishing the European
Aviation Safety Agency (OJ L 212, 22.8.18), in particular Article 139 thereof.

Edition : 2.1 Released Issue Page 1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

compliance with the essential requirements and regulatory provisions in agreement with their
national supervisory authority.

Page 2 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

1. INTRODUCTION

1.1 Document Structure

1.1.1 This EUROCONTROL Specification is organised as a number of Chapters
and Annexes. The chapters in the main body of the document provide
contextual guidance and explanatory material and point to the annexes which
contain the normative requirements. The main body is structured as follows:
• The present Chapter includes introductory material describing the
purpose and scope of the EUROCONTROL Specification, its structure,
and a description of the document conventions, abbreviations,
definitions and the interoperability target.
• Chapter 2 describes the basic level of interoperability for the Air Traffic
Services Message Handling Service (ATSMHS) in Europe.
• Chapter 3 contains explanatory material concerning the Extended
ATSMHS functionality.
• Chapter 4 describes the introduction of Directory systems and
procedures.
• Chapter 5 describes the Security mechanisms and procedures to
support the Extended ATSMHS.
• Chapter 6 describes additional requirements relating to implementation
options, testing and validation.
• Chapter 7 describes some of the transition and coexistence issues.
• Chapter 8 addresses traceability between the means of compliance in
this EUROCONTROL Specification and Single European Sky (SES)
essential requirements.
• Chapter 9 describes the procedures for maintaining and updating this
EUROCONTROL Specification.
• Chapter 10 contains a list of documents which are referenced from the
main body and annexes by means of reference numbers contained in
square brackets.
1.1.2 Detailed interoperability and compliance requirements are specified in
Annexes, which form an integral part of this EUROCONTROL Specification:
• Annex A (normative) contains detailed requirements for the Air Traffic
Services (ATS) Message Handling functionality at the level of the Basic
ATSMHS. It identifies the systems that are deployed in order to provide
those services, the system level requirements, and the external
standards and documents applicable to each system. For each such
standard, the baseline version is identified in Chapter 10, and any
additional requirements are specified.
• Annex B (normative) contains detailed requirements for the ATS
Message Handling functionality at the Extended ATSMHS level of
service, requiring support of Functional Groups (FG) for the Basic

Edition : 2.1 Released Issue Page 3

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

ATSMHS (Basic FG), use of file transfer body parts for binary data
exchange (FTBP FG), use of interpersonal messaging heading
extensions (IHE FG) and use of Directory (DIR FG). Support of AMHS
Security (SEC FG) is foreseen in the future.
• Annex C (normative) contains detailed requirements for Directory
systems to support the DIR FG of the Extended ATSMHS.
• Annex D (informative) indicates high level provisions for security
mechanisms that would be needed to support the SEC FG of the
Extended ATSMHS (see Note 2).
Note 1. The actual requirements are therefore specified in normative Annexes,
with a separate Annex for each main area of functionality. This could facilitate
a step-wise implementation approach to full compliance with this
EUROCONTROL Specification (see 1.5.6 below).
Note 2. It is recognised that the provision of AMHS Security services is not as
advanced as other elements of the Extended ATSMHS, and still requires a
number of technical and procedural issues to be resolved in a suitable forum.
For that reason, the specifications in Annex D are considered as advisory
indications of the evolutionary direction.
1.1.3 Compliance requirements are provided where possible in the form of protocol
implementation conformance statement (PICS) tables giving a detailed
statement of functional and protocol compliancy. These tables are generally
contained in external standards referenced from this EUROCONTROL
Specification.
1.1.4 The document includes the following Appendices:
• Appendix 1 provides traceability between SES essential requirements
and the provisions of this EUROCONTROL Specification.
• Appendix 2 lists the editions of the base standards invoked in the
referenced AMHS provisions.
• Appendix 3 describes procedures for maintaining and updating this
EUROCONTROL Specification.
• Appendix 4 records the changes introduced in the current issue.

1.2 Purpose
1.2.1 This EUROCONTROL Specification on the Air Traffic Services Message
Handling System (AMHS) is developed to complement the Single European
Sky (SES) interoperability Regulation [1] in the area of ground-ground ATS
communications.
1.2.2 This EUROCONTROL Specification is organised as a number of chapters and
normative annexes. Compliance with this EUROCONTROL Specification is
achieved once implementations comply with all requirements of the normative
Annexes. After being referenced in the Official Journal of the European Union
as a Community specification (CS), full compliance to this edition of the
EUROCONTROL Specification gives a formal presumption of conformity with

Page 4 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

the essential requirements and regulatory provisions identified in Chapter 8

and Appendix 1.
1.2.3 The use of a CS to demonstrate conformity with the essential requirements
and regulatory provisions is voluntary. ANSPs may choose to use other
specifications, or part of this EUROCONTROL Specification. However, ANSPs
would then be required to demonstrate compliance with the essential
requirements and regulatory provisions in agreement with their national
supervisory authority.
1.2.4 To ensure the interoperability and the seamless operations of the ATSMHS in
the European Air Traffic Management Network (EATMN) in terms of the SES
interoperability Regulation [1], this EUROCONTROL Specification is intended
to augment the relevant technical standards with further standardisation
materials directly applicable to the EATMN.
1.2.5 This EUROCONTROL Specification on AMHS supports the co-ordinated
introduction of new concepts of operations in the EATMN based on high
capacity, secure, reliable ground-ground communications.

1.3 Background Context

1.3.1 The exchange of ATS messages, as part of the Aeronautical Fixed Service
(AFS) defined in ICAO Annex 10 Volume II [3] is an essential function to the
safety of air navigation and to the regular, efficient and economical operation
of ATS provision.
1.3.2 The Aeronautical Fixed Telecommunications Network (AFTN), complemented
in Europe by the Common ICAO Data Interchange Network (CIDIN), has
provided an effective store-and-forward messaging service for the conveyance
of text messages, using character-oriented procedures, for many years.
However AFTN / CIDIN technology is now becoming obsolescent, and is not
sufficiently flexible to support messaging functions found in modern
messaging systems (such as transfer of binary information).
1.3.3 It is intended that existing AFTN and CIDIN users and systems will transition
to the architecture of the Aeronautical Telecommunication Network (ATN), and
this is enabled in part by the ATSMHS application, which has been defined by
ICAO to replace the AFTN telegraphic style of working with a modern store-
and-forward Message Handling System based on international Standards.
1.3.4 Standards and Recommended Practices (SARPs) for the ATSMHS application
are specified in ICAO Annex 10 to the Convention on International Civil
Aviation (Annex 10 Volume II [3], Chapter 4.6 and Annex 10 Volume III, Part I
[26], Chapter 3.5). These SARPs refer to detailed specifications in the relevant
technical Manual (ICAO Doc 9880 Part II [5]).
1.3.5 The technical provisions in ICAO Doc 9880 Part II [5] define two fundamental
levels of service within the ATSMHS; the Basic ATSMHS and the Extended
ATSMHS. Additionally, ICAO Doc 9880 (Part II, section 3.4) outlines various
subsets of the Extended ATSMHS, to which conformance can be claimed.
1.3.6 The Basic ATSMHS performs an operational role similar to the AFTN with a
few enhancements, while the Extended ATSMHS provides more advanced
features. The Extended level of service includes the Basic level of service

Edition : 2.1 Released Issue Page 5

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

capability; in this way it is ensured that users with Extended Service

capabilities can interoperate, at a basic level, with users having Basic Service
capabilities and vice-versa.
1.3.7 The ATSMHS is provided by a set of ATN End Systems, which collectively
comprise the ATS Message Handling System (AMHS), and which co-operate
to provide users (human or automated) with a data communication service.
The AMHS network is composed of interconnected ATS Message Servers that
perform message switching at the application layer (Layer 7 in the basic
reference model for open systems interconnection (OSI)). Direct users
connect to ATS Message Servers by means of ATS Message User Agents. An
ATS Message User Agent supporting the Extended level of service will use
the Basic level of service to allow communication with users who only support
the Basic ATSMHS. To support the transition from AFTN, AFTN/AMHS
Gateways provide interfaces between the AMHS and the AFTN. The AMHS
network makes use of an underlying network infrastructure that allows data
interchange to be performed.
1.3.8 Implementation of the Extended ATSMHS implies the existence of various
support functions, which are not necessarily exclusively dedicated to
messaging. These include Directory support and (if secure messaging is
implemented) public key management functions.
1.3.9 Communication systems and procedures for ground-to-ground
communications in the EATMN are required 2 to support the implementation of
advanced, agreed and validated concepts of operation for all phases of flight.
1.3.10 The establishment of common interoperability and performance levels once
AMHS is deployed across the EATMN will contribute to the achievement of
seamless operations by specifying:
• Coherent service levels and operational concepts throughout the
applicable area;
• A communications system supporting a seamless relationship between
ground-based systems, so that a service is not disrupted by breaks in
coverage or wide variations in quality of service.
1.3.11 The ATSMHS offers a communication service to ground systems and their
constituents supporting new, agreed and validated concepts of operation
which must be designed, built, maintained and operated, using appropriate
and validated procedures, in such as way as to be interoperable in terms of
timely sharing of correct and consistent information.
1.3.12 The requirement to implement ICAO specifications for aeronautical message
handling is reflected in the European ATM Master Plan [46], (implementation
objective COM 10 - Migrate from AFTN to AMHS).
1.3.13 It is therefore likely that ATSMHS functionality will be a fundamental
requirement in any procurement of a system that supports aeronautical
message handling. This is particularly true for systems that will communicate
across national borders.

2
SES interoperability Regulation [1], Annex II, Part B, paragraph 4.2.

Page 6 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

1.4 Scope
1.4.1 This EUROCONTROL Specification defines detailed requirements,
explanatory materials and conformity assessment materials providing means
of compliance (MOC) associated with the SES interoperability Regulation [1].
1.4.2 The scope of this document covers the Basic and Extended levels of the
ATSMHS. Specifically, support for functional groups Basic, FTBP, IHE and
DIR is specified. Functional group SEC is outlined as an indication of future
requirements.
1.4.3 This EUROCONTROL Specification is intended to provide a definitive
statement on the compliancy requirements for systems and procedures. As
such, for each external standard, it identifies the baseline version of that
standard and the changes to those standards that are required. Each
identified change that is incorporated into this specification includes the
original reference.
1.4.4 The specification applies to the following EATMN systems:
• Ground communication systems, including end systems concerned
with message submission, transfer, delivery and (in the case of AFTN
interworking) conversion;
• Ground data logging and recording systems, which, in general, will be
an integral part of the communication subsystems.
1.4.5 Compliance with this EUROCONTROL Specification would be mandated in a
call for tender for an AMHS End System. However, this EUROCONTROL
Specification is not intended to be a complete system specification sufficient
for procurement purposes.
1.4.6 The specification includes requirements applicable to operational procedures
in the following areas:
• Procedures for the operation and introduction of the ATSMHS,
including coexistence with, and transition from, AFTN, and migration
from Basic to Extended ATSMHS;
• Procedures for the management of names and addresses and other
information required for the operation of the AMHS, such as
information on address conversion, user capabilities, etc.
1.4.7 Topics addressed by this EUROCONTROL Specification include:
• The Basic ATSMHS and transition to Extended ATSMHS, including
Safety and Security standards, and Directory services;
• The interoperability aspects between implementations of the Basic
ATSMHS, with its functional components, and implementations
conforming to the provisions of this EUROCONTROL Specification;
• The interoperability aspects of AFTN/AMHS gateways within the
transition phase from AFTN to AMHS;
• The tests and verifications of compliance with the provisions of this
EUROCONTROL Specification.

Edition : 2.1 Released Issue Page 7

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

1.4.8 This EUROCONTROL Specification aims to be consistent with relevant ICAO

and European standards, and includes mechanisms to ensure an efficient
process of update to enable ongoing consistency.

EUROCONTROL SES
SES AMHS Environment
Regulations Specification

EUR Doc 020 EUR Doc 021 ICAO EUR

EUR AMHS ATS Messaging Region
Manual Management Manual

Annex 10
Doc 9880 Part Doc 9880 Doc 9705
SARPs ICAO Global
II Part IV (DIR) Sub-Volume
ATSMHS VIII (SEC)

International
ISO/IEC & ISO/IEC Standards
ITU-T MHS
ISPs
Standards

Figure 1: Relationship to other documents

1.4.9 The relationship of this EUROCONTROL Specification to other documents is
summarised in Figure 1. This shows that the EUROCONTROL Specification
refines the SES Essential Requirements in the AMHS area and refers to
technical manuals produced by ICAO. The high level ICAO SARPs in Annex
10 [3] are complemented by the detailed technical specifications in ICAO Doc
9880 , which in turn refer to international standards and profiles for message
handling systems. The ICAO EUR manuals refine and adapt the AMHS
specifications for the specific Regional environment.

1.5 Document Status

1.5.1 In accordance with Article 4.1b of the interoperability Regulation [1], the
second edition of this EUROCONTROL Specification was recognised as a CS
within the SES regulatory framework 3. The current edition is proposed for
recognition as a new edition of the CS. As such, it has the status of a
voluntary standard, offering a recognised means of compliance with SES
regulatory materials and relevant ICAO provisions for ground-ground ATS
messaging systems and constituents.

3
Edition 2.0 of this Specification referenced in OJ 323/24, 31.12.2009 (amended by corrigendum C
18/47, 23.1.2010

Page 8 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

1.5.2 It is intended to be used notably in order to refine and complement the

essential requirements laid down in the interoperability Regulation to provide
measures aimed at ensuring the interoperability of the EATMN.
1.5.3 This EUROCONTROL Specification was developed in accordance with
stakeholder consultation mechanisms under the EUROCONTROL Regulatory
and Advisory Framework (ERAF) 4 .
1.5.4 A EUROCONTROL Specification, after being referenced in the Official Journal
of the European Union, gives a formal presumption of conformity with
identified essential requirements and regulatory provisions. When an EATMN
stakeholder system specification complies with the requirements of such a
EUROCONTROL Specification, there is no need to justify separately that the
specification defines means of compliance with identified essential
requirements and regulatory provisions.
1.5.5 It is expected that ANSPs will plan to implement the complete set of
requirements specified in this document and its normative Annexes, and
obtain the relevant EC declaration(s).
1.5.6 However, it is recognised that during the transition period from AFTN to full
ATSMHS capability, intermediate deployment steps will be necessary, as
indicated in section 7 below. This EUROCONTROL Specification is structured
to facilitate such step-wise implementation:
• During the transition period, interoperability at the Basic ATSMHS level
of service can be achieved as specified in Annex A. ANSPs may
choose initially to deploy the Basic level of service as an interim step
towards full compliance with this EUROCONTROL Specification.
• As support for the features of the Extended ATSMHS becomes
available, including support for binary data, compliance can be
assessed against the requirements in Annex B.
• Deployment and use of the ATN Directory in support of the Extended
ATSMHS can be assessed against the requirements in Annex C.
• It is recognised that the provision of AMHS Security services is not as
advanced as other elements of the Extended ATSMHS. For that
reason, the specifications in Annex D are considered as advisory.

1.6 Applicability
1.6.1 The provisions of this EUROCONTROL Specification are applicable to AMHS
implementations. Specifically, the provisions apply to the parts of an ANSP’s
organisation responsible for providing, directly or by outsourcing, data
messaging services to end users both within and between States.
1.6.2 The provisions of this EUROCONTROL Specification are indirectly applicable
to manufacturers of AMHS End Systems, who need to produce an EC
declaration of conformity (DoC).

4
EUROCONTROL Regulatory and Advisory Framework:
https://www.eurocontrol.int/articles/stakeholder-consultation

Edition : 2.1 Released Issue Page 9

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

1.6.3 Although developed as a CS in the EU SES framework, this EUROCONTROL

Specification is equally applicable to non-EU States in the ICAO EUR Region.
It may also voluntarily be applied worldwide.
1.6.4 In terms of the EATMN systems defined in the SES Interoperability Regulation
[1], Annex I, this EUROCONTROL Specification specifies interoperability
requirements for a "communications system and procedures for ground-to-
ground communications," which supports the communications requirements of
other EATMN systems.
1.6.5 The basic feature of a CS such as this is that it is a voluntary standard, which
may be adopted by Stakeholders.
1.6.6 In this function such voluntary standards contribute positively to the quest for
interoperability as part of the SES and other related Regulations and
Directives.

1.7 Conventions
1.7.1 Only the minimum subset of requirements necessary for the correct and
harmonised implementation of the EUROCONTROL Specification is specified.
Mandatory items within the EUROCONTROL Specification are clearly
separated from non-mandatory items.
1.7.2 Every requirement and recommendation in this specification is preceded by a
structured identifier which can be used to reference uniquely the requirement /
recommendation from associated documents and traceability tools. Such
identifiers have the form:
AMHS-[Fn]-[Ann]
where:
[Fn]: is a sequence of characters to identify the operational procedure or
category to which the requirement applies, e.g. DIR for general
requirements related to Directory functions.
[Ann]: is the Annex identifier followed by a number, unique within a given [Fn];
1.7.3 An example requirement identifier is shown in Figure 2. Note that the structure
of requirement identifiers allows differentiation between the Basic ATSMHS
and Extended ATSMHS and also identifies the major system components,
which can be considered as candidate EATMN constituents.
Example requirement tag: [AMHS-AMU-Axx]

Component level: Basic vs. Extended:

“AMU” = ATS Message “A” = Annex A (Basic service)
User Agent “B” = Annex B (Extended service)

Figure 2: Requirement identifier format

1.7.4 Conventions for denoting requirements in the normative Annexes A, B and C
are as follows:

Page 10 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

• ‘Shall’ - indicates a statement of specification, the compliance with

which is mandatory to achieve the implementation of the
EUROCONTROL Specification. It indicates a requirement which must
be satisfied by all systems claiming conformity to the specification.
Such requirements are intended to be testable and their
implementation auditable.
• ‘Should’ - indicates a recommendation or best practice, whose use is
encouraged, but which may or may not be satisfied by all systems
claiming conformity to the specification.
• ‘May’ – indicates an optional feature.
• ‘Will’ – is meant in its normal English usage to indicate a forward-
looking statement or statement of intent.
1.7.5 The following legend is used in profile requirements lists (PRL) in the
Annexes:
m Mandatory – the item is required
c.x Conditional – the item may or may not be required, depending upon
conditions stated in the table footer
o Optional – the item may be implemented / supported
x Excluded – the item must not be implemented / supported
i Out of Scope

1.8 Abbreviations and Definitions

1.8.1 Abbreviations
The following abbreviations are used throughout this Main Body and
associated Annexes:
84IW 1984 Interworking (MHS functional group)
ACP ICAO Aeronautical Communications Panel
ACSE Association Control Service Element
ADEXP EUROCONTROL Standard for ATS Data Exchange Presentation
AF-Address AFTN-form address
AFS Aeronautical Fixed Service
AFSG Aeronautical Fixed Service Group (ICAO EUR Regional group)
AFTN Aeronautical Fixed Telecommunication Network
AIRAC Aeronautical Information Regulation And Control
AMC ATS Messaging Management Centre
AMHS ATS Message Handling System
AMHxx Application profile for MHS standards
ANSP Air Navigation Service Provider
API Application Programming Interface
ASN.1 Abstract Syntax Notation One
ATM Air Traffic Management
ATN Aeronautical Telecommunication Network
ATS Air Traffic Services
ATSMHS ATS Message Handling Service
AU Access Unit
BC Business Class

Edition : 2.1 Released Issue Page 11

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CA Certificate Authority
CAAS Common AMHS Addressing Scheme
CIC Content Integrity Check
CIDIN Common ICAO Data Interchange Network
CLNP Connectionless Network Protocol
CNS/ATM Communications Navigation and Surveillance / Air Traffic Management
COM Communication
COTS Commercial-off-the-Shelf
CP Certificate Policy
CPS Certificate Practice Statement
CRL Certificate Revocation List
CS Community Specification
CSV Comma Separated Values
CV Conversion
DAP Directory Access Protocol
DIB Directory Information Base
DIR Directory
DISP Directory Information Shadowing Protocol
DIT Directory Information Tree
DL Distribution List
DMD Directory Management Domain
DMZ De-militarised Zone
DN Distinguished (Directory) Name
Doc ICAO Document
DoC EC declaration of conformity (Article 5 of interoperability Regulation [1])
DOP Directory Operational Binding Protocol
DoV EC declaration of verification (Article 6 of interoperability Regulation [1])
DSA Directory System Agent
DSP Directory System Protocol
DUA Directory User Agent
EANPG ICAO European Air Navigation Planning Group
EATMN European Air Traffic Management Network
EC European Commission
ECDSA Elliptic Curve Digital Signature Algorithm
ED EUROCAE Document
EDS European Directory Service
EIT Encoded Information Type
ENPRM EUROCONTROL Notice of Proposed Rule Making
ER Exempted Recipients (MHS context)
ER Essential Requirement (SES context)
ERAF EUROCONTROL Regulatory and Advisory Framework
ETSI European Telecommunications Standards Institute
EU European Union
EUR ICAO European Region
EUROCAE The European Organization for Civil Aviation Equipment
FG Functional Group
FHA Functional Hazard Assessment
FIPS Federal Information Processing Standard
FTBP File Transfer Body Part
HMI Human-Machine Interface
IA5 International Alphabet Number 5
ICAO International Civil Aviation Organization
ICS Implementation Conformance Statement

Page 12 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Id Identifier
IEC International Electro-technical Commission
IETF Internet Engineering Task Force
IHE IPM Heading Extension
IP Internet Protocol
IPM Interpersonal Message
IPN Interpersonal Notification
IPS Internet Protocol Suite
IPsec Internet Protocol Security (RFC 4301)
IPv4 Internet Protocol version 4 (RFC 791)
IPv6 Internet Protocol version 6 (RFC 2460)
IR SES Implementing Rule
IRV International Reference Version
ISO International Organisation for Standardization
ISP International Standardized Profile
ITU-T International Telecommunication Union – Telecommunications Sector
LD Latest Delivery
LDAP Lightweight Directory Access Protocol
LDIF LDAP Data Interchange Format (RFC 2849)
MD Management Domain
MF-Address MHS-form address
MHS Message Handling System
MM Military Messaging
MMHS Military Message Handling System
MOC Means of Compliance
MS Message Store
MTA Message Transfer Agent
MTCU Message Transfer and Control Unit
MTS Message Transfer Service
NAT ICAO North Atlantic Region
NATO North Atlantic Treaty Organization
NB Notified Body
NIST USA National Institute of Standards and Technology
NOTAM Notice to Airmen
NRN Non-Receipt Notification
O/R Originator / Recipient
OCSP Online Certificate Status Protocol (RFC 2560)
OHI Optional Heading Information
OID Object Identifier
OJEU Official Journal of the European Union
OPA Operational Performance Assessment
OSA Operational Safety Assessment
OSED Operational Services and Environment Definition
OSI Open Systems Interconnection
OU1 Organisational Unit One (in AMHS address)
P1 MHS Protocol for message transfer
P2 MHS Protocol for interpersonal messaging
P3 MHS Protocol for message submission and retrieval between UA and MTA
P7 MHS Protocol for message indirect submission and retrieval from MS
P772 Military messaging protocol
PAG PKI Assessment Guidelines
PD Physical Delivery
PDR Proposed Defect Report (on ICAO Doc 9705)

Edition : 2.1 Released Issue Page 13

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

PENS Pan-European Network Service(s)

PICS Protocol Implementation Conformance Statement
PKI Public Key Infrastructure
PRL Profile Requirements List
QoS Quality of Service
RA Registration Authority
RCP Required Communication Performance
RDN Relative Distinguished Name
RED Redirection
RFC Request For Comments (IETF)
RN Receipt Notification
RoC Return Of Content
ROSE Remote Operations Service Element
RTCA Radio Technical Commission for Aeronautics, Inc.
RTSE Reliable Transfer Service Element
S0 Security Class zero
SARPs ICAO Standards and Recommended Practices
SEC Security
SES Single European Sky
SESAR Single European Sky ATM Research
SHA Secure Hash Algorithm
SHS Secure Hash Signature
SNMP Simple Network Management Protocol (RFC 1157)
SPR Safety and Performance Requirements Specification
SSA System Safety Assessment
SSO System Security Object.
STANAG NATO Standards Agreement
SV Sub-Volume of ICAO Doc 9705
TCP/IP Transmission Control Protocol / Internet Protocol
TP0 ISO Transport Protocol Class 0
TP4 ISO Transport Protocol Class 4
TTP Trusted Third Party
UA User Agent
WAN Wide Area Network
X.400 ITU-T message handling series of recommendations
X.500 ITU-T Directory series of recommendations
X.509 ITU-T Recommendation defining public key certificate format
XF-Address Translated-form address

1.8.2 Definitions
This section defines the terms specific to this document, as well as some
common terms which are included for ease of reference. Other definitions are
included by reference to other documents (references are italicised in
brackets).

Page 14 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

AMHS The set of end systems providing the ATSMHS. In this document, “AMHS” refers
only to that part of the global AMHS which is implemented in the EATMN unless
otherwise stated, including the interfaces at boundaries with third countries. The
AMHS comprises a set of ATN End Systems of type:
- ATS Message Server, which includes an MTA, optionally one or more MS(s) and,
for the support of the Directory Service, a DUA;
- ATS Message User Agent which includes a UA and, for the support of the Directory
Service, a DUA;
- AFTN/AMHS Gateway which includes an MTA, an AU and, for the support of the
Directory Service, a DUA.

AMHS One of the functional objects identified in ICAO Doc 9880 Part II [5] which form part
Component of an AMHS End System; i.e. an MTA, UA, MS, AU or DUA.

AMHS End An ATN End System participating in the provision of the ATSMHS; either an ATS
System Message Server, ATS Message User Agent or AFTN/AMHS Gateway.
A body that manages flight traffic on behalf of a company, region or country. It is a
ANSP (Air
provider of air traffic control services.
Navigation
Service
Provider)

ATN End A computer system that supports one of the ATN applications identified in ICAO
System Annex 10 Volume III Part I Chapter 3 [26] “Aeronautical Telecommunication
Network”.

ATSMHS The air traffic services message handling service (ATSMHS) application aims at
providing generic messaging services over the Aeronautical Telecommunication
Network (ATN). Two levels of service are defined within the ATSMHS:
- The Basic ATSMHS;
- The Extended ATSMHS.

CA (Certificate In cryptography, a certificate authority (CA) is an entity which issues digital

Authority) certificates for use by other parties, containing a public key and the identity of the
owner. A CA is an example of a trusted third party (TTP) which is characteristic of
many public key infrastructure (PKI) schemes. The CA also attests that the public
key contained in the certificate belongs to the person, organisation, server or other
entity noted in the certificate. Optionally the certificate authority may create the users'
keys.
(The term “Certificate Authority” is used rather than “Certification Authority” due to
the common use of the latter term in the aviation community for aircraft certification,
etc).
A data structure containing a public key and some other information, which is digitally
(Public Key)
signed with the private key of the CA which issued it (IETF Definition). The end
Certificate
entity, i.e. the user of the certificate, can be an end-user, an application or a device.
A certificate can be associated with an end entity or with a CA.
Constituents Tangible objects such as hardware and intangible objects such as software upon
which the interoperability of the EATMN depends (SES framework Regulation [23]).
Constituents would normally be identified in interoperability implementing rules (IR) in
accordance with Article 3 of the SES Interoperability Regulation [1], but in this case
there is no IR.

Edition : 2.1 Released Issue Page 15

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CP (Certificate A named set of rules that indicates the applicability of a certificate to a particular
Policy) community and/or class of application with common security requirements. (ITU-T
X.509 [35])

CPS Defines how a specific CA meets the technical, organisational and procedural
(Certificate requirements identified in a certificate policy.
Practice
Statement)

EATMN The collection of systems listed in Annex I of the interoperability Regulation [1]
enabling air navigation services in the Community to be provided, including the
interfaces at boundaries with third countries (SES framework Regulation [23]).

EATMN The EATMN systems within the scope of this EUROCONTROL Specification are
systems “Communication systems and procedures for ground-to-ground … communications”
(SES interoperability Regulation [1], Annex I) and other systems which interface with
them.

End System A system that contains the seven layers defined in the basic reference model for
open systems interconnection including one or more end user application processes.

End-to-end Pertaining or relating to an entire communication path, typically from (1) the interface
between the information source and the communication system at the transmitting
end to (2) the interface between the communication system and the information user
or processor or application at the receiving end (Annex 10 Volume III Part 1 [26]).
In the context of this EUROCONTROL Specification, “end-to-end” is taken to mean
the path between a message originator and the addressee(s) of that message.

Interoperability ‘Interoperability’ means a set of functional, technical and operational properties

required of the systems and constituents of the EATMN and of the procedures for its
operation, in order to enable its safe, seamless and efficient operation.
Interoperability is achieved by making the systems and constituents compliant with
the essential requirements. [SES framework Regulation [23]]

Interoperability An interoperability target is a description of specific operational, functional and/or

Target technical elements within the EATMN used to support the identification of regulatory
and specification provisions. Used within a EUROCONTROL Specification, it
provides a high level operational and services environment description that supports
understanding of what is to be achieved.
(Refer to Article 8 of the interoperability Regulation [1]). A body which carries out the
Notified Body
tasks pertaining to the conformity assessment procedures referred to in the
(NB)
applicable EC directives when a third party is required. With the "Recognised Third
Party Organisations" and "User Inspectorates", "Notified Bodies" is a type of body
involved with Conformity Assessment. For example, “EC” verification is the
procedure whereby a notified body checks and certifies that a subsystem:
• complies with the Directive
• complies with the other regulations deriving from the Treaty, and may be put into
operation.
RA An authority which receives certificate requests and which verifies the acceptance of
(Registration the request by verification of the requester and sends the request to the CA.
Authority)

Page 16 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Security policy A set of objectives, rules of behaviour for users and administrators, and requirements
for system configuration and management that collectively are designed to safeguard
systems and communication resources concerned with the provision of
communication services against acts of unlawful interference.

TTP (Trusted An entity trusted by other entities with respect to security-related services and
Third Party) activities. As this party is trusted, it can act as a CA. The TTP will be an organisation,
licensed or accredited by a regulatory authority.

1.9 Interoperability Target

1.9.1 In a generic specification such as this it is impossible to foresee all possible
messaging configurations. The actual environment will have to be elaborated
as part of the detailed specification for each individual implementation.
1.9.2 The functional environment specification includes:
• Required gateway functionality;
• Messaging systems that are to be interconnected;
• Available communications and network infrastructure.
1.9.3 A messaging system in terms of this EUROCONTROL Specification may be
required to interwork with:
• ATS Message Servers within a State or in other States, implementing the
ATSMHS over ATN/IPS transport services;
• ATS Message User Agents, for the local submission and delivery of
messages by "direct" ATSMHS users;
• AFTN/AMHS Gateways, for the transition of AMHS messages into the
AFTN, and vice-versa;
• National and/or multi-national directory services.
1.9.4 Possible interworking with other message handling systems is a local matter,
outside the scope of this EUROCONTROL Specification.
1.9.5 To ensure seamless operation, there are interoperability requirements at a
number of distinct levels:
• Geographical
The ATSMHS is applicable within and between countries. The ATS
Message Server topology needs to be optimised for efficient routing in
this context.
• Procedural
The ATSMHS must be used in a consistent way to ensure a seamless
service. Procedures must be specified for day-to-day configuration and
operation of the message handling service, as well as for orderly
transition from legacy systems.

Edition : 2.1 Released Issue Page 17

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

• Human-machine interface (HMI)

For direct AMHS users in the human user subgroup, the HMI must
offer the required input capabilities and display the required
information. However, human factors / ergonomics are out of scope of
this EUROCONTROL Specification.
• Communication protocols
Ground end systems must interwork at the technical level. End
systems must interwork with logically adjacent end systems (e.g. an
ATS Message User Agent must interwork with an ATS Message
Server for message submission and delivery) as well as with peer end
systems (i.e. interworking between AMHS users, both direct and
indirect). The end system includes:
- Application entities (e.g. MTA, MS, UA, DUA, DSA)
- Upper Layers (above transport layer)
- Lower Layers (transport layer and below)
1.9.6 Figure 3 illustrates the interoperability target for AMHS.

Direct AMHS Direct AMHS

User P2 (IHE, FTBP) User
ATS Message ATS Message
Human User
User Agent User Agent Human User
(HMI)
(HMI)
or UA P3 / P7 ATS Message ATS Message P3 / P7 UA or
/ local Server Server / local
Host User
(e.g. Host User
MTA MTA (e.g.
terminal server) DUA DUA
P1 terminal server)
MS
MS MS
MS MS
MS
DUA DUA (Optional)
DAP (Optional) DAP

DAP DAP

Legend:
P3: Message submission / delivery
P1: Message transfer protocol between MTA and UA
P2: Inter-personal message protocol P7: Message submission / delivery /
retrieval between MS and UA
DAP: Directory Access Protocol
between DUA and DSA (not shown)

Figure 3: AMHS Interoperability Target

1.9.7 The ATS Message User Agent is a logical component that may or may not be
physically identifiable in an implementation. It may be either logically co-
located or remote from the ATS Message Server with which it is associated.
When logically remote from the ATS Message Server, it will use the P7
protocol if using a Message Store (MS), or the P3 protocol if communicating
directly with the Message Transfer Agent (MTA). The MS is an optional
component of the ATS Message Server.
1.9.8 If end-to-end message security services are implemented, the user agent (UA)
components would need additional functionality for generating and verifying
the content integrity check and digital signature, and there would need to be
additional infrastructure to support the management of public key certificates.

Page 18 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note that there are also security measures applied to ATS Message Servers
and DSAs, as well as link level security.
1.9.9 The directory function (DIR), accessed via a Directory User Agent (DUA)
which communicates with a Directory System Agent (DSA), provides an
enhanced level of service, supporting functions such as address lookup and
enabling a message originator to determine the capability of an intended
recipient (direct AMHS user) before initiating the message exchange. The
DUA is a mandatory component of the ATS Message Server and ATS
Message User Agent when these end systems support the Extended
ATSMHS. The DUA enables access to the ATN Directory by means of the
Directory Access Protocol (DAP). Note that within a local system, other access
protocols such as LDAP may be considered.
1.9.10 During the transition phase, which may take a number of years, legacy AFTN
systems and terminals will need to be supported, both within States and
between States. A State which has an operational AMHS may still support
legacy AFTN users within that State (indirect AMHS users), and will also need
to interwork with States that do not have operational AMHS deployments.
1.9.11 The goal is for interoperability between end users. Clearly, the degree of
interoperability possible will depend upon the capability of the end user’s
system. For example, an AFTN terminal would not be expected to interoperate
with an ATS Message User Agent for the exchange of binary encoded
weather maps. However, basic interoperability at the level of ATS message
exchange (textual rendition of flight plan, etc. messages) would be supported,
and would be achieved through the use of an AFTN/AMHS gateway.

Edition : 2.1 Released Issue Page 19

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Direct AMHS Direct AMHS

User P2 (IHE, FTBP) User
ATS Message ATS Message
Human User
User Agent User Agent Human User
(HMI)
(HMI)
or UA P3 / P7 ATS Message ATS Message P3 / P7 UA or
/ local Server Server / local
Host User
(e.g. Host User
MTA MTA (e.g.
terminal server) DUA DUA
P1 terminal server)
MS
MS MS
MS MS
MS
DUA DUA (Optional)
DAP (Optional) DAP

DAP DAP

P1 P1
P1

AFTN/AMHS AFTN/AMHS
Gateway Gateway

Indirect AMHS MTCU MTA P1 MTA MTCU Indirect AMHS

User (AU) (AU) User

AFTN AFTN/CIDIN AFTN/CIDIN AFTN

AFTN AFTN
Station Component DUA DUA Component Station

DAP DAP

P2
Legend:
P3: Message submission / delivery
P1: Message transfer protocol between MTA and UA
P2: Inter-personal message protocol P7: Message submission / delivery /
(P2 between UAs and MTCUs not retrieval between MS and UA
shown for clarity)
DAP: Directory Access Protocol
between DUA and DSA (not shown)

Figure 4: AMHS Interoperability Target (transitional phase)

1.9.12 Figure 4 illustrates the elements which are needed for transition, and
represents the initial Interoperability Target.
1.9.13 The DUA is a mandatory component of the AFTN/AMHS Gateway when the
Extended ATSMHS is supported. If an AFTN/AMHS Gateway additionally
supports message security services, the access unit (AU) components would
need additional functionality for verifying the content integrity check and digital
signature.
1.9.14 At a future date, when the transition from AFTN/CIDIN is complete, and no
legacy AFTN stations remain, the AFTN/AMHS Gateways will no longer be
required. The ultimate interoperability target for AMHS is for all end users to
become Direct AMHS users.
1.9.15 Figure 5 illustrates the initial interoperability target from the perspective of a
European international COM Centre. It shows:
a) An ATS Message Server, comprising an X.400 message transfer agent
(MTA) and optionally one or several message stores (MS), and a Directory
User Agent (DUA). The ATS Message Server uses the P1 protocol over
TCP/IP (e.g. using PENS) to communicate with other ATS Message
Servers and with AFTN/AMHS Gateways in the EATMN.

Page 20 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

b) The MTA may optionally use “dual stack” ATN/OSI (or other bilaterally
agreed solution) and ATN/IPS lower layer protocols to communicate via P1
with ATS Message Servers and AFTN/AMHS Gateways outside the
EATMN.
c) An AFTN/AMHS Gateway, which includes an AFTN component, an ATN
component (MTA), a Message Transfer and Control Unit (MTCU), a
Control Position and a DUA. The MTA may in actuality be the same MTA
in a) above. The MTCU is an MHS access unit.
d) A Directory service, comprising one or more interconnected or free-
standing DSAs.
e) Access to the COM Centre by Indirect AMHS user using the AFTN/AMHS
gateway.
f) Access to the COM Centre by Direct AMHS user, comprising an ATS
Message User Agent using P3 and/or P7 protocols and a DUA.
g) Interconnection of the COM Centre with another ATS Message Server,
which is part of the State’s internal messaging system using P1 protocol.
h) End-to-end message security services for direct AMHS users, which may
be bilaterally agreed. (For indirect AMHS recipients, the message security
may be established between a sending AMHS direct user and
AFTN/AMHS Gateway).
i) An abstract “National Network,” which may be composed of several
networks, leased lines, dial-up connections, etc. providing connectivity
between end systems within a State. In some cases an ATS Message
User Agent may be connected using other networks instead of, or
additionally to, the national network.

End-to-gateway security services

Indirect DUA
AFTN AFTN AFTN
AMHS
Users User GWY Directory

DUA

MTA AMHS/IP to other

Directory National EATMN COM Centres
Network e.g. PENS

DUA P1
AMHS
AMHS/IP or AMHS/OSI to
MTA MS AMHS systems in other
P3 region(s)
DUA
AMHS
Direct
UA
P7
AMHS
DUA
Users AMHS
UA
End-to-end security services

Figure 5: COM Centre perspective

1.9.16 The functional model and architectures depicted in this section provide an
abstract, logical view of AMHS functional components. UA and MS

Edition : 2.1 Released Issue Page 21

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

functionality may be implemented, for example, by means of an AMHS

terminal server providing centralised UA/MS functionality, and supporting
AMHS protocols and message formats. The dialogue between the user
workstation itself and the terminal server is then a matter local to the State and
considered ANSP.
1.9.17 In the full scope of European ATS message handling, there could also be one
or more gateway(s) to/from local non-AMHS message handling systems, but
this is outside the scope of this EUROCONTROL Specification.
1.9.18 To enable the interoperability target to be reached, this EUROCONTROL
Specification defines means of compliance largely by reference to external
standards and documents maintained by ICAO and EUROCAE. In turn, these
documents also reference many ISO/IEC standards and ITU-T
Recommendations.

Page 22 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

2. AMHS INTEROPERABILITY – BASIC ATSMHS

2.1 General
2.1.1 This chapter contains guidance and explanatory material for the AMHS
Interoperability requirements in Annex A, which apply to the Basic ATSMHS
level of service as defined in ICAO Doc 9880 Part II [5].

2.2 Standards Baseline

2.2.1 The standards baseline in Annex A defines the standards which through
reference constitute part of the EUROCONTROL Specification.
2.2.2 The approach is to reference ICAO material where available, noting deviations
where required and specifying additional functionality where necessary.
2.2.3 ICAO Annex 10 Volume II [3] refers to the detailed technical specifications for
the ATSMHS in ICAO Doc 9880 Part II [5]. These provisions in turn make
reference to International Standardised Profiles (ISPs) originally published by
the International Organisation for Standardization (ISO) 5.
2.2.4 In the MHS base standards (ISO/IEC 10021 | ITU-T X.400 [18]), a subset of
the OSI Upper Layer protocols (ROSE, RTSE, ACSE, Presentation and
Session layers) is used to support communications between the MHS
components (MTA, UA, AU and MS).
2.2.5 However, there remain some options and implementation choices in the
AMHS technical specifications in ICAO Doc 9880 Part II [5]. These include
support of the Extended and/or Basic ATSMHS, support for different body part
types, message size constraints, etc.
2.2.6 The responsible group (AFSG) within the ICAO European Region (EUR) has
produced the EUR AMHS Manual (ICAO EUR Doc 020 [8]), which provides
general guidance and detailed information on requirements concerning AMHS
implementation in the ICAO EUR Region.
2.2.7 The ICAO European Regional office has also published the ATS Messaging
Management Manual (ICAO EUR Doc 021 [9]), which describes the
framework in which the services of the ATS Messaging Management Centre
(AMC) are provided, and also describes the procedure for the introduction of a
new AMHS COM Centre in the international EUR/NAT AMHS network.

2.3 Network Support

2.3.1 This section describes interoperability between the AMHS components (MTA,
UA, etc.) and the supporting network infrastructure. In general, there will be
network level security features such as firewalls to control access to the
infrastructure. Security protocols such as IPsec can be used to ensure that
only named servers can connect to one another. However, these are not
specific to the messaging system and are not described further.

5
The referenced ISPs are no longer available from ISO/IEC.

Edition : 2.1 Released Issue Page 23

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

2.3.2 As specified in ICAO Doc 9880 Part II [5], an AMHS End System can make
use of the connection mode transport service provided by either or both of the
ATN/OSI or the ATN/IPS. In the former case, it operates over the ATN internet
communications service, based on a TP4/CLNP protocol stack, while in the
latter case it operates over a TCP/IP protocol stack.
2.3.3 Implementations by ANSPs in Europe will make use of a ground-ground
network infrastructure based on TCP/IP, as specified in ICAO EUR Doc 020
[8], section 3.5. This is consistent with the ATN/IPS as defined in ICAO Doc
9896 [22], and with the option to use the ATN IPS transport service as defined
in ICAO Doc 9880 Part II [5], section 3.2.2.2.
2.3.4 An underlying network infrastructure that can provide physical connectivity
between international ATS Message Servers is a prerequisite. This may be
provided by the Pan-European Network Service (PENS). Bilateral or
multilateral connectivity arrangements can accommodate initial AMHS
operations.
2.3.5 TCP/IP is specified for interconnections between MTAs of different ANSP
international COM Centres within Europe. The same lower layer profile may
also be used within an ANSP’s local systems – e.g. to support P1, P3 and P7
transfer and access protocols.
2.3.6 Additional protocol stacks may be required in other situations (e.g. the
ATN/OSI profile may be additionally required in EATMN boundary systems,
and other profiles may need to be used between the MTAs operating within an
ANSP’s Management Domain).

2.4 Safety and Performance Requirements

2.4.1 In terms of the SES interoperability Regulation [1]:
"Communication systems shall be designed, built, maintained and operated
using the appropriate and validated procedures, in such a way as to achieve
the required performances … for a specific application, in particular in terms of
communication processing time, integrity, availability and continuity of
function."
2.4.2 Detailed safety and performance requirements (SPR) are specific to the
applications using the ATSMHS. Safety and performance requirements for a
particular operational environment are typically enumerated in a SPR
specification, as defined in ED-78A [11], and are the products of operational
safety assessment (OSA) and operational performance assessment (OPA)
processes.
2.4.3 Safety requirements are shared risk mitigation strategies that aim at satisfying
safety objectives. Safety objectives apply, for example, to the probability of
undetected message loss or corruption. The severity of the hazard depends
upon the nature of the message, i.e. upon the user application, and is
assessed during the OSA process for that application.
2.4.4 Within the Extended ATSMHS, security services can help to protect against
safety hazards such as accidental or deliberate message corruption and can
provide protection against undetected misdelivery. Note that additional

Page 24 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

functions are necessary to protect against other threats such as messages

containing computer viruses.
2.4.5 The OSA and OPA are dependent upon the specific operational services and
environment definition (OSED). The OSA determines, validates, and allocates
requirements to ensure that the CNS/ATM system, as described in the OSED,
is acceptably safe. The OPA derives and/or validates required communication
performance (RCP) type.
2.4.6 For the operational hazard assessment (part of the OSA), services are
examined to identify and classify hazards that could adversely affect those
services. For AMHS, the hazard depends upon the safety-criticality of the
message content. High-level hazards (e.g. probability of message loss or
corruption) can be identified, but not quantified for the AMHS in isolation.
2.4.7 Implementers will have to show for approval that the relevant SPR standards
are satisfied per ED-78A [11] Section 5 (Development and Qualification of a
System Element) and Section 6 (Entry into Service).

2.5 Message Transfer Service Interoperability

2.5.1 This section is concerned with MTA-to-MTA interoperability requirements.
2.5.2 The Message Transfer Service (MTS) is provided by MTAs communicating via
the message transfer protocol P1. The profile requirements for MTAs in the
EATMN are specified in ICAO EUR Doc 020 [8], Appendix B section 4.5.
2.5.3 There is a clear distinction in the design of the European AMHS between
national and international communications. Each European State/ANSP
implementing an AMHS management domain may decide to decouple the
international AMHS from its national messaging network by the setting up of
one or more international ATS Message Servers (together with an
AFTN/AMHS Gateway if necessary for transition purposes) forming the
interconnection point between both environments.
2.5.4 A backup ATS Message Server may be specified to take over from an
international ATS Message Server if the primary system becomes unavailable.
2.5.5 An important consideration is the topology to be adopted for ATS Message
Servers if more than one is to be deployed for the State AMHS service.
Nationally, the AMHS architecture of ATS Message Servers can be
centralised or distributed. This is discussed in section 3.3 of ICAO EUR Doc
020 [8].

2.6 End to End Interoperability of Direct AMHS Users

2.6.1 This section is concerned with UA-to-UA interoperability requirements.
2.6.2 A direct AMHS user is a human or automated system that uses an ATS
Message User Agent for message submission and delivery.
2.6.3 The ATSMHS is based on the standards for the interpersonal messaging
protocol (P2), i.e. ISO/IEC 10021-7 | ITU-T Recommendation X.420 [18], using
message content type 22.

Edition : 2.1 Released Issue Page 25

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

2.6.4 Users of the Basic ATSMHS are able to send and receive simple text
messages using a single ia5-text body part containing a structured ATS
Message Header.

2.7 Interoperability between AFTN and AMHS

2.7.1 This section is concerned with AFTN/AMHS Gateway requirements.
2.7.2 During the transition phase from AFTN/CIDIN to the AMHS, the
interoperability between AFTN and AMHS is achieved by the use of
AFTN/AMHS gateways.
2.7.3 Interconnection between the AFTN/CIDIN and the AMHS in Europe will be by
means of AFTN/AMHS Gateways directly interfacing with the AFTN
application supported by European international AFTN/CIDIN COM Centres.
2.7.4 Technical provisions for the AFTN/AMHS gateway are specified in ICAO Doc.
9880 Part II [5], Chapter 4.

2.8 Ground Recording of Messages

2.8.1 Annex A elaborates on the information required to be recorded by AMHS End
Systems, in accordance with ICAO recording requirements. These are
minimum requirements for recording the message exchanges for audit and
incident investigation purposes.

2.9 Naming and Addressing

2.9.1 Annex A includes requirements for specifying, maintaining and disseminating
unambiguous name and address information required for safe and efficient
operation of the communications system.
2.9.2 ICAO Doc 9880 Part II [5] section 2.5.1.4 requires each AMHS management
domain to implement an AMHS addressing scheme policy. The management
domain may implement either a MHS-form (MF) addressing scheme, or a
locally defined addressing scheme, or a combination of both. Two alternative
MF-addressing schemes are defined: the Common AMHS Addressing
Scheme (CAAS) and the Translated-form (XF) addressing scheme.
2.9.3 Adoption of a single EATMN-wide addressing scheme would simplify address
management and hence aid seamless operations. Therefore the CAAS is
recommended for the EATMN. This is consistent with ICAO Doc 9880 Part II,
section 2.5.1.4 and with ICAO EUR Doc 020 [8], section 3.2.5.1.

Page 26 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

2.9.4 However, for interoperability purposes, all components of Basic and Extended
ATSMHS systems must support all of the AMHS address formats identified in
ICAO Doc 9880, including XF-addresses. This does not require any form of
address translation by an ATS User Agent or an ATS Message Server.
2.9.5 ICAO Doc 9880 Part II [5] section 2.5.1.3 requires that a unique identifier for
each AMHS management domain is registered in the ICAO Register of AMHS
Management Domains [28].

2.10 Operational Procedures

2.10.1 Operational procedures for implementing and managing international AMHS
are specified by the Aeronautical Fixed Services Group (AFSG) under the
auspices of the ICAO European Air Navigation Planning Group (EANPG).
Such procedures are documented in ICAO EUR Doc 020 [8], ICAO EUR Doc
021 [9] and Part I of the Routing Directory for COM Centres in the EUR/NAT
Regions [27].
2.10.2 These procedures, which are applicable for ICAO Contracting States in the
EUR Region, are equally applicable to all EATMN countries.

2.11 Interoperability with Military Message Handling Systems

2.11.1 It is a requirement of the interoperability Regulation ([1], Annex II) that the
EATMN, its systems and constituents support the progressive implementation
of civil/military coordination by supporting the timely sharing of correct and
consistent information between civil and military parties.
2.11.2 Options for military interconnection with AMHS may vary from merely retaining
AFTN remote tails, accessing AMHS via gateways, to a certain level of
interconnection with military networks including the X.400 based Military
Message Handling System (MMHS). The latter solution might raise significant
challenges in terms of security and directory services.
2.11.3 The EUROCONTROL Roadmap on Enhanced Civil-Military CNS
Interoperability and Technology Convergence [45], section 6.3, considers
AFTN/CIDIN transition and AMHS interoperability.
2.11.4 Note that the MMHS specifications referred to above include STANAG 4406
[43], which defines an X.400 based MHS with extensions for military use,
including a possible interface to Civilian MHS via a trusted gateway. The
MMHS Elements of Service and protocol are defined as a Military Messaging
(MM) content type, identified as the P772 protocol. Several of the Business
Class attributes as defined for the Extended ATSMHS (e.g. precedence,
originators-reference) can translate easily to P772 equivalents.

Edition : 2.1 Released Issue Page 27

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

2.11.5 AMHS connectivity will be an important step towards the network centric
architecture System Wide Information Management (SWIM), which requires all
ATM actors, including military ATC and Air Defence, to be able to exchange
information in a distributed and fully automated way.
2.11.6 Consequently, medium and longer term civil-military interoperability solutions
are likely to include higher levels of connectivity and exchange of aeronautical
messaging services including compatible security levels.

2.12 Interoperability with Systems External to EATMN

2.12.1 Within the EATMN, AMHS communication uses ATN/IPS lower layers.
Elsewhere in the world, it is possible that AMHS communication could be
based on ATN/OSI lower layers. ICAO Annex 10 Volume III [26] requires that
regional air navigation agreements will specify the area in which the
communication standards for the ATN/OSI or the ATN/IPS are applicable.
2.12.2 If the external systems support only ATN/OSI lower layer protocols, the
implementation of dual stacks as illustrated in Figure 6 can be proposed as
the interworking solution. Other solutions may also be possible, but are
outside the scope of this EUROCONTROL Specification.

Country External to
Scope of EATMN
EATMN using OSI
transport layer
MTA Boundary ATS MTA
Message Server
MTA
ATN/OSI ATN/IPS

ATN/ ATN/
OSI IPS TCP/IP

TP4/CLNP TCP/IP

ATN / OSI
network or PENS
dedicated line

Figure 6: MTA Communication with an External Region using ATN/OSI

2.12.3 The European AMHS incorporates an ISO TP0 transport service implemented
over a TCP/IP stack. If needed, boundary ATS Message Servers in selected
boundary COM centres will implement dual stack systems to allow
interconnection with ATN/OSI AMHS systems external to the EATMN.

Page 28 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

3. EXTENDED ATSMHS

3.1 General
3.1.1 This section contains explanatory material for the requirements in Annex B
concerning the Extended ATSMHS.
3.1.2 The Extended ATSMHS is an enabler for ATS operational improvements. It
offers significant operational benefits, improvement of ATS capacity and
performance.
3.1.3 The requirements for Extended ATSMHS are in addition to those for Basic
ATSMHS.

3.2 Standards Baseline

3.2.1 The standards baseline in Annex B defines the standards which through
reference constitute part of the EUROCONTROL Specification concerned with
the Extended ATSMHS.

3.3 Extended ATSMHS Functionality

3.3.1 All AMHS End Systems supporting the Extended ATSMHS must conform to
the relevant requirements of the Basic ATSMHS.
3.3.2 In addition, implementations which support the Extended ATSMHS include
functionality which can conveniently be described in terms of the following
functional groups:
a) Use of File Transfer Body Parts (FTBP). This functional group
enables the transfer of binary data between direct AMHS users.
When binary files can be transferred it is important to include
virus protection in the architecture, associated with the ATS
Message Server and/or ATS Message User Agent; however
this is out of scope of this EUROCONTROL Specification.
b) Use of IPM Heading Extensions (IHE). This functional group
uses standard message fields instead of the AMHS-specific
ATS Message Header which is required in the Basic ATSMHS.
c) AMHS Security (SEC). This functional group enables support of
the AMHS security policy, providing message origin
authentication and content integrity assurance between direct
AMHS users.
d) Use of Directory (DIR). This functional group enables support
of the ATN Directory through the use of a DUA included in the
AMHS End System.
3.3.3 An implementation of an ATS Message User Agent or of an ATS Message
Server claiming full conformance to ICAO Doc 9880 Part II [5] for the
Extended ATSMHS is required to support all of these functional groups.
3.3.4 ICAO Doc 9880 Part II [5] also allows an implementation of an ATS Message
User Agent or of an ATS Message Server to claim conformance for a subset

Edition : 2.1 Released Issue Page 29

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

of the Extended ATSMHS, in accordance with one of the valid configurations

listed in Table 1.
Table 1: Definition of ATSMHS subsets
Configuration Reference Functional Group Combination
I. Basic
II. Basic + FTBP
III. Basic + IHE
IV. Basic + DIR
V. Basic + DIR + FTBP
VI. Basic + DIR + IHE
VII. Basic + DIR + SEC
VIII. Basic + IHE + DIR + SEC
IX. Basic + IHE + DIR + FTBP
X. Basic + IHE + DIR + FTBP + SEC
3.3.5 If different AMHS End Systems in the EATMN were to support different
combinations of functional groups this would be detrimental to full functional
interoperability and seamless operations (although interoperability would be
possible at least at the Basic ATSMHS level).
3.3.6 Conformance to this EUROCONTROL Specification for the Extended
ATSMHS requires implementation of configuration IX (Basic + IHE + DIR +
FTBP functional groups) only.
3.3.7 Note that the future migration to configuration X (addition of SEC) may be
foreseen, but is not currently required for compliance with this
EUROCONTROL Specification.
3.3.8 For the AFTN/AMHS Gateway, ICAO Doc 9880 Part II does not specify any
distinct functional groups; an implementation may or may not support the
Extended ATSMHS as a whole. In practice, FTBP is not relevant for an
AFTN/AMHS Gateway; if an AMHS message containing an FTBP body part
were received it would unconditionally be rejected by the gateway according to
ICAO Doc 9880 Part II, paragraph 4.5.2.1. SEC would be applicable in the
AMHS-to-AFTN direction. IHE and DIR would be supported by an
AFTN/AMHS Gateway that supports the Extended ATSMHS.
3.3.9 For maximum flexibility and forward compatibility, a minimum level of support
of the SEC functional group of the P1 profile is recommended in Annex B for
the ATS Message Server and AFTN/AMHS Gateway. The minimum support
specified in ICAO Doc 9880 Part II includes security class S0, which is
confined to security functionality operating between MTS-users on an end-to-
end basis in order to permit transfer across an MTS which may be untrusted. It
is designed to minimise the required functionality in the MTS to support the
submission of elements associated with these services.
3.3.10 This does not imply that the AMHS user is required to support secure
messaging, merely that the MTA supports the required envelope extensions
as an enabler for future AMHS user functionality.
3.3.11 It is important to note the distinction between the AMHS functional group SEC
and the SEC functional group in the referenced standards. This is illustrated in
Figure 7.

Page 30 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

What is meant by “Security Support”?

“SEC”

SEC functional group in the SEC functional group of

referenced MHS the Extended ATSMHS
standardised profiles
ICAO Doc ICAO Doc
9880 Pt II 9705 SV8
Transparent relay of security-
related elements of service Secure cryptographic
for forward compatibility messaging algorithms,
using the PKI
System Enabler for secure message
messaging in the future token

Recommended in Annex B Informative in Annex D

for MTA, UA and MS
components implementing
the Extended ATSMHS

Figure 7: SEC FG in Base Standards vs. Extended ATSMHS

3.4 End to End Interoperability of Direct AMHS Users

3.4.1 Users of the Extended ATSMHS have access to advanced features that are
not available to users of the Basic ATSMHS. These include binary data
transfer using file transfer body part and, if the SEC functional group is
implemented, message security features. The profile requirements for UAs in
the EATMN are as specified in ICAO EUR Doc 020 [8], Appendix B Annex A
(IPM content) and Annex P (message token generation and reception).
3.4.2 Interoperability issues may arise when a user supporting the Extended
ATSMHS wishes to communicate with a user supporting the Basic ATSMHS.
In such cases, interoperability will only be possible at the Basic ATSMHS level
of service.
3.4.3 For example, if a direct user wishes to send a file transfer body part, this will
only be meaningful if all of the addressed recipients can process such body
part types correctly, i.e. they support the FTBP Functional Group of the
Extended ATSMHS. For the sake of robustness, even an ATS Message User
Agent supporting only the Basic level of service is expected to be able to
receive a message containing unsupported body parts without aborting or
malfunctioning.

3.5 Naming and Addressing

3.5.1 In the Extended ATSMHS, the O/R name of an AMHS user is required to
comprise both the MF-address (O/R address) and the directory name
(distinguished name form) of the AMHS user (see ICAO Doc 9880 Part II [5]
section 2.5.1.1).

Edition : 2.1 Released Issue Page 31

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

3.5.2 This implies conveyance of both MF-address and directory name in the
message envelope and IPM heading. In practice, a UA, MTA, or Gateway
receiving a message has no use for the received directory names, as it never
needs to look anything up in the directory (except possibly a user’s certificate,
if secure messaging is implemented). Theoretically, support for IPM Use of
Directory requires a UA to be able to display the directory component in a
received O/R Name (ISO ISP 12062-1 A.2.3).
3.5.3 For maximum interoperability and efficiency, it is recommended that, in
addition to the MF-address, a directory name is registered for all direct users,
but that Extended AMHS systems do not include the directory name element
of O/R Names on message submission.

Page 32 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

4. USE OF DIRECTORY

4.1 General
4.1.1 This section contains explanatory material for the requirements in Annex C for
the use of Directory by AMHS.
4.1.2 Topics addressed include:
• Directory Architecture in the EATMN (section 4.2);
• Directory System Protocols (DSP, DISP) (section 4.3);
• Directory access (section 4.4);
• Directory Schema (section 4.5);
• Versioning and data life cycle (section 4.6).
• Determination of AMHS recipient capabilities (see section 4.7);
4.1.3 In the Basic ATSMHS, the equivalent of a "directory" function may be realised
as a simple look-up table of addresses. In the Extended ATSMHS, the
directory may be a centralised or fully distributed database, including support
for replication, chaining, etc.
4.1.4 ICAO EUR Doc 020 [8] specifies, in Appendix B Annex K (which has
Informative status), directory information, in the form of Object Classes and
Attribute Types that are useful to support Directory Name resolution and the
mapping of AFTN addresses to and from AMHS addresses.
4.1.5 ICAO Doc 9880 Part IV Chapter 2 [7] specifies the ATN Directory service. In
particular, a set of ATN Object Classes and Attribute Types are specified for
use with systems supporting the Extended ATSMHS.
4.1.6 An ANSP's system specification would need to include requirements for (a)
the directory information base, (b) the directory access method and (c) the
directory system protocols to be supported.
4.1.7 ICAO EUR Doc 020 [8] specifies, in Appendix G and associated Annexes, a
European Directory Service (EDS), in which a Central European DSA provides
such a service.

4.2 Directory Architecture

4.2.1 This section describes a directory architecture for the EATMN and details
requirements to be met by the Directory System Agents (DSAs) and Directory
User Agents (DUAs), in order to guarantee interoperability and data sharing.
4.2.2 The general Directory Service (DIR) allows users to obtain directory
information about other users, applications and services participating in the
network. The DIR is composed of three parts, Directory Information Base
(DIB), DSAs and DUAs, illustrated in Figure 8.
4.2.3 The general DIB is organised into a tree-shaped hierarchy, the Directory
Information Tree (DIT). The DIT may contain shared data replicated between
DSAs (shadowing), shared data referenced by other DSAs (chaining),

Edition : 2.1 Released Issue Page 33

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

references to data stored on other DSAs (chaining / referrals) and local data
not shared with other DSAs.
4.2.4 The ATN Directory Service is a specific profile of the general Directory Service
specified in ISO/IEC 9594 | ITU-T Recommendation X.500 [34], including
ATN-specific schema elements.

DUA DUA

DAP DSP, DISP DAP

DUA DSA1 DSA2 DUA
Chaining / Shadowing

DIB
DUA DUA
from from
DSA2 DSA1

Private data

Country 1 Country 2
Figure 8: General Directory Architecture
4.2.5 For Directory Services deployment in the EATMN, the EDS operational
concept described in ICAO EUR Doc 020 [8] Appendix G elaborates the
concept of common shared information hosted by a central Directory
Management Domain (DMD). In the EDS concept, Co-operating DSAs and
Adjacent DSAs communicate with a Central European DSA.

4.3 Directory System Protocols

4.3.1 The Directory standards define several different system protocols - the
Directory System Protocol (DSP), the Directory Information Shadowing
Protocol (DISP), and the Directory Operational Binding Protocol (DOP).
4.3.2 DSP supports chaining, where a request that cannot be resolved by a DSA is
passed to another DSA, and referrals, where a request that cannot be
resolved by a DSA returns a reference to another DSA. ICAO Doc 9880 Part
IV Chapter 2 [7] specifies DSP for use in the ATN.
4.3.3 DISP supports replication of information between DSAs. ICAO Doc 9880 Part
IV Chapter 2 [7] provides indications for usage, but does not define a detailed
DISP profile. The implementation of DISP is optional.

Page 34 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

4.3.4 Note that while DISP implementation is optional, it could be useful to support
automatic information updates when authorised by an administrator, and is
therefore recommended in the EDS.
4.3.5 DOP is considered out of scope.

4.4 Directory Access

4.4.1 If the ATN Directory is implemented, access to directory information is via the
standard X.500 Directory Access Protocol (DAP), which is the only access
protocol specified in ICAO Doc 9880 Part IV Chapter 2 [7].
4.4.2 DAP may be used with an OSI lower layer stack, or with a TCP/IP mapping,
which is the recommended approach in the EATMN.
4.4.3 LDAP [39] is the IETF equivalent of X.500 DAP. It can provide most (but not
all) of the services that DAP provides. LDAP is only an access protocol,
whereas X.500 defines a complete directory system, with features such as
replication, which will be important to ATS systems. There will be situations
where use of both DAP and LDAP will be desirable. However, LDAP is not
currently included in ICAO Doc 9880 Part IV [7] and is therefore out of scope
of this EUROCONTROL Specification, though not precluded for local directory
access. ICAO EUR Doc 020 [8] Appendix G notes that: “Use of LDAP Version
3 is optional for end users with limited needs.”

4.5 Directory Schema

4.5.1 The general DIT structure to be supported by ATN DSAs is specified in ICAO
Doc 9880 Part IV [7] Chapter 2. The DIT subtree to support AMHS in the
EATMN is part of the EDS specified in ICAO Doc 020 [8] Appendix G.

4.6 Versioning and Data Life Cycle

4.6.1 Currently, the AMC is responsible for distributing ATS messaging
management information updates at regular intervals based on the AIRAC
cycle. Thus, different versions of the information may exist at different times.
The EDS specified in ICAO EUR Doc 020 supports Pre-operational and
Operational versions of the shared DIT and defines an EDS-specific Object
Class containing version identification.

4.7 Use of Directory to determine AMHS Recipient Capabilities

4.7.1 The technical provisions in ICAO Doc 9880 do not explain how to use the
Directory to determine which elements of the Extended ATSMHS are
supported by a recipient. Various approaches are possible, including the
following:
a) Recipient capabilities can be “known” in advance by bilateral
agreement. For example, direct host (application) AMHS users
would send only to agreed pre-configured addresses, with
compatible capability level.

Edition : 2.1 Released Issue Page 35

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

b) The EDS can be used to determine AMHS user capabilities, as

described in ICAO EUR Doc 020 [8] Appendix G-B, Section
5.2:
IHE supported – if the ‘atn-ipm-heading-extensions’ attribute is
TRUE;
FTBP supported – if the ‘mhs-exclusively-acceptable-eits’
attribute includes the file transfer value ‘{joint-iso-itu-t(2) mhs(6)
ipms(1) eit(12) file-transfer(0)}’;
SEC supported – if the ‘atn-use-of-amhs-security’ attribute is
TRUE. Note that a sending UA does not need to know this, as a
recipient that does not support security simply ignores the
security features of a message (because they are in envelope
extensions marked ‘non-critical’). If the sender needs to know
that the recipient lacks the means to verify signatures, this
could be achieved by including in a given AMHS-user
application specification the requirement that an AMHS user
must send a signed reply whenever it receives a signed
message; the lack of a reply would indicate lack of security
capability for that recipient.
4.7.2 ICAO Doc 9880 Part II [5], Chapter 3.4 allows an implementation of an ATS
Message User Agent or of an ATS Message Server to claim conformance to
either the Basic ATSMHS or one of the defined subsets of the Extended
ATSMHS. This EUROCONTROL Specification simplifies the subsetting
problem by reducing the options to Configuration IX {Basic + IHE + DIR +
FTBP} (see 3.3.6 above).
4.7.3 Therefore, any European system recipient with the ‘atn-ipm-heading-
extensions’ attribute set to TRUE by implication supports both IHE and FTBP
functional groups.

Page 36 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

5. AMHS SECURITY

5.1 General
5.1.1 This chapter contains background and explanatory material for the use of
Security services in the Extended ATSMHS. A set of related technical
provisions are specified in Annex D for information.
Note: It is recognised that the provision of AMHS Security services is not as
advanced as other elements of the Extended ATSMHS. For that reason, the
specifications in Annex D are to be considered as advisory indications of the
evolutionary direction, whose implementation is not required for compliance to
this version of the EUROCONTROL Specification. However, ANSPs are
encouraged to prepare the referenced end-to-end security policy as soon as
possible. Further, there is a general recommendation that ATS Message
Server implementations can accept and transparently relay the relevant
security-related fields without causing systems to fail.
5.1.2 Support of the AMHS Security (SEC) functional group is part of the Extended
ATSMHS. ICAO Doc 9880 Part II [5] section 2.2.3.2 requires an end-to-end
security policy to be implemented which provides message origin
authentication, content integrity and message sequence integrity.
Note: It must be recognised that the technical end-to-end message security
mechanisms specified in ICAO Doc 9880 Part II [5] are only one part of the
overall security architecture. Other elements such as virus protection,
firewalls, DMZs, IPsec, etc. are equally important and must be addressed in
operational ATS messaging systems.
5.1.3 Use of the AMHS Security functionality enables a message recipient to have a
very high level of confidence that a received message has not been corrupted
in transit or modified accidentally or deliberately. It also provides a very high
degree of confidence that the message does come from the claimed
originator, who is known and trusted.
5.1.4 A message recipient can verify that the message was indeed addressed to
that recipient, thereby allowing mis-delivery protection.
5.1.5 The importance of these security functions depends upon the nature of the
information being transmitted in the message and the potential consequences
of misdelivery, modification or masquerade.
5.1.6 ICAO Doc 9880 Part II [5] indicates support for message sequence integrity
but does not specify how message sequence numbers are assigned and
verified. This would need to be specified in supporting material, or in bilateral
agreements. Support for message sequence integrity using sequence
numbers in the message token is not required. (The AFTN/AMHS Gateway
supports sequence integrity by other means; see ICAO Doc 9880 Part II [5]
section 4.5.2.4).
5.1.7 As in ICAO Doc 9880 Part II [5], implementation of content confidentiality is
not mandatory.

Edition : 2.1 Released Issue Page 37

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

5.1.8 To support content integrity, a recipient must be provided with tools to verify
that the content of a message has not been modified during the transfer
process.
5.1.9 To support message origin authentication, a recipient must be provided with
tools to confirm the identity of the sender of the received message.
5.1.10 Some security provisions are also available at the lower layers. However, this
does not provide end-to-end assurance between end users.

5.2 AMHS Security Framework

5.2.1 In the Basic ATSMHS, the security at each AMHS End System is deemed a
local issue to be addressed by the authority in charge of the system. ICAO
Doc 9880 Part II [5] recommends, in 2.2.3.1, that security in the Basic
ATSMHS be obtained by procedural means rather than by technical features
inherent to the AMHS.
5.2.2 In the Extended ATSMHS, the general AMHS security provisions aim at
protecting ATS Message exchanges against the identified threats, namely
masquerade, modification and replay.
5.2.3 The security model in ICAO Doc 9880 Part II [5] §2.2.3 is fully applicable when
AMHS Security services are implemented.
5.2.4 In the AMHS security architecture, a digital signature is transferred end-to-end
along with the message, and the format of the message being transferred is
not affected. This means that AMHS security can be added with minimal
disruption to a deployment that does not use the security features, provided
that the ATS message transfer service transparently relays the required
elements of service.
5.2.5 One possible architecture of an AMHS implementation is illustrated in Figure
9, in which the Directory service is used in support of the delivery of security
elements.
Certification Authority
• Key Generation
• Private Key Escrow
• CRL Generation

National ANSP
• Registration Authority
• Directory Service
• Public Key Delivery
AFTN/AMHS • CRL Delivery DSA
Gateway

Message Directory
DUA DSA
Transfer System
System MTA
DSA
MTA

DUA
UA

Figure 9: Global AMHS Architecture including CA

Page 38 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

5.3 Public Key Infrastructure

5.3.1 To overcome the issues associated with secure distribution of cryptographic
keys, a public key infrastructure (PKI) is assumed if AMHS Security services
are implemented. The PKI is used to distribute public keys via certificates
signed by a trusted certificate authority (CA). Each State implementing AMHS
Security needs access to a CA; the same CA may be shared by several
States.
5.3.2 When using AMHS Security functions, sending ATS Message User Agents
derive a digital signature from the message content using a private signing
key. Recipient ATS Message User Agents validate the signature using the
public key of the sender.
5.3.3 The recipient needs to know the CA’s public key in order to verify the
certificate containing the originator’s public key. Verifying the originator’s
certificate is the core function of PKI. For simple deployment with a single CA,
the originator and recipient use the same CA, and the recipient is configured
to trust certificates issued by its own CA and thus will trust the originator’s
certificate.
5.3.4 In the model where originator and recipient have different CAs, it is necessary
for CAs to cross-certify either with each other, or with a common “bridge” CA,
in order for the message recipient to be able to trust the received certificate.

Edition : 2.1 Released Issue Page 39

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

6. ADDITIONAL AMHS REQUIREMENTS

6.1 Testing and Verification

6.1.1 In order to demonstrate compliance with this EUROCONTROL Specification, a
suite of test cases with appropriate test coverage must be successfully
executed. A description of the tests could accompany the EC declaration of
conformity (DoC).
6.1.2 ICAO EUR Doc 020 [8] specifies in Appendices C through F a set of testing
requirements, conformance, interoperability and pre-operational tests, with
testing guidelines for the European Directory Service in Appendix G. Testing
procedures for SEC are yet to be developed.

Page 40 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

7. TRANSITION / COEXISTENCE ISSUES

7.1 AFTN to AMHS Transition

7.1.1 As a first step, the Basic ATSMHS can be deployed across Europe simply to
replace AFTN, in compliance with ICAO Regional requirements endorsed by
EANPG. Subsequently, it is envisaged that ANSPs will continue to implement
elements of the Extended ATSMHS.
7.1.2 As aging AFTN switches are replaced with ATS Message Servers, AFTN end
users will become AMHS indirect users, supported by the AFTN/AMHS
Gateway.
7.1.3 The ultimate goal is to phase out the AFTN terminal equipment in favour of
ATS Message User Agents. At this stage, all users will be AMHS direct users.
The AFTN/AMHS Gateways can only be decommissioned when all indirect
users connected to the switch (terminals and applications) are migrated to
AMHS. Note that such decommissioning depends also on the migration of all
communicating EATMN countries from AFTN to AMHS.
7.1.4 Systems sending and receiving AFTN messages must be considered. As long
as these systems expect AFTN formatted messages, the AFTN/AMHS
Gateways will have to remain.
7.1.5 There are a number of transition steps to achieving this end state. Timescales
for migration and transition are outside the scope of this EUROCONTROL
Specification.
7.1.6 The migration from AFTN/CIDIN to AMHS requires the development of AMHS
Operational Procedures, to ensure that transition steps are performed
smoothly and without service disruption.
7.1.7 Common facilities, and specifically the routing management function, are of
utmost importance to the performance of these AMHS Operational
Procedures. It is one of the main goals of the AMC to provide support to the
transition to AMHS.
7.1.8 AMHS procedures for migrating from AFTN to AMHS are included as
Appendix A to ICAO EUR Doc 021 [9], which defines the procedure for the
introduction of a new AMHS COM Centre in the ICAO EUR/NAT AMHS
network.
7.1.9 During transition from AFTN/CIDIN to AMHS, existing AFTN/CIDIN routes will
be "concatenated" with direct AMHS routes in AMHS Gateways at the borders
between the remaining AFTN/CIDIN and the growing AMHS islands.
7.1.10 ICAO EUR Doc 021 [9] provides guidance in this area.

7.2 Basic ATSMHS to Extended ATSMHS Transition

7.2.1 The Basic ATSMHS has been implemented as a transition step to full
Extended ATSMHS. ICAO Doc 9880 Part II [5] notes:
It is intended that the extended ATSMHS will eventually be supported by all
ATSMHS users, so that the basic ATSMHS will no longer be required.

Edition : 2.1 Released Issue Page 41

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

However, the latter may be maintained for transition purposes as long as

required.
7.2.2 Coexistence between the two levels of service is facilitated by the use of
Directory service by users of the Extended ATSMHS, to determine the
capabilities of intended message recipients.

7.3 Deployment of Directory

7.3.1 The EDS specified in Appendix G of ICAO EUR Doc 020 [8] describes how
updates to European ATS messaging configuration and addressing
information can be collected and distributed by the Central European DSA,
including transition from existing AMC procedures described in ICAO EUR
Doc 021 [9].
7.3.2 As DSAs become deployed in Europe, AMHS address and capability
information which is stored in the Directory can be distributed using the EDS.

Page 42 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

8. TRACEABILITY TO REGULATORY PROVISIONS

8.1 Implementation Conformance Statements

8.1.1 This EUROCONTROL Specification provides means of compliance to SES
regulatory material and each Annex includes a section describing relevant
conformity assessment materials. These include implementation conformance
statement (ICS) templates, which allow the level of compliance with the
specification to be recorded. In many cases, the ICS is included by reference
to other documents.
8.1.2 The ICS templates are intended to support clear statements of:
a) conformity or non-conformity with the requirements (‘shall’ items) of the
specification;
b) any reasons or mitigations in the case of declaration of non-conformity.
8.1.3 The ICS template also allows the degree of conformity with recommended
items (‘should’ statements) to be described.
8.1.4 The Annexes of this EUROCONTROL Specification provide separate ICS
templates for various functional elements of the specification. This structure
facilitates the possible future definition of additional means of compliance
(MOC) for any of the separate functional areas without impacting the other
functional areas. For example, support for alternative security algorithms or
directory schemas could be defined as requirements or technology evolve.
Each Annex therefore constitutes a “MOC element”.
8.1.5 Completed ICS can be used in support of the DoC and/or part of Technical
File accompanying the DoV.

8.2 Traceability to SES Essential Requirements

8.2.1 Essential requirements applicable to systems within the EATMN are
categorised in Annex II of the interoperability Regulation [1].
8.2.2 For the purpose of the interoperability Regulation [1], the EATMN is
subdivided into eight types of system. The systems and procedures of
greatest relevance to this EUROCONTROL Specification are identified in
Annex I of the interoperability Regulation [1] as:
• Communications systems and procedures for ground-to-ground, ( … )
communications.
8.2.3 Also relevant, insofar as they may interface to the AMHS as direct “host”
users, are:
• Systems and procedures for ATS, in particular flight data processing
systems, [and] surveillance data processing systems (…).
8.2.4 Appendix 1 provides traceability tables between the SES essential
requirements and the provisions of this EUROCONTROL Specification.

Edition : 2.1 Released Issue Page 43

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

9. DOCUMENT UPDATE PROCEDURES

9.1.1 This edition of the EUROCONTROL Specification has been updated in

accordance with the current EUROCONTROL Standards development
process. Accordingly, the update process for this EUROCONTROL
Specification is summarised in Appendix 3.

Page 44 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

10. LIST OF REFERENCES

10.1 Description of References

10.1.1 This EUROCONTROL Specification incorporates by reference a number of
specifications and standards maintained by ICAO, EUROCAE and ETSI. In
turn, these documents also reference many ISO/IEC, ITU-T and IETF
standards. A list of the referenced versions of these standards is provided for
information in Appendix 2.
10.1.2 Primary references are those referred to in the requirements of, and which
therefore constitute an integral part of, this EUROCONTROL Specification.
10.1.3 Associated references are those standards and other documents which are
referenced from recommendations or explanatory material and are therefore
not essential for implementation.

10.2 Primary References

[1] Regulation (EC) No 552/2004 of the European Parliament and of the Council
of 10 March 2004 on the interoperability of the European Air Traffic
Management network (the interoperability Regulation), OJ L 96/26, 31.3.2004,
Amended by Regulation (EC) No 1070/2009, OJ L 300/34, 14.11.2009
[2] Regulation (EU) No 910/2014 of the European Parliament and of the Council
of 23 July 2014 on Electronic Identification and Trust Services for Electronic
Transactions in the Internal Market and Repealing Directive 1999/93/EC, OJ L
257/73, 28.8.2014
[3] ICAO Convention on International Civil Aviation, Annex 10 — Aeronautical
Telecommunications, Volume II — Communication Procedures including
those with PANS status, 7th edition, incorporating Amendments 44–90 (July
2016) ISBN 978-92-9249-967-9
[4] ICAO Convention on International Civil Aviation, Annex 11 – Air Traffic
Services, 14th edition, incorporating Amendments 1–50-A (July 2016) ISBN
978-92-9249-972-3
[5] ICAO Doc. 9880-AN/466 Manual on Detailed Technical Specifications for the
Aeronautical Telecommunication Network (ATN) using ISO/OSI Standards
and Protocols, Part II – Ground-Ground Applications – Air Traffic Services
Message Handling Services (ATSMHS), Second Edition - (2016) ISBN 978-
92-9258-141-1
[6] [ATN SEC] ICAO Doc. 9705-AN/956 – Manual of Technical Provisions for the
Aeronautical Telecommunications Network (ATN) Third Edition (2002), ISBN
92-9194-003-8, Sub-Volume VIII – ATN Security. 6

6
Partially replaced by ICAO Doc 10094: Manual of the ATN Secure Dialogue Service (planned
publication 2020). See also Doc 9880 Part IV – ref [7] – which states only: “Chapter 3 - SECURITY -
(Under development by update of Doc 9705 Sub-Volume VIII)”.

Edition : 2.1 Released Issue Page 45

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[7] [ATN DIR] ICAO Doc 9880-AN/466 – Manual on Detailed Technical

Specifications for the Aeronautical Telecommunication Network (ATN) using
ISO/OSI Standards and Protocols, Part IV – Directory Services, Security and
Identifier Registration, Second Edition – (2016) ISBN 978-92-9258-143-5
[8] ICAO EUR Doc 020 EUR AMHS Manual, Version 13.0 (April
2018) https://www.icao.int/EURNAT/EUR%20and%20NAT%20Documents/Fo
rms/AllItems.aspx
[9] ICAO EUR Doc 021 ATS Messaging Management Manual, Version 12.0 (April
2016) https://www.icao.int/EURNAT/Pages/EUR-and-NAT-Document.aspx
[10] ICAO EUR Doc 022 AFS Security Guidelines, AFSG Planning Group, Version
7.0 (April 2015) https://www.icao.int/EURNAT/Pages/EUR-and-NAT-
Document.aspx
[11] EUROCAE Document ED-78A, Guidelines for Approval of the Provision and
use of Air Traffic Services supported by Data Communications, December
2000
[12] EUROCAE Document ED-111, Functional Specifications for CNS/ATM
Recording, July 2002 including Amendment 1 (30/07/2003)
[13] ETSI EG 201 057 v1.1.2 (1997-07) Telecommunications security; Trusted
Third Parties (TTP); Requirements for TTP
services. http://www.etsi.org/deliver/etsi_eg/201000_201099/201057/01.01.02
_60/eg_201057v010102p.pdf
[14] ETSI EN 319 411-2 v2.2.2 (2018-04) Electronic Signatures and
Infrastructures (ESI) Policy and security requirements for Trust Service
Providers issuing certificates: Part 2: Requirements for trust service providers
issuing EU qualified
certificates. http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.
02.02_60/en_31941102v020202p.pdf
[15] FIPS PUB 180-4 Federal Information Processing Standards Publication -
Secure Hash Standard (SHS) (August
2015) https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[16] ISO/IEC ISP 15126-1:1999 Information technology - International
Standardized Profiles FDY1n –Directory Data Definitions – Part 1: FDY11 –
Common directory use (normal) 7
[17] (reference deleted)
[18] ISO/IEC 10021-n Information technology - Message Handling Systems (MHS)
– (multi-part Standard) Edition 2 (2003) | ITU-T X.400 Series of
Recommendations (1999)
[19] ISO/IEC ISP 10611-n:2003 Information technology - International
Standardized Profiles AMH1n -- Message Handling Systems - Common
Messaging (multi-part Standard), Edition 3 (2003) 8

7
ISP Withdrawn by ISO.
8
Generic reference to the whole series of ISO/IEC ISP 10611 standardised profiles, now Withdrawn
by ISO.

Page 46 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[20] ISO/IEC ISP 12062-n:2003 Information technology - International

Standardized Profiles AMH2n - Message Handling Systems - Interpersonal
Messaging - (multi-part Standard), Edition 3 (2003) 9
[21] IETF RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework (November
2003) https://www.ietf.org/rfc/rfc3647.txt
[22] ICAO Doc 9896-AN/469 Manual for the Aeronautical Telecommunication
Network (ATN) using Internet Protocol Suite (IPS) Standards and Protocols,
2nd edition (2015) ISBN 978-92-9249-876-4

10.3 Associated References

[23] Regulation (EC) No 549/2004 of the European Parliament and of the Council
of 10 March 2004 laying down the framework for the creation of the single
European sky (the framework Regulation), OJ L 96/1, 31.3.2004, Amended by
Regulation (EC) No 1070/2009, OJ L 300/34, 14.11.2009
[24] Commission Regulation (EC) No 482/2008 of 30 May 2008 establishing a
software safety assurance system to be implemented by air navigation service
providers and amending Annex II to Regulation (EC) No 2096/2005, OJ L
141/5, 31.5.2008 10
[25] Commission Implementing Regulation (EU) No 1035/2011 of 17 October 2011
laying down common requirements for the provision of air navigation services
and amending Regulations (EC) No 482/2008 and (EU) No 691/2010 (Text
with EEA relevance) (OJ L 271, 18.10.2011, p. 23) Amended by: Commission
Implementing Regulation (EU) No 923/2012 of 26 September 2012 OJ L
281/1, 13.10.2012 and Commission Implementing Regulation (EU) No
448/2014 of 2 May 2014 OJ L 132/53, 3.5.2014 11
[26] [ATN SARPs] ICAO Convention on International Civil Aviation, Annex 10 —
Aeronautical Telecommunications, Volume III, – Communication Systems,
Second Edition – July 2007, incorporating Amendments 70-90, ISBN 978-92-
9258-278-4 , Part I – Digital Data Communication Systems, Chapter 3 –
Aeronautical Telecommunication Network (ATN).
[27] Routing Directory for COM Centres in the EUR/NAT Regions, Part I –
Documentation. Overview, Explanations, Procedures, ICAO AFSG Operations
Group http://www.eurocontrol.int/amc
[28] ICAO Register of AMHS Management
Domains https://www.icao.int/safety/acp/Pages/AMHS.aspx

9
Generic reference to the whole series of ISO/IEC ISP 12062 standardised profiles, now Withdrawn
by ISO.
10
Regulation 482/2008 remains in force until 01/01/2020; it will be repealed 02/01/2020 by
Commission Implementing Regulation (EU) 2017/373 laying down common requirements for providers
of air traffic management/air navigation services and other air traffic management network functions
and their oversight, repealing Regulation (EC) No 482/2008, Implementing Regulations (EU) No
1034/2011, (EU) No 1035/2011 and (EU) 2016/1377 and amending Regulation (EU) No 677/2011, OJ
L 62/1, 8.3.2017
11
To be repealed by Commission Implementing Regulation (EU) 2017/373 effective 02.01.2020

Edition : 2.1 Released Issue Page 47

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[29] ICAO Convention on International Civil Aviation, Annex 17 – Security, 10th

edition - April 2017 ISBN 978-92-9249-884-9
[30] (reference deleted)
[31] EUROCAE Document ED-109A, Software Integrity Assurance Considerations
for Communication and Navigation and Surveillance and Air Traffic
Management (CNS/ATM) Systems, January 2012
[32] ETSI TR 102 040 v1.3.1 (2005-03) Electronic Signatures and Infrastructures
(ESI); International Harmonization of Policy Requirements for CAs issuing
Certificates http://www.etsi.org/deliver/etsi_tr/102000_102099/102040/01.03.0
1_60/tr_102040v010301p.pdf
[33] ETSI TS 119 312 V1.2.1 (2017-05) Electronic Signatures and Infrastructures
(ESI); Cryptographic
Suites. http://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.02.01_6
0/ts_119312v010201p.pdf
[34] ISO/IEC 9594-n Information technology - Open Systems Interconnection - The
Directory, (multi-part Standard) | ITU-T X.500 Series of Recommendations 12
[35] ISO/IEC 9594-8:2017 | ITU-T Recommendation X.509 (10/2016) Information
technology - Open Systems Interconnection - The Directory – Part 8: Public-
key and attribute certificate frameworks.
[36] ISO/IEC 8825-1:2015 | ITU-T Recommendation X.690 (08/2015) Information
technology – ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
[37] (reference deleted)
[38] X/Open Technical Standard "API to Electronic Mail (X.400)" Issue 3
(1996) http://pubs.opengroup.org/onlinepubs/9693999099/toc.pdf
[39] [LDAP] IETF RFC 4510 Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map, K. Zeilenga, Ed. (June
2006) https://www.ietf.org/rfc/rfc4510.txt
[40] [SNMP] IETF RFC 3411 (STD 062) An Architecture for Describing Simple
Network Management Protocol (SNMP) Management Frameworks, D.
Harrington, R. Presuhn, B. Wijnen (December
2002) https://www.ietf.org/rfc/rfc3411.txt
[41] [OCSP] IETF RFC 2560 X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S.
Galperin, C. Adams (June 1999) https://www.ietf.org/rfc/rfc2560.txt
[42] IETF RFC 2849 The LDAP Data Interchange Format (LDIF) – Technical
Specification, G. Good (June 2000) https://www.ietf.org/rfc/rfc2849.txt
[43] NATO Standardization Agreement (STANAG) No 4406 – Military Message
Handling System (MMHS), Edition 2 (October 2006)

12
This is a generic reference to the whole series of ISO/IEC 9594 | X.500 standards. Different parts
have different versions

Page 48 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[44] (reference deleted)

[45] Roadmap on Enhanced Civil-Military CNS Interoperability and Technology
Convergence, Edition 2.0, Reference: EUROCONTROL 13/10/17-07 (October
2013)
[46] SESAR European ATM Master Plan (2015) https://www.atmmasterplan.eu/
[47] IETF RFC 2789 Mail Monitoring MIB. N. Freed, S. Kille. (March
2000) https://www.ietf.org/rfc/rfc2789.txt
[48] PKI Assessment Guidelines (PAG v1.0), Information Security Committee of
the American Bar Association (May
2003) https://www.americanbar.org/content/dam/aba/events/science_technol
ogy/2013/pki_guidelines.authcheckdam.pdf

Edition : 2.1 Released Issue Page 49

 EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL Specification for

the Air Traffic Services Message
Handling System (AMHS)
ANNEX A – Basic Service

DOCUMENT IDENTIFIER : EUROCONTROL-SPEC-0136

Edition Number : 2.1

Edition Date : 06/09/2018
Status : Released Issue
Intended for : General Public
Category : EUROCONTROL Specification
 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.

EDITION EDITION INFOCENTRE PAGES

REASON FOR CHANGE
NUMBER DATE REFERENCE AFFECTED

0.1 16/01/08 Initial outline All

0.2 25/01/08 Detail added All

0.3 26/02/08 Further evolution. Input to Drafting Group All

Further evolution. Requirements from
0.4 01/04/08 All
GESS added.
0.5 13/06/08 Draft for Review Group All
Updated and restructured after informal
0.6 24/10/08 stakeholder review. Annex A split into 2 – All
Basic & Extended
Updated after informal stakeholder review.
1.0 08/12/08 All
Input to formal consultation.
Updated after ENPRM-09/001 formal
1.1 27/07/09 All
consultation.
2.0 18/09/09 Released Issue Footers
Update references, align with ICAO &
2.1 06/09/18 ATM Master Plan. See Appendix 4 for All
details.

Page A-ii Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CONTENTS

ANNEX A - SPECIFICATION OF BASIC INTEROPERABILITY

REQUIREMENTS ................................................................................................. 1
A.1 CONFIGURATION CONTROL .................................................................................................1
A.2 REQUIREMENTS AND EXPLANATORY MATERIALS ...........................................................2
A.2.1 Common Requirements ....................................................................................................2
A.2.1.1 Standards Baseline .................................................................................................2
A.2.1.2 General Requirements ............................................................................................3
A.2.1.3 Safety Requirements ...............................................................................................3
A.2.1.4 Performance Requirements ....................................................................................5
A.2.1.5 Naming and Addressing ..........................................................................................6
A.2.1.6 Logging....................................................................................................................6
A.2.1.7 Availability, Reliability, Maintainability .....................................................................6
A.2.1.8 System Operation and Management ......................................................................7
A.2.1.9 Transitional Procedures ..........................................................................................9
A.2.2 ATS Message Server Requirements .................................................................................9
A.2.2.1 EATMN Boundary Requirements ..........................................................................10
A.2.3 ATS Message User Agent Requirements .......................................................................10
A.2.4 Message Store Requirements .........................................................................................12
A.2.5 AFTN/AMHS Gateway Requirements .............................................................................12
A.3 CONFORMITY ASSESSMENT MATERIALS .........................................................................14
A.3.1 Compliance Statement ....................................................................................................14
A.3.2 Testing Requirements .....................................................................................................17

Edition : 2.1 Released Issue Page A-iii

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

ANNEX A – SPECIFICATION OF AMHS BASIC INTEROPERABILITY

REQUIREMENTS
A.1 CONFIGURATION CONTROL
A.1.1 MOC Element Identification
MOC_Title MOC_Version MOC_Edition
AMHS_BAS_IOP 1 2

A.1.2 MOC Element Change Record

The following table records the complete history of the successive editions of MOC
specifications.

Version Edition Sections

Edition Date Reason for Change
Number Number Affected

1 1 18/09/09 Initial specification All

1 2 06/09/18 Updated references All

A.1.3 MOC Element Traceability towards Regulatory Provisions

The following table records the traceability history of regulatory provisions associated with
this MOC element.

Version Edition Implementing Validation

References of regulatory provisions
Number Number rule references date
Regulation (EC) No 552/2004 [1] Annex II
Part A and Part B (4) - Essential
1 1 N/A requirements applicable to
communications systems and procedures
for ground-to-ground communications
1 2 N/A SES interoperability Regulation [1]

A.1.4 MOC Element Traceability towards International Standards

The following table records the traceability of international standards associated with this
MOC element.

International standards References of text parts used Standards text incorporated by

identification to derive MOC specifications reference into the MOC element

ICAO Doc 9880 Part II [5] (Basic ATSMHS only)

ICAO EUR Doc 020 [8] Whole document

ICAO EUR Doc 021 [9] Whole document

Edition : 2.1 Released Issue Page A-1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

A.2 REQUIREMENTS AND EXPLANATORY MATERIALS

Note 1: This normative Annex is an integral part of this EUROCONTROL Specification. It
specifies requirements for AMHS End Systems that support the Basic ATSMHS as defined in
ICAO Doc 9880 Part II [5].
Note 2: This Annex must be read in conjunction with the Main Body of this EUROCONTROL
Specification, which provides definitions, document references and contextual information.
References given in square brackets are defined in section 10 of the Main Body.
Note 3: The Basic ATSMHS is intended as a transition step providing interoperability with
existing AFTN equipment and supporting the migration from AFTN to AMHS technology. As
such, it supports existing data flows and concepts of operation for applications based on the
interchange of ATS messages.
Note 4: The Basic ATSMHS provides only for the exchange of simple text messages,
including a formatted ATS Message Header field. It does not support new concepts of
operation requiring the general exchange of binary data or files and does not provide strong
authentication or data integrity services. Further, the Basic ATSMHS does not benefit from a
standardised directory function, which in the Extended ATSMHS can be used to enhance
seamless operation by ensuring the up-to-date dissemination of address and configuration
information.
Note 5: This Annex is structured such that requirements common to all AMHS End Systems
are specified in section A.2.1, followed by requirements specific to each AMHS End System
type. Compliance is conditional upon the type of AMHS End System under consideration
(e.g. section A.2.2 on ATS Message Server is not applicable when considering requirements
for ATS Message User Agents).

A.2.1 Common Requirements

A.2.1.1 Standards Baseline

[AMHS-BAS-A01] AMHS End Systems shall comply with the requirements identified in
ICAO EUR Doc 020 [8] unless otherwise explicitly stated in this EUROCONTROL
Specification.
[AMHS-BAS-A03] AMHS End Systems shall comply with the requirements specified in
ICAO Doc 9880 Part II [5] applicable to the Basic ATSMHS, except where explicitly stated
otherwise.
[AMHS-BAS-A04] In the event of conflicting requirements not explicitly identified, the
specification in ICAO Doc 9880 Part II [5] shall take precedence.
[AMHS-BAS-A05] Due account shall be taken of any published defect resolutions relating
to the ICAO AMHS documentation.
Note. Any outstanding defect reports and/or amendment proposals need to be analysed
when preparing an ANSP's system specification. Any that affect interoperability would be
required to be implemented in the supplied system.
[AMHS-BAS-A06] Implementations of AMHS Components shall conform to the 2003
version of the ISO/IEC MHS base standards or the 1999 version of the ITU-T equivalents
[18].
[AMHS-BAS-A06A] Although the International Standardized Profiles (ISPs) [19], [20]
referenced in ICAO Doc 9880 and ICAO EUR Doc 020 have been withdrawn and are no
longer maintained by ISO/IEC, implementations of AMHS Components shall conform to the
last published versions of the ISPs or equivalent provisions which may be published
elsewhere.

Page A-2 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note: This differs from ICAO Doc 9880 Part II [5], which refers to the 1990 MHS standards
and Edition 1 (1994/95) or later ISPs for the Basic ATSMHS, but refers to the 2003 MHS
standards and Edition 3 (2003) ISPs to define the Extended ATSMHS. The European ATS
Messaging Service Profile in Appendix B of ICAO EUR Doc 020 [8] refers only to the Edition
3 (2003) ISPs, and by implication to the 2003 ISO/IEC base standards. It provides, in
Appendix B Annex R, a mapping between the elements of 2003 ISPs to the corresponding
elements of the earlier versions.
[AMHS-BAS-A07] Compatibility with the current version of referenced standards and any
relevant corrigenda should be taken into account.

A.2.1.2 General Requirements

[AMHS-GEN-A01] The AMHS shall enable the exchange of messages between the
following types of users:
• direct AMHS user to direct AMHS user;
• direct AMHS user to indirect AMHS user;
• indirect AMHS user to direct AMHS user;
• indirect AMHS user to indirect AMHS user.
[AMHS-GEN-A02] AMHS Components shall be able to communicate using the TCP/IP
Transport Service, as specified in ICAO Doc 9880 Part II [5], section 3.2.2.2.3.
[AMHS-GEN-A03] AMHS End System implementations should follow the “Guidelines for
system requirements” in section 5 of ICAO EUR Doc 020 [8].
[AMHS-GEN-A04] Wherever possible, AMHS Component implementations should make
use of common and standardised interfaces.
Note: Such interfaces are specified in IETF RFCs or by established industry groups such as
The Open Group [38].
[AMHS-GEN-A05] Specifically, standardised interfaces where available for message
submission, transfer and delivery, system management, etc. shall be used as a means of
enhancing Interoperability between system components.
[AMHS-GEN-A06] AMHS End Systems should support by local means the object classes
and attribute types of directory information specified in ICAO EUR Doc 020 [8] Appendix B
Annex K, with a (local) mechanism to obtain such information by a UA, MTA or MTCU
component.
[AMHS-GEN-A07] AMHS End Systems shall be capable of interworking with independent
implementations of AMHS End Systems in accordance with the permissible combinations
listed in ICAO Doc 9880 Part II [5], section 1.2.
Note: Such interworking includes correct interoperation representing the services explicitly
and implicitly requested by either end user.
[AMHS-GEN-A08] AMHS End Systems supporting the Basic ATSMHS shall be designed
to accommodate the evolution to support the Extended ATSMHS, e.g. by including well-
defined interfaces and software hooks in areas where future extensions are foreseen.

A.2.1.3 Safety Requirements

Note 1: Using the methodology of EUROCAE ED-78A [11] (Guidelines for Approval of the
Provision and Use of ATS Supported by Data Communications), this EUROCONTROL
Specification can be likened to an INTEROP specification. In general, it would be

Edition : 2.1 Released Issue Page A-3

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

complemented by a detailed specification of Safety and Performance Requirements (SPR).

ANSPs will have responsibility to ensure the SPR exists for each defined service.
Note 2: The migration from AFTN/CIDIN to AMHS requires the ANSP to prepare an "AMHS
Introduction Safety Case”. It is expected that a Functional Hazard Assessment (FHA) will
have been performed. During the design, a preliminary System Safety Assessment (SSA)
will be carried out, with a final SSA after installation.
Note 3: No specific safety requirements other than the general requirements common to the
introduction of any ATS system and constituent have been identified for AMHS.
[AMHS-SAF-A01] As for any EATMN system or constituent, a safety assessment shall be
performed for the initial planned use of the ATSMHS.
[AMHS-SAF-A02] Procedures shall be put in place to ensure that a further safety
assessment is performed as and when additional end-user applications making use of the
ATSMHS are deployed.
[AMHS-SAF-A03] AMHS End Systems and operations in the EATMN shall achieve
agreed high levels of safety using established safety management and reporting
methodologies.
Note: For example, the EUROCONTROL Safety Assessment Methodology 1 and associated
tools could be employed.
[AMHS-SAF-A04] In accordance with the SES interoperability Regulation [1], a
harmonised set of safety requirements for the design, implementation, maintenance and
operation of AMHS End Systems, both for normal and degraded modes of operation, shall be
applied with a view to achieving the agreed safety levels for the entire AMHS.
Note: ANSPs have responsibility to cooperate to derive harmonised safety requirements for
each defined service supported by AMHS.
[AMHS-SAF-A05] In accordance with the SES interoperability Regulation [1], AMHS End
Systems shall be designed, built, maintained and operated, using the appropriate and
validated procedures, in such a way that the tasks assigned to the control staff are
compatible with human capabilities, in both the normal and degraded modes of operation,
and are consistent with required safety levels.
[AMHS-SAF-A06] In accordance with the SES interoperability Regulation [1], AMHS End
Systems shall be designed, built, maintained and operated using the appropriate and
validated procedures, in such a way as to be free from harmful interference in their normal
operational environment.

A.2.1.3.1 Software Assurance Level

Note. A Software Safety Assurance System complying with relevant EC/EU Regulations [24]
will deal specifically with software related aspects, including all on-line software operational
changes (such as cutover/hot swapping).
[AMHS-SAF-A07] The allocated software assurance level shall be commensurate with
the most adverse effect that software malfunctions or failures may cause, taking into account
the risks associated with software malfunctions or failures and the architectural and/or
procedural defences identified.
Note 1: The ANSP is required to ensure that software requirements specify, as appropriate:
• The functional behaviour (normal and downgraded modes) of the ATM software,
• Timing performances,

1
http://www.eurocontrol.int/articles/safety-assessment-methodology-sam

Page A-4 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

• Capacity,
• Accuracy,
• Software resource usage on the target architecture,
• Robustness to abnormal operating conditions,
• Overload tolerance.
Note 2: The assurance level required will be based on the local system safety case, together
with acceptable means of compliance, such as a reference to EUROCAE document ED-
109A [31] Guidelines for CNS/ATM Systems Software Integrity Assurance. Note that ED-
109A does not provide guidance to allocate Assurance Level. Only a part of the safety
lifecycle is considered in ED-109A and no requirements are set concerning acquisition,
supply, installation, acceptance, maintenance, operation and decommissioning phases as
required by EC/EU Regulations [24].

A.2.1.4 Performance Requirements

[AMHS-PER-A01] An operational performance assessment (OPA, as defined in
EUROCAE Document ED-78A [11]) shall be performed for the initial planned use of the
ATSMHS.
[AMHS-PER-A02] Procedures shall be put in place to ensure that a further OPA is
performed as and when additional end-user applications making use of the ATSMHS are
deployed.
[AMHS-PER-A03] The ATSMHS within the EATMN shall be such as to meet the
requirements of quality of service, coverage and redundancy as required for the supported
applications.
Note: This implies that applications using the ATSMHS must have such requirements
specified. For legacy AFTN applications migrating to AMHS, e.g. flight plan distribution, the
minimum requirement is that the existing performance is maintained.
[AMHS-PER-A04] When adding new services, the affect of the additional message traffic
on the existing traffic shall be considered.
[AMHS-PER-A05] In accordance with the SES interoperability Regulation [1], AMHS End
Systems shall be designed, built, maintained and operated using the appropriate and
validated procedures, in such a way as to achieve the required performances for a specific
application, in particular in terms of:
a) communication processing time,
b) integrity,
c) availability and
d) continuity of function.
[AMHS-PER-A06] AMHS End Systems shall be designed and dimensioned to enable the
end-to-end performance requirements for each “QoS Flow Type Class” listed in ICAO EUR
Doc 020 [8], section 3.1.4, Table 1 to be met.
Note: Testing compliance to the above requirement may require the implementation of
suitable monitoring tools to enable statistical measurements of the end-to-end performance
of the ATSMHS to be performed.
[AMHS-PER-A07] In accordance with the SES interoperability Regulation [1], AMHS End
Systems and their constituents supporting new, agreed and validated concepts of operation
shall be designed, built, maintained and operated, using appropriate and validated

Edition : 2.1 Released Issue Page A-5

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

procedures, in such a way as to be interoperable in terms of timely sharing of correct and

consistent information.
Note: Timely sharing of information is taken to mean that the user information transported by
the ATSMHS is delivered with minimal delay, consistent with the performance requirements
of the individual application. The correctness of the information can be enhanced by ensuring
the integrity of the transported information, which will be by application-specific means for
users of the Basic ATSMHS.
[AMHS-PER-A08] AMHS End Systems should be capable of supporting the peak rate
hour's performance, which corresponds to at least 20% of the daily traffic requirements for
that AMHS End System.
[AMHS-PER-A09] An AMHS End System shall comply, to the extent possible, with the
sizing recommendations specified in section 5.7 of ICAO EUR Doc 020 [8].

A.2.1.5 Naming and Addressing

Note: Naming and addressing requirements are specified in ICAO Doc 9880 Part II [5],
section 2.5.
[AMHS-N&A-A01] Operators of AMHS systems shall ensure that a unique identifier is
assigned and inserted in the ICAO Register of AMHS Management Domains [28].

A.2.1.6 Logging
[AMHS-LOG-A01] Data exchanges using the ATSMHS shall be recorded in accordance
with the following ICAO standards applicable to the ground-based recording function of data
link communications:
• Section 3.5.1.5 of ICAO Annex 10 Volume II [3];
• Section 6.2 of ICAO Annex 11 [4].
[AMHS-LOG-A02] EUROCAE ED-111 [12] shall be considered as sufficient means of
compliance of the ground-based recording function with regard to the identified ICAO
standards applicable to the ground-based recording function of ATS data communications.
[AMHS-LOG-A03] AMHS End Systems shall support the relevant requirements for traffic
logging as described in sections 2.7, 3.2.3 and 4.3.1 of ICAO Doc 9880 Part II [5].
[AMHS-LOG-A04] All operator inputs shall be recorded and traceable for a configurable
period (e.g. 30 days).
Note: Section 5.9 of ICAO EUR Doc 020 [8] provides guidelines on the statistics to be
produced for each MTA partner.

A.2.1.7 Availability, Reliability, Maintainability

[AMHS-ARM-A01] A reliability, availability and maintainability analysis shall be conducted
before entry into service and periodically thereafter to verify that AMHS End Systems satisfy
or exceed the minimum requirements in these areas.

A.2.1.7.1 Availability
[AMHS-ARM-A02] An ATS Message Server and AFTN/AMHS Gateway shall be available
24 hours per day, with availability (defined as lack of unplanned outages) of at least 99.999%
per year.
[AMHS-ARM-A03] An ATS Message User Agent shall be available as required, with
availability of at least 99.99% per year.

Page A-6 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-ARM-A04] Precise constraints for the restart time are dependent on the
configuration of the system and specific modes of failure, but for guidance a target restart
time of less than 5 minutes shall be assumed.
[AMHS-ARM-A05] Components and system modes of failure which imply a restart time of
more than 1 minute shall be identified.
[AMHS-ARM-A06] AMHS End Systems shall be designed such that processing of
messages during recovery does not overload the system or degrade the performance below
the performance targets.

A.2.1.7.2 Reliability
[AMHS-ARM-A07] AMHS End Systems shall be designed to minimise the effect of a
failure of an AMHS End System or component thereof on the function of the entire system.
Note: This requires an audit of design documentation to ensure that factors such as
redundancy of components, alternative routings, etc. have been considered.
[AMHS-ARM-A08] AMHS End Systems and their functional components shall be
designed to avoid loss of messages.

A.2.1.7.3 Maintainability
[AMHS-ARM-A09] Commercial Off-the-Shelf (COTS), industry standard software, should
be used as widely as possible, in order to enable an upward compatible growth path.
Note: Refer to EUROCAE Document ED-109A [31] Section 12.4 for the applicability of
software assurance level to COTS software.
[AMHS-ARM-A10] AMHS End System implementations should be modular in nature and
by using a series of industry standard interfaces provide a flexible and expandable
combination of communication services.

A.2.1.8 System Operation and Management

Note: An ATS Messaging Management Centre (AMC) will continue to operate as a Common
Facility for the benefit of the whole European area, to manage AMHS routing during the
transition from AFTN/CIDIN to AMHS.

A.2.1.8.1 Fault Management

[AMHS-MGT-A01] AMHS End System implementations shall support fault management in
all components.
[AMHS-MGT-A02] It should be possible to schedule the execution of diagnostic tests.
[AMHS-MGT-A03] On detection of a fault condition, depending upon the fault severity and
classification, AMHS End Systems should be configurable to perform one or more of the
following actions, in increasing order of severity:
a) Reconfigure;
b) Switch over or re-assign resources;
c) Perform software re-initialisation;
d) Perform hardware re-initialisation.
[AMHS-MGT-A04] All fault conditions and actions shall be logged and remain accessible
for a configurable period of not less than 1 month.

Edition : 2.1 Released Issue Page A-7

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-MGT-A05] The maximum period for stored events shall not be limited by the
system design, and only be constrained by management configuration or the available
resources of the specific system.
[AMHS-MGT-A06] An AMHS End System shall be able to meet its performance
requirements when generation and storage of additional information (tracing) in support of
basic failure analysis is enabled.

A.2.1.8.2 Configuration Management

[AMHS-MGT-A07] AMHS End Systems shall support the configuration management of all
components.
[AMHS-MGT-A08] Where applicable, the AMHS End System or specific component
should allow the on-line modification and activation of configuration parameters without
requiring an interruption of service.
[AMHS-MGT-A09] The configuration, maintenance and activation of new addressing and
routing information shall be possible through on-line modification without stopping the AMHS
End System or substantially impairing its performance.
[AMHS-MGT-A10] The design of an AMHS End System shall not constrain the size of the
address space or addressing and routing tables; these are only constrained by system
management configuration or available system resources.
[AMHS-MGT-A11] All modifications of the application configuration should be logged.
[AMHS-MGT-A12] AMHS End Systems should have the capability to import data
specified in the address management function of ICAO EUR Doc 021 [9].

A.2.1.8.3 Accounting Management

Note: Accounting management requires usage information to be stored and maintained in a
suitable format to enable it to be processed off-line to attribute resource usage to the
individual users for accounting purposes, financial or otherwise. No specific requirements
have been identified in this area.

A.2.1.8.4 Performance Management

[AMHS-MGT-A13] AMHS End System implementations shall support the collection and
analysis of performance management data.
[AMHS-MGT-A14] It should be possible for the collection of statistical data to be
configured, including the use of filters and the specification of collection and consolidation
intervals.
[AMHS-MGT-A16] ATS Message Server implementations shall export statistics data in
accordance with the format specified in ICAO EUR Doc 021 [9], Appendix C.
[AMHS-MGT-A17] It should be possible to configure trigger conditions to automatically
regulate and prevent processor or storage overloads.
[AMHS-MGT-A18] Statistics shall be provided for overall performance, use of overall
capacity, use of component capacity, overall availability and component availability.
[AMHS-MGT-A19] Statistical data shall be stored and accessible for a configurable period
of not less than 1 month.

Page A-8 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

A.2.1.8.5 Security Management

[AMHS-MGT-A20] AMHS End System implementations shall support security
management functions, including management of access control lists, local user
authentication and authorisation, in accordance with ICAO EUR AFS Security Guidelines
[10].
Note: In the Basic ATSMHS, these are locally managed functions independent of any
technical features inherent to the AMHS.
[AMHS-MGT-A21] Access control mechanisms shall be provided to restrict access to
system management information.
[AMHS-MGT-A22] User roles with configurable access rights should be supported.
Note: Examples of the roles and corresponding access rights that could be accommodated
include:
• Traffic Management: corrective actions, message processing, on-line modification of
routing;
• Technical Operation: all network management functions without modification of
routing;
• Supervisor: all.

A.2.1.8.6 System Monitoring Functions

[AMHS-MGT-A23] All events, occurring due to automatically triggered changes to the
AMHS End System configuration, components or subscribers as well as occurring due to
forced changes shall be indicated on-line (e.g. as system messages).

A.2.1.8.7 System Management Interface

[AMHS-MGT-A24] AMHS End System implementations shall include a systems
management interface consistent with the provisions of ICAO EUR Doc 020 [8], with suitable
access control.
[AMHS-MGT-A25] Communication between the management interface and the system
should be through the use of an SNMP [40] compatible interface, enabling interoperability
between manager and agent components (see ICAO EUR Doc 020 [8], section 5.8.5).
Note: SNMP management information bases have been developed for monitoring X.400
systems, e.g. RFC 2789 [47]. These can be used by COTS monitoring products.

A.2.1.9 Transitional Procedures

[AMHS-MGT-A26] Procedures for the introduction of ATSMHS into an international COM
Centre shall be as specified in Appendix A of ICAO EUR Doc 021, ATS Messaging
Management Manual [9].

A.2.2 ATS Message Server Requirements

Note: An ATS Message Server supporting the Basic ATSMHS includes an MTA and
optionally one or more MSs, as specified in ICAO Doc 9880 Part II [5] section 3.2.2.
[AMHS-AMS-A01] An ATS Message Server shall route, store and forward ATS
Messages, taking into account the applicable performance requirements and routing
configuration.
[AMHS-AMS-A02] An ATS Message Server shall be able to support the routing of
messages according to a non-hierarchical addressing plan, as well as the MF-Addressing
Schemes specified in ICAO Doc 9880 Part II [5] section 2.5.1.4.

Edition : 2.1 Released Issue Page A-9

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-AMS-A03] An ATS Message Server should have the capability to import data
specified in the routing management function of ICAO EUR Doc 021 [9].
[AMHS-AMS-A04] MTAs shall implement the P1 MTS transfer profile as specified in
Appendix B Annex F of ICAO EUR Doc 020 [8] (profile AMH11 plus AMHS-specific features),
for communication with other ATS Message Servers.
[AMHS-AMS-A05] MTAs shall implement the P1 IPM requirements profile as specified in
Appendix B Annex B of ICAO EUR Doc 020 [8] (profile AMH22 plus AMHS-specific features),
for IPM communication with other ATS Message Servers.
[AMHS-AMS-A06] MTAs shall support at least the minimum P1 message length specified
in Appendix B Annex F of ICAO EUR Doc 020 [8].
[AMHS-AMS-A07] The ATS Message Server should support a common and standardised
interface for the submission and delivery of messages.
[AMHS-AMS-A08] In support of the integration of an ATS Message User Agent into other
computer applications, an API for the submission and delivery of messages using Open
Group API specifications [38] may be specified.
Note 1: The logical architecture includes an "AMHS User" and a "Local Application" for
constructing and submitting messages, and for receiving messages from remote users. The
Local Application is undefined, but a well-defined interface is provided for message
submission and delivery.
Note 2: The above requirement supports the SES requirement for modularity of systems.
[AMHS-AMS-A09] MTAs shall support the Distribution List (DL) functional group.
Note: The DL+ER (Exempted Recipients) class of the DL functional group is outside the
scope of this EUROCONTROL Specification. It may be supported according to local
requirements.
[AMHS-AMS-A10] It is recommended that the ATS Message Server should have the
capability to open multiple associations between each pair of communicating MTAs (see
ICAO EUR Doc 020 [8] section 5.2 and Appendix B Annex F.2.4.1).
Note: This means that there is no guarantee that messages are transferred in their received
order, only that the start of transfer is independent of message size.
[AMHS-AMS-A11] The ATS Message Server shall use the Monologue dialogue-mode of
the Reliable Transfer Service Element (RTSE) protocol for associations between each pair of
communicating MTAs, as specified in Appendix B Annex J of ICAO EUR Doc 020 [8].

A.2.2.1 EATMN Boundary Requirements

[AMHS-AMS-A12] EATMN boundary ATS Message Servers shall additionally have the
capability to communicate with ATS Message Servers external to the EATMN, subject to
bilateral agreement.
Note: Communication with ATS Message Servers situated in countries external to the
EATMN may use any appropriate solution, for example using the connection mode transport
service of either the ATN/IPS (TCP/IP) or the ATN/OSI (TP4/CLNP), as defined in ICAO
Annex 10, Volume III, Part 1, Chapter 3 [26].

A.2.3 ATS Message User Agent Requirements

Note 1: In the AMHS architecture defined in ICAO Doc 9880 Part II [5], each direct AMHS
user is provided with an ATS Message User Agent to access the message transfer service.
ATS Message User Agents include a UA to perform submission of messages to the message
transfer service and delivery of messages from the message transfer service.

Page A-10 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note 2: The logical architecture includes an optional AMHS Message Store component for
storing, on behalf of local direct AMHS users, messages received from other users as well as
other information objects such as reports.
Note 3: The ATSMHS uses the Inter-Personal Messaging (IPM) protocol P2 for
communication between UAs. ICAO Doc 9880 Part II [5] specifies the relevant IPM Content
Type profile.
Note 4: In the Basic ATSMHS, each IPM message contains a single ia5-text or general-text
body part.
[AMHS-AMU-A01] ATS Message User Agents shall comply with the requirements
specified in section 3.1 of ICAO Doc 9880 Part II [5] for the support of the Basic ATSMHS,
summarised as the following requirements:
• A UA profile based on AMH21 as specified in Appendix B Annex A of ICAO EUR Doc
020 [8];
• The requirements of Repertoire Group A, for messages including a body part whose
type is an Extended Body Part Type of general-text-body-part type;
• Provisions related to traffic logging.
[AMHS-AMU-A02] It is recommended that standard ISO/IEC 10021 | ITU-T X.400 [18]
protocols P3 and/or P7 should be used for message submission and delivery.
Note: In the Basic ATSMHS, a UA can communicate with the MTS using P3, P7 or
proprietary access protocols, as an implementation choice local to the AMHS MD. The above
recommendation is intended to foster seamless operation and enable a smooth transition to
the Extended ATSMHS.
[AMHS-AMU-A03] The maximum message-text length supported by the UA shall be a
configurable parameter value, in accordance with Appendix B Annex A.2.3.8 of ICAO EUR
Doc 020 [8].
[AMHS-AMU-A04] A UA shall be capable of accepting and processing a maximum
received message-text length of at least 64 kByte and be capable of handling messages
longer than the maximum length without malfunction.
Note: ICAO EUR Doc 020 [8] section 5.2.1 recommends support of AFTN messages up to
64 kByte. It is a local implementation matter how to handle received messages longer than
the maximum supported message length.
[AMHS-AMU-A05] If a user application is co-located with an MTA on a common platform,
then the interface between the application's (logical) UA and the message transfer service
shall provide equivalent functionality to the MT-Access abstract service as defined for the P3
access protocol specified in ISO/IEC 10021-6 | ITU-T Recommendation X.419 [18].
Note: Some Message Server configurations may include a co-located UA or Access Unit that
provides access to remote users via protocols external to AMHS.
[AMHS-AMU-A06] If "forced" delivery to a UA is required (e.g. for reception of urgent, high
priority messages) then either the P3 protocol or (in the case of MS) P7 with Alerts
configured should be used.
[AMHS-AMU-A07] It should be possible for direct AMHS users to request confirmation of
delivery and to receive delivery reports.

Edition : 2.1 Released Issue Page A-11

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

A.2.4 Message Store Requirements

Note 1: The MS is Optional in the AMHS logical architecture. It is a local decision whether
MS functionality is required. The local options of the MS that are appropriate to the MS user’s
intended task need to be specified when procuring an ATS Message Server.
Note 2: In ICAO EUR Doc 020 [8], there is no distinction between the MS and enhanced
MS(94), since the enhancements in the MS(94) standards are of a purely local nature (i.e.
effective only between the UA and the MS and not effective on an end-to-end basis).
[AMHS-MST-A01] It is recommended that, when an MS is included in the ATS Message
Server, standard ISO/IEC 10021-6 | ITU-T Recommendation X.419 [18] protocol P3 should
be used between the MS and MTA for message submission and delivery.
Note: In the Basic ATSMHS, an MS can communicate with the MTS using P3 or proprietary
access protocols, as an implementation choice local to the AMHS MD. The above
recommendation is intended to foster seamless operation and enable a smooth transition to
the Extended ATSMHS.
[AMHS-MST-A02] It is recommended that the standard ISO/IEC 10021-6 | ITU-T
Recommendation X.419 [18] protocol P7 should be used between MS and UA for message
retrieval and indirect submission.
Note: In the Basic ATSMHS, a UA can communicate with the MS using P7 or proprietary
access protocols, as an implementation choice local to the AMHS MD. The above
recommendation is intended to foster seamless operation and enable a smooth transition to
the Extended ATSMHS.
[AMHS-MST-A03] It is recommended that the MS application context should exclude the
RTSE.
Note: This differs from ICAO EUR Doc 020 [8] Appendix B, where the inclusion and use of
RTSE is left Optional in the MS protocol stack; it is a local implementation decision whether
or not RTSE is required for message submission and retrieval. The above recommendation
is intended to foster a common approach using “lightweight” UA protocols over a robust
network service.
[AMHS-MST-A04] MS implementations shall support the Distribution List (DL) functional
group, in accordance with Appendix B of ICAO EUR Doc 020 [8].
Note: The DL Exempted Recipients class (DL+ER) is an Optional functional group in profiles
AMH13 and AMH15. It is only needed if support of dl-exempted-recipients is required in the
message submission envelope. DL is required by the P7 profile in Appendix B Annexes H
and I of ICAO EUR Doc 020 [8].
[AMHS-MST-A05] Requirements for the maximum number of MS users that can be
simultaneously supported by an MS implementation shall be based upon current and
foreseen ATSMHS usage.

A.2.5 AFTN/AMHS Gateway Requirements

Note: An AFTN/AMHS Gateway supporting the Basic ATSMHS includes an MTA and an
Access Unit (the Message Transfer and Control Unit – MTCU), as specified in ICAO Doc
9880 Part II [5] Chapter 4.
[AMHS-GWY-A01] Where interworking with AFTN end systems is required, a gateway
between the AMHS and AFTN message services shall be implemented in conformance with
ICAO Doc 9880 Part II [5] Chapter 4.

Page A-12 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-GWY-A02] An AFTN/AMHS Gateway supporting the Basic ATSMHS shall

implement all elements which are applicable to the Basic ATSMHS and which are marked as
“M” in the “ATSMHS” column of ICAO Doc 9880 Part II Table 4-3.
[AMHS-GWY-A03] The AFTN/AMHS Gateway shall support address conversion of O/R
addresses belonging to a non-hierarchical addressing plan, as well as the MF-Addressing
Schemes specified in ICAO Doc 9880 Part II [5] section 2.5.1.4.
[AMHS-GWY-A04] The AFTN/AMHS Gateway shall support address conversion and
routing for all currently assigned ICAO eight-letter addressee indicators (AF-addresses).
[AMHS-GWY-A05] The AFTN/AMHS Gateway should have the capability to import the
address mapping tables in comma-separated value (CSV) format provided by the European
ATS Messaging Management Centre (AMC).
Note: In the ICAO Doc 9880 Part II [5] specification of the AFTN/AMHS Gateway, a small
number of implementation details are left to the decision of Management Domains, i.e. of
ANSPs implementing AMHS. The most significant of these elements is related to message
splitting when leaving the AMHS, because of the increased message lengths that are
allowed in the European AFTN in support of ADEXP. To achieve sufficient flexibility in
support of these existing messaging requirements the following procedure is defined:
[AMHS-GWY-A06] If the length of the ATS-Message–Text element in an AMHS message
exceeds the maximum supported length (a parameter set initially to 64 kByte, in accordance
with current AFTN/CIDIN practices for the support of ADEXP messages), the message shall
be rejected by the AFTN/AMHS Gateway’s MTCU as specified in ICAO Doc 9880 Part II [5]
section 4.5.2.1.7 a).
Note: The above requirement modifies the specification of the AFTN/AMHS gateway in ICAO
Doc 9880 Part II [5], section 4.5.2.1.7, in that an upper limit is defined for the size of a
message that can be converted. In ICAO Doc 9880 Part II, the message size is limited only
by system resources.
[AMHS-GWY-A07] If the length of the ATS-Message-Text element in an AMHS message
exceeds 1800 characters but does not exceed the maximum supported length, the AFTN
component of the AFTN/AMHS Gateway shall handle the message using one of the following
options, depending on the AFTN/CIDIN capability of the next international COM centres
towards the destination:
a) Transfer the message without modification; or
b) Truncate the message text to 1800 characters; or
c) Perform the message splitting procedure specified in ICAO Doc 9880 Part II [5]
section 4.5.2.1.7 b).
Note: The above requirement modifies the specification of the AFTN/AMHS gateway in ICAO
Doc 9880 Part II [5], section 4.5.2.1.7, in that messages with text length between 1801
characters and the upper limit may be transferred without being split, or may be truncated.
ICAO Doc 9880 Part II specifies only that the message is split “if the procedure proposed in
Annex 10 Volume II Attachment B is applied in the AFTN/AMHS Gateway”. It does not alter
in any way current AFTN/CIDIN practices.

Edition : 2.1 Released Issue Page A-13

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

A.3 CONFORMITY ASSESSMENT MATERIALS

This section includes the profile requirements list (PRL) for the communications services
specified in Annex A. Completed conformance statements can be used in support of the DoC
and/or part of Technical File accompanying the DoV.

A.3.1 Compliance Statement

[AMHS-CA-A01] A claim of conformance for an implementation shall be supported by
completion of the relevant Protocol Implementation Conformance Statement (PICS) pro
forma.
[AMHS-CA-A02] Implementers claiming conformance to the specified services shall
complete the PICS specified in Appendix B Annex Q of ICAO EUR Doc 020 [8].
Note: For AMHS components except the AFTN/AMHS Gateway, the EUR AMHS profile
specification in [8] contains a corresponding Implementation Conformance Statement (ICS)
pro forma that is intended to document each implementation’s conformance to the Base
Standards, the referenced ISPs, the ICAO technical provisions and the corresponding EUR
Profile Annexes.
[AMHS-CA-A03] Implementers shall state whether all of the requirements and which of
the optional elements of the AFTN/AMHS Gateway supporting the Basic ATSMHS as
specified in ICAO Doc 9880 Part II [5] Chapter 4 have been implemented, using the tables in
this section, or equivalent.
Note 2: FTBP, IHE, SEC and DIR functional groups are specified as Optional in ICAO Doc
9880 (Table 3-6) for ATS Message Server and ATS Message User Agent claiming Basic
ATSMHS conformance. For an AFTN/AMHS Gateway, FTBP is not relevant; SEC could be
applicable in the AMHS-to-AFTN direction but is not currently specified. IHE and DIR could
optionally be supported.

Table A-1: Profile requirements list for AFTN/AMHS Gateway supporting the Basic
ATSMHS
PRL Ref Basic Question/Feature Doc 9880 Profile Supplier Notes
Part II Ref Req Response
Subsetting Rules 3.4
1 Classification of ATSMHS Functional Table 3-6
Groups
Which of the following functional groups are
supported?
1.1 Basic ATSMHS m Basic
1.2 Use of File Transfer Body Parts for Binary i FTBP
data exchange
1.3 Use of IPM Heading Extensions o IHE
1.4 AMHS Security i SEC
1.5 Use of Directory o DIR
Definition of ATSMHS subsets Table 3-7
2 Which of the following subsets is supported?
2.1 I. Basic ATSMHS (Basic) m
2.2 II. Basic + FTBP i Out of scope
2.3 III. Basic + IHE i Out of scope

Page A-14 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

PRL Ref Basic Question/Feature Doc 9880 Profile Supplier Notes

Part II Ref Req Response
2.4 IV. Basic + DIR i Out of scope
2.5 V. Basic + DIR + FTBP i Out of scope
2.6 VI. Basic + DIR + IHE i Out of scope
2.7 VII. Basic + DIR + SEC i Out of scope
2.8 VIII. Basic + IHE + DIR + SEC i Out of scope
2.9 IX. Basic + IHE + DIR + FTBP i Out of scope
2.10 X. Basic + IHE + DIR + FTBP + SEC i Out of scope
3 Message Transfer and Control Unit
3.1 Conversion of AFTN Acknowledgement 4.4.3
Messages
3.1.1 Is the case of the user element of the IPM- 4.4.3.3.3.1 o
identifier modified when constructing a RN?
3.2 AMHS IPM Conversion 4.5.2
3.2.1 Is conversion from ISO 8859-1 to IA5IRV 4.5.2.1.4 a) o
supported? 4)
3.2.1.2 Can the conversion be modified to o
support locally defined conversion rules?
3.2.2 If recipient names cannot be translated into 4.5.2.2.8
an AF-Address how many non-delivery
reports are generated?
3.2.2.1 One report for each failure c.a One of these
options shall be
3.2.2.2 A single report c.a
supported
3.2.4 For ATS-Message-Text length >1800 -
characters:
3.2.4.1 Is the maximum ATS-Message-Text length m
limited by parameter setting?
3.2.4.1.1 What is the range of values for the maximum - Default 64 kB
message length parameter?
3.2.4.2 Can a “long” AFTN message of the same c.b
length be generated by the MTCU?
At least one of
3.2.4.3 Can an AFTN message truncated to 1800 c.b these options
characters be generated by the MTCU? shall be
supported
3.2.4.4 Is the message splitting procedure in Annex c.b
10 Volume II Attachment B supported?
3.3 Generation of AMHS reports 4.5.6
3.3.1 Is a single non-delivery report generated on 4.5.6.1.2 o
the rejection for multiple recipients?
3.3.2 Is a single delivery report generated for 4.5.6.1.4 o
multiple recipients?
3.3.3 Is the case of the global-domain-identifier 4.5.6.2.11.1 o
element of the MTS-identifier modified when
constructing a report?
3.3.4 Is the Return Of Content (RoC) Functional 4.5.6.2.16.1 o
Group implemented in the MTCU?
c.a, c.b: At least one must be supported

Note: ICAO Doc 9880 Part II expresses the functional requirements of the AFTN/AMHS
Gateway component using tabular profile requirement lists which apply at the abstract

Edition : 2.1 Released Issue Page A-15

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

service boundary between the ATN Component (MTA) and the MTCU of the AFTN/AMHS
Gateway, as shown in Figure A-1.

AFTN/AMHS Gateway

Message Transfer
and Control Unit
(AU)

Abstract
Service
Boundary

ATN
AFTN
Component
Component
(MTA)

Figure A-1: MTCU and ATN Component Abstract Service Boundary

[AMHS-CA-A04] For AFTN/AMHS Gateway implementations, a PICS shall be provided
stating the level of support, for each of the elements relevant to support of the Basic
ATSMHS, listed in the profile requirements lists in Chapter 4 of ICAO Doc 9880 Part II [5]
and specified in Table A-2.
Table A-2: MTCU Profile Requirements for the Basic ATSMHS
Reference in Description
ICAO Doc 9880
Part II
Table 4-3 Specifies the required and optional elements for the generation of an IPM when
converting a received AFTN message to AMHS. The column headed “ATSMHS”
in the referenced Table specifies the static capability requirements of an IPM AU
supporting the ATSMHS. Elements marked with an asterisk (*) are not
applicable and elements marked as “C1” are optional for AFTN/AMHS Gateway
implementations supporting the Basic ATSMHS level of service.
Table 4-4 Specifies the required and optional elements for the generation of a message
transfer envelope when converting from AFTN to AMHS. The column headed
“ATSMHS” in the referenced Table specifies the static capability requirements of
an IPM AU supporting the ATSMHS. Elements marked with an asterisk (*) are
not applicable for AFTN/AMHS Gateway implementations supporting the Basic
ATSMHS level of service.
Table 4-6 Specifies the required and optional elements for the generation of an AMHS
Receipt Notification resulting from the receipt of an AFTN acknowledgement
message. The column headed “Basic ATSMHS” in the referenced Table
specifies the static capability requirements of an IPM AU supporting the Basic
ATSMHS.

Page A-16 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Reference in Description
ICAO Doc 9880
Part II
Table 4-7 Specifies the required elements for the generation of a message transfer
envelope for an AMHS Receipt Notification resulting from the receipt of an
AFTN acknowledgement message. The column headed “Basic ATSMHS” in the
referenced Table specifies the static capability requirements of an IPM AU
supporting the Basic ATSMHS.
Table 4-9 Specifies the required and optional elements for the generation of an AFTN
message when converting from AMHS. The column headed “Basic ATSMHS
support” in the referenced Table specifies the static capability requirements of
an IPM AU supporting the ATSMHS. Elements marked with an asterisk (*) are
not applicable for AFTN/AMHS Gateway implementations supporting the Basic
ATSMHS level of service.
Table 4-10 Specifies the required support of elements in a received message transfer
envelope when converting from AMHS to AFTN. The column headed “Basic
ATSMHS” in the referenced Table specifies the static capability requirements of
an AU in relation to the message transfer elements of service.
Table 4-12 Specifies the required support of elements in a received AMHS Receipt
Notification when converting to an AFTN acknowledgement message. The
column headed “Basic ATSMHS” in the referenced Table specifies the static
capability requirements of an IPM AU supporting the Basic ATSMHS.
Table 4-13 Specifies the required support of elements in a message transfer envelope
received with an AMHS Receipt Notification when converting to AFTN. The
column headed “Basic ATSMHS” in the referenced Table specifies the static
capability requirements of an AU in relation to the message transfer elements of
service.
Table 4-15 Specifies the required support of elements in a received AMHS Report when
converting to an AFTN service message. The column headed “Basic ATSMHS”
in the referenced Table specifies the static capability requirements of an IPM AU
supporting the Basic ATSMHS.
Table 4-16 Specifies the required support of elements when generating an AMHS Report.
The column headed “Basic ATSMHS” in the referenced Table specifies the
static capability requirements of an AU supporting the Basic ATSMHS.

A.3.2 Testing Requirements

[AMHS-CA-A05] AMHS End Systems shall be tested according to suitable test cases
and procedures ensuring adequate coverage of the BASIC functional group.
Note: Suitable test cases are specified in Appendices C to F of ICAO EUR Doc 020 [8].
[AMHS-CA-A06] Testing shall be conducted within a common framework consistent
with the procedures in ICAO EUR Doc 020 [8] using appropriate test tools and procedures.
Note 1: As part of the assessment of the conformity or suitability for use of constituents
required by the interoperability Regulation, the manufacturer is responsible for: determining
the appropriate test environment, verifying that there exists a test plan providing full coverage
of applicable requirements, ensuring the consistency and quality of the technical
documentation and the test plan, performing the inspections and tests as specified in the test
plan and writing the report presenting the results of inspections and tests.
Note 2: As part of the verification of systems required by the interoperability Regulation, the
ANSP or Notified Body is responsible for: verifying that there exists a test plan providing full

Edition : 2.1 Released Issue Page A-17

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

coverage of the interoperability and performance requirements, ensuring the consistency and
quality of the technical documentation and the test plan, performing the inspections and tests
as specified in the test plan and writing the report presenting the results of inspections and
tests.

Page A-18 Released Issue Edition : 2.1

 EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL Specification for

the Air Traffic Services Message
Handling System (AMHS)
ANNEX B – Extended Service

DOCUMENT IDENTIFIER: EUROCONTROL-SPEC-0136

Edition Number : 2.1

Edition Date : 06/09/2018
Status : Released Issue
Intended for : General Public
Category : EUROCONTROL Specification
 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.

EDITION EDITION INFOCENTRE PAGES

REASON FOR CHANGE
NUMBER DATE REFERENCE AFFECTED
Created after informal stakeholder review
0.6 24/10/08 from split of previous Annex A into 2 parts All
– Basic & Extended ATSMHS
Updated after informal stakeholder review.
1.0 08/12/08 All
Input to formal consultation.
Updated after ENPRM-09/001 formal
1.1 27/07/09 All
consultation.
2.0 18/09/09 Released Issue Footers
Update references, align with ICAO &
2.1 06/09/18 ATM Master Plan. See Appendix 4 for All
details.

Page B-ii Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CONTENTS

ANNEX B - SPECIFICATION OF EXTENDED INTEROPERABILITY

REQUIREMENTS ................................................................................................. 1
B.1 CONFIGURATION CONTROL .................................................................................................1
B.2 REQUIREMENTS AND EXPLANATORY MATERIALS ...........................................................2
B.2.1 Common Requirements ....................................................................................................2
B.2.1.1 Standards Baseline .................................................................................................2
B.2.1.2 General Requirements ............................................................................................2
B.2.1.3 Naming and Addressing ..........................................................................................3
B.2.1.4 Safety Requirements ...............................................................................................3
B.2.1.5 Performance Requirements ....................................................................................3
B.2.2 ATS Message Server Requirements .................................................................................3
B.2.2.1 General....................................................................................................................3
B.2.2.2 P1 Message Transfer ..............................................................................................3
B.2.2.3 P3 Message Access ................................................................................................4
B.2.2.4 Directory Access .....................................................................................................4
B.2.3 ATS Message User Agent Requirements .........................................................................5
B.2.3.1 General....................................................................................................................5
B.2.3.2 IPM Content ............................................................................................................5
B.2.3.3 P3 Access ...............................................................................................................6
B.2.3.4 P7 Access ...............................................................................................................7
B.2.3.5 Directory Access .....................................................................................................8
B.2.4 Message Store Requirements ...........................................................................................8
B.2.4.1 General....................................................................................................................8
B.2.4.2 MS Access to MTA ..................................................................................................8
B.2.4.3 P7 Access ...............................................................................................................9
B.2.5 AFTN/AMHS Gateway Requirements .............................................................................10
B.2.5.1 General..................................................................................................................10
B.2.5.2 Directory Access ...................................................................................................10
B.3 CONFORMITY ASSESSMENT MATERIALS .........................................................................11
B.3.1 Compliance Statement ....................................................................................................11
B.3.2 Testing Requirements .....................................................................................................15

Edition : 2.1 Released Issue Page B-iii

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

ANNEX B – SPECIFICATION OF AMHS EXTENDED

INTEROPERABILITY REQUIREMENTS
B.1 CONFIGURATION CONTROL
B.1.1 MOC Element Identification
MOC_Title MOC_Version MOC_Edition
AMHS_EXT_IOP 1 2

B.1.2 MOC Element Change Record

The following table records the complete history of the successive editions of MOC
specifications.

Version Edition Sections

Edition Date Reason for Change
Number Number Affected

1 1 18/09/09 Initial specification All

1 2 06/09/18 Updated references All

B.1.3 MOC Element Traceability towards Regulatory Provisions

The following table records the traceability history of regulatory provisions associated with
this MOC element.

Version Edition Implementing Validation

References of regulatory provisions
Number Number rule references date
Regulation (EC) No 552/2004 [1] Annex II
Part A and Part B (4) - Essential
1 1 N/A requirements applicable to
communications systems and procedures
for ground-to-ground communications
1 2 N/A SES interoperability Regulation [1]

B.1.4 MOC Element Traceability towards International Standards

The following table records the traceability of international standards associated with this
MOC element.

International standards References of text parts used Standards text incorporated by

identification to derive MOC specifications reference into the MOC element

ICAO Doc 9880 Part II [5] (Extended ATSMHS)

ICAO EUR Doc 020 [8] Appendix B

Edition : 2.1 Released Issue Page B-1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

B.2 REQUIREMENTS AND EXPLANATORY MATERIALS

Note 1: This normative Annex is an integral part of this EUROCONTROL Specification. It
specifies requirements for AMHS End Systems that support the Extended ATSMHS as
defined in ICAO Doc 9880 Part II [5].
Note 2: This Annex must be read in conjunction with the Main Body of this EUROCONTROL
Specification, which provides definitions, document references and contextual information.
References given in square brackets are defined in section 10 of the Main Body. Reference
is also made to Annex A of this EUROCONTROL Specification for the definition of the Basic
ATSMHS, and to Annex C for DUA details.
Note 3: The Extended ATSMHS is functionally a superset of the Basic ATSMHS, and is
backward compatible with it, in that the ability to downgrade to the Basic ATSMHS level of
service is required. AMHS End Systems claiming compliance with the requirements in this
Annex must also be compliant with the requirements in Annex A.
Note 4: The Extended ATSMHS satisfies the SES essential requirement to support new
concepts of operation by providing for the general exchange of binary data or files and, if the
AMHS SEC functional group is implemented, enabling strong authentication and data
integrity services between peer direct AMHS users. (Note that the use of AMHS Security is
not included, nor needed for compliance with this Annex). Seamless operation between a
direct AMHS user and an ATS Message Server is achieved through the specification of a
standard profile for the access protocol. Further, the Extended ATSMHS benefits from a
standardised directory function, which can be used to enhance seamless operation by
ensuring the up-to-date dissemination of address and configuration information.
Note 5: This Annex is structured such that requirements common to all AMHS End Systems
supporting the Extended ATSMHS are specified in section B.2.1, followed by requirements
specific to each AMHS End System type. Compliance is conditional upon the type of AMHS
End System under consideration (e.g. section B.2.2 on ATS Message Server is not
applicable when considering requirements for ATS Message User Agents).

B.2.1 Common Requirements

B.2.1.1 Standards Baseline

[AMHS-BAS-B01] AMHS End Systems shall comply with the standards identified in
Annex A of this EUROCONTROL Specification unless stated otherwise.
[AMHS-BAS-B02] AMHS End Systems conforming to this Annex shall comply with the
requirements specified in ICAO Doc 9880 Part II [5], including those requirements specific to
the support of the Extended ATSMHS, unless explicitly stated otherwise in this Annex.
[AMHS-BAS-B03] In the event of conflicting requirements not explicitly identified, the
specification in ICAO Doc 9880 Part II [5] shall take precedence.

B.2.1.2 General Requirements

[AMHS-GEN-B01] ATS Message Servers and ATS Message User Agents shall conform
to configuration IX as defined in ICAO Doc 9880 Part II [5] section 3.4 (i.e. functional groups
Basic + IHE + DIR + FTBP).
Note: Migration to configuration X (addition of AMHS functional group SEC) may be foreseen
at some time in the future, but is not currently required for compliance with this
EUROCONTROL Specification.

Page B-2 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-GEN-B02] AMHS End Systems shall support the object classes and attribute
types of directory information specified in ICAO EUR Doc 020 [8] Appendix B Annex K.
[AMHS-GEN-B03] In accordance with the SES interoperability Regulation [1], AMHS End
Systems shall support the implementation of advanced, agreed and validated concepts of
operation by providing managed access to the messaging system for new end-user
applications via well-defined interfaces.
Note: The basic recommendation for the use of standardised interfaces wherever possible
also applies to AMHS components supporting the Extended ATSMHS. However, it is noted
that the Open Group APIs are not fully compliant with extended service requirements such
as support for the Business Class (BC) functional group, so some customisation may be
necessary.

B.2.1.3 Naming and Addressing

[AMHS-N&A-B01] The responsible operators of AMHS Management Domains shall
register a unique directory name for each AMHS user in their domain.

B.2.1.4 Safety Requirements

Note: There are no additional safety requirements specified in this Annex. The safety
requirements specified in Annex A are fully applicable to elements of the Extended ATSMHS.

B.2.1.5 Performance Requirements

Note: There are no additional performance requirements specified in this Annex. The
performance requirements specified in Annex A are fully applicable to elements of the
Extended ATSMHS. However, it should be noted that the use of binary attachments will tend
to result in larger message sizes. Unless the number of messages with file transfer body
parts is very small, there will be an impact on performance. Also, the use of security will
increase the submission time and also the time to open a message.

B.2.2 ATS Message Server Requirements

B.2.2.1 General
Note: An ATS Message Server supporting the Extended ATSMHS includes an MTA, a DUA
and optionally one or more MSs, as specified in ICAO Doc 9880 Part II [5] sections 3.2.4 and
3.2.5.

B.2.2.2 P1 Message Transfer

[AMHS-AMS-B01] MTAs shall implement the P1 MTS transfer profile AMH11 as specified
in Annex A of this EUROCONTROL Specification, with the addition of support of the DIR
Functional Group as specified in ICAO Doc 9880 Part II [5], section 3.2.4.2.
[AMHS-AMS-B02] MTAs should implement the SEC Functional Group of the P1 IPM
requirements profile AMH22, for security class S0, in addition to the AMH22 requirements
specified in Annex A of this EUROCONTROL Specification.
Note 1: The above recommendation differs from ICAO Doc 9880 Part II, which does not
explicitly state support for the SEC FG in profiles AMH11 and AMH22, but implicitly
mandates such support for the Extended ATSMHS. MTA support of the SEC functional
group for P1 is specified as Optional for the EUR AMHS Profile in Appendix B Annex B
(AMH22) and Annex F (AMH11) of ICAO EUR Doc 020 [8].
Note 2: Implementation of the SEC Functional Group of profile AMH22 also implies
implementation of the SEC Functional Group of profile AMH11; AMH22 does not add any
IPM-specific requirements.

Edition : 2.1 Released Issue Page B-3

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note 3: Support of the SEC(S0) FG of profile AMH11 means that MTAs support and use
initiator-credentials and responder-credentials fields in the MTABind operation for simple
authentication (strong authentication may optionally be bilaterally agreed). It means support
(but not necessarily use) of the Message Token extension data type, including the signed-
data element.

B.2.2.3 P3 Message Access

[AMHS-AMS-B03] MTAs supporting direct message submission and delivery shall
support P3 access conforming to the profile in Appendix B Annex G of ICAO EUR Doc 020
[8].
Note: The referenced profile requires conformance to MHS Profile AMH12 and optionally
also allows support of MHS Profile AMH14. It requires support of the DL functional group and
the file transfer encoded information type.
[AMHS-AMS-B04] MTAs supporting direct message submission and delivery shall
support IPM P3 access conforming to the profile in Appendix B Annex C of ICAO EUR
Doc 020 [8], with the addition of support of the DIR Functional Group as specified in ICAO
Doc 9880 Part II [5], section 3.1.4.3.1.
Note: The referenced profile requires conformance to MHS Profiles AMH23 and AMH25. It
requires support of the DL functional group.
[AMHS-AMS-B05] MTAs should additionally implement the SEC Functional Group of the
IPM P3 Access profile AMH23/AMH25, for security class S0.
Note 1: The above recommendation, if followed, enables authentication between MTAs and
their users and provides forward compatibility for secure messaging. ICAO Doc 9880 Part II
states that SEC(S0) support is required for the Extended ATSMHS, but also implies that
such support is conditional upon the ATSMHS SEC functional group. MTA support of the
SEC functional group for P3 is specified as optional for the EUR AMHS Profile in Appendix B
Annex C (AMH23/AMH25) and Annex G (AMH12/AMH14) of ICAO EUR Doc 020 [8].
Note 2: Implementation of the SEC Functional Group of profile AMH23/AMH25 also implies
implementation of the SEC Functional Group of profile AMH12/AMH14, with the addition of
support for certificates in the IPM message submission and delivery envelopes.
Note 3: Implementation of the SEC(S0) FG of profile AMH12/AMH14 means that MTAs
support and use initiator-credentials and responder-credentials fields in the MTSBind
operation for simple authentication (strong authentication may optionally be bilaterally
agreed). It also means support (but not necessarily use) of the SubmissionControl element
and the Message Token extension data type, including the signed-data element. Security
related fields in submission and delivery envelopes are minimally supported, i.e. relayed
transparently between MTA and MTS-user.

B.2.2.4 Directory Access

[AMHS-AMS-B06] An ATS Message Server implementing the DIR functional group shall
include a DUA for access to the ATN Directory.
Note 1: Annex C of this EUROCONTROL Specification specifies DUA requirements.
Note 2: ICAO Doc 9880 Part II [5] notes that an MTA may access a directory service using a
DUA. The interface between the MTA and the DUA is a local matter. The minimum
information that is required to be capable of being returned by the directory service is an
attribute containing one or more OR-addresses. A supplementary class of the DIR Functional
Group, DIR+SEC adds the requirement for the User Certificates and Supported Algorithms
attributes, and the Certificate Match matching-rule. The use of a directory service to support
distribution list processing is defined in the DL+DIR class of the DL FG, and requires support

Page B-4 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

for the MHS Distribution List object-class and for the MHS DL Members, MHS DL Policy and
MHS DL Submit Permissions attributes. Support of the supplementary class DIR+ROUT to
support MHS Routing is not required for AMHS implementation.

B.2.3 ATS Message User Agent Requirements

B.2.3.1 General
Note 1: An ATS Message User Agent supporting the Extended ATSMHS includes an IPM UA
and a DUA, as specified in ICAO Doc 9880 Part II [5] sections 3.1.2 to 3.1.5.
Note 2: The UA in the Extended ATSMHS supports the P3 protocol to access the MTA in an
ATS Message Server and/or the P7 protocol to access the MS in an ATS Message Server,
where available.
Note 3: In the Extended ATSMHS, each IPM message may contain a combination of ia5text,
general text and file transfer body parts. Use of the Bilaterally Defined body part type is
prohibited for sending, though it must be supported for reception for backwards compatibility
– see ICAO Doc 9880 Part II [5] paragraph 3.1.4.2.3.
[AMHS-AMU-B01] An ATS Message User Agent supporting the Extended ATSMHS shall
comply with the requirements specified in section 3.1 of ICAO Doc 9880 Part II [5] for the
support of the Extended ATSMHS, summarised as the following requirements;
• A UA profile based on Profile AMH21 as specified in Appendix B Annex A of ICAO
EUR Doc 020 [8];
• The requirements of Repertoire Group A, for messages including a body part whose
type is an Extended Body Part Type of general-text-body-part type;
• Support of the IPM Business Class (BC) functional group
• Support of the file-transfer body part;
• UA access profile based on Profiles AMH23 or AMH25 for P3 access to the MTS, or
based on Profiles AMH24 or AMH26 for P7 access to the MS, as specified in
Appendix B Annexes C, D and E of ICAO EUR Doc 020 [8];
• The additional provisions relating to parameters generated at an ATS Message User
Agent, as specified for the Extended ATSMHS;
• Provisions related to traffic logging.
• A DUA profile supporting the defined access profile and the specified object classes
and attribute types.

B.2.3.2 IPM Content

[AMHS-AMU-B02] A UA in an ATS Message User Agent supporting the Extended
ATSMHS shall conform to the profile in Appendix B Annex A of ICAO EUR Doc 020 [8].
Note: The referenced profile requires conformance to MHS Profile AMH21. It requires
support of the file transfer encoded information type.
[AMHS-AMU-B03] A UA in an ATS Message User Agent shall be prohibited from sending
messages containing a Bilaterally Defined body part.
[AMHS-AMU-B04] A UA shall additionally implement the elements of the BC Functional
Group of the IPM Content profile AMH21 indicated as “m” in the “Support” column of Table
B-1, as specified in ICAO Doc 9880 Part II [5], section 3.1.4.2.1.
Note 1: This requirement differs from Appendix B Annex A of ICAO EUR Doc 020 [8], where
UA support of the BC functional group is specified as Optional.

Edition : 2.1 Released Issue Page B-5

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note 2: The support requirements for the BC functional group are indicated in the following
table, which modifies the requirements of profile AMH21 in Appendix B Annex A of ICAO
EUR Doc 020 [8] and extends Table 3-2 in ICAO Doc 9880 Part II [5]. Elements indicated as
“o” in the “Support” column of Table B-1 are not required for AMHS.
Note 3: A sending UA needs to ensure that all message recipients also support the BC
functional group. This could be achieved by Directory lookup.
[AMHS-AMU-B05] The values of the precedence field in the per-recipient heading fields of
a message shall be the same for all recipients, as this field corresponds to AFTN Priority.
Table B-1: IPM Business Class (BC) support requirements
Ref Element AMH21 Support
Originator Recipient Originator Recipient.
IPM heading fields
17.6 authorization-time m m m m
17.7 circulation-list-recipients m m o o
17.8 distribution-codes m m o o
17.10 information-category m m o o
17.11 manual-handling-instructions m m o o
17.12 originators-reference m m m m
17.13 precedence-policy-identifier m m m m
Common data types
A.1.5/1.4.2 circulation-list-indicator m o
A.1.5/1.4.3 precedence m m m m

Note: UA support of the IPM Security (SEC) functional group is also specified as Optional in
Appendix B Annex A of ICAO EUR Doc 020 [8]. However, support of IPM-specific security
features SEC-n is not required, nor is it specified in ICAO Doc 9880 Part II. Instead, any
security functionality is provided by the Common Messaging security class S0; there are no
additional requirements for a UA in an IPM environment.

B.2.3.3 P3 Access
[AMHS-AMU-B06] A UA supporting P3 access shall conform to the profile in Appendix B
Annex G of ICAO EUR Doc 020 [8].
Note: The referenced profile requires conformance to MHS Profile AMH12 and optionally
also allows support of MHS Profile AMH14. It requires support of the DL functional group and
the file transfer encoded information type.
[AMHS-AMU-B07] A UA supporting P3 access shall conform to the profile in Appendix B
Annex C of ICAO EUR Doc 020 [8], with the addition of support of the DIR Functional Group
as specified in ICAO Doc 9880 Part II [5], section 3.1.4.3.1.
Note 1: The referenced profile requires conformance to MHS Profiles AMH23 and/or AMH25.
It requires support of the DL functional group.
Note 2: Unlike the P7 Access profiles AMH24/AMH26, the P3 Access profiles
AMH23/AMH25 do not specify a BC Functional Group. Instead, the optional BC Functional
Group is inherited from the IPM Content profile AMH21, as specified above.
[AMHS-AMU-B08] It is recommended that a UA supporting P3 access should conform to
the MTS Access profile AMH23.

Page B-6 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note: The above recommendation is to promote interoperability and support seamless

operation. The above recommendation also implies conformance to the AMH12 MTS Access
profile.
[AMHS-AMU-B09] A UA should additionally implement the SEC Functional Group of the
P3 Access profile AMH12/AMH14, for security class S0.
Note 1: The above recommendation, if followed, enables authentication between ATS
Message User Agent and ATS Message Server, and provides forward compatibility for
secure messaging. ICAO Doc 9880 Part II states that SEC(S0) support is required for the
Extended ATSMHS, but also implies that such support is conditional upon the ATSMHS SEC
functional group. UA support of the SEC functional group for P3 is specified as optional for
the EUR AMHS Profile in Appendix B Annex C and Annex G of ICAO EUR Doc 020 [8].
Note 2: Profiles AMH23/AMH25, which specify IPM requirements for P3 access, contain
additional requirements for IPM Security, with additional security classes “SECn” (compared
with “Sn” used in Common Messaging profiles). However, the Extended ATSMHS does not
require IPM-specific Security functionality, only the Common Messaging SEC(S0) FG.
Note 3: Implementation of the SEC(S0) FG means that the UA supports and uses initiator-
credentials and responder-credentials fields in the MTSBind operation for simple
authentication (strong authentication may optionally be bilaterally agreed). It also means
support (but not necessarily use) of the SubmissionControl element and the Message Token
extension data type, including the signed-data element. Security related fields in submission
and delivery envelopes are minimally supported, i.e. relayed transparently between MTA and
UA.

B.2.3.4 P7 Access
[AMHS-AMU-B10] A UA supporting P7 access shall conform to the profile in Appendix B
Annex H, or Appendix B Annex I of ICAO EUR Doc 020 [8].
Note: The referenced profile requires conformance to MHS Profile AMH13 or AMH15. It
requires support of the optional DL functional group and the file transfer encoded information
type. DL is only needed if dl-exempted-recipients is supported in the message submission
envelope.
[AMHS-AMU-B11] A UA supporting P7 access shall conform to the profile in Appendix B
Annex D, or Appendix B Annex E of ICAO EUR Doc 020 [8], with the addition of support of
the DIR Functional Group as specified in ICAO Doc 9880 Part II [5], section 3.1.4.3.1.
Note: The referenced profile requires conformance to MHS Profile AMH24 or AMH26. It
requires support of the DL functional group and the file transfer body part type.
[AMHS-AMU-B12] It is recommended that a UA supporting P7 access should conform to
the Enhanced MS Access profile AMH24.
Note: The above recommendation is made to promote interoperability and support seamless
operation. The above recommendation also implies conformance to the AMH13 MS Access
profile.
[AMHS-AMU-B13] A UA supporting P7 access should additionally implement the SEC
Functional Group of the IPM P7 Access profile AMH24/AMH26, for security class S0 (only).
Note 1: The above recommendation, if followed, enables authentication between ATS
Message User Agent and ATS Message Server and provides forward compatibility for secure
messaging. ICAO Doc 9880 Part II states that SEC(S0) support is required for the Extended
ATSMHS, but also implies that such support is conditional upon the ATSMHS SEC functional
group. UA support of the SEC functional group for P7 is specified as optional for the EUR
AMHS Profile in Appendix B Annexes H, I, D and E of ICAO EUR Doc 020 [8].

Edition : 2.1 Released Issue Page B-7

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note 2: Implementation of the SEC Functional Group of profile AMH24/AMH26 also implies
implementation of the SEC Functional Group of profile AMH13/AMH15.
Note 3: Basic conformance to AMH13 and/or AMH15 means that the UA supports and uses
initiator-credentials and responder-credentials fields in the MSBind operation for simple
authentication (strong authentication may optionally be bilaterally agreed). Conformance to
the SEC Functional Group of profile AMH13/AMH15 requires support (but not necessarily
use) of security fields in the message submission envelope, including the Message Token.
[AMHS-AMU-B14] A UA supporting P7 access shall additionally implement the BC
Functional Group of the IPM P7 Access profile AMH24/AMH26 as specified in ICAO Doc
9880 Part II [5], section 3.1.4.3.1, for the IPM heading fields indicated as “m” in Table B-1.

B.2.3.5 Directory Access

[AMHS-AMU-B15] An ATS Message User Agent implementing the DIR functional group
shall include a DUA for access to the ATN Directory.
Note 1: Annex C of this EUROCONTROL Specification specifies DUA requirements.
Note 2: A directory may be used directly by MHS users to obtain information to assist in the
submission of messages. However, such use is not necessarily MHS-specific and is
therefore not within scope. For a UA, support of the DIR FG only requires the ability to submit
a message with one or more OR-names specified using a directory name (DN). In addition,
the UA is able to make use of a DN to identify itself. Whether or not the UA also has the
capability to access a directory directly is outside the scope of the MHS standards.

B.2.4 Message Store Requirements

B.2.4.1 General
Note: The MS is an optional functional object in the AMHS logical architecture. For an MS in
an ATS Message Server supporting the Extended ATSMHS, the access profiles are
prescribed in ICAO Doc 9880 Part II [5].

B.2.4.2 MS Access to MTA

[AMHS-MST-B01] An MS which supports P3 access in an ATS Message Server
supporting the Extended ATSMHS shall conform to the profile in Appendix B Annex G of
ICAO EUR Doc 020 [8].
Note: The referenced profile requires conformance to MHS Profile AMH12 and optionally
also allows support of MHS Profile AMH14. It requires support of the DL functional group and
the file transfer encoded information type.
[AMHS-MST-B02] An MS which supports P3 access in an ATS Message Server
supporting the Extended ATSMHS shall conform to the profile in Appendix B Annex C of
ICAO EUR Doc 020 [8], with the addition of support of the DIR Functional Group as specified
in ICAO Doc 9880 Part II [5], section 3.2.4.4.
Note: The referenced profile requires conformance to MHS Profiles AMH23 and/or AMH25. It
requires support of the DL functional group.
[AMHS-MST-B03] It is recommended that an MS supporting P3 access should conform to
the MTS Access profile AMH23.
Note: The above recommendation is made to promote interoperability and support seamless
operation. The above recommendation also implies conformance to the AMH12 MTS Access
profile.

Page B-8 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-MST-B04] An MS which supports P3 access should additionally implement the

SEC Functional Group of the IPM P3 Access profile AMH23/AMH25, for security class S0.
Note 1: MS support of the SEC functional group for P3 is specified as optional for the EUR
AMHS Profile in Appendix B Annex C and Annex G of ICAO EUR Doc 020 [8].
Note 2: Implementation of the SEC Functional Group of profile AMH23/AMH25 also implies
implementation of the SEC Functional Group of profile AMH12/AMH14, with the addition of
support for certificates in the IPM message submission and delivery envelopes.
Note 3: The above recommendation means that the MS supports and uses initiator-
credentials and responder-credentials fields in the MTSBind operation for simple
authentication (strong authentication may optionally be bilaterally agreed). It also
recommends support (but not necessarily use) of the SubmissionControl element and the
Message Token extension data type, including the signed-data element. Security related
fields in submission and delivery envelopes are minimally supported, i.e. relayed
transparently between MTA and MTS-user.
[AMHS-MST-B05] An MS which accesses the MTA by local means shall provide
equivalent message submission and delivery functionality to that specified in the P3 access
profile above.
Note: Use of P3 is optional for an MS, and the MS-MTA interface would not normally be
visible. However, the MS still needs to support the message submission and delivery
information objects as used in the P3 abstract service.

B.2.4.3 P7 Access
[AMHS-MST-B06] An MS in an ATS Message Server supporting the Extended ATSMHS
shall conform to the P7 access profile in Appendix B Annex H, or Appendix B Annex I of
ICAO EUR Doc 020 [8] for message retrieval and indirect submission.
Note: The referenced profile requires conformance to MHS Profile AMH13 or AMH15. It
requires support of the optional DL functional group and the file transfer encoded information
type. DL is only needed if dl-exempted-recipients is supported in the message submission
envelope.
[AMHS-MST-B07] An MS in an ATS Message Server supporting the Extended ATSMHS
shall conform to the profile in Appendix B Annex D, or Appendix B Annex E of ICAO EUR
Doc 020 [8], with the addition of support of the DIR Functional Group as specified in ICAO
Doc 9880 Part II [5], section 3.1.4.3.1.
Note: The referenced profile requires conformance to MHS Profile AMH24 or AMH26. It
requires support of the DL functional group and the file transfer body part type. The choice
between AMH24 and AMH26 depends on the functionality of the associated UA.
Conformance to AMH24 implies conformance to AMH13. Conformance to AMH26 implies
conformance to AMH15.
[AMHS-MST-B08] An MS in an ATS Message Server supporting the Extended ATSMHS
should additionally implement the SEC Functional Group of the IPM P7 Access profile
AMH24/AMH26, for security class S0 (only).
Note 1: MS support of the SEC functional group for P7 is specified as optional for the EUR
AMHS Profile in Appendix B Annexes H, I, D and E of ICAO EUR Doc 020 [8].
Note 2: Implementation of the SEC Functional Group of profile AMH24/AMH26 also implies
implementation of the SEC Functional Group of profile AMH13/AMH15.
Note 3: Basic conformance to AMH13 and/or AMH15 means that the MS supports and uses
initiator-credentials and responder-credentials fields in the MSBind operation for simple
authentication (strong authentication may optionally be bilaterally agreed). Conformance to

Edition : 2.1 Released Issue Page B-9

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

the SEC Functional Group of profile AMH13/AMH15 requires support (but not necessarily
use) of security fields in the message submission envelope, including the Message Token.
[AMHS-MST-B09] An MS in an ATS Message Server supporting the Extended ATSMHS
shall additionally implement the BC Functional Group of the IPM P7 Access profile
AMH24/AMH26 as specified in ICAO Doc 9880 Part II [5], section 3.1.4.3.1 for the IPM
heading fields indicated as “m” in Table B-1.

B.2.5 AFTN/AMHS Gateway Requirements

B.2.5.1 General
Note: An AFTN/AMHS Gateway supporting the Extended ATSMHS includes an MTA, a DUA
and an Access Unit (the Message Transfer and Control Unit – MTCU), as specified in ICAO
Doc 9880 Part II [5] Chapter 4.

B.2.5.2 Directory Access

[AMHS-GWY-B01] An AFTN/AMHS Gateway implementing the DIR functional group shall
include a DUA for access to the ATN Directory.
Note: Annex C of this EUROCONTROL Specification specifies DUA requirements.
[AMHS-GWY-B02] It is recommended that the DUA in an AFTN/AMHS Gateway
supporting the Extended ATSMHS should be used to retrieve information in support of
address and content conversion.
Note: The retrieval of directory information can be used by the MTCU to facilitate address
conversion. The MTCU also requires further information on the level of service supported by
the intended AMHS recipients.

Page B-10 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

B.3 CONFORMITY ASSESSMENT MATERIALS

This section includes the profile requirements list (PRL) for the communications services
specified in Annex B. Completed conformance statements can be used in support of the DoC
and/or part of Technical File accompanying the DoV.

B.3.1 Compliance Statement

[AMHS-CA-B01] A claim of conformance for an implementation shall be supported by
completion of the relevant Protocol Implementation Conformance Statement (PICS) pro
forma.
[AMHS-CA-B02] Implementers claiming conformance to the specified services shall
complete the PICS specified in Appendix B Annex Q of ICAO EUR Doc 020 [8], taking due
account of the specific requirements for implementations of AMHS End Systems supporting
the Extended ATSMHS specified in this Annex of the EUROCONTROL Specification.
Note: For each AMHS system component the EUR AMHS profile specification in [8] contains
a corresponding Implementation Conformance Statement (ICS) pro forma that is intended to
document each implementation’s conformance to the Base Standards, the referenced ISPs,
the ICAO technical provisions and the corresponding EUR Profile Annexes.
[AMHS-CA-B03] Implementers shall state whether all of the requirements and which of
the optional elements of the AFTN/AMHS Gateway supporting the Extended ATSMHS as
specified in ICAO Doc 9880 Part II [5] Chapter 4 have been implemented, using the tables in
this section or equivalent.

Table B-2: Profile requirements list for AFTN/AMHS Gateway supporting the Extended
ATSMHS
PRL Ref Question Doc 9880 Profile Supplier Notes
Extended Part II Ref Req Response
Subsetting Rules 3.4
1 Classification of ATSMHS Functional Table 3-6
Groups
Which of the following functional groups are
supported?
1.1 Basic ATSMHS m Basic
1.2 Use of File Transfer Body Parts for Binary m FTBP
data exchange
1.3 Use of IPM Heading Extensions m IHE
1.4 AMHS Security o SEC
1.5 Use of Directory m DIR
Definition of ATSMHS subsets Table 3-7
2 Which of the following subsets is supported?
2.1 I. Basic ATSMHS (Basic) m
2.2 II. Basic + FTBP i
2.3 III. Basic + IHE i
2.4 IV. Basic + DIR i
2.5 V. Basic + DIR + FTBP i
2.6 VI. Basic + DIR + IHE i
2.7 VII. Basic + DIR + SEC i

Edition : 2.1 Released Issue Page B-11

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

PRL Ref Question Doc 9880 Profile Supplier Notes

Extended Part II Ref Req Response
2.8 VIII. Basic + IHE + DIR + SEC i
2.9 IX. Basic + IHE + DIR + FTBP m
2.10 X. Basic + IHE + DIR + FTBP + SEC o
ATN Component 4.2.2
3 Which of the following MHS optional 4.2.2.4
functional groups are implemented?
3.1 Conversion (CV) o
3.2 Distribution List (DL) m
3.3 Physical Delivery (PD) o
3.4 Redirection (RED) o
3.5 Latest Delivery (LD) o
3.6 Return of Contents (RoC) o
3.7 Security (SEC) Class: o
3.7.1 S0 m
3.7.2 S1 x
3.7.3 S2 x
3.7.4 SnC x
3.8 Use of Directory (DIR) m
3.9 84 Interworking (84IW) x
3.10 If RED is implemented, does the ATN 4.2.2.4 o
Component redirect messages and probes in
the event that the MTCU is unable to accept
them?
3.11 If DL is implemented, does the ATN 4.2.2.8
Component interface with the DUA
component for DL-expansion?
Message Transfer and Control Unit 4.2.3
4 Does the MTCU interface with the gateway 4.2.3.10 o For the retrieval
DUA component? of address
information for
the purpose of
address
conversion
Conversion of AFTN Acknowledgement 4.4.3
Messages
5 Is the case of the user element of the IPM- 4.4.3.3.3.1 o
identifier modified when constructing a RN?
AMHS IPM Conversion 4.5.2
6 Is conversion from ISO 8859-1 to IA5IRV 4.5.2.1.4 a) o
supported? 4)
7 Can the conversion be modified to support o
locally defined conversion rules?
8 If recipient names cannot be translated into 4.5.2.2.8
an AF-Address how many non-delivery
reports are generated?
8.1 One report for each failure c.a One of these
options shall be
8.2 A single report c.a
supported

Page B-12 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

PRL Ref Question Doc 9880 Profile Supplier Notes

Extended Part II Ref Req Response
Generation of AMHS reports 4.5.6
9 Is a single non-delivery report generated on 4.5.6.1.2 o
the rejection for multiple recipients?
10 Is a single delivery report generated for 4.5.6.1.4 o
multiple recipients?
11 Is the case of the global-domain-identifier 4.5.6.2.11.1 o
element of the MTS-identifier modified when
constructing a report?
12 Is the Return Of Content (RoC) Functional 4.5.6.2.16.1 o
Group implemented in the MTCU?
AFTN/AMHS Gateway Control Position 4.2.6
13 Does the Control Position interface to the 4.2.6.4 o To allow the
DUA component? Control Position
access to the
ATN Directory
DUA Component 4.2.7
14 Is the DUA Component used to retrieve 4.2.7.3 o To support
information from the ATN Directory? address
conversion
c.a: At least one must be supported

Note: ICAO Doc 9880 Part II expresses the functional requirements of the AFTN/AMHS
Gateway component using tabular profile requirement lists which apply at the abstract
service boundary between the ATN Component (MTA) and the MTCU of the AFTN/AMHS
Gateway, as shown in Figure B-1.

AFTN/AMHS Gateway

Message Transfer
and Control Unit
(AU)

Abstract
Service
Boundary

ATN
AFTN
Component
Component
(MTA)

Figure B-1: MTCU and ATN Component Abstract Service Boundary

[AMHS-CA-B04] For AFTN/AMHS Gateway implementations, a PICS shall be provided
stating the level of support, for each of the elements relevant to support of the Extended
ATSMHS, listed in the profile requirements lists in Chapter 4 of ICAO Doc 9880 Part II [5]
and specified in Table B-3.

Edition : 2.1 Released Issue Page B-13

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Table B-3: MTCU Profile Requirements for the Extended ATSMHS

Reference in Description
ICAO Doc 9880
Part II
Table 4-3 Specifies the required and optional elements for the generation of an IPM when
converting a received AFTN message to AMHS. The column headed “ATSMHS”
in the referenced Table specifies the static capability requirements of an IPM AU
supporting the ATSMHS. Elements marked with an asterisk (*) are applicable
and elements marked as “C1” are mandatory for AFTN/AMHS Gateway
implementations supporting the Extended ATSMHS level of service.
Table 4-4 Specifies the required and optional elements for the generation of a message
transfer envelope when converting from AFTN to AMHS. The column headed
“ATSMHS” in the referenced Table specifies the static capability requirements of
an IPM AU supporting the ATSMHS. Elements marked with an asterisk (*) are
applicable for AFTN/AMHS Gateway implementations supporting the Extended
ATSMHS level of service.
Table 4-6 Specifies the required and optional elements for the generation of an AMHS
Receipt Notification resulting from the receipt of an AFTN acknowledgement
message. The column headed “Basic ATSMHS” in the referenced Table
specifies the static capability requirements of an IPM AU.
Table 4-7 Specifies the required elements for the generation of a message transfer
envelope for an AMHS Receipt Notification resulting from the receipt of an
AFTN acknowledgement message. The column headed “Basic ATSMHS” in the
referenced Table specifies the static capability requirements of an IPM AU.
Table 4-9 Specifies the required and optional elements for the generation of an AFTN
message when converting from AMHS. The column headed “Basic ATSMHS
support” in the referenced Table specifies the static capability requirements of
an IPM AU supporting the ATSMHS. Elements marked with an asterisk (*) are
applicable for AFTN/AMHS Gateway implementations supporting the Extended
ATSMHS level of service.
Table 4-10 Specifies the required support of elements in a received message transfer
envelope when converting from AMHS to AFTN. The column headed “Basic
ATSMHS” in the referenced Table specifies the static capability requirements of
an AU in relation to the message transfer elements of service.
Table 4-12 Specifies the required support of elements in a received AMHS Receipt
Notification when converting to an AFTN acknowledgement message. The
column headed “Basic ATSMHS” in the referenced Table specifies the static
capability requirements of an IPM AU.
Table 4-13 Specifies the required support of elements in a message transfer envelope
received with an AMHS Receipt Notification when converting to AFTN. The
column headed “Basic ATSMHS” in the referenced Table specifies the static
capability requirements of an AU in relation to the message transfer elements of
service.
Table 4-15 Specifies the required support of elements in a received AMHS Report when
converting to an AFTN service message. The column headed “Basic ATSMHS”
in the referenced Table specifies the static capability requirements of an IPM
AU.
Table 4-16 Specifies the required support of elements when generating an AMHS Report.
The column headed “Basic ATSMHS” in the referenced Table specifies the
static capability requirements of an AU.

Page B-14 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

B.3.2 Testing Requirements

[AMHS-CA-B05] AMHS End Systems supporting the Extended ATSMHS shall be tested
according to suitable test cases and procedures ensuring adequate coverage of the IHE,
FTBP and DIR functional groups.
[AMHS-CA-B06] Testing shall be conducted within a common framework consistent
with the procedures in ICAO EUR Doc 020 [8] using appropriate test tools and procedures.

Edition : 2.1 Released Issue Page B-15

 EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL Specification for

the Air Traffic Services Message
Handling System (AMHS)
ANNEX C - Directory

DOCUMENT IDENTIFIER : EUROCONTROL-SPEC-0136

Edition Number : 2.1

Edition Date : 06/09/2018
Status : Released Issue
Intended for : General Public
Category : EUROCONTROL Specification
 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.

EDITION EDITION INFOCENTRE PAGES

REASON FOR CHANGE
NUMBER DATE REFERENCE AFFECTED

0.1 16/01/08 Initial outline All

0.2 25/01/08 Detail added All

0.3 26/02/08 Further evolution. Input to Drafting Group All

Further evolution. Comments from drafting
0.4 01/04/08 All
group 29/02/08.
0.5 13/06/08 Draft for Review Group All
Updated after informal stakeholder review.
0.6 24/10/08 All
Was previously Annex B.
Updated after informal stakeholder review.
1.0 08/12/08 All
Input to formal consultation.
Updated after ENPRM-09/001 formal
1.1 27/07/09 All
consultation.
2.0 18/09/09 Released Issue Footers
Update references, align with ICAO &
2.1 06/09/18 ATM Master Plan. See Appendix 4 for All
details.

Page C-ii Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CONTENTS

ANNEX C - DIRECTORY REQUIREMENTS .............................................................. 1

C.1. CONFIGURATION CONTROL ....................................................................... 1

C.2. REQUIREMENTS AND EXPLANATORY MATERIALS ................................ 2

C.2.1 General Directory Requirements ..............................................................................................2
C.2.1.1 Architecture .......................................................................................................................2
C.2.1.2 Directory User Agent access .............................................................................................3
C.2.1.3 Directory Contents Access Policy .....................................................................................3
C.2.2 AMHS-Specific Directory Requirements ...................................................................................4
C.2.2.1 Directory Functions in support of AMHS ...........................................................................4
C.2.2.2 Directory Information in support of AMHS .........................................................................6
C.2.2.3 Simple AMHS Address Conversion Directory Algorithm ...................................................6
C.2.3 Directory support of PKI ............................................................................................................7
C.2.4 System capacity and performance............................................................................................8

C.3. CONFORMITY ASSESSMENT MATERIALS ................................................ 9

C.3.1 Object Class Requirements ......................................................................................................9
C.3.2 Attribute Requirements ...........................................................................................................10
C.3.3 List of X.500 Global Statement and Protocol Operations Supported by the Directory
Service ....................................................................................................................................12
C.3.4 Requirements Statement for DUAs .........................................................................................13
C.3.5 Requirements Statement for DSAs .........................................................................................15
C.3.6 Requirements Statement for Conformance by a Shadow Supplier ........................................17
C.3.7 Requirements Statement for Conformance by a Shadow Consumer .....................................18

Edition : :2.1 Released Issue Page C-iii

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

ANNEX C – DIRECTORY REQUIREMENTS

C.1. CONFIGURATION CONTROL

C.1.1 MOC Element Identification

MOC_Name MOC_Version MOC_Edition
AMHS_DIR 1 2

C.1.2 MOC Element Change Record

The following table records the complete history of the successive editions of MOC
specifications.

Version Edition Sections

Edition Date Reason for Change
Number Number Affected

1 1 18/09/09 Initial specification All

1 2 06/09/18 Updated references All

C.1.3 MOC Element Traceability towards Regulatory Provisions

The following table records the traceability history of regulatory provisions associated with
this MOC element.

Implementing
Version Edition Validation
rule References of regulatory provisions
Number Number date
references
Regulation (EC) No 552/2004 [1] Annex II
Part A and Part B (4) - Essential
1 1 N/A requirements applicable to 22/10/08
communications systems and procedures
for ground-to-ground communications

1 2 N/A SES interoperability Regulation [1]

C.1.4 MOC Element Traceability towards International Standards

The following table records the traceability of international standards associated with this
MOC element.

International standards References of text parts used References of text parts

identification to draft MOC specifications imported into the MOC

ICAO Doc 9880 Part II [5] Functional group DIR

ICAO Doc 9880 Part IV
Whole document
Chapter 2 [7]
ICAO EUR Doc 020 [8] Appendix G

Edition : :2.1 Released Issue Page C-1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

C.2. REQUIREMENTS AND EXPLANATORY MATERIALS

Note 1: This normative Annex is an integral part of this EUROCONTROL Specification. It

specifies requirements for the use of Directory service by AMHS. The scope of this Annex is:
a) to define the basis of a general directory service that could be used to share
information generally in the EATMN (section C.2.1);
b) to define specific requirements for the use of the directory service to support AMHS
(section C.2.2);
c) to define specific requirements for the use of the directory service to support the
public key infrastructure (PKI) to support AMHS security service (section C.2.3), if
required.
Note 2: This Annex must be read in conjunction with the Main Body of this EUROCONTROL
Specification, which provides definitions, document references and contextual information.
References given in square brackets are defined in section 10 of the Main Body.

C.2.1 General Directory Requirements

Note 1: This section describes the generic/common part of the directory service to be used in
support of the Extended ATSMHS, but that may also be used by other ATM services outside
of the scope of this EUROCONTROL Specification.
Note 2: The Directory system consists of one or more Directory System Agents (DSAs),
accessed from Directory User Agents (DUAs) via an access protocol. The Directory Access
Protocol (DAP) is required by ICAO. Where multiple DSAs cooperate to provide a distributed
directory service, the Directory System Protocol (DSP) can be used to support chaining
(passing a query to another DSA when it cannot be resolved locally) and referrals (returning
a reference to another DSA when a query cannot be resolved locally). The Directory
Information Shadowing Protocol (DISP) may be used to replicate shared parts of the
Directory Information Tree (DIT) between DSAs.
Note 3: ICAO EUR Doc 020 [8] includes requirements for a European Directory Service
(EDS), in which a Central European DSA shares information with DSAs operated by
participating States or Organisations. The EDS defines a workflow concept supporting
incremental versions of pre-operational and operational shared data.
[AMHS-DIR-C01] AMHS End Systems supporting the DIR functional group shall include
access to directory information as specified in the schema defined in ICAO Doc 9880 Part IV
Chapter 2 [7].
[AMHS-DIR-C02] The directory functionality shall comply with the standards referenced
from ICAO Doc 9880 Part IV Chapter 2 [7].
Note: These ICAO provisions are in turn based on ISO/IEC 9594 [34] standards, which are
technically aligned with ITU-T X.500 Recommendations.
[AMHS-DIR-C03] Directory protocols shall operate over the TCP transport service as
specified in ICAO Doc 9880 Part IV Chapter 2 [7], section 2.5.7.6.

C.2.1.1 Architecture
Note: This section describes a directory architecture for the EATMN and details requirements
met by the directory systems in order to guarantee interoperability and data sharing.
[AMHS-DIR-C04] In order to guarantee the consistency of the shared part(s) of the DIT,
it shall be ensured that each DSA:
a) has a common view of the schema for the shared data,

Page C-2 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

b) supports a common means of directory replication and/or chaining / referral of

queries,
c) does not require any modification of the data replicated from other DSAs.
[AMHS-DIR-C05] The DSA shall implement DSP to support the exchange of data with
other DSAs.
[AMHS-DIR-C06] The DSA should implement DISP including support for incremental
and full shadow updates, supplier and consumer initiated, scheduled and on-change
updates, attribute filtering and chop shadowing.
Note: For DSAs participating in the EDS described in ICAO EUR Doc 020 [8] Appendix G
and using DISP, the co-operating or adjacent DSA always acts in the consumer role.
[AMHS-DIR-C07] The DSA shall support the bind operation using as a minimum simple
authentication for DAP, DSP and DISP as defined in the base standards.
[AMHS-DIR-C08] The DSA should additionally support the bind operation using strong
authentication for DAP, DSP and DISP as defined in the base standards.
[AMHS-DIR-C09] The Directory service implementation shall allow additional directory
object classes and attributes to be included in order to allow the use of this service by other
applications within the scope of other private or EATMN directory service deployment.
[AMHS-DIR-C10] The DSA shall have the ability to export and import directory
information in Lightweight Directory Access Protocol Interchange Format (LDIF) format,
where applicable.
Note: This is required to enable simple uploads of directory information (e.g. the Initial Step
of EDS deployment described in ICAO EUR Doc 020 [8] Appendix G). LDIF is a standard
plain text data interchange format for representing LDAP (Lightweight Directory Access
Protocol) directory content and update requests. It is specified in RFC 2849 [42].

C.2.1.2 Directory User Agent access

Note: This section describes characteristics of the directory to support DUAs.
[AMHS-DIR-C11] The DSA shall implement DAP to support user access to the directory
information.
Note: The above is the minimum requirement for standardised access to the ATN Directory.
It does not preclude the implementation of additional access mechanisms in individual cases.
[AMHS-DIR-C12] The DSA may also implement other access protocols based on LDAP
[39] or a proprietary protocol to support user access to the directory information.
[AMHS-DIR-C13] If DAP or LDAP is implemented by the DUA, the use of “referral”
identifying a DSA external to the EATMN should be strictly controlled.
Note: It may be required to prevent a DUA from one country requiring direct access to a DSA
in a foreign country. The EDS specified in ICAO EUR Doc 020 [8] discourages the use of
referral.

C.2.1.3 Directory Contents Access Policy

Note: This section describes the need for defining different directory content access policies,
e.g. public information (shared with other States/Organisations), and different privacy groups
of users for internal directory data.
[AMHS-DIR-C14] It shall be possible to define access control policy in order to regulate
what type of operation can be performed on a directory entry, attributes or values.

Edition : :2.1 Released Issue Page C-3

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-DIR-C15] The basic operations listed in Table C-1 shall be supported by DSAs
and selectively by DUAs depending upon the type of DUA as defined in Table 2-18 of ICAO
Doc 9880 Part IV Chapter 2 [7].
Table C-1: Directory Access Operations

Operation Description
Read Retrieve the information contained in an entry, as specified by its
Distinguished Name;
Compare Compare a user-supplied attribute value against one held in an entry, as
specified by its Distinguished Name;
List List the subordinate entries of an entry, as specified by its Distinguished
Name;
Search Search through all the subordinate entries of an entry, as specified by its
Distinguished Name, returning those entries which match specified
criteria;
Add Entry Add a new entry to the Directory Information Base, specifying the new
entry's name and contents;
Remove Entry Delete an entry from the Directory Information Base, as specified by its
Distinguished Name;
Modify Entry Modify the contents of a Directory entry, as specified by its Distinguished
Name, specifying the desired modifications;
Modify DN Change the Relative Distinguished Name (RDN) of an entry, as specified
by its Distinguished name, or move it to a new superior in the DIT, or
both.

C.2.2 AMHS-Specific Directory Requirements

Note: This section describes directory service requirements linked to AMHS.

C.2.2.1 Directory Functions in support of AMHS

[AMHS-DIR-C16] The Directory implementation shall support the following functions:
a) Name resolution: This function consists of converting the O/R-name of an AMHS
user that takes the form of a Directory-name into the O/R-address of this AMHS user.
This function is used to perform message-submission and probe-submission
procedures when the O/R-Name of the message or the recipient-Name of the probe
only contains the directory name. This will ultimately include support of name
resolution for addresses from other domains;
b) Distribution list (DL) expansion and management: An MTA can manage the
distribution lists it hosts by means of directory information. The members and
characteristics of the DL stored in the directory are used at the moment of DL-
expansion;
c) Determination of recipient (direct/indirect UA or DL) capabilities: this function
consists of retrieving information about an intended recipient, identified by a directory
name, prior to message submission/transfer. Such information could include, for
example, maximum deliverable message length, support for Extended ATSMHS, etc.
This information can be used to determine if delivery of a message to the intended
recipients is possible or not.
d) AFTN/AMHS address conversion and publication: This function provides
information in support of conversion of an AFTN address into an O/R-address and
vice-versa, as required by an AFTN/AMHS gateway. The same information is also
useful for message generation;

Page C-4 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-DIR-C17] The Directory implementation should additionally support the following

function, if required:
e) Retrieval of security certificates and CRLs; This function is used by ATS Message
User Agents and AFTN/AMHS Gateways implementing AMHS Security at the
moment of verification of the ATN signature. This function consists of storing public
key information of AMHS users in the form of user certificate and certificate
revocation list (CRL).
[AMHS-DIR-C18] The Directory implementation may additionally support one or more of
the following functions:
f) Support for system configuration: this function consists of storing the configuration
of AMHS components (MTA, MTCU, UA) in order to allow maintenance via the
directory. This function is not specified in ICAO Doc 9880 Part IV Chapter 2, but is
sometimes implemented in directory systems associated with message handling.
g) AMHS systems management information: ICAO Doc 9880 Part IV Chapter 2 [7]
includes a number of object classes and attribute types that provide systems
management information. This function is specified in ICAO technical provisions, but
rarely implemented by X.500 product providers.
h) Address book: this function allows definition of a set of “regular recipients” that can
be used by multiple users at a single location. This function is not specified in ICAO
Doc 9880 Part IV Chapter 2, but is commonly implemented in directory systems.
Note 1: Some of the above functions do not need to use data imported from other Directory
Management Domains (DMDs): “Address book” and “Support for system configuration”.
These functions do not require common structure definitions shared between directories, and
their implementation can be a local matter. While not concerned with technical
interoperability between systems, a common set of functions will aid interoperability in the
wider, procedural sense.
Note 2: The “AMHS systems management information” function uses data imported from
other DMDs, but this function is not mandatory for the correct functioning of AMHS
communications.
[AMHS-DIR-C19] AMHS End System support of the directory functions shall be as
indicated in Table C-2.
Table C-2: Directory functions per AMHS End System type
ATS ATS
AFTN/AMHS
Directory functions Message Message
Gateway
User Agent Server
Name resolution yes yes yes
Distribution list (DL) expansion and
yes yes
management
Determination of recipient capabilities yes yes yes
AFTN/AMHS address conversion and
optionally yes
publication
Retrieval of security certificates and CRLs optionally optionally
AMHS systems management information
(*)
Address book optionally

Edition : :2.1 Released Issue Page C-5

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

ATS ATS
AFTN/AMHS
Directory functions Message Message
Gateway
User Agent Server
Support for system configuration (MTA,
optionally optionally optionally
Gateway)
(*) The AMHS systems management information function should only be used by AMHS
operators for “monitor” operations.

C.2.2.2 Directory Information in support of AMHS

Note: This section defines the data sub tree exported/imported by participating DMDs in
order to support the directory functions useful for AMHS: Name resolution, DL expansion and
management, Determination of recipient capabilities, AFTN/AMHS address conversion and
publication, Retrieval of security certificates and CRLs.
[AMHS-DIR-C20] The Directory information tree exported by Border DSAs shall conform
to the DIT structure defined in ICAO Doc 9880 Part IV Chapter 2 [7], unless otherwise stated
in this section.
Note: The object classes defined in ICAO Doc 9880 Part IV Chapter 2 [7] are used to support
several air-ground and ground-ground ATN applications. For AMHS support, the directory
does not need to implement all of the information objects defined in the ICAO specification.
The minimum required subset of these objects and attributes is specified in sections C.3.1
and C.3.2 below.
[AMHS-DIR-C22] It is recommended that only the eds-amhs-user object class, as
specified in Annex G-B of ICAO EUR Doc 020 [8], should be used to represent users which
have the capability to send/receive AMHS messages to/from other ATSMHS users.
[AMHS-DIR-C23] It is recommended that the exported / imported sub-trees should be
attached to the country root DIT.
[AMHS-DIR-C24] The DSA shall use this DIT structure to support the name resolution
function, using object-classes specified in Annex G-B of ICAO EUR Doc 020 [8].
[AMHS-DIR-C25] The DSA shall use this DIT structure to support the DL expansion and
management function, with MTAs accessing members of the atn-amhs-distribution-list
object-class.
[AMHS-DIR-C26] The DSA shall use this DIT structure to support the AFTN/AMHS
address conversion function performed by the AFTN/AMHS Gateway using object classes
specified in Annex G-B of ICAO EUR Doc 020 [8].
[AMHS-DIR-C27] [Requirement deleted]
[AMHS-DIR-C28] [Requirement deleted]

C.2.2.3 Simple AMHS Address Conversion Directory Algorithm

[AMHS-DIR-C29] Each State or organisation participating in the EDS shall implement a
DSA containing a DIT sub tree shadowed from the Central European DSA based on a
member of the organization object-class named O=European-Directory, as specified in
Appendix G-B of ICAO EUR Doc 020 [8].
Note: the MD-registry sub tree starting with a member of the organization object-class named
O=ICAO-MD-Registry and containing atn-amhsMD objects is contained within this sub tree.
[AMHS-DIR-C30] The Directory information shall support address conversion between
AMHS and AFTN address types.

Page C-6 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Note: For performance reasons, it is assumed that MTCU implementations will maintain a
local address conversion storage capability. This may be populated by caching addresses
obtained via the DUA, by replication of DIT subtrees, or by other means.
[AMHS-DIR-C31] An O/R Address (MF-Address) included in an AMHS message shall be
processed for translation into the AFTN address in one of four mutually exclusive manners,
depending on the MF-Address format, after preliminary conversion of all address attribute
values to upper case characters:
a) Look up the MF-Address in the local address storage maintained in the
MTCU. If an exact match is found, then extract the corresponding AF-
Address, if present. In case information for a given user cannot be
found, then an on-line query can be activated to retrieve information
from the distributed ATN directory.
b) if a) cannot be achieved, and the MF-Address to be converted is a
CAAS-compliant address including a syntactically valid AF-Address as
a common-name value, then:
1) Extract the AF-Address found as the common-name value, and
2) Perform a consistency check by re-converting this AF-Address
as specified in [AMHS-DIR-C32] and comparing this with the
MF-Address being converted. In case of discrepancy, log the
error and report to a control position; or
c) if a) cannot be achieved, and the MF-Address to be converted is an
XF-Address including an organizational-unit-names value which is a
syntactically valid AF-Address, then:
1) Extract the AF-Address found as organizational-unit-names
value, and
2) Perform a consistency check by re-converting this AF-Address
as specified in [AMHS-DIR-C32] and comparing this with the
MF-Address being converted. In case of discrepancy, log the
error and report to a control position; or
d) if none of the conditions in a), b) and c) can be met, notify the failure to
translate the MF-Address.
[AMHS-DIR-C32] For AFTN to AMHS address conversion, the algorithm described in
Appendix G-B, section 5.1 of ICAO EUR Doc 020 [8] shall be supported.
[AMHS-DIR-C33] States supporting the CAAS scheme within the EATMN should register
values of the "Organization Name" field with length not exceeding 8 characters.
Note: The above recommendation is for backwards compatibility with a previous version of
the defined ATN Directory schema. The atn-FacilityName attribute (of the atn-organization
object) is used by the AFTN/AMHS address translation algorithm to construct the field
"Organization Name" of an AMHS O/R-address for CAAS countries.

C.2.3 Directory support of PKI

Note: This section describes directory service requirements linked to PKI.
[AMHS-DIR-C34] When being used to provide Directory support for PKI, the DSA shall
use the specified DIT structure to provide support for retrieval of security certificates and
CRLs, using atn-amhs-user (attribute atn-der-certificate) and atn-certification-authority
object-classes.

Edition : :2.1 Released Issue Page C-7

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

C.2.4 System capacity and performance

[AMHS-DIR-C35] The DSA design should be scalable in a cost effective manner in order
to be able to store more AMHS information and support additional DUA directory operations.
Note: The ATN directory needed to support the Extended ATSMHS will eventually need to
hold an entry for every AMHS user in the world. This has been estimated to be around
80,000 users.

Page C-8 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

C.3. CONFORMITY ASSESSMENT MATERIALS

This section specifies the Profile Requirements List (PRL) for the services specified in Annex
C. Completed conformance statements can be used in support of the DoC and/or part of
Technical File accompanying the DoV.

C.3.1 Object Class Requirements

[AMHS-CA-C01] DSAs shall implement as a minimum the object classes specified in
Table C-3 to Table C-6 and, for DSAs participating in EDS, the EDS-specific object classes
specified in ICAO EUR Doc 020 [8] in order to guarantee correct understanding of the data
shared between DMDs.
Table C-3: DSA Supported ISO/IEC 9594-7 | ITU-T Rec. X.521 [34] Object Classes
Ref. No Object Class Support required
1 top m
2 alias m
3 country m
4 locality o
5 organization m
6 organizationalUnit o
7 person o
8 organizationalPerson o
9 organizationalRole m
10 groupOfNames o
11 groupOfUniqueNames o
12 residentialPerson o
13 applicationProcess o
14 applicationEntity o
15 dSA o
16 device o
17 strongAuthenticationUser o
18 certificationAuthority m
19 userSecurityInformation o
20 certificationAuthority-V2 o
21 dMD o
22 userPwdClass o

Table C-4: Additional DSA supported Object Classes Defined in profile FDY11 [16]
Ref. No Object Class Support required
1 ispApplicationEntity o

Table C-5: DSA Object Classes Defined for Message Handling System (MHS) in
ISO/IEC 10021-2 | ITU-T Rec. X.402 [18]
Ref. No Object Class Doc 9880 Support
required
1 mhs-distribution-list m m
2 mhs-message-store m o
3 mhs-message-transfer-agent m o
4 mhs-user m m
5 mhs-user-agent m o

Edition : :2.1 Released Issue Page C-9

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Table C-6: ATN-specific DSA Object Classes Defined in ICAO Doc 9880 Part IV [7]
Ref. No Object Class Doc 9880 Support
required
1 atn-amhs-user m m*
2 atn-organizational-unit m o
3 atn-organizational-person m o
4 atn-organizational-role m c
5 atn-application-entity m o
6 atn-certification-authority m m
7 atn-amhs-distribution-list m m
8 atn-amhs-user-agent m o
9 atn-amhs-gateway m o
10 atn-aircraft m o
11 atn-facility m c
12 atn-amhsMD m m*
13 atn-idrp-router m o
14 atn-dSA m o
15 atn-organization m m*
m*: Required by EDS (see ICAO EUR Doc 020 Appendix G-B)
c: m if participating in EDS, o otherwise

C.3.2 Attribute Requirements

[AMHS-CA-C02] Table C-7 specifies the attributes that shall be used in support of the
ATSMHS for each required object class.
Note: The way that successive versions of attribute values can be managed is out of the
scope of the Directory standards.
Table C-7: Supported Attributes
Object class Support
attribute required
alias
aliasedEntryName m

country
countryName m
description m
searchGuide o

atn-amhs-user
(sub-class of top, derived from mhs-user)
mhs-maximum-content-length m
mhs-deliverable-content-types m
mhs-acceptable-eits m
mhs-exclusively-acceptable-eits m
mhs-message-store-dn o
mhs-or-addresses m
atn-per-certificate o
atn-der-certificate m
atn-ipm-heading-extensions m
atn-amhs-direct-access m
atn-AF-address m
atn-maximum_number-of-body-parts m

Page C-10 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

atn-maximum_text_size m
atn-maximum_file_size m
atn-use-of-amhs-security m
atn-use-of-directory m
atn-group-of-addresses m

atn-certification-authority
(sub class of certificationAuthority)
authorityRevocationList m
cACertificate m
certificateRevocationList m
crossCertificatePair m
atn-per-certificate o
atn-der-certificate m

atn-amhs-distribution-list
(sub class of mhs-distributionList)
commonName m
description m
mhs-deliverable-content-types m
mhs-acceptable-eits m
mhs-exclusively-acceptable-eits m
mhs-unacceptable-eits o
mhs-dl-submit-permissions m
mhs-or-addresses m
organizationName m
organizationalUnitName o
owner m
seeAlso o
mhs-maximum-content-length m
mhs-dl-policy o
mhs-dl-subscription-service o
mhs-dl-archive-service o
mhs-dl-related-lists o
mhs-dl-members m
atn-ipm-heading-extensions m
atn-PerCertificate o
atn-DerCertificate o
atn-maximum_number-of-body-parts m
atn-maximum_text_size m
atn-maximum_file_size m
atn-use-of-amhs-security m
atn-use-of-directory m
atn-AFaddress m

atn-amhsMD
common-name m
atn-global-domain-identifier m
atn-icao-designator m
atn-amhs-addressing-scheme m
atn-amhsMD-naming-context c
c: m if atn-amhsMD-addressing-scheme is CAAS, o otherwise

atn-organization
(sub class of organization)
organizationName m

Edition : :2.1 Released Issue Page C-11

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

OrganizationalAttributeSet o
atn-facility-name m
atn-per-certificate o
atn-der-certificate o

atn-organizational-role
(sub class of organizationalRole)
commonName m
description m
LocaleAttributeSet o
organizationalUnitName o
PostalAttributeSet o
preferredDeliveryMethod o
roleOccupant o
seeAlso o
TelecommunicationAttributeSet o
atn-per-certificate o
atn-der-certificate o

atn-facility
atn-facility-name m
atn-per-certificate o
atn-der-certificate o

C.3.3 List of X.500 Global Statement and Protocol Operations Supported

by the Directory Service
[AMHS-CA-C03] Table C-8 specifies the overall conformance and protocol operations
that shall be used in support of the ATSMHS for each mandatory object class.
Note: The DUA categories Administrative DUA, Operational Personnel DUA and
Autonomous Operational DUA are defined in ICAO Doc 9880 Part IV Chapter 2, section
2.1.3.12. The DUA component of the ATS Message Server, ATS Message User Agent and
AFTN/AMHS Gateway belongs to the latter category. The other categories are necessary for
directory administration.
Table C-8: X.500 Global Statement and Protocol Operations Supported by the
Directory Service
Autonomous Operational
Administrative
Operations Ref DSA Operational Personnel
DUA
DUA DUA
global conformance statement
Support of Basic Access control X.501 m - - -
Support of “simple” authentication
X.509 m o o o
procedure
Support of “strong” authentication
X.509 o o o o
procedure
DISP Operations
DSA Shadow Bind X.525 c1 - - -
DSA Shadow UnBind X.525 c1 - - -
Coordinate Shadow Update X.525 c1 - - -
Request Shadow update X.525 c1 - - -
Update Shadow X.525 c1 - - -
DSP Operations
X.511-
Directory bind m - - -
X.518

Page C-12 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Autonomous Operational
Administrative
Operations Ref DSA Operational Personnel
DUA
DUA DUA
X.511-
Directory unbind m - - -
X.518
X.511-
Chained Read m - - -
X.518
X.511-
Chained Compare m - - -
X.518
X.511-
Chained Abandon m - - -
X.518
X.511-
Chained List m - - -
X.518
X.511-
Chained Search m - - -
X.518
X.511-
Chained Add Entry o - - -
X.518
X.511-
Chained Remove Entry o - - -
X.518
X.511-
Chained Modify Entry o - - -
X.518
X.511-
Chained Modify DN o - - -
X.518
DAP Operations
Directory bind X.511 m m m m
Directory unbind X.511 m m m m
Read X.511 m m m m
Compare X.511 m m m m
Abandon X.511 m m m m
List X.511 m m m m
Search X.511 m m m m
Add Entry X.511 m - - m
Remove Entry X.511 m - - m
Modify Entry X.511 m - - m
Modify DN X.511 m - - m
Administer Password X.519 o o
Change Password X.519 o o
c1: m if DISP supported, else o. Strongly recommended for participation in EDS.

C.3.4 Requirements Statement for DUAs

[AMHS-CA-C04] Implementers shall state whether all of the requirements and which of
the optional elements of the DUA supporting the Extended ATSMHS, as specified in ICAO
Doc 9880 Part IV Chapter 2 [7] section 2.5.2.1, have been implemented, using the table in
this section or equivalent.
Note: The following table is derived from the X.500 conformance specifications taken from
section 13.1.1 of ISO/IEC 9594-5 | ITU-T Rec. X.519 [34].
Table C-9: Directory User Agent Requirements
X.500 Conformance Statement Requirements Profile
a) the operations of the directoryAccessAC application-context that the DUA is See DAP Operations in Table C-8
capable of invoking for which conformance is claimed

Edition : :2.1 Released Issue Page C-13

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

X.500 Conformance Statement Requirements Profile

b) the bind security level(s) for which conformance is claimed m – simple, with password
none
simple, without password o - others
simple, with password
simple, with protected-password
strong
Is the userPwd supported for password policy?
Can the DUA generate signed arguments or validate signed results?
c) the extensions listed in Table 1 of ITU-T Rec. X.511 | ISO/IEC 9594-3 [34], o - all
that the DUA is capable of initiating for which conformance is claimed;
1 subentries
2 copyShallDo
3 attribute size limit
4 extraAttributes
5 modifyRightsRequest
6 pagedResultsRequest
7 matchedValuesOnly
8 extendedFilter
9 targetSystem
10 useAliasOnUpdate
11 newSuperior
12 manageDSAIT
13 use of Contexts
14 partialNameResolution
15 overspecFilter
16 selectionOnModify

18 Security parameters - Operation code

19 Security parameters - Attribute certification path
20 Security parameters - Error Protection
25 Service administration
26 entryCount
27 hierarchySelections
28 relaxation
29 familyGrouping
30 familyReturn
31 dnAttributes
32 friend attributes
33 Abandon of paged results
34 Paged results on the DSP
35 replaceValues
d) Is conformance claimed to Rule-based Access Control? (capability of o
supporting security labels as identified in ITU-T Rec. X.501 | ISO/IEC 9594-2)
[34]
e) Identification of the Certificate and CRL extensions for which conformance is
claimed. (Conformity to clauses 9 and 17 of ITU-T Rec. X.509 | ISO/IEC 9594-8
[35]):
Certificate extensions: c
keyUsage
subjectAltName
basicConstraints
nameConstraints
cRLDistributionPoints

CRL extensions: c
cRLNumber
reasonCode
invalidityDate
deltaCRLIndicator
issuingDistributionPoint
deltaInfo

State which other optional Certificate and CRL extensions are supported. o

Page C-14 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

X.500 Conformance Statement Requirements Profile

If the subjectAltName certificate extension is supported, which name types (from m – x400Address (ORAddress),
GeneralNames ASN.1 type) are supported? directoryName (Name)
o – all other types

c: if (strong authentication or signed operations) then m, else n/a

C.3.5 Requirements Statement for DSAs

[AMHS-CA-C05] Implementers shall state whether all of the requirements and which of
the optional elements of the DSA supporting the Extended ATSMHS, as specified in ICAO
Doc 9880 Part IV Chapter 2 [7] section 2.5.2.2, have been implemented, using the table in
this section or equivalent.
Note: The following table is derived from the X.500 conformance specifications taken from
section 13.2.1 of ISO/IEC 9594-5 | ITU-T Rec. X.519 [34].
Table C-10: Directory System Agent Requirements
X.500 Conformance Statement Requirements Profile
a) The application-contexts for which conformance is claimed: m - directoryAccessAC
directoryAccessAC, c1 - directorySystemAC
directorySystemAC,
directoryOperationalBindingManagementAC

b) The operational binding types for which conformance is claimed: o – shadowOperationalBindingID

shadowOperationalBindingID, should be supported
specificHierarchicalBindingID,
non-specificHierarchicalBindingID,
or a combination of these. A DSA that claims conformance to
the shadowOperationalBindingID shall support one or more of the application
contexts for shadow suppliers and/or shadow consumers
c) Whether or not the DSA is capable of acting as a first level DSA, as defined in m - Can act as first level DSA
ITU-T Rec. X.518 | ISO/IEC 9594-4 [34].
d) If conformance is claimed to the application-context specified c1 - Chained mode shall be
by directorySystemAC, whether or not the chained mode of operation is supported
supported, as defined in ITU-T Rec. X.518 | ISO/IEC 9594-4 [34].
e) If conformance is claimed to the application-context specified m – simple, with password
by directoryAccessAC protocol, the bind security level(s) for which
conformance is claimed (none, simple, strong – and if simple, then whether o – Originator and Result
without password, with password, or with protected password, or the userPwd is authentication
supported for password policy); whether the DSA can perform originator
authentication as defined in 22.1 of ITU-T Rec. X.518 | ISO/IEC 9594-4 [34] and
if so, whether identity-based or signature-based; and whether the DSA can
perform result authentication as defined in 22.2 of ITU-T Rec. X.518 | ISO/IEC
9594-4 [34].
f) If conformance is claimed to the application-context specified by c1 – simple, with password
directorySystemAC, the bind security level(s) for which conformance is claimed
(none, simple, strong – and if simple, then whether without password, with o – Originator and Result
password, or with protected password); whether the DSA can perform originator authentication
authentication as defined in 22.1 of ITU-T Rec. X.518 | ISO/IEC 9594-4 [34] and
if so, whether identity-based or signature-based; and whether the DSA can
perform result authentication as defined in 22.2 of ITU-T Rec. X.518 | ISO/IEC
9594-4 [34].
g) State which of the selected attribute types defined in Section 2 (paragraphs o – uUIDPair, all “Notification”
6.1 to 6.17) of ITU-T Rec. X.520 | ISO/IEC 9594-6 [34] are supported attributes
Any other attribute types, for which conformance is claimed.
For attributes based on the syntax DirectoryString, is conformance claimed for m - all attributes defined in section
the UniversalString, BMPString, or UTF8String choices? C.3.2 above

Edition : :2.1 Released Issue Page C-15

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

X.500 Conformance Statement Requirements Profile

h) The selected object classes defined in ITU-T Rec. X.521 | ISO/IEC 9594-7 m - all classes defined in section
[34]: C.3.1 above
Country
Locality
Organization
Organizational Unit
Person
Organizational Person
Organizational Role
Group of Names
Group of Unique Names
Residential Person
Application Process
Application Entity
DSA
Device
Strong Authentication User
User Security Information
User Password
Certification Authority
Certification Authority-V2
DMD
Any other object classes, for which conformance is claimed.
i) The extensions listed in Table 1 of ITU-T Rec. X.511 | ISO/IEC 9594-3 [34], o – all (see list in Table C-9 (c)
that the DSA is capable of responding to for which conformance is claimed.
j) Whether conformance is claimed for collective attributes as defined in 8.10.2 o
of ITU-T Rec. X.501 | ISO/IEC 9594-2 and 7.6, 7.8.2 and 12.3.2 of ITU-T Rec.
X.511 | ISO/IEC 9594-3 [34].
k) Whether conformance is claimed for hierarchical attributes as defined in 7.9 o
and 11.2.2 of ITU-T Rec. X.511 | ISO/IEC 9594-3 [34]
l) The operational attribute types defined in ITU-T Rec. X.501 | ISO/IEC 9594-2 o – All operational attributes defined
[34] and any other operational attribute types for which conformance is claimed. in ITU-T Rec. X.501| ISO/IEC 9594-
2 [34]
m) Whether conformance is claimed for return of alias names as described in c1
7.7.1 of ITU-T Rec. X.511 | ISO/IEC 9594-3 [34].
n) Whether conformance is claimed for indicating that returned entry information c1
is complete, as described in 7.7.1 of ITU-T Rec. X.511 | ISO/IEC 9594-3[34].
o) Whether conformance is claimed for modifying the object class attribute to o
add and/or remove values identifying auxiliary object classes, as described in
12.3.2 of ITU-T Rec. X.511 | ISO/IEC 9594-3 [34].
p) Basic Access Control. (ITU-T Rec. X.501 | ISO/IEC 9594-2 [34]) o
q) Simplified Access Control. (ITU-T Rec. X.501 | ISO/IEC 9594-2 [34]) o
r) Whether the DSA is capable of administering the subschema for its portion of o
the DIT, as defined in ITU-T Rec. X.501 | ISO/IEC 9594-2 [34].
Note – The capability to administer a subschema shall not be divided;
specifically, the capability to administer particular subschema definitions shall not
be claimed.
s) The selected name bindings defined in ITU-T Rec. X.521 | ISO/IEC 9594-7 o
[34] and any other name bindings, for which conformance is claimed.
t) Whether the DSA is capable of administering collective attributes, as defined in o
ITU-T Rec. X.501 | ISO/IEC 9594-2 [34].
u) The selected context types defined in ITU-T Rec. X.520 | ISO/IEC 9594-6 o
[34], and any other context types, for which conformance is claimed.
v) Whether conformance is claimed for contexts as defined in 8.8, 8.9 and 12.8 o
of ITU-T Rec. X.501 | ISO/IEC 9594-2, and in 7.3 and 7.6 of ITU-T Rec. X.511 |
ISO/IEC 9594-3 [34].
w) Whether conformance is claimed for the management of the DSA Information o
Tree, as defined in 7.12 of ITU-T Rec. X.511 | ISO/IEC 9594-3 [34].

Page C-16 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

X.500 Conformance Statement Requirements Profile

x) Rule-based Access Control. (ITU-T Rec. X.501 | ISO/IEC 9594-2 [34]) o
Note – The support of security labels requires the following minimal support of
contexts: Context lists as per 8.8 of ITU-T Rec. X.501 | ISO/IEC 9594-2 and
returnContexts per 7.6 of ITU-T Rec. X.511 | ISO/IEC 9594-3.
y) Whether conformance is claimed to integrity of Directory operations. o
z) Whether conformance is claimed that the DSA can hold and provide access to o
encrypted and digitally signed information.
aa) If conformance is claimed for strong authentication, signed operations, or
protected operations, identification of the Certificate and CRL extensions for
which conformance is claimed:
Certificate extensions: c
keyUsage
subjectAltName
basicConstraints
nameConstraints
cRLDistributionPoints

CRL extensions: c
cRLNumber
reasonCode
invalidityDate
deltaCRLIndicator
issuingDistributionPoint
deltaInfo

State which other optional Certificate and CRL extensions are supported. o
If the subjectAltName certificate extension is supported, which name types (from m – x400Address, directoryName
GeneralNames ASN.1 type) are supported?
o – all other types

c: if (strong authentication or signed operations) then m, else n/a

c1: m in final ATN directory deployment; could be omitted in initial transition step.

C.3.6 Requirements Statement for Conformance by a Shadow Supplier

[AMHS-CA-C06] For a DSA supporting DISP, implementers shall state whether all of
the requirements and which of the optional elements of the DSA supporting the Extended
ATSMHS, as specified in ICAO Doc 9880 Part IV Chapter 2 [7] section 2.5.5, have been
implemented, using the table in this section or equivalent.
Note: The following table is derived from the X.500 conformance specifications taken from
section 13.3.1 of ISO/IEC 9594-5 | ITU-T Rec. X.519 [34]. It is conditional upon DISP being
supported.
Table C-11: Shadow Supplier Requirements
X.500 Conformance Statement Requirements Profile
a) The application context(s) for which conformance is claimed as a shadow c1 – at
supplier: least shadowSupplierInitiatedAC
shadowSupplierInitiatedAC, and shadowConsumerInitiatedAC
shadowConsumerInitiatedAC, shall be supported
shadowSupplierInitiatedAsynchronousAC,
shadowConsumerInitiatedAsynchronousAC. For the EDS described in ICAO
A DSA implementation claiming conformance as a shadow supplier and not EUR Doc 020 [8] Appendix G the
supporting disp-ip shall, at a minimum, support either Central European DSA conforms to
the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. If the DSA shadowSupplierInitiatedAC
supports the shadowSupplierInitiatedAC, it may optionally support
the shadowSupplierInitiatedAsynchronousAC. If the DSA supports
the shadowConsumerInitiatedAC, it may optionally support
the shadowConsumerInitiatedAsynchronousAC

Edition : :2.1 Released Issue Page C-17

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

b) The security-level(s) for which conformance is claimed (none, simple, strong). c1 – None and simple
c2 - strong
c) To which degree the UnitOfReplication is supported. Specifically, which (if -
any) of the following optional features are supported:
– entry filtering on objectClass; c1
– selection/Exclusion of attributes via AttributeSelection; c1
– the inclusion of subordinate knowledge in the replicated area; c1
– the inclusion of extended knowledge in addition to subordinate knowledge; c1
– selection/Exclusion of attribute values based on contexts. c2

c1: if DISP supported then m, else n/a

c2: if DISP supported then o, else n/a

C.3.7 Requirements Statement for Conformance by a Shadow Consumer

[AMHS-CA-C07] For a DSA supporting DISP, implementers shall state whether all of
the requirements and which of the optional elements of the DSA supporting the Extended
ATSMHS, as specified in ICAO Doc 9880 Part IV Chapter 2 [7] section 2.5.5, have been
implemented, using the table in this section or equivalent.
Note: The following table is derived from the X.500 conformance specifications taken from
section 13.4.1 of ISO/IEC 9594-5 | ITU-T Rec. X.519 [34]. It is conditional upon DISP being
supported.
Table C-12: Shadow Consumer Requirements
X.500 Conformance Statement Requirements Profile
a) The application context(s) for which conformance is claimed as a shadow c1 – at
consumer: least shadowSupplierInitiatedAC
shadowSupplierInitiatedAC, and shadowConsumerInitiatedAC
shadowConsumerInitiatedAC, shadowSupplierInitiatedAsynchronousAC, s shall be supported
hadowConsumerInitiatedAsynchronousAC.
A DSA implementation claiming conformance as a shadow consumer and not For DSAs participating in the EDS
supporting disp-ip shall, at a minimum, support either described in ICAO EUR Doc 020 [8]
the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. If the DSA Appendix G, conformance to
supports the shadowSupplierInitiatedAC, it may optionally support shadowSupplierInitiatedAC is
the shadowSupplierInitiatedAsynchronousAC. If the DSA supports required if DISP is implemented.
the shadowConsumerInitiatedAC it may optionally support
the shadowConsumerInitiatedAsynchronousAC
b) The security-level(s) for which conformance is claimed c1 - None, simple
none,
simple, c2 - strong
strong
c) Whether the DSA can act as a secondary shadow supplier (i.e., participate in c2
secondary shadowing as an intermediate DSA);
d) Whether the DSA supports shadowing of overlapping units of replication c2

c1: if DISP supported then m, else n/a

c2: if DISP supported then o, else n/a

Page C-18 Released Issue Edition : 2.1

 EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL Specification for

the Air Traffic Services Message
Handling System (AMHS)
ANNEX D - Security

DOCUMENT IDENTIFIER: EUROCONTROL-SPEC-0136

Edition Number : 2.1

Edition Date : 06/09/2018
Status : Released Issue
Intended for : General Public
Category : EUROCONTROL Specification
 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.

EDITION EDITION INFOCENTRE PAGES

REASON FOR CHANGE
NUMBER DATE REFERENCE AFFECTED

0.1 16/01/08 Initial outline All

0.2 25/01/08 Detail added All

0.3 26/02/08 Further evolution. Input to Drafting Group All

Further evolution. Comments from drafting
0.4 01/04/08 All
group 29/02/08.
0.5 13/06/08 Draft for Review Group All
Updated after informal stakeholder review.
0.6 24/10/08 All
Was previously Annex C.
Updated after informal stakeholder review.
1.0 08/12/08 All
Input to formal consultation.
Updated after ENPRM-01/2009 formal
1.1 27/07/09 All
consultation.
2.0 18/09/09 Released Issue Footers
Update references, align with ICAO &
2.1 06/09/18 ATM Master Plan. See Appendix 4 for All
details.

Page D-ii Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

CONTENTS

ANNEX D - SECURITY REQUIREMENTS ................................................................. 1

D.1. CONFIGURATION CONTROL ....................................................................... 1

D.2. REQUIREMENTS AND EXPLANATORY MATERIALS ................................ 2

D.2.1 Introduction ...............................................................................................................................2
D.2.2 General Requirements ..............................................................................................................2
D.2.2.1 Security Architecture .........................................................................................................2
D.2.2.2 Cryptographic and Hashing functions ...............................................................................5
D.2.3 AMHS Security Specific Requirements.....................................................................................6
D.2.3.1 Security Policy ...................................................................................................................6
D.2.3.2 AMHS Security Framework ...............................................................................................7
D.2.3.3 Recommendations for Secure Message Submission .......................................................8
D.2.3.4 Recommendations for Secure Message Reception ........................................................11
D.2.3.5 Message Sequence Integrity ...........................................................................................13

D.3. CONFORMITY ASSESSMENT MATERIALS .............................................. 15

APPENDIX 1 TO ANNEX D - PDR Resolutions Applicable to ICAO Doc

9705, Third Edition, Sub-Volume VIII ............................................................... 16

Edition : 2.1 Released Issue Page D-iii

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

ANNEX D – SECURITY REQUIREMENTS

D.1. CONFIGURATION CONTROL

D.1.1 MOC Element Identification

MOC_Name MOC_Version MOC_Edition
AMHS_SEC 1 2

D.1.2 MOC Element Change Record

The following table records the complete history of the successive editions of MOC
specifications.

Version Edition Sections

Edition Date Reason for Change
Number Number Affected

1 1 18/09/09 Initial specification All

1 2 06/09/18 Updated references All

D.1.3 MOC Element Traceability towards Regulatory Provisions

The following table records the traceability history of regulatory provisions associated with
this MOC element.

Implementing
Version Edition Validation
rule References of regulatory provisions
Number Number date
references
Regulation (EC) No 552/2004 [1]
Annex II Part A and Part B (4) -
Essential requirements applicable to
1 1 N/A 22/10/08
communications systems and
procedures for ground-to-ground
communications
1 2 N/A SES interoperability Regulation [1]

D.1.4 MOC Element Traceability towards International Standards

The following table records the traceability of international standards associated with this
MOC element.

International standards References of text parts used References of text parts

identification to draft MOC specifications imported into the MOC

ICAO Doc 9880 Part II [5] Functional Group SEC

ICAO Doc 9705 Sub-Volume ECDSA and related algorithms,
VIII [6] PKI

Edition : 2.1 Released Issue Page D-1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

D.2. REQUIREMENTS AND EXPLANATORY MATERIALS

D.2.1 Introduction
Note 1: This informative Annex is included for guidance to potential implementers of the
technical security features of the Extended ATSMHS. Completed conformance statements
can be used in support of the DoC and/or part of Technical File accompanying the DoV.
Note 2: This Annex aims to provide complementary information for the EATMN on the
application of security aspects defined in the ICAO technical specifications for ATN Security
[6]. Any differences or complementary specifications with respect to the ICAO provisions are
explicitly identified.
Note 3: The first part of the Annex (D.2.2) deals with general security framework
requirements, while the second part (D.2.3) deals with security requirements specific to
AMHS.
Note 4: This Annex must be read in conjunction with the Main Body of this EUROCONTROL
Specification, which provides definitions, document references and contextual information.
References given in square brackets are defined in section 10 of the Main Body. Reference
is also made to Annex C of this EUROCONTROL Specification for the definition of the
Directory system supporting certificate and CRL distribution.
Note 5: Due to the informative nature of this Annex, the use of “shall” and “should” to identify
requirements and recommendations differs from their usage in the other Annexes of this
EUROCONTROL Specification. The respective requirements and recommendations are
applicable only in cases where it is decided to include AMHS message security in a particular
implementation.

D.2.2 General Requirements

Note: The technical provisions specified in this Annex will be just one element of an overall
security framework that would be necessary to protect the assets of the AMHS and its users
from malicious attack. Other technical elements include virus protection, firewalls, etc.

D.2.2.1 Security Architecture

Note: ANSPs will need to provide further specifications for any purely local protocol aspects
that remain options in the referenced standards e.g. the details of UA-MTA and UA-MS Bind
Operations and Authentication resulting from an ANSP’s local security policy.
[AMHS-SEC-D01] An AMHS End System implementation shall implement protocol
provisions as necessary to comply with the local security policy relating to aeronautical data
access and interchange.
Note: A minimum set of compliance requirements for such protocol provisions is specified in
this EUROCONTROL Specification.
[AMHS-SEC-D02] Measures should be taken by ANSPs and other entities providing data
communications services to ensure appropriate security of information exchanges
[AMHS-SEC-D04] Implementations shall be conformant with the Extended ATSMHS and
in particular the security aspects of ATN relevant for ground-ground communication; Chapter
8.3.1.1 (Framework Standards) of the ATN Security provisions [6] is fully applicable.

Page D-2 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-SEC-D05] Each State implementing AMHS Security shall designate a Trusted

Third Party (TTP) acting as a Root Certificate Authority (CA) which issues certificates and
certificate revocation lists (CRLs), in accordance with chapter 8.3.1.2.2 of the ATN Security
provisions [6].
Note 1: Due to geopolitical, governance and local policies aspects, it is important that each
State is free to select a CA of their choice. This CA can be public or private. Several States /
Organisations may decide to share the same CA.
Note 2: The CA chosen by the State must comply with local laws and regulations.
[AMHS-SEC-D06] The TTP shall conform to the ETSI Guide EG 201 057 [13], which
defines the role and attribution of a TTP acting as a CA in a PKI.
[AMHS-SEC-D07] Item 8.3.1.2.3 of the ATN Security provisions [6] shall be applicable in
the conditions provided below.
Note: The referenced item states that State CAs shall have a non-transitive peer
relationship among one another, rather than a hierarchical relationship. To ensure that
relationships can be defined globally with countries conformant to the ATN provisions, the
policies used in Europe can be applied as-is by the other countries.
[AMHS-SEC-D08] CAs in the EATMN shall use policies to ensure the overall security of
the ATN.
[AMHS-SEC-D09] CAs shall be conformant with the Community framework for electronic
signatures specified in the Regulation on electronic identification and trust services for
electronic transactions [2].
[AMHS-SEC-D10] CAs shall comply with the certificate policy requirements defined in
ETSI policy and security requirements for Trust Service Providers issuing certificates [14].
Note 1: The referenced ETSI specification is conformant with European Regulation [2]. See
also ETSI TR 102 040 [32] for aspects relating to cross certification between CAs over the
world.
Note 2: The referenced policy is defined with respect to guidelines given in PKI Assessment
Guidelines (PAG) [48] and RFC 3647 [21] – Internet X.509 Public Key Infrastructure –
Certificate Policy and Certification Practices Framework.
[AMHS-SEC-D11] Where the ATN Security provisions [6] refer to RFC 2527, this shall be
replaced with a reference to RFC 3647 [21].
[AMHS-SEC-D12] CAs shall develop a Certificate Policy (CP) that defines the creation,
management, and use of public key certificates that they issue, consistent with section
8.4.1.1 of the ATN Security provisions [6].
[AMHS-SEC-D13] CAs shall publish a Certificate Practice Statement (CPS) that
describes the expected use of public key certificates that they issue, consistent with section
8.4.2.1 of the ATN Security provisions [6].
Note: Practices may include such items as initialisation/certification of entities and their key
pairs, certificate revocation, key backup and recovery, CA key rollover, cross-certification,
etc.
[AMHS-SEC-D14] The CP and CPS shall be aligned with the framework presented in
RFC 3647 [21].
Note 1: The above reference differs from sections 8.4.1.2 and 8.4.2.2 of the ATN Security
provisions [6], which require that “the Certificate Policy and Certificate Practice Statement
shall conform to the Internet X.509 Public Key Infrastructure Certificate Policy and

Edition : 2.1 Released Issue Page D-3

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Certification Practices Framework, IETF PKIX RFC2527”. RFC 2527 is obsoleted by RFC
3647.
Note 2: The CP and CPS of a given State could be used by other States in establishing their
trust relationships and operating policies such as cross certification.
[AMHS-SEC-D15] Each CA shall define its own CPS conformant with the rules defined in
the ETSI policy and security requirements for Trust Service Providers issuing certificates
[14].
[AMHS-SEC-D16] Each CA shall propose a service for certificate and CRL distribution.
[AMHS-SEC-D17] Each CA shall give simple access to the public certificate and CRL
repository in its own domain.
[AMHS-SEC-D18] The distribution system of public key certificates and CRLs should be
done using Directory services.
[AMHS-SEC-D19] Where item 8.3.1.2.7 of the ATN Security provisions [6] refers to use of
a directory service for certificate and CRL distribution, this shall be taken to mean conformity
with the Directory as specified in Annex C of this EUROCONTROL Specification.

D.2.2.1.1 PKI Deployment in the EATMN

Note: If it were to evolve in an uncoordinated manner, there is a risk that the PKI
implementation for EATMN ground-ground communication could result in the architecture
presented in Figure D-1, where each State has a bilateral cross-certification with all other
participating States (so for N participants, it implies N(N-1) relations of confidence need to be
put in place). For example, if 10 States were to interconnect together, a total of 10*9 = 90
bilateral cross-certifications are required.

CA root CA root
Nation i Nation j

European Community
CA root
CA root Nation l
Nation k

CA root
Nation x

Figure D-1: European PKI with Multiple Cross-Certified CAs

In this infrastructure, all participating States would have to conform to a common security
policy.
[AMHS-SEC-D20] The EATMN PKI in support of AMHS should therefore be based on a
common ATS Bridge CA (see Figure D-2) in order to:
a) Simplify the process of cross-certification for each CA;
b) Minimise the issues due to multiple policy agreements;
c) Minimise the risk of problems occurring due to the limit of validity of
cross certificates;

Page D-4 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

d) Allow a central organisation to verify that the policy applied by each CA

complies with the European Regulation on a Community framework for
electronic signatures [2].
Note 1: In this case, and only in this case, a transitive relationship may be allowed between
two States’ CAs if a central EATMN-wide CA Root is provided.

CA root
Nation x

CA root CA root
Nation i Nation j

European
Community EU-CA
root
CA root
CA root Nation l
Nation k

CA root
Nation x

Figure D-2: Future European Public Key Infrastructure

Note 2: Due to a number of considerations, it is unlikely that the common European ATS
Bridge CA with all State CAs participating as envisaged above will be available in a single
step. As an initial transition step, it may be possible to establish a single central CA as a
common facility, with ANSPs using certificates issued by this CA rather than by their National
CA for message signatures. More practically, their CAs could be subCAs of the single central
CA, otherwise there could be significant time delays when adding or removing users.

D.2.2.2 Cryptographic and Hashing functions

Note: In order to achieve interoperability across the EATMN and beyond, it is necessary that
each implementation of the Extended ATSMHS uses a common set of algorithms and
parameter settings for cryptographic and hashing functions.
[AMHS-SEC-D21] The cryptographic signing and hashing functions and parameter
settings shall be conformant with ATN Security provisions [6], Chapter 8.5.
Note 1: The detailed technical specifications for ATN Security [6] specify the use of an Elliptic
Curve cryptosystem for ATN public-key algorithms. Cryptographic and Hashing functions
defined in the ATN Security provisions are conformant with ETSI recommendations for
cryptographic suites [33].
Note 2: The maintenance procedures for this EUROCONTROL Specification allow the
possibility of updating the choice of security algorithms and associated parameters used for
digital signatures and public key authentication. For example, an upgrade to conform to
current NIST security suites could be foreseen.
[AMHS-SEC-D22] The general certificate format used for ATN PKI certificates shall be
conformant with the X.509 Format with parameters defined in chapter 8.4.3 of the ATN
Security provisions [6].

Edition : 2.1 Released Issue Page D-5

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-SEC-D23] The signature scheme E-ATSMHS-SEC shall be conformant, for the

hash function, to the Secure Hash Standard (SHA-1, SHA-224, SHA-256, SHA-384, and
SHA-512) defined in the Federal Information Processing Standard for Secure Hash Standard
(SHS) [15].
Note: The content integrity check algorithm is based on the E-ATSMHS-SEC signature
scheme ("ecdsa-with-SHA2"). The signature scheme ("ecdsa-with-SHA2") is drawn from the
ATN signature scheme ("ecdsa-with-SHA1") and consists of replacing the SHA-1 hash
function with one of the SHA-2 family functions: SHA-224, SHA-256, SHA-384, and SHA-
512.
[AMHS-SEC-D24] The elements of a certificate should be encoded following the DER
(Distinguished Encoding Rules) standard defined in ITU-T Rec X.509 [35] and specified by
ITU-T Rec X.690 [36].
[AMHS-SEC-D25] It is recommended that a symmetric algorithm should be used for the
Content Integrity Check algorithm in Extended ATSMHS, and that this should initially be the
secure hash algorithm “SHA-1”.
Note: SHA-1 is being replaced with stronger algorithms such as “SHA-256”, but this may not
be necessary for ATS messages; depending on the threat model.

D.2.3 AMHS Security Specific Requirements

D.2.3.1 Security Policy

[AMHS-SEC-D26] If secure messaging is required in the Extended ATSMHS, a general
AMHS end-to-end security policy shall be implemented in compliance with ICAO Doc 9880
Part II [5] section 2.2.3, providing the following security services:
a) Message origin authentication; and
b) Content integrity.
Note: ICAO Doc 9880 Part II also specifies Message Sequence Integrity as a provided
service. See D.2.3.5 below.
[AMHS-SEC-D27] An appropriate security policy shall be implemented in order to secure
the AMHS, notably by applying common security rules to protect the distributed physical
resources supporting message submission, transfer and delivery.
Note 1: Definition of a security policy is beyond the scope of this EUROCONTROL
Specification. Such a policy will comply with the requirements of various international
standards, including ICAO Annex 17 [29], ICAO EUR Security Guidelines [10], and EU
Common Requirements for air navigation services [25].
Note 2: The security policy for EATMN ground-ground communication also needs to consider
communication with external countries, and not impose security elements that will prevent
communication where such communication is required.
[AMHS-SEC-D28] For messages using these security services, the processing of the
message envelope shall be in compliance with ICAO Doc 9880 Part II [5] sections 3.1.4.3
and 3.2.4.
Note: This requires support of security class S0, which only requires support of end-to-end
security services between UAs (content integrity, message origin authentication, proof of
delivery), and hence can be used to provide some protection even in the case of transit
through an intermediary MTS which may not be trusted.

Page D-6 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

D.2.3.2 AMHS Security Framework

Note: This section first describes the security services provided to the different users (ATS
Message User Agent, ATS Message Server, AFTN/AMHS Gateway) and then deals with
security framework for AMHS such as end to end AMHS user message exchange security
(PKI). It gives related normative documents from standards bodies such as ITU, ISO and
IETF applicable in the context of AMHS.
[AMHS-SEC-D29] The Security model given in §2.2.3 of the AMHS technical provisions in
ICAO Doc 9880 Part II [5] shall be applied.
[AMHS-SEC-D30] The general AMHS security policy shall be aligned with the general
ATN Security Framework as defined in the ATN Security provisions [6]; this is a common
minimum which does not prevent specific communities of AMHS users from implementing
more stringent security policies in case of additional user requirements.
[AMHS-SEC-D31] The use of AMHS security services shall apply to:
a) communications between direct AMHS users supporting the Extended
ATSMHS; and
b) communications from direct AMHS users to indirect AMHS users as far as
the AFTN/AMHS Gateway supporting the Extended ATSMHS.
[AMHS-SEC-D32] The AMHS security policy shall make use of the Elliptic Curve Digital
Signature Algorithm (ECDSA) as specified in the ATN Security provisions [6] section 8.5.5.
[AMHS-SEC-D33] For the support of security in the context of the Extended ATSMHS, an
ATS Message User Agent shall implement the Security requirements defined in §3.1.4.3.3 of
ICAO Doc 9880 Part II [5].
Note: The specified cryptographic and hashing functions are used to generate and verify
digital signatures for messages exchanged between ATS Message User Agents supporting
AMHS Security.
[AMHS-SEC-D34] The generation by the ATS Message User Agent of the message token
in the per-recipient-extensions of the message envelope shall be as specified in section
3.1.3.4 of ICAO Doc 9880 Part II [5], refined as specified in this Annex.
[AMHS-SEC-D35] For the support of security in the context of the Extended ATSMHS, an
MTA in an ATS Message Server shall implement the requirements for the support by an MTA
of the SEC Functional Group, implementing Security-Class S0, as defined in §3.2.4.3 b) of
ICAO Doc 9880 Part II [5].
[AMHS-SEC-D36] For the support of security in the context of the Extended ATSMHS, a
Message Store in an ATS Message Server shall implement the requirements for the support
by an MS of the SEC Functional Group, implementing Security-Class S0, as defined in
§3.2.4.4 b) of ICAO Doc 9880 Part II [5].
[AMHS-SEC-D37] For the support of security in the context of the Extended ATSMHS, an
AFTN/AMHS Gateway shall implement the requirements for handling the security-related
elements of the message transfer envelope as defined in §4.5.2.4.16 to 4.5.2.4.22 of ICAO
Doc 9880 Part II [5].
Note: The specified cryptographic and hashing functions may be used for messages
addressed to indirect AMHS users if the AFTN/AMHS Gateway supports AMHS Security.
Although not providing end-to-end security in this case, the security service can help to
prevent unauthorised users from accessing the gateway, provided that the gateway knows
which users are expected to sign messages.

Edition : 2.1 Released Issue Page D-7

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-SEC-D38] It is recommended that to simplify certificate signature checking, and

facilitate interoperability, the certificate (and CRL) extensions that may be used within the
Extended ATSMHS are precisely defined and kept to a minimum.

D.2.3.3 Recommendations for Secure Message Submission

D.2.3.3.1 Use of Message Token

Note: A message-token is a general purpose structure for conveying signed (and possibly
also encrypted) information from originator to recipients, in circumstances where some of the
information needs to be specified differently per recipient. The message-token is depicted
graphically in Figure D-3. (Items in italics are not used by AMHS Security).

Figure D-3: Content of Message Token

[AMHS-SEC-D39] A message originator wishing to send a secure message at an ATS
Message User Agent that supports AMHS SEC shall create and sign a message-token for
each recipient in the per-recipient-extensions in the message envelope.
Note: The AsymmetricToken form of the message-token is used by AMHS Security, as
shown in Figure D-4. The SIGNED construct indicates that the SEQUENCE construct is
present in plaintext, followed by a signature appendix.

Page D-8 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Figure D-4: ASN.1 definition of Message Token

The AsymmetricToken includes:
a) A signature algorithm identifier, which for AMHS Security is the value "ecdsa-
with-SHA1" with NULL parameters;
b) A name. For AMHS Security this would be the O/R Name of the recipient. It
typically matches the recipient O/R Name to which it refers, but this is not the
case after distribution list expansion or when the message has been
redirected;
c) The time the message-token was created;
d) Signed data information, as shown in Figure D-5.
e) Encryption algorithm identifier. Not used for AMHS Security.
f) Encrypted data. Not used for AMHS Security.

Figure D-5: ASN.1 definition of Signed Data information

Of the various elements of the signed data information, the AMHS SEC only uses the
Content Integrity Check (CIC).This consists of the algorithm identification followed by a
computed integrity-check value, as shown in Figure D-6. The SIGNATURE construct for the
CIC indicates that the algorithm is applied to both the algorithm identifier and the message
content. It is possible to use an asymmetric algorithm (e.g. "ecdsa-with-SHA1") or a
symmetric algorithm (e.g. “SHA-1”). The symmetric algorithm is recommended because it is
quicker to compute. Note that “SHA-1” is being replaced with stronger algorithms such as

Edition : 2.1 Released Issue Page D-9

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

“SHA-256”, but this may not be necessary for ATS messages, depending on the threat
model.

Figure D-6: ASN.1 definition of Content Integrity Check

[AMHS-SEC-D40] The MessageTokenSignedData should include only the CIC algorithm
identifier and the CIC value, computed using a symmetric algorithm.

D.2.3.3.2 Inclusion of originator’s certificate

Note 1: In order to verify a message signature, a message recipient must obtain the correct
public key of the message signer. This is held in the signer’s certificate. When submitting a
message, an AMHS user which supports AMHS SEC can optionally include the certificate
containing their own public key within the message envelope.
Note 2: If no certificate is supplied by the message originator, the message recipient must
look up the correct certificate in the directory. It is necessary for the receiving application to
identify the directory entry of the message signer (preferably via a Directory Name (DN) in
the originator’s O/R Name, otherwise by a directory search for the originator’s O/R Address),
then perform a directory lookup and download the certificate attribute, then pick out the
correct certificate from the set of values in the certificate attribute. There can be several
certificate values because certificate keys may be rolled over after a period of time (say, 1
year) but the old values need to be retained to (partially) verify signatures of old messages.
The application needs to select a certificate value with a validity period matching the
message submission/delivery time, even if the validity period has expired. This approach is
not recommended because of the extra time it will take to verify a signature, and the extra
load placed on the directory.
Note 3: There are various approaches for including the originator’s certificate with the
message, including:
a) Originator provides certificate in message envelope
This is by far the most common approach adopted, and it is strongly
recommended that this approach is followed in ATS Message User Agents
that support SEC. The message originator places the certificate containing the
required public key in the originators-certificate element in the message
envelope extensions.
The advantage of this approach is that recipients are provided with exactly the
right certificate to proceed with signature verification. There is no need to
identify the directory entry of the message signer, then perform a directory
lookup and download the certificate attribute, then pick out the correct
certificate from the set of values in the certificate attribute. All of these
operations introduce processing delays.
Note that with this approach, users’ certificates don’t need to be published to
the directory at all. This simplifies maintenance and makes replication
between different directories simpler.

Page D-10 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Also note that when the certificate is stored with the message, it can be used
to perform an integrity check on an archived message, after the certificate
validity period has expired and non-repudiation of origin is no longer practical.
The only disadvantage is that messages are bigger than necessary because
of the certificate, which might be around 1 kByte in size.
b) Originator provides certificate in multiple-originator-certificates element of
message
In this approach, the message originator places one or more certificates in the
multiple-originator-certificates element in the message envelope
extensions. This field is currently available for use in the Extended ATSMHS
profile, but there is no reason to use it, as all message recipients will be
capable of using the same originator’s certificate.
[AMHS-SEC-D41] It is recommended that message originators using AMHS Security
should provide a valid certificate containing the required public key in the originators-
certificate element in the message envelope extensions.
Note: Providing the originator’s certificate in the message envelope is optional, but is strongly
recommended for Extended ATSMHS systems due to the reduced processing overheads.
[AMHS-SEC-D42] It is recommended that use of the multiple-originator-certificates
element in the message envelope extensions should be prohibited on message submission.
Note: It should not be necessary to provide more than one certificate, as in Extended
ATSMHS all message recipients will be capable of using the same originator’s certificate.

D.2.3.4 Recommendations for Secure Message Reception

D.2.3.4.1 Certificate validation

Note: Upon receiving a signed message, an ATS Message User Agent which supports
AMHS SEC must retrieve the originator’s certificate and validate it. To validate a certificate, it
is necessary to:
a) Verify that the certificate is associated with the message originator;
1) One approach is to compare the DN provided in the originator’s O/R
Name with the Subject’s Name in the certificate. This approach is not
recommended as there may not be a DN in the originator’s O/R Name.
2) The recommended approach is to compare the originator’s O/R
Address with one found in the Subject Alternative Name extension of the
certificate. This approach is much more flexible as the check is a pure X.400
check not involving the directory. The message originator must have access to
the correct private key to sign the message. It is not relevant which entry in
the directory (if any) is used to store the certificate, so the DIT structure of the
originating and receiving organisations could be different.
b) Check that the certificate has not expired or been revoked, and has a valid
signature
1) One option is for the recipient to use the Online Certificate Status
Protocol (OCSP, RFC 2560 [41]). The certificate is passed to an OCSP
Responder which validates it and returns the result. The OCSP Responder is
a server component that can often perform directory lookups faster than a
client application, which may need to make requests across a network.

Edition : 2.1 Released Issue Page D-11

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

2) Another option is for the application itself to check the certificate. This
would involve the following operations:
i. Compare the validity period of the certificate with the current
time. (This requires all EATMN systems to have their time
synchronised to within a few minutes). Note that if the validity period
has expired, this would be unacceptable to an AFTN/AMHS Gateway
or ATS Message User Agent receiving a new message, but might be
acceptable for an ATS Message User Agent displaying an archived
message. If the validity period has expired for an archived message,
the ATS Message User Agent can use the certificate to verify message
integrity but not attempt a full signature check; it could inform the user
that the full signature can no longer be checked.
ii. Check the certificate signature. The certificate will be signed by
a CA, and to check the signature the CA’s certificate must be obtained.
This is to be found in the caCertificate attribute of a CA’s directory
entry. This certificate will be self-signed if this is the root CA;
otherwise, a chain of CA certificates must be retrieved and checked
back to the root CA. (Or if the originator and recipient do not share the
same root CA, somewhere in the chain will be a cross-certificate
attribute, possibly belonging to a Bridge CA, to be processed).
iii. Check for revocation. For each CA in the certificate path, a
Certificate Revocation List (CRL) must be retrieved from the directory
to check that none of the certificates it issued has since been revoked.
The CRL itself has a signature which must be checked. A CA may
delegate the issuing of CRLs to a CRL Issuer; if so, information
explaining where to find the CRL needs to be provided in certificates.
Once the originator’s certificate has been validated, the public key within it can be used to
check the message signature.
[AMHS-SEC-D43] It is recommended that on receipt of a message containing the
originator’s certificate in the message envelope extensions, the originator’s O/R Address
should be compared with one found in the SubjectAltName extension of the certificate to
ensure that the supplied certificate is associated with the message originator.
[AMHS-SEC-D44] It is recommended that an OCSP Responder compliant with RFC 2560
[41] should be deployed to facilitate the verification of received certificates.
Note: This approach has the advantage that the validation rules in the OCSP Responder can
be adjusted and a standard validation algorithm will apply to all applications using it.

D.2.3.4.2 Message token processing

[AMHS-SEC-D45] An application should validate the message token, contained in the
message delivery envelope extensions, when the message is first received, including:
a) Verifying the time field in the message token;
b) Applying the CIC Algorithm Id to the received message content / stated
algorithm id, and comparing this to the received CIC Hash value;
c) Applying the Signature Algorithm Id and originator’s certificate public
key to the whole contents of the Asymmetric Token, and comparing
this with the token signature;
d) Checking the Recipient Name in the message-token.

Page D-12 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-SEC-D46] A receiving application should report an error if a message-token that

is ‘too old’ is received (except when displaying an archived message).
[AMHS-SEC-D47] The maximum acceptable time difference between the time field in the
message token and the current system time should be specified in the security policy.
[AMHS-SEC-D48] If a message is received that is too old, the receiving application
should check the message integrity but ignore the signature.
Note: After a signed message has been received and validated, an ATS Message User
Agent might want to re-use the message-token whenever the message is opened for display
purposes. In such a situation, checking the message-token recipient name, time, and
message sequence number is not valid. The ATS Message User Agent might automatically
perform an integrity check using the CIC (as this does not involve the directory and so is very
fast), but provide the user with an option to perform a full signature check on the message
(which is likely to fail if the message is old).
[AMHS-SEC-D49] When applying the CIC Algorithm Id to the received message content /
stated algorithm id, and comparing this to the received CIC Hash, it is recommended that the
AMHS SEC convention is to use the message content as received, i.e. the recipient should
not need to ensure that it is DER-encoded.
Note: The above recommendation assumes that the CIC Algorithm is symmetric; otherwise
the process is more complicated. It improves performance, and is acceptable because ATS
Message Servers never modify the message content en route, as they do not support the
Conversion functional group.

D.2.3.5 Message Sequence Integrity

Note 1: The Message Sequence Number in the Message Token may be set individually for
each recipient. This would allow a recipient to detect replay, re-ordering, and message loss.
Re-ordering may not be important for an ATS Message User Agent, but could be for a
specialised application (e.g. receiving database updates to be applied in a particular
sequence). Both the sending and receiving applications would need to keep track of what is
the next expected number. However, it is recommended not to use the message sequence
number field for message sequence integrity, since sequencing problems may be quite
common:
a) If the message originator is sending messages of different priority. An
MTA will send high-priority messages first;
b) If there are multiple channels between a pair of MTAs. In this situation,
a small message may overtake a large message on another channel;
c) If there are alternate routes between a pair of MTAs, involving other
MTAs.
Note 2: Support for Message sequence integrity is indicated in ICAO Doc 9880 Part II [5], as
a countermeasure against replay. The details of how to provide such a service are not
defined. Message sequence assurance in an AFTN/AMHS Gateway may be provided by
means of timestamp analysis. Use of the message sequence field in the Message Token is
not required for compliance with this EUROCONTROL Specification (nor is it prohibited).
[AMHS-SEC-D50] Message sequence integrity should be achieved by the message
originator setting the Time field in the Message Token to the current time, and the message
recipient checking that the value of this field is within acceptable parameters.

Edition : 2.1 Released Issue Page D-13

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

[AMHS-SEC-D51] Message sequence integrity may be provided according to ISO/IEC

10021-4 | ITU-T Recommendation X.411 [18], section 8.2.1.1.1.26. In an AMHS End System
supporting the Extended ATSMHS, the message-sequence-number may be present in the
asymmetric token MessageTokenSignedData. The first occurrence of a message sequence
number may be a random number.
[AMHS-SEC-D52] However, it is recommended that applications using the Extended
ATSMHS should avoid using the message-sequence-number field in the Message Token for
message sequence integrity assurance.
Note: If the above recommendation is not followed, and message sequence integrity is
important (e.g. not when just displaying a list of messages), the following initial check would
have to be made before acting on the received sequence number. If the Recipient Name in
the message-token matches the message delivery envelope this-recipient-name field, the
receiving application is free to use the message sequence number provided in the message-
token, as the message has not been redirected and there has been no DL expansion
involving the recipient. Otherwise, the receiving application should not use any message
sequence number provided in the message-token, because it was generated for another
user (or for a distribution list).

Page D-14 Released Issue Edition : 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

D.3. CONFORMITY ASSESSMENT MATERIALS

D.3.1 This section specifies the Profile Requirements List (PRL) for the services
specified in Annex D.
[AMHS-CA-D01] For ATS Message User Agent implementations supporting the SEC
functional group, a PICS shall be provided stating the level of support, for each of the
elements listed in the profile requirements list in Table 3-3 of ICAO Doc 9880 Part II [5].
[AMHS-CA-D02] Support for message-sequence-number in the message token signed-
data, which is indicated as “Optional” in the referenced PRL, should be made “M”
(Mandatory), to allow for the possible provision of the Message Sequence Integrity function.
[AMHS-CA-D03] Support for the encrypted-data and content-confidentiality-algorithm-id
fields in the message token, which is indicated as “Optional” in the referenced PRL, should
be considered “out of scope”, and not used when communicating with AMHS users compliant
with this EUROCONTROL Specification, since the AMHS security model in ICAO Doc 9880
Part II [5], does not include message confidentiality.

Edition : 2.1 Released Issue Page D-15

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

APPENDIX 1 TO ANNEX D
PDR Resolutions Applicable to ICAO Doc 9705, Third Edition, Sub-Volume VIII
Note: A number of Proposed Defect Reports (PDRs) applicable to the ATN Security service
were considered and resolved by working groups of the ICAO ATN Panel. The PDR
resolutions will eventually be included in ICAO Doc 9880, Part IV Chapter 3.
Until the Security chapter of ICAO Doc 9880 Part IV becomes available, this Appendix will
reference the applicable PDR resolutions, which can be found in the Repository section of
the ICAO ACP website 1.
[AMHS-SEC-D54] Security implementations shall include the relevant PDR resolutions
from the following list:
PDR ref Title
M1030007 Security - Editorial errors found during development of
Guidance Material
M1030008 Security - Defects found during development of Guidance
Material
M2030004 All SV - Editorials (version of PDR current on 2004/05/28)
M2080001 SV8 - Unnecessary random challenge field
M2080003 Security - Clarify representation of AMHS identities in ATN
certificates
M2080004 Security - Additional extensions in CA certificates
M2080005 Security - Clarify ATN CRL processing
M2080006 Security - Add warning concerning the use of invalid keys by
the secret value derivation primitive
M2080007 Security - Remove CheckResult references from 8.6.3
M2080008 Security - Remove duplicate certificate retrieval requirements
M2080009 Security - Sub-Volume VIII ASN.1
M2090002 SV8, SV4 - SSO-GetCertificatePath target
M2090003 SV8 - ASN.1 padding issues
M2090004 SV8 - SSO-SessionKey Certificate Knowledge
M2090005 SV8 - SSO counter initialization
M2100005 SV8 - Tagging in SV8 ASN.1 module
M4020001 Security - Error in ATN Key Derivation Function
M4030001 SV8 - Missing requirement on User Data padding
M4050007 SV8 - Key lifetime clarification
M6080004 SV8 - Directory Security Requirements

1
https://www.icao.int/safety/acp/repository/ACFF6F3.zip

Page D-16 Released Issue Edition : 2.1

 EUROCONTROL Specification for the Air Traffic Services Message Handling System (AMHS)

APPENDIX 1

Traceability Matrix between SES Essential Requirements and EUROCONTROL Specification

TABLE OF CONTENTS

Appendix 1. Traceability Matrix between SES Essential Requirements and EUROCONTROL Specification .................................................. 2
A1.1 INTRODUCTION ................................................................................................................................................................................ 2
A1.2 Essential Requirements mapping to EUROCONTROL Specification .................................................................................................. 2
A1.2.1 Essential Requirements – Part A .................................................................................................................................................... 3
A1.2.2 Essential Requirements – Part B .................................................................................................................................................... 8
A1.3 EUROCONTROL Specification mapping to Essential Requirements ................................................................................................ 11
A1.3.1 Annex A – Basic Service ............................................................................................................................................................... 12
A1.3.2 Annex B – Extended Service ........................................................................................................................................................ 22
A1.3.3 Annex C – Directory Service ......................................................................................................................................................... 27
A1.3.4 Annex D – Security ....................................................................................................................................................................... 31

Edition: 2.1 Released Issue Appendix 1-1

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

APPENDIX 1. TRACEABILITY MATRIX BETWEEN SES ESSENTIAL REQUIREMENTS AND

EUROCONTROL SPECIFICATION

A1.1 INTRODUCTION
This informational Appendix provides traceability between the Essential Requirements (ER) in Annex II of the SES Interoperability Regulation
[1] and the tagged requirements in the Annexes of the EUROCONTROL Specification for the Air Traffic Services Message Handling System
(AMHS).

A1.2 Essential Requirements mapping to EUROCONTROL Specification

Note 1: The following table lists the ERs as given in Annex II of the Interoperability Regulation [1], and assigns reference numbers to individual paragraphs.
The complete set of ERs is shown for completeness; ERs that are not considered relevant for ATS messaging systems are shown shaded.
The ERs are divided into parts A (General requirements) and B (Specific requirements per system type) each containing numbered sections with one
requirement per paragraph; since there are multiple unnumbered paragraphs (and hence requirements) in some sections and subsections, individual
requirements are identified by adding a paragraph number to the section number using the following format:
ER Reference: Part-Section-Paragraph
Where Part and Section correspond to the numbering in Annex II of the Interoperability Regulation and Paragraph denotes the paragraph number preceded
by a P.
For example the tag: B-3.1.2-P3 - denotes Annex II Part B, section 3.1.2, paragraph 3.
Note 2: Every requirement and recommendation in the EUROCONTROL Specification is identified by a structured tag, which can be used to reference
uniquely the requirement / recommendation. The structure of requirement identifiers allows differentiation between the Basic ATSMHS and Extended
ATSMHS and also identifies the major system components, which can be considered as candidate EATMN constituents. Such identifiers have the form:
AMHS-[Fn]-[Ann]
where:
[Fn]: is a sequence of characters to identify the operational procedure or category to which the requirement applies, e.g. “AMU” for requirements specific to
ATS Message User Agent, “AMS” for requirements specific to ATS Message Server, “DIR” for general requirements related to Directory functions.
[Ann]: is the Annex identifier followed by a number, unique within a given [Fn], taking the value “A” for requirements specific to the Basic ATSMHS, “B” for
requirements specific to the Extended ATSMHS, “C” for requirements specific to Directory functions and “D” for requirements specific to Security functions.

Edition: 2.1 Released Issue Appendix 1-2

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

A1.2.1 Essential Requirements – Part A

Table 1: Essential Requirements - Part A
ER Reference Requirement Description EUROCONTROL Specification Reference
Part A: GENERAL REQUIREMENTS
1. Seamless operation
A-1-P1 Air traffic management systems and their constituents shall be designed, built, [AMHS-BAS-A01], [AMHS-BAS-A03], [AMHS-BAS-A04],
maintained and operated using the appropriate and validated procedures, in such a [AMHS-BAS-A05], [AMHS-BAS-A06], [AMHS-BAS-A06A],
way as to ensure the seamless operation of the EATMN at all times and for all phases [AMHS-BAS-A07], [AMHS-MGT-A26], [AMHS-N&A-A01]
of flight. Seamless operation can be expressed, in particular, in terms of information [AMHS-CA-A01], [AMHS-CA-A02], [AMHS-CA-A03],
sharing, including the relevant operational status information, common understanding [AMHS-CA-A04], [AMHS-CA-A05], [AMHS-CA-A06]
of information, comparable processing performances and the associated procedures [AMHS-BAS-B01], [AMHS-BAS-B03], [AMHS-CA-B01], [AMHS-
enabling common operational performances agreed for the whole or parts of the CA-B02], [AMHS-CA-B03], [AMHS-CA-B04], [AMHS-CA-B05],
EATMN. [AMHS-CA-B06]
[AMHS-DIR-C04][AMHS-DIR-C29][AMHS-CA-C01]
Note:
Contributions are made to this requirement by specifying:
a) A coherent ATS Message Handling Service and
operational concepts throughout the applicable area.
b) A communications system supporting a seamless
relationship between ground-based systems, so that a
service is not disrupted by breaks in coverage or wide
variations in quality of service.

Edition: 2.1 Released Issue Appendix 1-3

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

2. Support for new concepts of operation
A-2-P1 The EATMN, its systems and their constituents shall support, on a coordinated basis, [AMHS-BAS-A01], [AMHS-BAS-A03], [AMHS-BAS-A04],
new agreed and validated concepts of operation that improve the quality, sustainability [AMHS-BAS-A05], [AMHS-BAS-A06], [AMHS-BAS-A07].
and effectiveness of air navigation services, in particular in terms of safety and [AMHS-ARM-A01]
capacity. [AMHS-GEN-B01], [AMHS-GEN-B02], [AMHS-GEN-B03]
[AMHS-DIR-C01], [AMHS-DIR-C02],
[AMHS-DIR-C09], [AMHS-DIR-C12], [AMHS-DIR-C13],
[AMHS-DIR-C14], [AMHS-DIR-C33], [AMHS-DIR-C34],
[AMHS-DIR-C35]
Note:
This requirement influences the specification in terms of the co-
ordinated introduction of:
a) New concept of operations based on high capacity,
secure, reliable digital communications;
b) Validated technology(ies) supporting data
communications in the timeframe to 2020.

A-2-P2 The potential of new concepts, such as collaborative decision-making, increasing [AMHS-BAS-B02], [AMHS-GEN-B01], [AMHS-GEN-B02],
automation and alternative methods of delegation of separation responsibility, shall be [AMHS-GEN-B03], [AMHS-AMS-B01], [AMHS-AMS-B02],
examined taking due account of technological developments and of their safe [AMHS-AMS-B03], [AMHS-AMS-B04], [AMHS-AMS-B05],
implementation, following validation. [AMHS-AMS-B06], [AMHS-AMU-B02], [AMHS-AMU-B04],
[AMHS-AMU-B06], [AMHS-AMU-B07], [AMHS-AMU-B08],
[AMHS-AMU-B09], [AMHS-AMU-B10], [AMHS-AMU-B11],
[AMHS-AMU-B12], [AMHS-AMU-B13], [AMHS-AMU-B14],
[AMHS-AMU-B15], [AMHS-MST-B01], [AMHS-MST-B02],
[AMHS-MST-B03], [AMHS-MST-B04], [AMHS-MST-B05],
[AMHS-MST-B06], [AMHS-MST-B07], [AMHS-MST-B08],
[AMHS-MST-B09], [AMHS-GWY-B01], [AMHS-GWY-B02]
[AMHS-DIR-C01], [AMHS-DIR-C02]
3. Safety
A-3-P1 Systems and operations of the EATMN shall achieve agreed high levels of safety. [AMHS-SAF-A01], [AMHS-SAF-A02], [AMHS-SAF-A05]
Agreed safety management and reporting methodologies shall be established to [AMHS-SEC-D02]
achieve this.
Note:
Contributions are made to this requirement by specifying basic
safety requirements applicable to systems and constituents
implementing the ATSMHS.

Edition: 2.1 Released Issue Appendix 1-4

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

A-3-P2 In respect of appropriate ground-based systems, or parts thereof, these high levels of Note: This is assumed to apply only to ATM systems, with safety
safety shall be enhanced by safety nets which shall be subject to agreed common nets such as MSAW, STCA, etc.
performance characteristics.
A-3-P3 A harmonised set of safety requirements for the design, implementation, maintenance [AMHS-SAF-A03], [AMHS-SAF-A04]
and operation of systems and their constituents, both for normal and degraded modes [AMHS-SEC-D01]
of operation, shall be defined with a view to achieving the agreed safety levels, for all
phases of flight and for the entire EATMN. Note:
Contributions are made to this requirement by specifying data
communications mechanisms providing alternative
communication paths between users.

A-3-P4 Systems shall be designed, built, maintained and operated, using the appropriate and [AMHS-SAF-A05]
validated procedures, in such a way that the tasks assigned to the control staff are Note: In the case if AMHS, the “control staff” are those persons
compatible with human capabilities, in both the normal and degraded modes of responsible for managing and operating the constituent systems.
operation, and are consistent with required safety levels.

Edition: 2.1 Released Issue Appendix 1-5

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

A-3-P5 Systems shall be designed, built, maintained and operated using the appropriate and [AMHS-SAF-A06], [AMHS-MGT-A20], [AMHS-MGT-A21],
validated procedures, in such a way as to be free from harmful interference in their [AMHS-MGT-A22], [AMHS-MGT-A23]
normal operational environment. [AMHS-DIR-C07], [AMHS-DIR-C08], [AMHS-DIR-C14],
[AMHS-DIR-C34]
[AMHS-SEC-D01], [AMHS-SEC-D04],
[AMHS-SEC-D05], [AMHS-SEC-D06], [AMHS-SEC-D07],
[AMHS-SEC-D08], [AMHS-SEC-D09], [AMHS-SEC-D10],
[AMHS-SEC-D11], [AMHS-SEC-D12], [AMHS-SEC-D13],
[AMHS-SEC-D14], [AMHS-SEC-D15], [AMHS-SEC-D16],
[AMHS-SEC-D17], [AMHS-SEC-D18], [AMHS-SEC-D19],
[AMHS-SEC-D20], [AMHS-SEC-D21], [AMHS-SEC-D22],
[AMHS-SEC-D23], [AMHS-SEC-D24], [AMHS-SEC-D25],
[AMHS-SEC-D26], [AMHS-SEC-D27], [AMHS-SEC-D28],
[AMHS-SEC-D29], [AMHS-SEC-D30], [AMHS-SEC-D31],
[AMHS-SEC-D32], [AMHS-SEC-D33], [AMHS-SEC-D34],
[AMHS-SEC-D35], [AMHS-SEC-D36], [AMHS-SEC-D37],
[AMHS-SEC-D38], [AMHS-SEC-D39], [AMHS-SEC-D40],
[AMHS-SEC-D41], [AMHS-SEC-D42], [AMHS-SEC-D43],
[AMHS-SEC-D44], [AMHS-SEC-D45], [AMHS-SEC-D46],
[AMHS-SEC-D47], [AMHS-SEC-D48], [AMHS-SEC-D49],
[AMHS-SEC-D50], [AMHS-SEC-D51], [AMHS-SEC-D52],
[AMHS-SEC-D54]
Note:
Contributes to this requirement within the Extended ATSMHS;
security services help to protect against safety hazards such as
accidental or deliberate message corruption and provide
protection against undetected misdelivery. Directory services
also help to provide misdelivery protection.

4. Civil-military coordination
A-4-P1 The EATMN, its systems and their constituents shall support the progressive Main Body section 2.11
implementation of civil/military coordination, to the extent necessary for effective
airspace and air traffic flow management, and the safe and efficient use of airspace by
all users, through the application of the concept of the flexible use of airspace.
A-4-P2 To achieve these objectives, the EATMN, its systems and their constituents shall [AMHS-AMS-A12]
support the timely sharing of correct and consistent information covering all phases of
flight, between civil and military parties.
A-4-P3 Account should be taken of national security requirements.

Edition: 2.1 Released Issue Appendix 1-6

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

5. Environmental constraints
A-5-P1 Systems and operations of the EATMN shall take into account the need to minimise Note:
environmental impact in accordance with Community legislation.
Indirectly, improved data communication services enable
concepts leading to reduced paper-based transactions and the
need to travel to meetings, etc. However, this EUROCONTROL
Specification does not contribute directly to ER5.
6. Principles governing the logical architecture of systems
A-6-P1 Systems shall be designed and progressively integrated with the objective of achieving [AMHS-ARM-A09]
a coherent and increasingly harmonised, evolutionary and validated logical architecture
within the EATMN. Note:
Standardised data communication services support a common
view of the logical architecture, at least at the level of the
communications subsystems and of the communicating
application processes. This EUROCONTROL Specification is
based on ICAO provisions, which specify the X.400 architecture
of MTAs, UAs, Message Stores and Access Units. Beyond this,
the Specification does not prescribe any particular solution for
the logical architecture of systems.

Edition: 2.1 Released Issue Appendix 1-7

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

7. Principles governing the construction of systems
A-7-P1 Systems shall be designed, built and maintained on the grounds of sound engineering [AMHS-GEN-A04], [AMHS-GEN-A05], [AMHS-GEN-A08],
principles, in particular those relating to modularity, enabling interchangeability of [AMHS-SAF-A07], [AMHS-PER-A07], [AMHS-PER-A09],
constituents, high availability, and redundancy and fault tolerance of critical [AMHS-LOG-A01], [AMHS-LOG-A02], [AMHS-LOG-A03],
constituents. [AMHS-LOG-A04], [AMHS-ARM-A02], [AMHS-ARM-A03],
[AMHS-ARM-A10], [AMHS-MGT-A01], [AMHS-MGT-A05],
[AMHS-MGT-A06], [AMHS-MGT-A07], [AMHS-MGT-A08],
[AMHS-MGT-A09], [AMHS-MGT-A10], [AMHS-MGT-A11],
[AMHS-MGT-A12], [AMHS-MGT-A13], [AMHS-MGT-A14],
[AMHS-MGT-A16], [AMHS-MGT-A17], [AMHS-MGT-A18],
[AMHS-MGT-A19], [AMHS-MGT-A24], [AMHS-MGT-A25],
[AMHS-AMS-A07], [AMHS-AMS-A08], [AMHS-AMS-A09]
Note:
Standardised data communication elements are designed to be
modular, and are decoupled from specific exchange
mechanisms and communications subnetworks. In the Extended
ATSMHS, access protocols between UA and MTA are
standardised, opening up the possibility to source UAs from
different suppliers. However, this EUROCONTROL Specification
does not prescribe the construction of systems in terms of
modularity, high availability, redundancy and fault tolerance of
critical constituents

A1.2.2 Essential Requirements – Part B

Table 2: Essential Requirements - Part B

ER Reference Requirement Description EUROCONTROL Specification Reference

Part B: SPECIFIC REQUIREMENTS
3. Systems and procedures for air traffic services
3.1 Flight data processing systems
3.1.1 Seamless operation

Edition: 2.1 Released Issue Appendix 1-8

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

B-3.1.1-P1 Flight data processing systems shall be interoperable in terms of the timely sharing
of correct and consistent information, and a common operational understanding of
that information, in order to ensure a coherent and consistent planning process and
resource-efficient tactical coordination throughout the EATMN during all phases of
flight.
B-3.1.1-P2 In order to ensure safe, smooth and expeditious processing throughout the EATMN,
flight data processing performances shall be equivalent and appropriate for a given
environment (surface, terminal manoeuvring area (TMA), en-route), with known
traffic characteristics and exploited under an agreed and validated operational
concept, in particular in terms of accuracy and error tolerance of processing results.
3.1.2 Support for new concepts of operation
B-3-1.2-P1 Flight data processing systems shall accommodate the progressive implementation
of advanced, agreed and validated concepts of operation for all phases of flight, in
particular as envisaged in the ATM Master Plan.
B-3-1.2-P2 The characteristics of automation-intensive tools must be such as to enable
coherent and efficient pre-tactical and tactical processing of flight information in
parts of the EATMN.
B-3-1.2-P3 Airborne and ground systems and their constituents supporting new, agreed and [AMHS-PER-A07]
validated concepts of operation shall be designed, built, maintained and operated, Note: Flight Data Processing Systems are relevant, insofar as
using appropriate and validated procedures, in such a way as to be interoperable in they may interface to the AMHS as direct “host” users.
terms of timely sharing of correct and consistent information and a common
understanding of the current and predicted operational situation.
4. Communication systems and procedures for ground-to-ground, air-to-ground and air-air communications
4.1 Seamless operation
B-4.1-P1 Communication systems shall be designed, built, maintained and operated using [AMHS-GEN-A01], [AMHS-GEN-A02], [AMHS-GEN-A03],
the appropriate and validated procedures, in such a way as to achieve the required [AMHS-GEN-A04], [AMHS-GEN-A05], [AMHS-GEN-A06],
performances within a given volume of airspace or for a specific application, in [AMHS-GEN-A07], [AMHS-GEN-A08], [AMHS-PER-A01],
particular in terms of communication processing time, integrity, availability and [AMHS-PER-A02], [AMHS-PER-A04], [AMHS-PER-A05],
continuity of function. [AMHS-PER-A06], [AMHS-PER-A07], [AMHS-PER-A08],
[AMHS-ARM-A04], [AMHS-ARM-A05], [AMHS-ARM-A06],
[AMHS-ARM-A07], [AMHS-ARM-A08], [AMHS-MGT-A02],
[AMHS-MGT-A03], [AMHS-MGT-A04], [AMHS-AMS-A01],
[AMHS-AMS-A02], [AMHS-AMS-A03], [AMHS-AMS-A04],
[AMHS-AMS-A05], [AMHS-AMS-A06], [AMHS-AMS-A07],
[AMHS-AMS-A08], [AMHS-AMS-A09], [AMHS-AMS-A10],

Edition: 2.1 Released Issue Appendix 1-9

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

ER Reference Requirement Description EUROCONTROL Specification Reference

[AMHS-AMS-A11], [AMHS-AMU-A01], [AMHS-AMU-A02],
[AMHS-AMU-A03], [AMHS-AMU-A04], [AMHS-AMU-A05],
[AMHS-AMU-A06], [AMHS-AMU-A07], [AMHS-MST-A01],
[AMHS-MST-A02], [AMHS-MST-A03], [AMHS-MST-A04],
[AMHS-MST-A05], [AMHS-GWY-A01], [AMHS-GWY-A02],
[AMHS-GWY-A03], [AMHS-GWY-A04], [AMHS-GWY-A05],
[AMHS-GWY-A06], [AMHS-GWY-A07]
B-4.1-P2 The communications network within the EATMN shall be such as to meet the [AMHS-PER-A03]
requirements of quality of service, coverage and redundancy.
4.2 Support for new concepts of operation
B-4.2-P1 Communication systems shall support the implementation of advanced, agreed and [AMHS-N&A-B01], [AMHS-AMU-B01], [AMHS-AMU-B03],
validated concepts of operation for all phases of flight, in particular as envisaged in [AMHS-AMU-B04], [AMHS-AMU-B05]
the ATM Master Plan. [AMHS-DIR-C03], [AMHS-DIR-C05], [AMHS-DIR-C06],
[AMHS-DIR-C07], [AMHS-DIR-C08], [AMHS-DIR-C10],
[AMHS-DIR-C11], [AMHS-DIR-C15], [AMHS-DIR-C16],
[AMHS-DIR-C17], [AMHS-DIR-C18], [AMHS-DIR-C19],
[AMHS-DIR-C20], [AMHS-DIR-C22], [AMHS-DIR-C23],
[AMHS-DIR-C24], [AMHS-DIR-C25], [AMHS-DIR-C26],
[AMHS-DIR-C29],
[AMHS-DIR-C30], [AMHS-DIR-C31], [AMHS-DIR-C32],
[AMHS-CA-C01], [AMHS-CA-C02], [AMHS-CA-C03],
[AMHS-CA-C04], [AMHS-CA-C05], [AMHS-CA-C06],
[AMHS-CA-C07]

Edition: 2.1 Released Issue Appendix 1-10

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

A1.3 EUROCONTROL Specification mapping to Essential Requirements

The tables in this section map the tagged requirements to paragraphs in the ER (see note in section A1.2). In addition the tables contain a
classification of how each requirement can be tested for conformance during validation and testing.
Note: It is assumed that one or more test specifications will be produced for testing conformance to the EUROCONTROL Specification (“the Specification”), in
this document “Test Specification” is the term used.
The testing categories are as follows:
Test The Requirement may be tested and a definite result obtained
An assessment where the conformity of an implementation to the Specification Requirement is measured at a quantitative
level, through the application of defined input stimuli and comparison of the resulting outputs with what is specified in the
Test Specification.
Demonstrate The testing of the Specification Requirement cannot be defined by this document, but must be demonstrated by the
implementer to meet the requirement.
An assessment where the conformity of the implementation to the Specification Requirement can only be assessed at a
qualitative level, through the execution of a defined procedure which shows how the implementation meets the requirement
of the Specification.
Evaluate The Requirement may be tested or demonstrated and a full, or partial, result obtained
An assessment where the conformity of the implementation to the Specification Requirement can only be assessed by a
test or demonstration, the results of which only meet the notional requirement in part. The results are evaluated by the test
scrutinisers to assess the degree to which the requirement has been met.
Audit The Requirement cannot be tested, but must be assessed by other means
The conformity of the implementation must be assessed by means other than testing or demonstration, e.g. inspection of
the documentation, design processes, inspection records, design review records.

Edition: 2.1 Released Issue Appendix 1-11

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

A1.3.1 Annex A – Basic Service

Table 3: Annex A – Basic Service
Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
A.2 REQUIREMENTS AND EXPLANATORY MATERIALS
A.2.1 Common Requirements
A.2.1.1 Standards Baseline
[AMHS-BAS-A01] AMHS End Systems shall comply with the requirements identified in ICAO A-1-P1, A-2-P1 X
EUR Doc 020 [8] unless otherwise explicitly stated in this EUROCONTROL
Specification.
[AMHS-BAS-A03] AMHS End Systems shall comply with the requirements specified in ICAO A-1-P1, A-2-P1 X
Doc 9880 Part II [5] applicable to the Basic ATSMHS, except where
explicitly stated otherwise.
[AMHS-BAS-A04] In the event of conflicting requirements not explicitly identified, the A-1-P1, A-2-P1 X
specification in ICAO Doc 9880 Part II [5] shall take precedence.
[AMHS-BAS-A05] Due account shall be taken of any published defect resolutions relating to A-1-P1, A-2-P1 X
the ICAO AMHS documentation.
[AMHS-BAS-A06] Implementations of AMHS Components shall conform to the 2003 version A-1-P1, A-2-P1 X PICS will be supplied
of the ISO/IEC MHS base standards or the 1999 version of the ITU-T
equivalents [18] .
[AMHS-BAS-A06A] Although the International Standardized Profiles (ISPs) [19], [20] A-1-P1, A-2-P1 X PICS will be supplied
referenced in ICAO Doc 9880 and ICAO EUR Doc 020 have been
withdrawn and are no longer maintained by ISO/IEC, implementations of
AMHS Components shall conform to the last published versions of the
ISPs or equivalent provisions which may be published elsewhere.
[AMHS-BAS-A07] Compatibility with the current version of referenced standards and any A-1-P1, A-2-P1 X
relevant corrigenda should be taken into account.
A.2.1.2 General Requirements
[AMHS-GEN-A01] The AMHS shall enable the exchange of messages between the following B-4.1-P1 X
types of users:
• direct AMHS user to direct AMHS user;
• direct AMHS user to indirect AMHS user and vice-versa;
• indirect AMHS user to direct AMHS user;
• indirect AMHS user to indirect AMHS user.
[AMHS-GEN-A02] AMHS Components shall be able to communicate using the TCP/IP B-4.1-P1 X
Transport Service, as specified in ICAO Doc 9880 Part II [5] section
3.2.2.2.3.
[AMHS-GEN-A03] AMHS End System implementations should follow the “Guidelines for B-4.1-P1 X
system requirements” in section 5 of ICAO EUR Doc 020 [8].

Edition: 2.1 Released Issue Appendix 1-12

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-GEN-A04] Wherever possible, AMHS Component implementations should make use B-4.1-P1, A-7-P1 X
of common and standardised interfaces.
[AMHS-GEN-A05] Specifically, standardised interfaces where available for message B-4.1-P1, A-7-P1 X
submission, transfer and delivery, system management, etc. shall be used
as a means of enhancing Interoperability between system components.
[AMHS-GEN-A06] AMHS End Systems should support by local means the object classes and B-4.1-P1 X
attribute types of directory information specified in ICAO EUR Doc 020 [8]
Appendix B Annex K, with a (local) mechanism to obtain such information
by a UA, MTA or MTCU component.
[AMHS-GEN-A07] AMHS End Systems shall be capable of interworking with independent B-4.1-P1 X
implementations of AMHS End Systems in accordance with the permissible
combinations listed in ICAO Doc 9880 Part II [5] section 1.2.
[AMHS-GEN-A08] AMHS End Systems supporting the Basic ATSMHS shall be designed to B-4.1-P2, A-7-P1 X
accommodate the evolution to support the Extended ATSMHS, e.g. by
including well-defined interfaces and software hooks in areas where future
extensions are foreseen.
A.2.1.3 Safety Requirements
[AMHS-SAF-A01] As for any EATMN system or constituent, a safety assessment shall be A-3-P1 X
performed for the initial planned use of the ATSMHS.
[AMHS-SAF-A02] Procedures shall be put in place to ensure that a further safety assessment A-3-P1 X
is performed as and when additional end-user applications making use of
the ATSMHS are deployed.
[AMHS-SAF-A03] AMHS End Systems and operations in the EATMN shall achieve agreed A-3-P3 X
high levels of safety using established safety management and reporting
methodologies.
[AMHS-SAF-A04] In accordance with the SES interoperability Regulation [1], a harmonised A-3-P3 X
set of safety requirements for the design, implementation, maintenance
and operation of AMHS End Systems, both for normal and degraded
modes of operation, shall be applied with a view to achieving the agreed
safety levels for the entire AMHS.
[AMHS-SAF-A05] In accordance with the SES interoperability Regulation [1], AMHS End A-3-P4 X
Systems shall be designed, built, maintained and operated, using the
appropriate and validated procedures, in such a way that the tasks
assigned to the control staff are compatible with human capabilities, in both
the normal and degraded modes of operation, and are consistent with
required safety levels.

Edition: 2.1 Released Issue Appendix 1-13

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SAF-A06] In accordance with the SES interoperability Regulation [1], AMHS End A-3-P5 X
Systems shall be designed, built, maintained and operated using the
appropriate and validated procedures, in such a way as to be free from
harmful interference in their normal operational environment.
A.2.1.3.1 Software Assurance Level
[AMHS-SAF-A07] The allocated software assurance level shall be commensurate with the A-7-P1 X
most adverse effect that software malfunctions or failures may cause,
taking into account the risks associated with software malfunctions or
failures and the architectural and/or procedural defences identified.
A.2.1.4 Performance Requirements
[AMHS-PER-A01] An operational performance assessment (OPA, as defined in EUROCAE B-4.1-P1 X
Document ED-78A [11]) shall be performed for the initial planned use of the
ATSMHS.
[AMHS-PER-A02] Procedures shall be put in place to ensure that a further OPA is performed B-4.1-P1 X
as and when additional end-user applications making use of the ATSMHS
are deployed.
[AMHS-PER-A03] The ATSMHS within the EATMN shall be such as to meet the requirements B-4.1-P2 X
of quality of service, coverage and redundancy as required for the
supported applications.
[AMHS-PER-A04] When adding new services, the affect of the additional message traffic on B-4.1-P1 X
the existing traffic shall be considered.
[AMHS-PER-A05] In accordance with the SES interoperability Regulation [1], AMHS End B-4.1-P1 X
Systems shall be designed, built, maintained and operated using the
appropriate and validated procedures, in such a way as to achieve the
required performances for a specific application, in particular in terms of:
a) communication processing time,
b) integrity,
c) availability and
d) continuity of function.
[AMHS-PER-A06] AMHS End Systems shall be designed and dimensioned to enable the end- B-4.1-P1 X
to-end performance requirements for each “QoS Flow Type Class” listed in
ICAO EUR Doc 020 [8], section 3.1.4, Table 1 to be met.
[AMHS-PER-A07] In accordance with the SES interoperability Regulation [1], AMHS End A-7-P1, B-3-1.2-P3, X
Systems and their constituents supporting new, agreed and validated B-4.1-P1
concepts of operation shall be designed, built, maintained and operated,
using appropriate and validated procedures, in such a way as to be
interoperable in terms of timely sharing of correct and consistent
information.

Edition: 2.1 Released Issue Appendix 1-14

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-PER-A08] AMHS End Systems should be capable of supporting the peak rate hour's B-4.1-P1 X
performance, which corresponds to at least 20% of the daily traffic
requirements for that AMHS End System.
[AMHS-PER-A09] An AMHS End System shall comply, to the extent possible, with the sizing A-7-P1 X
recommendations specified in section 5.7 of ICAO EUR Doc 020 [8].
A.2.1.5 Naming and Addressing
[AMHS-N&A-A01] Operators of AMHS systems shall ensure that a unique identifier is A-1-P1 X
assigned and inserted in the ICAO Register of AMHS Management
Domains [28]
A.2.1.6 Logging
[AMHS-LOG-A01] Data exchanges using the ATSMHS shall be recorded in accordance with A-7-P1 X
the following ICAO standards applicable to the ground-based recording
function of data link communications:
• Section 3.5.1.5 of ICAO Annex 10 Volume II [3];
• Section 6.2 of ICAO Annex 11 [4]
[AMHS-LOG-A02] EUROCAE ED-111 [12] shall be considered as sufficient means of A-7-P1 X
compliance of the ground-based recording function with regard to the
identified ICAO standards applicable to the ground-based recording
function of ATS data communications.
[AMHS-LOG-A03] AMHS End Systems shall support the relevant requirements for traffic A-7-P1 X
logging as described in sections 2.7, 3.2.3 and 4.3.1 of ICAO Doc 9880
Part II [5]
[AMHS-LOG-A04] All operator inputs shall be recorded and traceable for a configurable A-7-P1 X
period (e.g. 30 days).
A.2.1.7 Availability, Reliability, Maintainability
[AMHS-ARM-A01] A reliability, availability and maintainability analysis shall be conducted A-2-P1 X
before entry into service and periodically thereafter to verify that AMHS
End Systems satisfy or exceed the minimum requirements in these areas.
A.2.1.7.1 Availability
[AMHS-ARM-A02] An ATS Message Server and AFTN/AMHS Gateway shall be available 24 A-7-P1 X
hours per day, with availability (defined as lack of unplanned outages) of at
least 99.999% per year.
[AMHS-ARM-A03] An ATS Message User Agent shall be available as required, with A-7-P1 X
availability of at least 99.99% per year.
[AMHS-ARM-A04] Precise constraints for the restart time are dependent on the configuration B-4.1-P1 X
of the system and specific modes of failure, but for guidance a target
restart time of less than 5 minutes shall be assumed.
[AMHS-ARM-A05] Components and system modes of failure which imply a restart time of B-4.1-P1 X
more than 1 minute shall be identified.

Edition: 2.1 Released Issue Appendix 1-15

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-ARM-A06] AMHS End Systems shall be designed such that processing of messages B-4.1-P1 X
during recovery does not overload the system or degrade the performance
below the performance targets.
A.2.1.7.2 Reliability
[AMHS-ARM-A07] AMHS End Systems shall be designed to minimise the effect of a failure of B-4.1-P1 X
an AMHS End System or component thereof on the function of the entire
system.
[AMHS-ARM-A08] AMHS End Systems and their functional components shall be designed to B-4.1-P1 X
avoid loss of messages.
A.2.1.7.3 Maintainability
[AMHS-ARM-A09] Commercial Off-the-Shelf (COTS), industry standard software, should be A-6-P1 X
used as widely as possible, in order to enable an upward compatible
growth path.
[AMHS-ARM-A10] AMHS End System implementations should be modular in nature and by A-7-P1 X
using a series of industry standard interfaces provide a flexible and
expandable combination of communication services.
A.2.1.8 System Operation and Management
A.2.1.8.1 Fault Management
[AMHS-MGT-A01] AMHS End System implementations shall support fault management in all A-7-P1 X
components.
[AMHS-MGT-A02] It should be possible to schedule the execution of diagnostic tests. B-4.1-P1 X
[AMHS-MGT-A03] On detection of a fault condition, depending upon the fault severity and B-4.1-P1 X
classification, AMHS End Systems should be configurable to perform one
or more of the following actions, in increasing order of severity:
a) Reconfigure;
b) Switch over or re-assign resources;
c) Perform software re-initialisation;
d) Perform hardware re-initialisation.
[AMHS-MGT-A04] All fault conditions and actions shall be logged and remain accessible for a B-4.1-P1 X
configurable period of not less than 1 month.
[AMHS-MGT-A05] The maximum period for stored events shall not be limited by the system A-7-P1 X
design, and only be constrained by management configuration or the
available resources of the specific system.
[AMHS-MGT-A06] An AMHS End System shall be able to meet its performance requirements A-7-P1 X
when generation and storage of additional information (tracing) in support
of basic failure analysis is enabled.
A.2.1.8.2 Configuration Management
[AMHS-MGT-A07] AMHS End Systems shall support the configuration management of all A-7-P1 X
components.

Edition: 2.1 Released Issue Appendix 1-16

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-MGT-A08] Where applicable, the AMHS End System or specific component should A-7-P1 X
allow the on-line modification and activation of configuration parameters
without requiring an interruption of service.
[AMHS-MGT-A09] The configuration, maintenance and activation of new addressing and A-7-P1 X
routing information shall be possible through on-line modification without
stopping the AMHS End System or substantially impairing its performance.
[AMHS-MGT-A10] The design of an AMHS End System shall not constrain the size of the A-7-P1 X
address space or addressing and routing tables; these are only constrained
by system management configuration or available system resources.
[AMHS-MGT-A11] All modifications of the application configuration should be logged. A-7-P1 X
[AMHS-MGT-A12] AMHS End Systems should have the capability to import data specified in A-7-P1 X
the address management function of the ATS Messaging Management
Manual [9].
A.2.1.8.3 Accounting Management
A.2.1.8.4 Performance Management
[AMHS-MGT-A13] AMHS End System implementations shall support the collection and A-7-P1 X
analysis of performance management data.
[AMHS-MGT-A14] It should be possible for the collection of statistical data to be configured, A-7-P1 X
including the use of filters and the specification of collection and
consolidation intervals.
[AMHS-MGT-A16] ATS Message Server implementations shall export statistics data in A-7-P1 X
accordance with the format specified in the ATS Messaging Management
Manual [9], Appendix C.
[AMHS-MGT-A17] It should be possible to configure trigger conditions to automatically A-7-P1 X
regulate and prevent processor or storage overloads.
[AMHS-MGT-A18] Statistics shall be provided for overall performance, use of overall capacity, A-7-P1 X
use of component capacity, overall availability and component availability.
[AMHS-MGT-A19] Statistical data shall be stored and accessible for a configurable period of A-7-P1 X
not less than 1 month.
A.2.1.8.5 Security Management
[AMHS-MGT-A20] AMHS End System implementations shall support security management A3-P5 X
functions, including management of access control lists, local user
authentication and authorisation, in accordance with ICAO EUR AFS
Security Guidelines [10]
[AMHS-MGT-A21] Access control mechanisms shall be provided to restrict access to system A3-P5 X
management information.
[AMHS-MGT-A22] User roles with configurable access rights should be supported. A3-P5 X
A.2.1.8.6 System Monitoring Functions

Edition: 2.1 Released Issue Appendix 1-17

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-MGT-A23] All events, occurring due to automatically triggered changes to the AMHS A3-P5 X
End System configuration, components or subscribers as well as occurring
due to forced changes shall be indicated on-line (e.g. as system
messages).
A.2.1.8.7 System Management Interface
[AMHS-MGT-A24] AMHS End System implementations shall include a systems management A-7-P1 X
interface consistent with the provisions of ICAO EUR Doc 020 [8], with
suitable access control.
[AMHS-MGT-A25] Communication between the management interface and the system should A-7-P1 X
be through the use of an SNMP [40] compatible interface, enabling
interoperability between manager and agent components (see ICAO EUR
Doc 020 [8], section 5.8.5).
A.2.1.9 Transitional Procedures
[AMHS-MGT-A26] Procedures for the introduction of ATSMHS into an international COM A-1-P1 X
Centre shall be as specified in Appendix A of ICAO EUR Doc 021, ATS
Messaging Management Manual [9].
A.2.2 ATS Message Server Requirements
[AMHS-AMS-A01] An ATS Message Server shall route, store and forward ATS Messages, B-4.1-P1 X
taking into account the applicable performance requirements and routing
configuration.
[AMHS-AMS-A02] An ATS Message Server shall be able to support the routing of messages B-4.1-P1 X
according to a non-hierarchical addressing plan, as well as the MF-
Addressing Schemes specified in ICAO Doc 9880 Part II [5] section
2.5.1.4.
[AMHS-AMS-A03] An ATS Message Server should have the capability to import data B-4.1-P1 X
specified in the routing management function of the ATS Messaging
Management Manual [9]
[AMHS-AMS-A04] MTAs shall implement the P1 MTS transfer profile as specified in Appendix B-4.1-P1 X
B Annex F of ICAO EUR Doc 020 [8] (profile AMH11 plus AMHS-specific
features), for communication with other ATS Message Servers.
[AMHS-AMS-A05] MTAs shall implement the P1 IPM requirements profile as specified in B-4.1-P1 X
Appendix B Annex B of ICAO EUR Doc 020 [8] (profile AMH22 plus AMHS-
specific features), for IPM communication with other ATS Message
Servers.
[AMHS-AMS-A06] MTAs shall support at least the minimum P1 message length specified in B-4.1-P1 X
Appendix B Annex F of ICAO EUR Doc 020 [8]
[AMHS-AMS-A07] The ATS Message Server should support a common and standardised A-7-P1, B-4.1-P1 X
interface for the submission and delivery of messages.

Edition: 2.1 Released Issue Appendix 1-18

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-AMS-A08] In support of the integration of an ATS Message User Agent into other B-4.1-P1 X
computer applications, an API for the submission and delivery of messages
using Open Group API specifications [38] may be specified.
[AMHS-AMS-A09] MTAs shall support the Distribution List (DL) functional group. B-4.1-P1 X
[AMHS-AMS-A10] It is recommended that the ATS Message Server should have the B-4.1-P1 X
capability to open multiple associations between each pair of
communicating MTAs (see ICAO EUR Doc 020 [8] section 5.2 and
Appendix B Annex F.2.4.1).
[AMHS-AMS-A11] The ATS Message Server shall use the Monologue dialogue-mode of the B-4.1-P1 X
RTSE protocol for associations between each pair of communicating
MTAs, as specified in Appendix B Annex J of ICAO EUR Doc 020 [8].
A.2.2.1 EATMN Boundary Requirements
[AMHS-AMS-A12] EATMN boundary ATS Message Servers shall additionally have the A-4-P2 X
capability to communicate with ATS Message Servers external to the
EATMN, subject to bilateral agreement.
A.2.3 ATS Message User Agent Requirements
[AMHS-AMU-A01] ATS Message User Agents shall comply with the requirements specified in B-4.1-P1 X
section 3.1 of ICAO Doc 9880 Part II [5] for the support of the Basic
ATSMHS, summarised as the following requirements:
• A UA profile based on AMH21 as specified in Appendix B Annex
A of ICAO EUR Doc 020 [8];
• The requirements of Repertoire Group A, for messages including
a body part whose type is an Extended Body Part Type of
general-text-body-part type;
• Provisions related to traffic logging
[AMHS-AMU-A02] It is recommended that standard ISO/IEC 10021 | ITU-T X.400 [18] B-4.1-P1 X
protocols P3 and/or P7 should be used for message submission and
delivery.
[AMHS-AMU-A03] The maximum message-text length supported by the UA shall be a B-4.1-P1 X
configurable parameter value, in accordance with Appendix B Annex
A.2.3.8 of ICAO EUR Doc 020 [8].
[AMHS-AMU-A04] A UA shall be capable of accepting and processing a maximum received B-4.1-P1 X
message-text length of at least 64 kByte and be capable of handling
messages longer than the maximum length without malfunction.
[AMHS-AMU-A05] If a user application is co-located with an MTA on a common platform, then B-4.1-P1 X
the interface between the application's (logical) UA and the message
transfer service shall provide equivalent functionality to the MT-Access
abstract service as defined for the P3 access protocol specified in ISO/IEC
10021-6 | ITU-T Recommendation X.419 [18]

Edition: 2.1 Released Issue Appendix 1-19

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-AMU-A06] If "forced" delivery to a UA is required (e.g. for reception of urgent, high B-4.1-P1 X
priority messages) then either the P3 protocol or (in the case of MS) P7
with Alerts configured should be used.
[AMHS-AMU-A07] It should be possible for direct AMHS users to request confirmation of B-4.1-P1 X
delivery and to receive delivery reports.
A.2.4 Message Store Requirements
[AMHS-MST-A01] It is recommended that, when an MS is included in the ATS Message B-4.1-P1 X
Server, standard ISO/IEC 10021-6 | ITU-T Recommendation X.419 [18]
protocol P3 should be used between the MS and MTA for message
submission and delivery.
[AMHS-MST-A02] It is recommended that standard ISO/IEC 10021-6 | ITU-T B-4.1-P1 X
Recommendation X.419 [18] protocol P7 should be used between MS and
UA for message retrieval and indirect submission.
[AMHS-MST-A03] It is recommended that the MS application context should exclude the B-4.1-P1 X
Reliable Transfer Service Element (RTSE).
[AMHS-MST-A04] MS implementations shall support the Distribution List (DL) functional B-4.1-P1 X
group, in accordance with Appendix B of ICAO EUR Doc 020 [8]. .
[AMHS-MST-A05] Requirements for the maximum number of MS users that can be B-4.1-P1 X
simultaneously supported by an MS implementation shall be based upon
current and foreseen ATSMHS usage.
A.2.5 AFTN/AMHS Gateway Requirements
[AMHS-GWY-A01] Where interworking with AFTN end systems is required, a gateway B-4.1-P1 X
between the AMHS and AFTN message services shall be implemented in
conformance with ICAO Doc 9880 Part II [5] Chapter 4.
[AMHS-GWY-A02] An AFTN/AMHS Gateway supporting the Basic ATSMHS shall implement B-4.1-P1 X
all elements which are applicable to the Basic ATSMHS and which are
marked as “M” in the “ATSMHS” column of ICAO Doc 9880 Part II Table 4-
3.
[AMHS-GWY-A03] The AFTN/AMHS Gateway shall support address conversion of O/R B-4.1-P1 X
addresses belonging to a non-hierarchical addressing plan, as well as the
MF-Addressing Schemes specified in ICAO Doc 9880 Part II [5] section
2.5.1.4.
[AMHS-GWY-A04] The AFTN/AMHS Gateway shall support address conversion and routing B-4.1-P1 X
for all currently assigned ICAO eight-letter addressee indicators (AF-
addresses).
[AMHS-GWY-A05] The AFTN/AMHS Gateway should have the capability to import the B-4.1-P1 X
address mapping tables in comma-separated value (CSV) format provided
by the European ATS Messaging Management Centre (AMC).

Edition: 2.1 Released Issue Appendix 1-20

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-GWY-A06] If the length of the ATS-Message-Text element in an AMHS message B-4.1-P1 X
exceeds the maximum supported length (a parameter set initially to 64
kByte, in accordance with current AFTN/CIDIN practices for the support of
ADEXP messages), the message shall be rejected by the AFTN/AMHS
Gateway’s MTCU as specified in ICAO Doc 9880 Part II [5] section
4.5.2.1.7 a).
[AMHS-GWY-A07] If the length of the ATS-Message-Text element in an AMHS message B-4.1-P1 X
exceeds 1800 characters but does not exceed the maximum supported
length, the AFTN component of the AFTN/AMHS Gateway shall handle the
message using one of the following options, depending on the AFTN/CIDIN
capability of the next international COM centres towards the destination:
a) Transfer the message without modification; or
b) Truncate the message text to 1800 characters; or
c) Perform the message splitting procedure specified in ICAO Doc
9880 Part II [5] section 4.5.2.1.7 b).
A.3 CONFORMITY ASSESSMENT MATERIALS
A.3.1 Compliance Statement
[AMHS-CA-A01] A claim of conformance for an implementation shall be supported by A-1-P1, Annex IV- X Part of Technical File
completion of the relevant Protocol Implementation Conformance P4
Statement (PICS) pro forma.
[AMHS-CA-A02] Implementers claiming conformance to the specified services shall A-1-P1, Annex IV- X Part of Technical File
complete the PICS specified in Appendix B Annex Q of ICAO EUR Doc P4
020 [8].
[AMHS-CA-A03] Implementers shall state whether all of the requirements and which of the A-1-P1, Annex IV- X Part of Technical File
optional elements of the AFTN/AMHS Gateway supporting the Basic P4
ATSMHS as specified in ICAO Doc 9880 Part II [5] Chapter 4 have been
implemented, using the pro forma tables in this section, or equivalent.
[AMHS-CA-A04] For AFTN/AMHS Gateway implementations, a PICS shall be provided A-1-P1, Annex IV- X Part of Technical File
stating the level of support, for each of the elements relevant to support of P4
the Basic ATSMHS, listed in the profile requirements lists in Chapter 4 of
ICAO Doc 9880 Part II [5] and specified in Table A-2.
[AMHS-CA-A05] AMHS End Systems shall be tested according to suitable test cases and A-1-P1, Annex IV- X Part of Technical File
procedures ensuring adequate coverage of the BASIC functional group. P4
[AMHS-CA-A06] Testing shall be conducted within a common framework consistent with the A-1-P1, Annex IV- X Part of Technical File
procedures in ICAO EUR Doc 020 [8] using appropriate test tools and P4
procedures.

Edition: 2.1 Released Issue Appendix 1-21

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

A1.3.2 Annex B – Extended Service

Table 4: Annex B – Extended Service
Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
B.2 REQUIREMENTS AND EXPLANATORY MATERIALS
B.2.1 Common Requirements
B.2.1.1 Standards Baseline
[AMHS-BAS-B01] AMHS End Systems shall comply with the standards identified in Annex A A-1-P1 X
of this EUROCONTROL Specification unless stated otherwise.
[AMHS-BAS-B02] AMHS End Systems conforming to this Annex shall comply with the A-2-P2 X
requirements specified in ICAO Doc 9880 Part II [5], including those
requirements specific to the support of the Extended ATSMHS, unless
explicitly stated otherwise in this Annex.
[AMHS-BAS-B03] In the event of conflicting requirements not explicitly identified, the A-1-P1 X
specification in ICAO Doc 9880 Part II [5] shall take precedence.
B.2.1.2 General Requirements
[AMHS-GEN-B01] ATS Message Servers and ATS Message User Agents shall conform to A-2-P1, A-2-P2 X
configuration IX as defined in ICAO Doc 9880 Part II [5] section 3.4 (i.e.
functional groups Basic + IHE + DIR + FTBP), with the goal of future
migration to configuration X (addition of functional group SEC).
[AMHS-GEN-B02] AMHS End Systems shall support the object classes and attribute types of A-2-P1, A-2-P2 X
directory information specified in ICAO EUR Doc 020 [8] Appendix B Annex
K.
[AMHS-GEN-B03] In accordance with the SES interoperability Regulation [1], AMHS End A-2-P1, A-2-P2 X
Systems shall support the implementation of advanced, agreed and
validated concepts of operation by providing managed access to the
messaging system for new end-user applications via well-defined
interfaces.
B.2.1.3 Naming and Addressing
[AMHS-N&A-B01] The responsible operators of AMHS Management Domains shall register a B-4.2-P1 X
unique directory name for each AMHS user in their domain.
B.2.1.4 Safety Requirements
B.2.1.5 Performance Requirements
B.2.2 ATS Message Server Requirements
B.2.2.1 General
B.2.2.2 P1 Message Transfer
[AMHS-AMS-B01] MTAs shall implement the P1 MTS transfer profile AMH11 as specified in A-2-P2 X
Annex A of this EUROCONTROL Specification, with the addition of support
of the DIR Functional Group as specified in ICAO Doc 9880 Part II [5]
section 3.2.4.2.

Edition: 2.1 Released Issue Appendix 1-22

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-AMS-B02] MTAs should implement the SEC Functional Group of the P1 IPM A-2-P2 X
requirements profile AMH22, for security class S0, in addition to the
AMH22 requirements specified in Annex A of this EUROCONTROL
Specification.
B.2.2.3 P3 Message Transfer
[AMHS-AMS-B03] MTAs supporting direct message submission and delivery shall support P3 A-2-P2 X
access conforming to the profile in Appendix B Annex G of ICAO EUR Doc
020 [8].
[AMHS-AMS-B04] MTAs supporting direct message submission and delivery shall support A-2-P2 X
IPM P3 access conforming to the profile in Appendix B Annex C of ICAO
EUR Doc 020 [8], with the addition of support of the DIR Functional Group
as specified in ICAO Doc 9880 Part II [5] section 3.1.4.3.1.
[AMHS-AMS-B05] MTAs should additionally implement the SEC Functional Group of the IPM A-2-P2 X
P3 Access profile AMH23/AMH25, for security class S0.
B.2.2.4 Directory Access
[AMHS-AMS-B06] An ATS Message Server implementing the DIR functional group shall A-2-P2 X
include a DUA for access to the ATN Directory.
B.2.3 ATS Message Server Requirements
B.2.3.1 General
[AMHS-AMU-B01] An ATS Message User Agent supporting the Extended ATSMHS shall B-4.2-P1 X
comply with the requirements specified in section 3.1 of ICAO Doc 9880
Part II [5] for the support of the Extended ATSMHS, summarised as the
following requirements;
• A UA profile based on Profile AMH21 as specified in Appendix B
Annex A of ICAO EUR Doc 020 [8];
• The requirements of Repertoire Group A, for messages including a
body part whose type is an Extended Body Part Type of general-text-
body-part type;
• Support of the IPM Business Class (BC) functional group
• Support of the file-transfer body part;
• UA access profile based on Profiles AMH23 or AMH25 for P3 access
to the MTS, or based on Profiles AMH24 or AMH26 for P7 access to
the MS, as specified in Appendix B Annexes C, D and E of ICAO EUR
Doc 020 [8];
• The additional provisions relating to parameters generated at an ATS
Message User Agent, as specified for the Extended ATSMHS;
• Provisions related to traffic logging.
• A DUA profile supporting the defined access profile and the specified
object classes and attribute types.

Edition: 2.1 Released Issue Appendix 1-23

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
B.2.3.2 IPM Content
[AMHS-AMU-B02] A UA in an ATS Message User Agent supporting the Extended ATSMHS A-2-P2 X
shall conform to the profile in Appendix B Annex A of ICAO EUR Doc 020
[8].
[AMHS-AMU-B03] A UA in an ATS Message User Agent shall be prohibited from sending B-4.2-P1 X
messages containing a Bilaterally Defined body part.
[AMHS-AMU-B04] A UA shall additionally implement the elements of the BC Functional Group A-2-P2, B-4.2-P1 X
of the IPM Content profile AMH21 indicated as “m” in the “Support” column
of Table B-1, as specified in ICAO Doc 9880 Part II [5], section 3.1.4.2.1.
[AMHS-AMU-B05] The values of the precedence field in the per-recipient heading fields of a B-4.2-P1 X
message shall be the same for all recipients, as this field corresponds to
AFTN Priority.
B.2.3.3 P3 Access
[AMHS-AMU-B06] A UA supporting P3 access shall conform to the profile in Appendix B A-2-P2 X
Annex G of ICAO EUR Doc 020 [8].
[AMHS-AMU-B07] A UA supporting P3 access shall conform to the profile in Appendix B A-2-P2 X
Annex C of ICAO EUR Doc 020 [8], with the addition of support of the DIR
Functional Group as specified in ICAO Doc 9880 Part II [5] section
3.1.4.3.1.
[AMHS-AMU-B08] It is recommended that a UA supporting P3 access should conform to the A-2-P2 X
MTS Access profile AMH23.
[AMHS-AMU-B09] A UA should additionally implement the SEC Functional Group of the P3 A-2-P2 X
Access profile AMH12/AMH14, for security class S0.
B.2.3.4 P7 Access
[AMHS-AMU-B10] A UA supporting P7 access shall conform to the profile in Appendix B A-2-P2 X
Annex H, or Appendix B Annex I of ICAO EUR Doc 020 [8].
[AMHS-AMU-B11] A UA supporting P7 access shall conform to the profile in Appendix B A-2-P2 X
Annex D, or Appendix B Annex E of ICAO EUR Doc 020 [8], with the
addition of support of the DIR Functional Group as specified in ICAO Doc
9880 Part II [5] section 3.1.4.3.1.
[AMHS-AMU-B12] It is recommended that a UA supporting P7 access should conform to the A-2-P2 X
Enhanced MS Access profile AMH24.
[AMHS-AMU-B13] A UA supporting P7 access should additionally implement the SEC A-2-P2 X
Functional Group of the IPM P7 Access profile AMH24/AMH26, for security
class S0 (only).
[AMHS-AMU-B14] A UA supporting P7 access shall additionally implement the BC Functional A-2-P2 X
Group of the IPM P7 Access profile AMH24/AMH26 as specified in ICAO
Doc 9880 Part II [5], section 3.1.4.3.1, for the IPM heading fields indicated
as “m” in Table B-1.

Edition: 2.1 Released Issue Appendix 1-24

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
B.2.3.5 Directory Access
[AMHS-AMU-B15] An ATS Message User Agent implementing the DIR functional group shall A-2-P2 X
include a DUA for access to the ATN Directory.
B.2.4 ATS Message Server Requirements
B.2.4.1 General
B.2.4.2 MS Access to MTA
[AMHS-MST-B01] An MS which supports P3 access in an ATS Message Server supporting A-2-P2 X
the Extended ATSMHS shall conform to the profile in Appendix B Annex G
of ICAO EUR Doc 020 [8].
[AMHS-MST-B02] An MS which supports P3 access in an ATS Message Server supporting A-2-P2 X
the Extended ATSMHS shall conform to the profile in Appendix B Annex C
of ICAO EUR Doc 020 [8], with the addition of support of the DIR
Functional Group as specified in ICAO Doc 9880 Part II [5], section 3.2.4.4.
[AMHS-MST-B03] It is recommended that an MS supporting P3 access should conform to the A-2-P2 X
MTS Access profile AMH23.
[AMHS-MST-B04] An MS which supports P3 access should additionally implement the SEC A-2-P2 X
Functional Group of the IPM P3 Access profile AMH23/AMH25, for security
class S0.
[AMHS-MST-B05] An MS which accesses the MTA by local means shall provide equivalent A-2-P2 X
message submission and delivery functionality to that specified in the P3
access profile above.
B.2.4.3 P7 Access
[AMHS-MST-B06] An MS in an ATS Message Server supporting the Extended ATSMHS shall A-2-P2 X
conform to the P7 access profile in Appendix B Annex H, or Appendix B
Annex I of ICAO EUR Doc 020 [8] for message retrieval and indirect
submission.
[AMHS-MST-B07] An MS in an ATS Message Server supporting the Extended ATSMHS shall A-2-P2 X
conform to the profile in Appendix B Annex D, or Appendix B Annex E of
ICAO EUR Doc 020 [8], with the addition of support of the DIR Functional
Group as specified in ICAO Doc 9880 Part II [5], section 3.1.4.3.1.
[AMHS-MST-B08] An MS in an ATS Message Server supporting the Extended ATSMHS A-2-P2 X
should additionally implement the SEC Functional Group of the IPM P7
Access profile AMH24/AMH26, for security class S0 (only).
[AMHS-MST-B09] An MS in an ATS Message Server supporting the Extended ATSMHS shall A-2-P2 X
additionally implement the BC Functional Group of the IPM P7 Access
profile AMH24/AMH26 as specified in ICAO Doc 9880 Part II [5], section
3.1.4.3.1 for the IPM heading fields indicated as “m” in Table B-1.
B.2.5 ATS Message Server Requirements
B.2.5.1 General

Edition: 2.1 Released Issue Appendix 1-25

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
B.2.5.2 Directory Access
[AMHS-GWY-B01] An AFTN/AMHS Gateway implementing the DIR functional group shall A-2-P2 X
include a DUA for access to the ATN Directory.
[AMHS-GWY-B02] It is recommended that the DUA in an AFTN/AMHS Gateway supporting A-2-P2 X
the Extended ATSMHS should be used to retrieve information in support of
address and content conversion.
B.3 CONFORMITY ASSESSMENT MATERIALS
B.3.1 Compliance Statement
[AMHS-CA-B01] A claim of conformance for an implementation shall be supported by A-1-P1, Annex IV- X Part of Technical File
completion of the relevant Protocol Implementation Conformance P4
Statement (PICS) pro forma.
[AMHS-CA-B02] Implementers claiming conformance to the specified services shall A-1-P1, Annex IV- X Part of Technical File
complete the PICS specified in Appendix B Annex Q of ICAO EUR Doc P4
020 [8], taking due account of the specific requirements for
implementations of AMHS End Systems supporting the Extended ATSMHS
specified in this Annex of the EUROCONTROL Specification.
[AMHS-CA-B03] Implementers shall state whether all of the requirements and which of the A-1-P1, Annex IV- X Part of Technical File
optional elements of the AFTN/AMHS Gateway supporting the Extended P4
ATSMHS as specified in ICAO Doc 9880 Part II [5] Chapter 4 have been
implemented, using the pro forma tables in this section or equivalent.
[AMHS-CA-B04] For AFTN/AMHS Gateway implementations, a PICS shall be provided A-1-P1, Annex IV- X Part of Technical File
stating the level of support, for each of the elements relevant to support of P4
the Extended ATSMHS, listed in the profile requirements lists in Chapter 4
of ICAO Doc 9880 Part II [5] and specified in Table B-3.
[AMHS-CA-B05] AMHS End Systems supporting the Extended ATSMHS shall be tested A-1-P1, Annex IV- X Part of Technical File
according to suitable test cases and procedures ensuring adequate P4
coverage of the IHE, FTBP and DIR functional groups.
[AMHS-CA-B06] Testing shall be conducted within a common framework consistent with the A-1-P1, Annex IV- X Part of Technical File
procedures in ICAO EUR Doc 020 [8] using appropriate test tools and P4
procedures.

Edition: 2.1 Released Issue Appendix 1-26

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

A1.3.3 Annex C – Directory Service

Table 5: Annex C – Directory Service
Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
C.2 REQUIREMENTS AND EXPLANATORY MATERIALS
C.2.1 General Directory Requirements
[AMHS-DIR-C01] AMHS End Systems supporting the DIR functional group shall include A-2-P1, A-2-P2 X
access to directory information as specified in the schema defined in ICAO
Doc 9880 Part IV Chapter 2 [7].
[AMHS-DIR-C02] The directory functionality shall comply with the standards and ISPs A-2-P1, A-2-P2 X
referenced from ICAO Doc 9880 Part IV Chapter 2 [7]
[AMHS-DIR-C03] Directory protocols shall operate over the TCP transport service as B-4.2-P1 X
specified in ICAO Doc 9880 Part IV Chapter 2 [7], section 2.5.7.6.
C.2.1.1 Architecture
[AMHS-DIR-C04] In order to guarantee the consistency of the shared part(s) of the DIT, it A-1-P1 X
shall be ensured that each DSA:
a) has a common view of the schema for the shared data,
b) supports a common means of directory replication and/or chaining /
referral of queries,
c) does not require any modification of the data replicated from other
DSAs.
[AMHS-DIR-C05] The DSA shall implement DSP to support the exchange of data with other B-4.2-P1 X
DSAs.
[AMHS-DIR-C06] The DSA should implement DISP including support for incremental and full B-4.2-P1 X
shadow updates, supplier and consumer initiated, scheduled and on-
change updates, attribute filtering and chop shadowing.
[AMHS-DIR-C07] The DSA shall support the bind operation using as a minimum simple B-4.2-P1, A-3-P5 X
authentication for DAP, DSP and DISP as defined in the base standards.
[AMHS-DIR-C08] The DSA should additionally support the bind operation using strong B-4.2-P1, A-3-P5 X
authentication for DAP, DSP and DISP as defined in the base standards.
[AMHS-DIR-C09] The Directory service implementation shall allow additional directory object A-2-P1 X
classes and attributes to be included in order to allow the use of this
service by other applications within the scope of other private or EATMN
directory service deployment.
[AMHS-DIR-C10] The DSA shall have the ability to export and import directory information in B-4.2-P1 X
Lightweight Directory Access Protocol Interchange Format (LDIF) format,
where applicable.
C.2.1.2 Directory User Agent access

Edition: 2.1 Released Issue Appendix 1-27

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-DIR-C11] The DSA shall implement DAP to support user access to the directory B-4.2-P1 X
information.
[AMHS-DIR-C12] The DSA may also implement other access protocols based on LDAP [39] A-2-P1 X
or a proprietary protocol to support user access to the directory information.
[AMHS-DIR-C13] If DAP or LDAP is implemented by the DUA, the use of “referral” identifying A-2-P1 X
a DSA external to the EATMN should be strictly controlled.
C.2.1.3 Directory Contents Access Policy
[AMHS-DIR-C14] It shall be possible to define access control policy in order to regulate what A-2-P1, A-3-P5 X
type of operation can be performed on a directory entry, attributes or
values.
[AMHS-DIR-C15] The basic operations listed in Table C-1 shall be supported by DSAs and B-4.2-P1 X
selectively by DUAs depending upon the type of DUA as defined in Table
2-18 of ICAO Doc 9880 Part IV Chapter 2 [7].
C.2.2 AMHS-Specific Directory Requirements
C.2.2.1 Directory Functions in support of AMHS
[AMHS-DIR-C16] The Directory implementation shall support the following functions: B-4.2-P1 X
a) Name resolution
b) Distribution list (DL) expansion and management
c) Determination of recipient (direct/indirect UA or DL) capabilities
d) AFTN/AMHS address conversion and publication
[AMHS-DIR-C17] The Directory implementation should additionally support the following B-4.2-P1 X
function, if required:
e) Retrieval of security certificates and CRLs
[AMHS-DIR-C18] The Directory implementation may additionally support one or more of the B-4.2-P1 X
following functions:
f) Support for system configuration
g) AMHS systems management information
h) Address book
[AMHS-DIR-C19] AMHS End System support of the directory functions shall be as indicated B-4.2-P1 X
in Table C-2
C.2.2.2 Directory Information in support of AMHS
[AMHS-DIR-C20] The Directory information tree exported by Border DSAs shall conform to B-4.2-P1 X
the DIT structure defined in ICAO Doc 9880 Part IV Chapter 2 [7], unless
otherwise stated in this section.
[AMHS-DIR-C22] It is recommended that only the eds-amhs-user object class, as specified B-4.2-P1 X
in Annex G-B of ICAO EUR Doc 020 [8], should be used to represent users
which have the capability to send/receive AMHS messages to/from other
ATSMHS users.

Edition: 2.1 Released Issue Appendix 1-28

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-DIR-C23] It is recommended that the exported / imported sub-trees should be B-4.2-P1 X
attached to the country root DIT.
[AMHS-DIR-C24] The DSA shall use this DIT structure to support the name resolution B-4.2-P1 X
function, using object-classes specified in Annex G-B of ICAO EUR Doc
020 [8].
[AMHS-DIR-C25] The DSA shall use this DIT structure to support the DL expansion and B-4.2-P1 X
management function, with MTAs accessing members of the atn-amhs-
distribution-list object-class.
[AMHS-DIR-C26] The DSA shall use this DIT structure to support the AFTN/AMHS address B-4.2-P1 X
conversion function performed by the AFTN/AMHS Gateway using object
classes specified in Annex G-B of ICAO EUR Doc 020 [8].
[AMHS-DIR-C27] [Requirement deleted]
[AMHS-DIR-C28] [Requirement deleted]
C.2.2.3 Simple AMHS Address Conversion Directory Algorithm
[AMHS-DIR-C29] Each State or organisation participating in the EDS shall implement a DSA A-1-P1, B-4.2-P1 X
containing a DIT sub tree shadowed from the Central European DSA
based on a member of the organization object-class named O=European-
Directory, as specified in Appendix G-B of ICAO EUR Doc 020 [8]
[AMHS-DIR-C30] The Directory information shall support address conversion between AMHS B-4.2-P1 X
and AFTN address types.
[AMHS-DIR-C31] An O/R Address (MF-Address) included in an AMHS message shall be B-4.2-P1 X
processed for translation into the AFTN address in one of four mutually
exclusive manners, depending on the MF-Address format, after preliminary
conversion of all address attribute values to upper case characters
[AMHS-DIR-C32] For AFTN to AMHS address conversion, the algorithm described in B-4.2-P1 X
Appendix G-B, section 5.1 of ICAO EUR Doc 020 [8] shall be supported
[AMHS-DIR-C33] States supporting the CAAS scheme within the EATMN should register A-2-P1 X
values of the "Organization Name" field with length not exceeding 8
characters.
C.2.3 Directory support of PKI
[AMHS-DIR-C34] When being used to provide Directory support for PKI, the DSA shall use A-2-P1, A-3-P5 X
the specified DIT structure to provide support for retrieval of security
certificates and CRLs, using atn-amhs-user (attribute atn-der-certificate)
and atn-certification-authority object-classes.
C.2.4 System capacity and performance
[AMHS-DIR-C35] The DSA design should be scalable in a cost effective manner in order to A-2-P1 X
be able to store more AMHS information and support additional DUA
directory operations.

Edition: 2.1 Released Issue Appendix 1-29

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
C.3 CONFORMITY ASSESSMENT MATERIALS
C.3.1 Object Class Requirements
[AMHS-CA-C01] DSAs shall implement as a minimum the object classes specified in Table A-1-P1, B-4.2-P1 X
C-3 to Table C-6 and, for DSAs participating in EDS, the EDS-specific
object classes specified in ICAO EUR Doc 020 [8], in order to guarantee
correct understanding of the data shared between DMDs
C.3.2 Attribute Requirement
[AMHS-CA-C02] Table C-7 specifies the attributes that shall be used in support of the B-4.2-P1 X
ATSMHS for each required object class.
C.3.3 List of X.500 Global Statement and Protocol Operations Supported by the Directory Service
[AMHS-CA-C03] Table C-8 specifies the overall conformance and protocol operations that B-4.2-P1 X
shall be used in support of the ATSMHS for each mandatory object class.
C.3.4 Requirements statement for DUAs
[AMHS-CA-C04] Implementers shall state whether all of the requirements and which of the B-4.2-P1 X
optional elements of the DUA supporting the Extended ATSMHS, as
specified in ICAO Doc 9880 Part IV Chapter 2 [7] section 2.5.2.1, have
been implemented, using the table in this section or equivalent.
C.3.5 Requirements statement for DSAs
[AMHS-CA-C05] Implementers shall state whether all of the requirements and which of the B-4.2-P1 X
optional elements of the DSA supporting the Extended ATSMHS, as
specified in ICAO Doc 9880 Part IV Chapter 2 [7] section 2.5.2.2, have
been implemented, using the table in this section or equivalent.
C.3.6 Requirements statement for Conformance by a Shadow Supplier
[AMHS-CA-C06] For a DSA supporting DISP, implementers shall state whether all of the B-4.2-P1 X
requirements and which of the optional elements of the DSA supporting the
Extended ATSMHS, as specified in ICAO Doc 9880 Part IV Chapter 2 [7]
section 2.5.5, have been implemented, using the table in this section or
equivalent.
C.3.7 Requirements statement for Conformance by a Shadow Consumer
[AMHS-CA-C07] For a DSA supporting DISP, implementers shall state whether all of the B-4.2-P1 X
requirements and which of the optional elements of the DSA supporting the
Extended ATSMHS, as specified in ICAO Doc 9880 Part IV Chapter 2 [7]
section 2.5.5, have been implemented, using the table in this section or
equivalent.

Edition: 2.1 Released Issue Appendix 1-30

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

A1.3.4 Annex D – Security

Table 6: Annex D – Security
Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
D.2 REQUIREMENTS AND EXPLANATORY MATERIALS
D.2.1 Introduction
D.2.2 General Requirements
D.2.2.1 Security Architecture
[AMHS-SEC-D01] An AMHS End System implementation shall implement protocol provisions A-3-P3, A-3-P5 X
as necessary to comply with the local security policy relating to
aeronautical data access and interchange.
[AMHS-SEC-D02] Measures should be taken by ANSPs and other entities providing data A-3-P1 X
communications services to ensure appropriate security of information
exchanges
[AMHS-SEC-D04] Implementations shall be conformant with the Extended ATSMHS and in A-3-P5 X
particular the security aspects of ATN relevant for ground-ground
communication; Chapter 8.3.1.1 (Framework Standards) of the ATN
Security provisions [6] is fully applicable.
[AMHS-SEC-D05] Each State implementing AMHS Security shall designate a Trusted Third A-3-P5 X
Party (TTP) acting as a Root Certificate Authority (CA) which issues
certificates and certificate revocation lists (CRLs), in accordance with
chapter 8.3.1.2.2 of the ATN Security provisions [6]
[AMHS-SEC-D06] The TTP shall conform to the ETSI Guide EG 201 057 [13], which defines A-3-P5 X
the role and attribution of a TTP acting as a CA in a PKI.
[AMHS-SEC-D07] Item 8.3.1.2.3 of the ATN Security provisions [6] shall be applicable in the A-3-P5 X
conditions provided below.
[AMHS-SEC-D08] CAs in the EATMN shall use policies to ensure the overall security of the A-3-P5 X
ATN.
[AMHS-SEC-D09] CAs shall be conformant with the Community framework for electronic A-3-P5 X
signatures specified in the Regulation on electronic identification and trust
services for electronic transactions [2].
[AMHS-SEC-D10] CAs shall comply with the certificate policy requirements defined in ETSI A-3-P5 X
policy and security requirements for Trust Service Providers issuing
certificates [14]
[AMHS-SEC-D11] Where the ATN Security provisions [6] refer to RFC 2527, this shall be A-3-P5 X
replaced with a reference to RFC 3647 [21]
[AMHS-SEC-D12] CAs shall develop a Certificate Policy (CP) that defines the creation, A-3-P5 X
management, and use of public key certificates that they issue, consistent
with section 8.4.1.1 of the ATN Security provisions [6]

Edition: 2.1 Released Issue Appendix 1-31

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SEC-D13] CAs shall publish a Certificate Practice Statement (CPS) that describes the A-3-P5 X
expected use of public key certificates that they issue, consistent with
section 8.4.2.1 of the ATN Security provisions [6]
[AMHS-SEC-D14] The CP and CPS shall be aligned with the framework presented in RFC A-3-P5 X
3647 [21].
[AMHS-SEC-D15] Each CA shall define its own CPS conformant with the rules defined in the A-3-P5 X
ETSI policy and security requirements for Trust Service Providers issuing
certificates [14].
[AMHS-SEC-D16] Each CA shall propose a service for certificate and CRL distribution. A-3-P5 X
[AMHS-SEC-D17] Each CA shall give simple access to the public certificate and CRL A-3-P5 X
repository in its own domain.
[AMHS-SEC-D18] The distribution system of public key certificates and CRLs should be done A-3-P5 X
using Directory services.
[AMHS-SEC-D19] Where item 8.3.1.2.7 of the ATN Security provisions [6] refers to use of a A-3-P5 X
directory service for certificate and CRL distribution, this shall be taken to
mean conformity with the Directory as specified in Annex C of this
EUROCONTROL Specification.
D.2.2.2 Cryptographic and Hashing functions
[AMHS-SEC-D20] The EATMN PKI in support of AMHS should therefore be based on a A-3-P5 X
common ATS Bridge CA (see Figure C-2) in order to:
a) Simplify the process of cross-certification for each CA;
b) Minimise the issues due to multiple policy agreements;
c) Minimise the risk of problems occurring due to the limit of validity
of cross certificates;
d) Allow a central organisation to verify that the policy applied by
each CA complies with the European Regulation on a Community
framework for electronic signatures [2].
[AMHS-SEC-D21] The cryptographic signing and hashing functions and parameter settings A-3-P5 X
shall be conformant with ATN Security provisions [6] Chapter 8.5.
[AMHS-SEC-D22] The general certificate format used for ATN PKI certificates shall be A-3-P5 X
conformant with the X.509 Format with parameters defined in chapter 8.4.3
of the ATN Security provisions [6]
[AMHS-SEC-D23] The signature scheme E-ATSMHS-SEC shall be conformant, for the hash A-3-P5 X
function, to the Secure Hash Standard (SHA-1, SHA-224, SHA-256, SHA-
384, and SHA-512) defined in the Federal Information Processing Standard
for Secure Hash Standard (SHS) [15].
[AMHS-SEC-D24] The elements of a certificate should be encoded following the DER A-3-P5 X
(Distinguished Encoding Rules) standard defined in ITU-T Rec X.509 and
specified by ITU-T Rec X.690 [36].

Edition: 2.1 Released Issue Appendix 1-32

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SEC-D25] It is recommended that a symmetric algorithm should be used for the A-3-P5 X
Content Integrity Check algorithm in Extended ATSMHS, and that this
should initially be the secure hash algorithm “SHA-1”.
D.2.3 AMHS Security Specific Requirements
D.2.3.1 Security Policy
[AMHS-SEC-D26] If secure messaging is required in the Extended ATSMHS, a general A-3-P5 X
AMHS end-to-end security policy shall be implemented in compliance with
ICAO Doc 9880 Part II [5] section 2.2.3, providing the following security
services:
a) Message origin authentication; and
b) Content integrity.
[AMHS-SEC-D27] An appropriate security policy shall be implemented in order to secure the A-3-P5 X
AMHS, notably by applying common security rules to protect the distributed
physical resources supporting message submission, transfer and delivery.
[AMHS-SEC-D28] For messages using these security services, the processing of the A-3-P5 X
message envelope shall be in compliance with ICAO Doc 9880 Part II [5]
sections 3.1.4.3 and 3.2.4.
D.2.3.2 AMHS Security Framework
[AMHS-SEC-D29] The Security model given in §2.2.3 of the AMHS technical provisions in A-3-P5 X
ICAO Doc 9880 Part II [5] shall be applied.
[AMHS-SEC-D30] The general AMHS security policy shall be aligned with the general ATN A-3-P5 X
Security Framework as defined in the ATN Security provisions [6] this is a
common minimum which does not prevent specific communities of AMHS
users from implementing more stringent security policies in case of
additional user requirements.
[AMHS-SEC-D31] The use of AMHS security services shall apply to: A-3-P5 X
a) communications between direct AMHS users supporting the Extended
ATSMHS; and
b) communications from direct AMHS users to indirect AMHS users as
far as the AFTN/AMHS Gateway supporting the Extended ATSMHS.
[AMHS-SEC-D32] The AMHS security policy shall make use of the Elliptic Curve Digital A-3-P5 X
Signature Algorithm (ECDSA) as specified in the ATN Security provisions
[6] section 8.5.5.
[AMHS-SEC-D33] For the support of security in the context of the Extended ATSMHS, an A-3-P5 X
ATS Message User Agent shall implement the Security requirements
defined in §3.1.4.3.3 of ICAO Doc 9880 Part II [5]

Edition: 2.1 Released Issue Appendix 1-33

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SEC-D34] The generation by the ATS Message User Agent of the message token in A-3-P5 X
the per-recipient-extensions of the message envelope shall be as specified
in section 3.1.3.4 of ICAO Doc 9880 Part II [5] refined as specified in this
Annex.
[AMHS-SEC-D35] For the support of security in the context of the Extended ATSMHS, an A-3-P5 X
MTA in an ATS Message Server shall implement the requirements for the
support by an MTA of the SEC Functional Group, implementing Security-
Class S0, as defined in §3.2.4.3 b) of ICAO Doc 9880 Part II [5]
[AMHS-SEC-D36] For the support of security in the context of the Extended ATSMHS, a A-3-P5 X
Message Store in an ATS Message Server shall implement the
requirements for the support by an MS of the SEC Functional Group,
implementing Security-Class S0, as defined in §3.2.4.4 b) of ICAO Doc
9880 Part II [5]
[AMHS-SEC-D37] For the support of security in the context of the Extended ATSMHS, an A-3-P5 X
AFTN/AMHS Gateway shall implement the requirements for handling the
security-related elements of the message transfer envelope as defined in
§4.5.2.4.16 to 4.5.2.4.22 of ICAO Doc 9880 Part II [5]
[AMHS-SEC-D38] It is recommended that to simplify certificate signature checking, and A-3-P5 X
facilitate interoperability, the certificate (and CRL) extensions that may be
used within the Extended ATSMHS are precisely defined and kept to a
minimum.
D.2.3.3 Recommendations for Secure Message Submission
[AMHS-SEC-D39] A message originator wishing to send a secure message at an ATS A-3-P5 X
Message User Agent that supports AMHS SEC shall create and sign a
message-token for each recipient in the per-recipient-extensions in the
message envelope.
[AMHS-SEC-D40] The MessageTokenSignedData should include only the CIC algorithm A-3-P5 X
identifier and the CIC value, computed using a symmetric algorithm.
[AMHS-SEC-D41] It is recommended that message originators using AMHS Security should A-3-P5 X
provide a valid certificate containing the required public key in the
originators-certificate element in the message envelope extensions.
[AMHS-SEC-D42] It is recommended that use of the multiple-originator-certificates element in A-3-P5 X
the message envelope extensions should be prohibited on message
submission.
D.2.3.4 Recommendations for Secure Message Reception

Edition: 2.1 Released Issue Appendix 1-34

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SEC-D43] It is recommended that on receipt of a message containing the originator’s A-3-P5 X
certificate in the message envelope extensions, the originator’s O/R
Address should be compared with one found in the Subject Alternative
Name extension of the certificate to ensure that the supplied certificate is
associated with the message originator.
[AMHS-SEC-D44] It is recommended that an OCSP Responder compliant with RFC 2560 [41] A-3-P5 X
should be deployed to facilitate the verification of received certificates.
[AMHS-SEC-D45] An application should validate the message token, contained in the A-3-P5 X
message delivery envelope extensions, when the message is first received,
including:
a) Verifying the time field in the message token;
b) Applying the CIC Algorithm Id to the received message content /
stated algorithm id, and comparing this to the received CIC Hash
value;
c) Applying the Signature Algorithm Id and originator’s certificate public
key to the whole contents of the Asymmetric Token, and comparing
this with the token signature;
d) Checking the Recipient Name in the message-token.
[AMHS-SEC-D46] A receiving application should report an error if a message-token that is A-3-P5 X
‘too old’ is received (except when displaying an archived message).
[AMHS-SEC-D47] The maximum acceptable time difference between the time field in the A-3-P5 X
message token and the current system time should be specified in the
security policy.
[AMHS-SEC-D48] If a message is received that is too old, the receiving application should A-3-P5 X
check the message integrity but ignore the signature.
[AMHS-SEC-D49] When applying the CIC Algorithm Id to the received message content / A-3-P5 X
stated algorithm id, and comparing this to the received CIC Hash, it is
recommended that the AMHS SEC convention is to use the message
content as received, i.e. the recipient should not need to ensure that it is
DER-encoded.
D.2.3.5 Message Sequence Integrity
[AMHS-SEC-D50] Message sequence integrity should be achieved by the message originator A-3-P5 X
setting the Time field in the Message Token to the current time, and the
message recipient checking that the value of this field is within acceptable
parameters.

Edition: 2.1 Released Issue Appendix 1-35

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SEC-D51] Message sequence integrity may be provided according to ISO/IEC 10021- A-3-P5 X
4 | ITU-T Recommendation X.411 [18], section 8.2.1.1.1.26. In an AMHS
End System supporting the Extended ATSMHS, the message-sequence-
number may be present in the asymmetric token
MessageTokenSignedData. The first occurrence of a message sequence
number may be a random number.
[AMHS-SEC-D52] However, it is recommended that applications using the Extended A-3-P5 X
ATSMHS should avoid using the message-sequence-number field in the
Message Token for message sequence integrity assurance.
D.3 CONFORMITY ASSESSMENT MATERIALS
[AMHS-CA-D01] For ATS Message User Agent implementations supporting the SEC B-4.2-P1 X
functional group, a PICS shall be provided stating the level of support, for
each of the elements listed in the profile requirements list in Table 3-3 of
ICAO Doc 9880 Part II [5].
[AMHS-CA-D02] Support for message-sequence-number in the message token signed-data, B-4.2-P1 X
which is indicated as “Optional” in the referenced PRL, should be made “M”
(Mandatory), to allow for the possible provision of the Message Sequence
Integrity function.
[AMHS-CA-D03] Support for the encrypted-data and content-confidentiality-algorithm-id B-4.2-P1 X
fields in the message token, which is indicated as “Optional” in the
referenced PRL, should be considered “out of scope”, and not used when
communicating with AMHS users compliant with this EUROCONTROL
Specification, since the AMHS security model in ICAO Doc 9880 Part II [5],
does not include message confidentiality.
APPENDIX 1 TO ANNEX D
PDR Resolutions Applicable to ICAO Doc 9705, Third Edition, Sub-Volume VIII

Edition: 2.1 Released Issue Appendix 1-36

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS) APPENDIX 1 – TRACEABILITY MATRIX
SES/IOP/AMHS/SPEC/2.1

Essential

Demo

Audit
Test

Eval
Requirement Requirements
Reference Requirement Description Reference Notes
[AMHS-SEC-D54] Security implementations shall include the relevant PDR resolutions from A-3-P5 X
the following list:
PDR ref Title
M1030007 Security - Editorial errors found during development of
Guidance Material
M1030008 Security - Defects found during development of
Guidance Material
M2030004 All SV - Editorials (version of PDR current on
2004/05/28)
M2080001 SV8 - Unnecessary random challenge field
M2080003 Security - Clarify representation of AMHS identities in
ATN certificates
M2080004 Security - Additional extensions in CA certificates
M2080005 Security - Clarify ATN CRL processing
M2080006 Security - Add warning concerning the use of invalid keys
by the secret value derivation primitive
M2080007 Security - Remove CheckResult references from 8.6.3
M2080008 Security - Remove duplicate certificate retrieval
requirements
M2080009 Security - Sub-Volume VIII ASN.1
M2090002 SV8, SV4 - SSO-GetCertificatePath target
M2090003 SV8 - ASN.1 padding issues
M2090004 SV8 - SSO-SessionKey Certificate Knowledge
M2090005 SV8 - SSO counter initialization
M2100005 SV8 - Tagging in SV8 ASN.1 module
M4020001 Security - Error in ATN Key Derivation Function
M4030001 SV8 - Missing requirement on User Data padding
M4050007 SV8 - Key lifetime clarification
M6080004 SV8 - Directory Security Requirements

Edition: 2.1 Released Issue Appendix 1-37

 EUROCONTROL Specification for the Air Traffic Services Message Handling
System (AMHS)

APPENDIX 2

Editions of Referenced ISO/IEC Standards, ITU-T Recommendations and IETF

RFCs

TABLE OF CONTENTS

Appendix 2. Editions of Referenced Standards ................................................................ 2

A2.1 INTRODUCTION ................................................................................................. 2
A2.2 LIST OF REFERENCED STANDARDS............................................................... 2

LIST OF TABLES

Table 1: Standards Referenced in ICAO Doc 9880 Part II ..................................................... 3

Table 2: ICAO Doc 9880 Part II Referenced Standardized Profiles ....................................... 4
Table 3: ICAO Doc 9880 Part II Referenced RFCs ............................................................... 5
Table 4: Equivalent ISO/IEC Standards & ITU-T Directory Recommendations ..................... 5
Table 5: Standards Referenced in ICAO Doc 9880 Part IV Chapter 2 ................................... 5
Table 6: ICAO Doc 9880 Part IV Referenced Standardized Profiles...................................... 7
Table 7: ICAO Doc 9880 Part IV Referenced RFCs .............................................................. 8
Table 8: ICAO Doc 9705 Sub-Volume VIII Referenced Standards ........................................ 8
Table 9: ICAO Doc 9705 Sub-Volume VIII Referenced RFCs ............................................... 9
Table 10: Standards Referenced in ICAO EUR Doc 020 Appendices B and G ..................... 9
Table 11: ICAO EUR Doc 020 Referenced Standardized Profiles ....................................... 10
Table 12: ICAO EUR Doc 020 Referenced RFCs ............................................................... 11

Edition: 2.1 Released Issue Appendix 2-1

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1

APPENDIX 2. EDITIONS OF REFERENCED STANDARDS

A2.1 INTRODUCTION
A2.1.1 This informational Appendix provides references to the current editions of
international standards that are invoked in the baseline ICAO detailed technical
specifications for the ATS Message Handling Service (ICAO Doc 9880 Part II), the ATN
Directory (ICAO Doc 9880 Part IV Chapter 2), ATN Security (ICAO Doc 9705 3rd Edition
Sub-Volume VIII) and the EUR AMHS Manual (ICAO EUR Doc 020).
A2.1.2 In many cases, these ICAO documents refer to specific editions of the standards,
identified by their year of publication. In other cases, they make non-specific references to
these standards (i.e. without edition number or year of publication).
A2.1.3 In support of implementers, tables in this Appendix show the latest editions of the
standards used/referenced in the ICAO documents. The intention is not to mandate their use
but to indicate the current standards editions (as at the date of publication of this
EUROCONTROL Specification). These latest editions may be used in place of the
referenced editions, provided backwards compatibility is maintained where any new
functionality is introduced in later editions.
A2.1.4 In case of doubt, the specific edition referred to in the ICAO documents remains
the master reference.
A2.1.5 As some of these editions are now unobtainable, the later edition may be used by
implementers, with the above provisos.

A2.2 LIST OF REFERENCED STANDARDS

A2.2.1 The following tables list the ISO/IEC standards, ITU-T Recommendations and
IETF RFCs that are referenced from the ICAO documents listed above. In general, these are
not qualified by a particular year or edition number.
A2.2.2 The left hand column gives the reference as given in the ICAO document. The right
hand column provides the full title and current status of the standard, taken from the
ISO online catalogue at https://www.iso.org/home.html or the ITU-T listing at
https://www.itu.int/itu-t/recommendations/index.aspx?ser=X. It also lists the relevant
Amendments and Technical Corrigenda to the base standard.
A2.2.3 Implementers are advised to check the latest version of the standards, which often
contain technical corrigenda compared with earlier versions.
A2.2.4 Table 1 lists the ISO/IEC standards | ITU-T Recommendations referenced in ICAO
Doc 9880 Part II (Ground-Ground Applications – Air Traffic Services Message Handling
Services (ATSMHS), Second edition).
Note: ISO/IEC 10021 multi-part standard “Information technology -- Message Handling
Systems (MHS)” was originally entitled “Information technology -- Text Communication --
Message-Oriented Text Interchange Systems (MOTIS)”.

Edition: 2.1 Released Issue Appendix 2-2

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1
Table 1: Standards Referenced in ICAO Doc 9880 Part II
ISO/IEC | ITU-T Title and Current Status
reference in ICAO Doc
9880 Part II
ISO 646 ISO/IEC 646:1991 Information technology -- ISO 7-bit coded character set
ISO/IEC 646:1991 for information interchange
Edition: 3 (1991)
ISO 8859-1 ISO/IEC 8859-1:1998 Information technology -- 8-bit single-byte coded
ISO/IEC 8859-1 graphic character sets -- Part 1: Latin alphabet No. 1
Edition: 1 (1998)
ISO/IEC 10021:1990 (Generic reference to all parts of ISO/IEC 10021 | ITU-T X.400 Series of
ISO/IEC 10021:2003 Recommendations. Basic AMHS service refers to profiles based on the
CCITT X.400 superseded 1990 edition; Extended service refers to profiles based on the
ITU-T X.400 current 2003 edition.)
ISO/IEC 10021-1:1990 Information technology -- Message Handling Systems (MHS) -- Part 1:
ISO/IEC 10021-1:2003 System and service overview
Edition 2 (2003)
ISO/IEC 10021-2 Information technology -- Message Handling Systems (MHS): Overall
architecture
Edition: 3 (2003)
ISO/IEC 10021-4 Information technology -- Message Handling Systems (MHS): Message
transfer system -- Abstract service definition and procedures
Edition: 3 (2003)
ISO 10021-4:1997/Cor. Corrigendum incorporated into 2003 edition
1:1998
ISO/IEC 10021-6 Information technology -- Message Handling Systems (MHS): Protocol
specifications
Edition: 3 (2003)
ISO/IEC 10021-7 Information technology -- Message Handling Systems (MHS): Interpersonal
ISO/IEC 10021-7:2003 messaging system
Edition: 3 (2003)
ISO 10021-7:1997/ Cor. Corrigendum incorporated into 2003 edition
1:1998.
ISO/IEC 9594 (Generic reference to multi-part Directory standard)
ISO/IEC 9594-2 Information technology -- Open Systems Interconnection -- The Directory:
Models
Edition: 8 (2017)
ISO/IEC 9594-8 / X.509, Information technology -- Open Systems Interconnection -- The Directory:
Public-key and attribute certificate frameworks
Edition: 8 (2017)
ISO/IEC 9646-7 ISO/IEC 9646-7:1995 Information technology -- Open Systems
Interconnection -- Conformance testing methodology and framework -- Part
7: Implementation Conformance Statements
Edition: 1 (1995)
Modified by ISO/IEC 9646-7:1995/Cor 1:1997
CCITT Rec X.400 ITU-T Recommendation F.400/X.400 (06/99): Message handling services:
Message handling system and service overview
CCITT Rec X.408 ITU-T Recommendation X.408 (11/1988): Message handling systems:
Encoded information type conversion rules
CCITT Rec X.509 ITU-T Recommendation X.509 (10/2016): Information technology – Open
Systems Interconnection – The Directory: Public-key and attribute certificate
frameworks
CCITT Rec X.666 ITU-T Recommendation X.666 (08/2008): Information technology – Open
Systems Interconnection – Procedures for the operation of OSI Registration
Authorities: Joint ISO and ITU-T registration of international organizations

A2.2.5 The following table lists the International Standardized Profiles (ISPs) referenced
in ICAO Doc 9880 Part II. Although these ISPs have been withdrawn and are no longer

Edition: 2.1 Released Issue Appendix 2-3

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1

maintained by ISO/IEC, implementations of AMHS Components are required to conform to

the last published versions of the ISPs or equivalent provisions which may be published
elsewhere.

Table 2: ICAO Doc 9880 Part II Referenced Standardized Profiles

ISO/IEC ISP reference in Title and last published version
ICAO Doc 9880 Part II
ISO/IEC ISP 10611-1 Information technology -- International Standardized Profiles AMH1n --
Message Handling Systems -- Common Messaging -- Part 1: MHS
Service Support
Edition: 3 (2003)
ISO/IEC ISP 10611-2 Information technology -- International Standardized Profiles AMH1n --
Message Handling Systems -- Common Messaging -- Part 2:
Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols
for use by MHS
Edition: 2 (1997)
ISO/IEC ISP 10611-3 Information technology -- International Standardized Profiles AMH1n --
ISO/IEC ISP 10611- Message Handling Systems -- Common Messaging -- Part 3: AMH11 --
3:1994 (or a later edition), Message Transfer (P1)
Edition: 3 (2003)
ISO/IEC ISP 10611- Information technology -- International Standardized Profiles AMH1n --
4:2003 Message Handling Systems -- Common Messaging -- Part 4: AMH12 and
AMH14 -- MTS Access (P3) and MTS 94 Access (P3)
Edition: 3 (2003)
ISO/IEC ISP 10611- Information technology -- International Standardized Profiles AMH1n --
5:2003 Message Handling Systems -- Common Messaging -- Part 5: AMH13 --
MS Access (P7)
Edition: 3 (2003)
ISO/IEC ISP 10611-6: Information technology -- International Standardized Profiles AMH1n --
2003 Message Handling Systems -- Common Messaging -- Part 6: AMH15 -
MS 94 Access (P7)
Edition: 2 (2003)
ISO/IEC ISP 11188-1 ISO/IEC ISP 11188-1:1995 Information technology -- International
Standardized Profile -- Common upper layer requirements -- Part 1: Basic
connection oriented requirements
Edition: 1 (1995)
ISO/IEC ISP 12062-2 Information technology -- International Standardized Profiles AMH2n --
ISO/IEC ISP 12062- Message Handling Systems -- Interpersonal Messaging -- Part 2: AMH21
2:1995 or later -- IPM Content
ISO/IEC ISP 12062- Edition: 3 (2003)
2:1988 [sic] or later
ISO/IEC ISP 12062-
2:2003
ISO/IEC ISP 12062- Information technology -- International Standardized Profiles AMH2n --
3:1995 (or a later edition) Message Handling Systems -- Interpersonal Messaging -- Part 3: AMH22
-- IPM Requirements for Message Transfer (P1)
Edition: 3 (2003)
ISO/IEC ISP 12062- Information technology -- International Standardized Profiles AMH2n --
4:1995 (or a later edition) Message Handling Systems -- Interpersonal Messaging -- Part 4: AMH23
ISO/IEC ISP 12062- and AMH25 -- IPM Requirements for MTS Access (P3) and MTS 94
4:2003 Access (P3)
Edition: 3 (2003)
ISO/IEC ISP 12062- Information technology -- International Standardized Profiles AMH2n --
5:1995 (or a later edition) Message Handling Systems -- Interpersonal Messaging -- Part 5: AMH24
ISO/IEC ISP 12062- -- IPM Requirements for Enhanced MS Access (P7)
5:2003 Edition: 3 (2003)

Edition: 2.1 Released Issue Appendix 2-4

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1
ISO/IEC ISP reference in Title and last published version
ICAO Doc 9880 Part II
ISO/IEC ISP 12062-6: Information technology -- International Standardized Profiles AMH2n --
2003 Message Handling Systems -- Interpersonal Messaging -- Part 6: AMH26
-- IPM Requirements for Enhanced MS 94 Access (P7)
Edition: 1 (2003)

A2.2.6 Table 3 lists the IETF RFCs referenced in ICAO Doc 9880 Part II (Ground-Ground
Applications – Air Traffic Services Message Handling Services (ATSMHS), Second edition).
Table 3: ICAO Doc 9880 Part II Referenced RFCs
IETF RFC reference in Title and Current Status
ICAO Doc 9880 Part II
RFC 1006:1987 (Also STD0035) ISO Transport Service on top of the TCP Version: 3. M.T.
Rose, D.E. Cass. May 1987.
(Obsoletes RFC0983) (Updated by RFC2126)
Status: STANDARD
RFC 2126:1997 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March
1997.
(Updates RFC1006)
Status: PROPOSED STANDARD)

A2.2.7 ICAO Doc 9880 Part IV Chapter 2 specifies that the directory aspects of ATN are
based on the ISO/IEC standards identified in the following table. These standards have
(almost) equivalent ITU-T Recommendations as identified in the second column of the table
and these are taken into account in this EUROCONTROL Specification.
Table 4: Equivalent ISO/IEC Standards & ITU-T Directory Recommendations
ISO/IEC reference in Equivalent ITU-T Title
ICAO Doc 9880 Part IV Recommendation
ISO/IEC 9594-1, 2001 X.500 The Directory: Overview of concepts, models and
services
ISO/IEC 9594-2, 2001 X.501 The Directory: Models,
ISO/IEC 9594-8, 2001 X.509 The Directory: Authentication framework,
ISO/IEC 9594-3, 2001 X.511 The Directory: Abstract service definition,
ISO/IEC 9594-4, 2001 X.518 The Directory: Procedures for distributed operation,
ISO/IEC 9594-5, 2001 X.519 The Directory: Protocol specifications,
ISO/IEC 9594-7, 2001 X.521 The Directory: Selected object classes,
ISO/IEC 9594-9, 2001 X.525 The Directory: Replication,

A2.2.8 Table 5 lists the ISO/IEC standards | ITU-T Recommendations referenced in ICAO
Doc 9880 Part IV Chapter 2 (Directory Services, Second edition).
Table 5: Standards Referenced in ICAO Doc 9880 Part IV Chapter 2
ISO/IEC | ITU-T Title and Current Status
reference in ICAO Doc
9880 Part IV Chapter 2
ISO 7498 Information processing systems -- Open Systems Interconnection -- Basic
Reference Model -- Part 2: Security Architecture
Edition 1 (1989)
ISO 6523 ISO/IEC 6523-2:1998
Information technology -- Structure for the identification of organizations
and organization parts -- Part 2: Registration of organization identification
schemes
Edition 1 (1998)

Edition: 2.1 Released Issue Appendix 2-5

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1

ISO/IEC | ITU-T Title and Current Status

reference in ICAO Doc
9880 Part IV Chapter 2
ISO 8649 Superseded by:
ISO/IEC 15953:1999
Information technology — Open Systems Interconnection — Service
definition for the Application Service Object Association Control Service
Element
Edition 1 (1999)
ISO 9072-2 SO/IEC 9072-2:1989 Information processing systems -- Text
communication -- Remote Operations -- Part 2: Protocol specification
Edition: 1 (1989)
ISO 9594-7 Information technology -- Open Systems Interconnection -- The Directory:
Selected object classes
Edition: 8 (2017)
ISO/IEC 8327-1 ISO/IEC 8327-1:1996 Information technology -- Open Systems
Interconnection -- Connection-oriented Session protocol: Protocol
specification
Edition: 2 (1996) See also Amendments (1998) and Corrigenda (2002)
ISO/IEC 8822 ISO/IEC 8822:1994 Information technology -- Open Systems
Interconnection -- Presentation service definition
Edition: 2 (1994) See also Amendments (1998)
ISO/IEC 9066-1 ISO/IEC 9066-1:1989 Information processing systems -- Text
communication -- Reliable Transfer -- Part 1: Model and service definition
Edition: 1 (1989)
ISO/IEC 10021-2 Information technology -- Message Handling Systems (MHS): Overall
architecture
Edition: 3 (2003)
ISO/IEC 13248-1 Information technology -- Open Systems Interconnection -- The Directory:
Protocol Implementation Conformance Statement (PICS) proforma for the
Directory Access Protocol
Edition: 1 (1998) WITHDRAWN
ISO/IEC 13248-2 Information technology -- Open Systems Interconnection -- The Directory:
Protocol Implementation Conformance Statement (PICS) proforma for the
Directory System Protocol
Edition: 1 (1998) WITHDRAWN
ISO/IEC 9594-1:1995 Information technology -- Open Systems Interconnection -- The Directory:
Overview of concepts, models and services
Edition: 8 (2017)
ISO/IEC 9594-2 Information technology -- Open Systems Interconnection -- The Directory:
Models
Edition: 8 (2017)
ISO/IEC 9594-5:1995 Information technology -- Open Systems Interconnection -- The Directory:
Protocol specifications
Edition: 8 (2017)
ISO/IEC 9594-6:1995 Information technology -- Open Systems Interconnection -- The Directory:
Selected attribute types
Edition: 8 (2017)
ISO/IEC 9594-7:1995 Information technology -- Open Systems Interconnection -- The Directory:
ISO/IEC 9594-7:1988. Selected object classes
Edition: 8 (2017)
ISO/IEC 9594-8 / X.509, Information technology -- Open Systems Interconnection -- The Directory:
Public-key and attribute certificate frameworks
Edition: 8 (2017)
ISO/IEC 9834-1 Information technology -- Procedures for the operation of object identifier
registration authorities: General procedures and top arcs of the
international object identifier tree
Edition: 4 (2012)

Edition: 2.1 Released Issue Appendix 2-6

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1
ISO/IEC | ITU-T Title and Current Status
reference in ICAO Doc
9880 Part IV Chapter 2
CCITT Rec. X.217 ITU-T Recommendation X.217 (04/95): Information technology - Open
Systems Interconnection - Service definition for the Association Control
Service Element
(Amendments 1 (1996) and 2 (1997) are In Force)
ITU-T Rec. X.216 ITU-T Recommendation X.216 (07/94): Information technology - Open
Systems Interconnection - Presentation service definition
(Amendments 1 (08/1997) and 2 (12/1997) are In Force)
ITU-T Rec. X.218 ITU-T Recommendation X.218 (03/93): Reliable Transfer: Model and
service definition
ITU-T X.500:1993 ITU-T Recommendation X.500 (10/2016): Information technology - Open
Systems Interconnection - The Directory: Overview of concepts, models
and services
ITU-T Rec. X.519:1993 ITU-T Recommendation X.519 (10/2016): Information technology - Open
Systems Interconnection - The Directory: Protocol specifications
ITU-T Rec. X.583 ITU-T Recommendation X.583 (12/1997) : Information technology - Open
Systems Interconnection - The Directory: Protocol Implementation
Conformance Statement (PICS) proforma for the Directory Access
Protocol
ITU-T Recs X.583, X.584, X.585 and X.586 were built upon the 1993
edition of the X.500-series Recommendations on the Directory. Three
editions of the Directory texts were later published without updating the
PICS proforma. Their content is no more irrelevant and they were thus
DELETED on 2006-02-09
ITU-T Rec. X.584 ITU-T Recommendation X.584 (12/1997): Information technology - Open
Systems Interconnection - The Directory: Protocol Implementation
Conformance Statement (PICS) proforma for the Directory System
Protocol
ITU-T Recs X.583, X.584, X.585 and X.586 were built upon the 1993
edition of the X.500-series Recommendations on the Directory. Three
editions of the Directory texts were later published without updating the
PICS proforma. Their content is no more irrelevant and they were thus
DELETED on 2006-02-09
ITU-T Rec. X.660 Amd. 2 ITU-T Recommendation X.660 (07/2011): Information technology -
Procedures for the operation of object identifier registration authorities:
General procedures and top arcs of the international object identifier tree
ITU-T Rec. X.881 ITU-T Recommendation X.881 (07/1994): Information technology -
Remote Operations: OSI realizations - Remote Operations Service
Element (ROSE) service definition
(Amendment 1 11/1995 is In Force)

A2.2.9 The following table lists the International Standardized Profiles (ISPs) referenced
in ICAO Doc 9880 Part IV. Although these ISPs have been withdrawn and are no longer
maintained by ISO/IEC, implementations of AMHS Components are required to conform to
the last published versions of the ISPs or equivalent provisions which may be published
elsewhere.
Table 6: ICAO Doc 9880 Part IV Referenced Standardized Profiles
ISO/IEC ISP reference in Title and last published version
ICAO Doc 9880 Part IV
ISO/IEC ISP 10616 Information technology -- International Standardized Profile FDI11 --
Directory data definitions -- Common Directory Use (Normal)
Edition: 1 (1995)
ISO/IEC ISP 11189 Information technology -- International Standardized Profile FDI2 --
Directory Data Definitions -- MHS Use of the Directory
Edition: 1 (1997).

Edition: 2.1 Released Issue Appendix 2-7

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1

ISO/IEC ISP reference in Title and last published version

ICAO Doc 9880 Part IV
ISO/IEC ISP 15126-1 Information technology - International Standardised Profiles FDY1n –
Directory data definitions – Part 1: FDY11 – Common directory use
(normal)
Edition: 1 (1999)
ISO/IEC ISP 15126-2 Information technology -- International Standardized Profiles FDY1n --
Directory data definitions -- Part 2: FDY12 -- Directory system schema
Edition: 1 (1999)

A2.2.10 Table 7 lists the IETF RFCs referenced in ICAO Doc 9880 Part IV Chapter 2
(Directory Services, Second edition).
Table 7: ICAO Doc 9880 Part IV Referenced RFCs
IETF RFC reference in Title and Current Status
ICAO Doc 9880 Part IV
RFC 1006:1987 (Also STD0035) ISO Transport Service on top of the TCP Version: 3. M.T.
Rose, D.E. Cass. May 1987.
(Obsoletes RFC0983) (Updated by RFC2126)
Status: STANDARD
RFC 2126:1997 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March
1997.
(Updates RFC1006)
Status: PROPOSED STANDARD)

A2.2.11 As at the date of publication of this edition of this EUROCONTROL Specification,

Chapter 3 of ICAO Doc 9880 (2nd Edition) is stated to be “under development by update of
Doc 9705 Sub-Volume VIII.” ICAO Doc 9705 3rd Edition Sub-Volume VIII specifies that the
security aspects of ATN are based on the ISO/IEC standards identified in the following table.
These standards have equivalent ITU-T Recommendations as identified in the second
column of the table and these are taken into account in this EUROCONTROL Specification.
Table 8: ICAO Doc 9705 Sub-Volume VIII Referenced Standards
ISO/IEC references in Equivalent ITU-T Title
ICAO Doc 9705 Ed 3 Recommendation
Sub-Volume VIII
ISO/IEC 10181-1 X.810 Information technology -- Open Systems
Interconnection -- Security frameworks for open
systems: Overview
Edition 1 (1996)
ISO/IEC 10181-2 X.811 Information technology -- Open Systems
Interconnection -- Security frameworks for open
systems: Authentication framework
Edition 1 (1996)
ISO/IEC 10181-3 X.812 Information technology -- Open Systems
Interconnection -- Security frameworks for open
systems: Access control framework
Edition 1 (1996)
ISO/IEC 10181-6 X.815 Information technology -- Open Systems
Interconnection -- Security frameworks for open
systems: Integrity framework
Edition 1 (1996)
ISO/IEC 11586-1 X.830 Information technology -- Open Systems
Interconnection -- Generic upper layers security:
Overview, models and notation
Edition 1 (1996)

Edition: 2.1 Released Issue Appendix 2-8

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1
ISO/IEC references in Equivalent ITU-T Title
ICAO Doc 9705 Ed 3 Recommendation
Sub-Volume VIII
ISO/IEC 10021 X.400 Series Information technology -- Message Handling Systems
(MHS)

A2.2.12 Table 9 lists the IETF RFCs referenced in ICAO Doc 9705 Third Edition, Sub-
Volume VIII (Security Services).
Table 9: ICAO Doc 9705 Sub-Volume VIII Referenced RFCs
IETF RFC reference in Title and Current Status
ICAO Doc 9705 SV8
RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework (1999)
RFC 2104 HMAC: Keyed-Hashing for Message Authentication (1997)

A2.2.13 The following ISO/IEC standards are referenced from the EUR AMHS Manual [8]
Appendix B (European ATS Messaging Service Profile) and Appendix G (European
Directory Service).
Table 10: Standards Referenced in ICAO EUR Doc 020 Appendices B and G
ISO/IEC | ITU-T reference Title and Current Status
in ICAO EUR Doc 020
CCITT Rec X.400 (1993) ITU-T Recommendation F.400/X.400 (06/1999): Message handling
services: Message handling system and service overview
CCITT Rec X.402 (1992) ITU-T Recommendation X.402 (06/1999): Information technology –
Message Handling Systems (MHS): Overall architecture
CCITT Rec X.411 (1992) ITU-T Recommendation X.411 (06/1999): Information technology –
Message Handling Systems (MHS): Message Transfer System:
Abstract Service Definition and Procedures
CCITT Rec X.419 (1992) ITU-T Recommendation X.419 (06/1999): Information technology –
Message Handling Systems (MHS): Protocol Specifications
CCITT Rec X.420 (1992) ITU-T Recommendation X.420 (06/1999): Information technology –
Message Handling Systems (MHS): Interpersonal Messaging System
ISO 3166:1993 Codes for the representation of names of countries and their
subdivisions -- Part 1: Country codes
Edition: 3 (2013)
ISO/IEC 10021-1:1990 Information technology -- Message Handling Systems (MHS) -- Part 1:
ISO/IEC 10021- System and service overview
1:1990/Amd.1:1994 Edition 2 (2003) (incorporates Amd.1:1994)
ISO/IEC 10021-1:2003
ISO/IEC 10021-2:1990 Information technology -- Message Handling Systems (MHS): Overall
ISO/IEC 10021- architecture
2:1990/Amd.1:1994 Edition: 3 (2003) (incorporates Amd.1:1994 and Amd.2:1994)
ISO/IEC 10021-
2:1990/Amd.2:1994
ISO/IEC 10021-2:2003
ISO/IEC 10021-3:1990 Information technology -- Text Communication -- Message-Oriented
Text Interchange Systems (MOTIS) -- Part 3: Abstract Service
Definition Conventions
WITHDRAWN
ISO/IEC 10021-4:1990 Information technology -- Message Handling Systems (MHS): Message
ISO/IEC 10021- transfer system -- Abstract service definition and procedures
4:1990/Amd.1:1994 Edition: 3 (2003)
ISO/IEC 10021-4:2003

Edition: 2.1 Released Issue Appendix 2-9

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1

ISO/IEC | ITU-T reference Title and Current Status

in ICAO EUR Doc 020
ISO/IEC 10021-5:1990 Information technology -- Message Handling Systems (MHS): Message
ISO/IEC 10021-5:1999 store: Abstract service definition
Edition: 4 (1999)
ISO/IEC 10021-6:1990 Information technology -- Message Handling Systems (MHS): Protocol
ISO/IEC 10021-6:2003 specifications
Edition: 3 (2003)
ISO/IEC 10021-7:1990 Information technology -- Message Handling Systems (MHS):
ISO/IEC 10021-7:2003 Interpersonal messaging system
Edition: 3 (2003)
ISO/IEC 646:1991 Information technology -- ISO 7-bit coded character set for information
interchange
Edition: 3 (1991)
ISO/IEC 7498-1 Information technology -- Open Systems Interconnection -- Basic
Reference Model: The Basic Model
Edition: 1 (1994)
ISO/IEC 8859-1:1987 Information technology -- 8-bit single-byte coded graphic character sets
-- Part 1: Latin alphabet No. 1
Edition: 1 (1998)
ISO/IEC 9594-n 5th Edition, Information technology – Open Systems Interconnection – The
2005 Directory (multi-part)
Edition: 8 (2017)
ITU-T X.500 (08/2005) set of ITU-T X.500 (10/2016) Series of Recommendations - Information
standards technology – Open Systems Interconnection – The Directory
ISO/IEC TR 10000-1: 1995 Information technology — Framework and taxonomy of International
Standardized Profiles — Part 1: General principles and documentation
framework
Edition: 4 (1998)
ISO/IEC TR 10000-2: 1995 Information technology — Framework and taxonomy of International
Standardized Profiles — Part 2: Principles and taxonomy for OSI
profiles
Edition: 5 (1998)

A2.2.14 Table 11 lists the International Standardized Profiles (ISPs) referenced in ICAO
EUR Doc 020 Appendix B (European ATS Messaging Service Profile). This Appendix is
structured with Annexes incorporating the ISPs with additional EUR AMHS requirements.
Although the ISPs have been withdrawn and are no longer maintained by ISO/IEC, the
European ATS Messaging Service Profile is dependent upon the last published versions of
the ISPs or equivalent provisions which may be published elsewhere.
Table 11: ICAO EUR Doc 020 Referenced Standardized Profiles
ISO/IEC ISP reference in Title and last published version
ICAO EUR Doc 020
ISO/IEC ISP 10611-1:1994 Information Technology — International Standardized Profiles AMH1n
— Message Handling Systems — Common Messaging — Part 1: MHS
Service Support
Edition: 3 (2003)
ISO/IEC ISP 10611-2:1994 Information Technology — International Standardized Profiles AMH1n
— Message Handling Systems — Common Messaging — Part 2:
Specification of ROSE, RTSE, ACSE, Presentation and Session
Protocols for use by MHS
Edition: 2 (1997)
ISO/IEC ISP 10611-3:1994 Information Technology — International Standardized Profiles AMH1n
— Message Handling Systems — Common Messaging — Part 3:
AMH11-Message Transfer (P1)
Edition: 3 (2003)

Edition: 2.1 Released Issue Appendix 2-10

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1
ISO/IEC ISP reference in Title and last published version
ICAO EUR Doc 020
ISO/IEC ISP 10611-4:1994 Information technology -- International Standardized Profiles AMH1n --
ISO/IEC ISP 10611-4:2003 Message Handling Systems -- Common Messaging -- Part 4: AMH12
and AMH14 -- MTS Access (P3) and MTS 94 Access (P3)
Edition: 3 (2003)
ISO/IEC ISP 10611-5:1994 Information Technology — International Standardized Profiles AMH1n
ISO/IEC ISP 10611-5:2003 — Message Handling Systems — Common Messaging — Part 5:
AMH13-MS Access (P7)
Edition: 3 (2003)
ISO/IEC ISP 10611-6: 2003 Information Technology — International Standardized Profiles AMH1n
— Message Handling Systems — Common Messaging — Part 5:
AMH15-MS 94 Access (P7)
Edition: 2 (2003)
ISO/IEC ISP 11188-1:1995 Information Technology — International Standardized Profile —
Common Upper Layer Requirements — Part 1: Basic connection
oriented requirements
Edition: 1 (1995)
ISO/IEC ISP 11189:1997 Information technology -- International Standardized Profile FDI2 --
Directory Data Definitions -- MHS Use of the Directory
Edition: 1 (1997).
ISO/IEC ISP 12062-1:1995 Information Technology — International Standardized Profiles AMH2n
ISO/IEC ISP 12062-1:2003 — Message Handling Systems — Interpersonal Messaging — Part 1:
IPM MHS Service Support
Edition: 3 (2003)
ISO/IEC ISP 12062-2:1995 Information Technology — International Standardized Profiles AMH2n
ISO/IEC ISP 12062-2:2003 — Message Handling Systems — Interpersonal Messaging — Part 2:
AMH21 — IPM Content
Edition: 3 (2003)
ISO/IEC ISP 12062-3:1995 Information Technology — International Standardized Profiles AMH2n
ISO/IEC ISP 12062-3:2003 — Message Handling Systems — Interpersonal Messaging — Part 3:
AMH22 — IPM Requirements for Message Transfer (P1)
Edition: 3 (2003)
ISO/IEC ISP 12062-4:1995 Information Technology — International Standardized Profiles AMH2n
ISO/IEC ISP 12062-4: 2003 — Message Handling Systems — Interpersonal Messaging — Part 4:
AMH23 and AMH25 — IPM Requirements for MTS Access (P3) and
MTS 94 Access (P3)
Edition: 3 (2003)
ISO/IEC ISP 12062-5:1995 Information Technology — International Standardized Profiles AMH2n
ISO/IEC ISP 12062-5: 2003 — Message Handling Systems — Interpersonal Messaging — Part 5:
AMH24 — IPM Requirements for Enhanced MS Access (P7)
Edition: 3 (2003)
ISO/IEC ISP 12062-6: 2003 Information Technology — International Standardized Profiles AMH2n
— Message Handling Systems — Interpersonal Messaging — Part 6:
AMH26 — IPM Requirements for Enhanced MS 94 Access (P7)
Edition: 1 (2003)

A2.2.15 Table 12 lists the IETF RFCs referenced in ICAO EUR Doc 020.
Table 12: ICAO EUR Doc 020 Referenced RFCs
IETF RFC reference in Title and Current Status
ICAO EUR Doc 020
Internet Engineer Task Transmission Control Protocol
Force (IETF) STD0007, Internet standard (1981)
RFC0793:1981
Internet Engineer Task Internet Protocol
Force (IETF) STD0005, Internet standard (1981)
RFC0791:1981

Edition: 2.1 Released Issue Appendix 2-11

EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)
APPENDIX 2 – STANDARDS EDITIONS
SES/IOP/AMHS/SPEC/2.1

IETF RFC reference in Title and Current Status

ICAO EUR Doc 020
Internet Engineer Task Requirements for Internet Hosts - Communication Layers
Force (IETF) STD0003, Internet standard (1989)
RFC1122:1989
Internet Engineer Task Security Architecture for the Internet Protocol
Force (IETF) RFC4301:2005 Proposed Standard (Dec 2005)
Internet Engineer Task Internet Protocol, Version 6 (IPv6) Specification
Force (IETF) RFC2460:1998 Draft Standard (Dec 1998)
Internet Engineer Task Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Force (IETF) RFC4443:2006 Version 6 (IPv6) Specification
Internet Standard (Mar 2006)
Internet Engineer Task Enhancing TCP over Satellite Channels Using Standard Mechanisms
Force (IETF) BCP0028, Best Current Practice (Jan 1999)
RFC2488:1999
IETF STD0035 RFC ISO Transport Service on top of the TCP Version: 3
1006:1987 Internet standard (May 1987)
IETF RFC 2126:1997 ISO Transport Service on top of TCP (ITOT)
IETF RFC4511 June 2006 Lightweight Directory Access Protocol (LDAP): The Protocol
Proposed Standard (Jun 2006)
IETF RFC2849 June 2000 The LDAP Data Interchange Format (LDIF) - Technical Specification
Proposed Standard (Jun 2000)

Edition: 2.1 Released Issue Appendix 2-12

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

APPENDIX 3 – SPECIFICATION UPDATE PROCEDURES

It is necessary to periodically check this EUROCONTROL Specification for consistency with
referenced material, notably ICAO SARPs and relevant Regulations. The Specification is also
expected to evolve following real project and field experience, as well as advances in
technology.
The main objectives of a regular review are:
a) to improve the quality of the requirements (e.g. clarity, testability, etc.);
b) to verify that the level of detail published is adequate;
c) to ensure that design-oriented requirements, imposing unnecessary constraints to
technical solutions, have been avoided;
d) to ensure that advances in technology are properly reflected;
e) to make all stakeholders incl. industry aware of the latest developments.
The update process for this EUROCONTROL Specification may be summarised as follows:
Stakeholders may provide change proposals either through existing working arrangements
(e.g. established working groups) or by sending a formal Change Request (CR) to the generic
email address: [email protected]
The CR needs to provide following minimum elements:
• Originator information (name, Organisation, contact details);
• Specification title, number and edition date;
• Page, chapter, section (subsection) where the issue appears;
• Description of the issue and reason for change;
• Specific change proposal text (incl. potential alternatives, if any).
Main steps towards a revised version:
• Agency (Standardisation unit) will assess each CR in coordination with content owners,
classify the urgency and establish the CR impact category (major, minor or editorial).
• Agency will then prepare resolution proposal(s) and, if needed, discuss those with the
originator and/or relevant working arrangements. Note: CR will be grouped into
“change packages” to consider reasonable update cycles.
• Agreed changes will be integrated into a revised version “Proposed Issue” including a
summarised list of changes.
• Consultation will be performed in accordance with the CR impact category identified:
o Major changes require full formal stakeholder consultation (PC level)
o Minor changes need consultation at working layers (e.g. working group or Team)
o Editorial changes may be implemented directly at any stage though grouped with
change packages.
Note: Identified errors which may cause potential problems when implementing, may be
corrected directly via separate “Corrigenda”.
The Agency will apply this process in an objective and impartial way and will consult
stakeholders as needed and in line with the formal Standards Development Process.

Edition: 2.1 Released Issue Appendix 3-1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

APPENDIX 4 – AMENDMENTS TO SPECIFICATION

Amendments applied in comparison to Edition 2.0.
Section Page Change proposal Reason, Justification
WHOLE DOCUMENT
General all Revised document configuration pages incl. headers Updated template
and footers, signatories, etc. Non-breaking spaces
removed .
General - “Doc 9880 Part IIB” replaced with “Doc 9880 Part II” ICAO document
restructuring in Ed 2
General - “Doc 9880 Part IVA” replaced with “Doc 9880 Part IV ICAO document
Chapter 2” restructuring in Ed 2
General - Replace ATS Message Handling Service with Editorial
ATSMHS
MAIN BODY
Abstract ii ERAF reference removed, wording improved Current EUROCONTROL
standardisation process
Executive 1 ERAF reference replaced with current standards Current EUROCONTROL
Summary development process. OJEU recognition of Edition standardisation process,
2.0 as CS added. Footnote on new EASA BR. status as SES CS.
Executive 1 Replaced “applicable to air navigation service Widen applicability
Summary providers (ANSPs) in EU Member States” with
“applicable to AMHS implementers”
Executive 1 Replaced “After being referenced in the Official Reflect CS status
Summary Journal of the European Union as a Community
specification” with “As a recognised CS within the
SES framework” & footnote with OJ reference
1.1.4 2 Reference to Appendices added Appendices were
previously omitted & add
new Appendices
General 3, 15, In references to SES interoperability Regulation, “No Generalise reference to
16 552/2004” deleted. reflect amendments
nd
1.2.2 3 Deleted “Therefore” at start of 2 sentence. Inserted Proposed as updated CS
Purpose abbreviation (CS) and “edition of the” before
EUROCONTROL Specification
1.3.4 4 Replaced “Chapter 3.5.3” with “Chapter 3.5”. Deleted Update references
“ICAO Doc 9705, superseded by”
1.3.12 6 Deleted “EUROCONTROL ATM Strategy for the Update to point to current
Years 2000+ [44]” and following text and footnote framework
referring to ECIP. Replaced with reference to SESAR
European ATM Master Plan.
1.3.13 6 Deleted section 1.3.13, renumber 1.3.14 as new Now redundant – repeats
1.3.13 section 1.3.12
1.4.4 6 “Ground communication and display systems, Better reflect scope
including user interfaces and end systems”
Figure 1 8 Removed Doc 9705 SV III and Future EUR docs, Updated standards
updated Doc 9880 part numbers. Added arrows from
Doc 020 to 9880 and from 9880 to base standards.
1.4.9 8 Annex 10 [3] Volume III [26] are complemented by Updated standards
the detailed technical specifications in ICAO Doc
9880 and Doc 9705
1.5.1 8 Inserted “the second edition of this EUROCONTROL Specification update
Specification is proposed for recognition as an EU
Community specification was recognised as a CS
within the SES regulatory framework [footnote OJEC
ref]. The current edition is proposed for recognition
as a new edition of the CS. As such, it will have has
the status …”

Edition: 2.1 Released Issue Appendix 4-1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

1.5.3 9 The This EUROCONTROL Specification was Update document history
developed in accordance with stakeholder
consultation mechanisms under the
EUROCONTROL Regulatory and Advisory
Framework (ERAF) has set up the basis for the
development of EUROCONTROL Specifications.
1.5.3 9 Update hyperlink to become Broken link
footnote https://www.eurocontrol.int/articles/stakeholder-
consultation
1.5.4 9 Replaced “can give” with “gives” Status of CS
1.5.5 9 EC declaration(s) More than one conformity
declaration
1.6.1 9 applicable to ANSPs in EU Member States AMHS Wider applicability
implementations
1.6.2 9 who may be required to produce an EC declaration of Improve wording
conformity (to the essential requirements).need to
produce an EC declaration of conformity (DoC)
1.6.3 9 Although targeted to become a Community Specification history
specification developed as a CS in the EU SES
framework, the this EUROCONTROL
Specification on AMHS would be is equally
applicable
1.6.5 10 The basic feature of specifications such as these Remove ERAF reference,
within the EUROCONTROL Regulatory and Advisory reflect CS status
Framework is that that they are a CS such as this is
that it is a voluntary standards
1.6.6 10 part of the related SES and other related Regulations Accuracy
1.7.5 11 PRL legend moved from Annexes to new subsection Editorial improvement
under Conventions heading.
1.8.1 12 Deleted: CFMU, DAP/CSP, ECIP, SDG, SPACE, Update list of
XMIB. Added: CS, DoC, DoV, EDS, OJEU. abbreviations
EC: Community replaced with Commission
PENS: remove brackets from PEN(S)
X.400 & X.500: Add “series of”
American spelling of Organization, Standardization,
Standardized
1.8.2 14 Other definitions may be are included by reference to Explanation of references
other documents (references are italicised in
brackets).
1.8.2 15 In CA definition, deleted “As noted in ICAO Doc 9705 Obsolete reference
§8.3.1.2.2,”
1.8.2 15 In Constituents definition, deleted “549/2004” and Generalise references to
“552/2004” reflect amendments
1.8.2 16 In EATMN definition, deleted “to Regulation (EC) No Generalise references
552/2004” and inserted cross-reference [1]. Deleted
“552/2004”
1.8.2 16 In EATMN systems definition, Generalise references
inserted interoperability Regulation and cross-
reference [1]. Deleted “552/2004”
1.8.2 16 In Interoperability definition, deleted “549/2004” Generalise references
1.8.2 16 In NB definition, deleted “New Approach” Generalise
1.9.15 20 Bullet a): Inserted “(e,g, using PENS)” Refer to PENS
1.9.15 22 Figure 5: Added “e.g. PENS”, clarify that other Refer to PENS, update
Regions may use AMHS/IP or AMHS/OSI external connectivity
possibilities
1.9.19 22 Section referring to other bodies’ change control Redundant text.
mechanisms releted.

Appendix 4-2 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

1.10 22 Section 1.10 “Responsible Unit” deleted Obsolete text
2.2.3 23 Replaced Volume III [26] with Volume II [3], inserted Updated standards
“originally” before published and footnote that ISPs
are no longer published.
2.2.4 23 Replaced “and” with vertical bar. Deleted “The use of Equivalent standards.
OSI upper layers is specified in a common ISP Redundant text - ISPs
applicable to each MHS component.” unavailable
2.2.5 23 Subsection deleted, subsequent subsections Unnecessary reference to
renumbered. ISPs
2.3.3 24 Replaced “section 3.2.2.2.3” with “section 3.2.2.2” Correct reference
2.3.4 23 An underlying network infrastructure … needs to be Availability of PENS
implemented as a Common Facility, in a timeframe
compatible with the AMHS deployment . It is
foreseen that this will plan is a prerequisite. This may
be provided by the Pan-European IP
nNetwork Service (PENS). Bilateral or multilateral
connectivity arrangements can accommodate initial
AMHS operations, until such a common facility
becomes available.
2.5.2 25 MTAs in the EATMN will be as are specified Update
2.7.4 26 Replaced “section 4” with “Chapter 4” Correct reference
2.9.3 27 Replaced “section 2.5.1.4.1.5” with “section 2.5.1.4” Correct reference
2.9.5 27 New para inserted referring to ICAO Register of Point to referenced item
AMHS Management Domains.
2.11.2 27 Delete from “Discussions at the EUROCONTROL Obsolete text
Civil-Military CNS Focus Group” to end of paragraph
2.11.3 28 Title & description of EUROCONTROL Civil-Military Update reference, remove
CNS Interoperability roadmap updated. Quotation redundant text
from former Civil-Military Roadmap removed.
2.11.5 28 Deleted “to be implemented in the sequence of Redundant text
SESAR Target Concept”
2.12.1 28 Replaced “will be based on” with “uses” ATN/IPS Current status
lower layers
2.12.2 – 28 - 29 Subsections describing ability to use multiple lower Out of scope.
2.12.4 layer stacks deleted
2.12.5 29 Renumbered as 2.12.2. Deleted: Provisions for Out of scope.
AMHS interworking at boundaries with countries
external to the EATMN will normally be concentrated
in Boundary ATS Message Servers.
2.12.5 29 Figure 6: Replaced “European IP service” with Clarify intent
“PENS”. Clarify that external country is using
ATN/OSI. Change caption from “Dual
communications stack at Regional boundary” to
“MTA Communication with an External Region using
ATN/OSI”
2.12.6 29 Renumber as 2.12.3. Replace “will make use of” with Current status
“incorporates”
2.12.7 29 Subsection referring to boundary ATS Message Out of scope.
Servers as a Common Facility deleted.
3.1.2 30 Replaced “will provide” with “offers” significant Current status
operational benefits
3.3.8 31 Replaced “paragraph 4.5.2.1.4.b” with “paragraph Correct reference
4.5.2.1”
3.3.9 31 The minimum support specified in ICAO Doc 9880 Refer to ICAO EUR
Part II includes security class S0, as defined in ISO AMHS Manual instead of
ISP 10611-1 Annex C. Security class S0 which is ISP
confined to

Edition: 2.1 Released Issue Appendix 4-3

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

3.3.11 32 Replaced “used in the ISPs” with “in the referenced Generalise
standards”
Figure 7 32 Updated 9880 reference. In caption, replaced “ISPs” Current standard
with “Base Standards”
3.5.1 33 Replaced “section 2.5.1.1.2” with “section 2.5.1.1” Correct reference
4.1.2 34 Replaced bullet “Directory support of PKI” with Correct description of
“Determination of AMHS recipient capabilities” document structure
4.1.7 34 Replaced text: A central Directory Service, ICAO EUR specified EDS
implemented as a Common Facility for the benefit of since previous edition of
the whole European area, would facilitate AMHS EUROCONTROL Spec.
address publication and thus aid address conversion.
With reference to ICAO EUR Doc 020 Appendix G
4.2.1 34 Replaced “ANSPs in Europe” with “the EATMN” Widen scope
4.2.5 35 Text replaced: A possible architecture that can be Superseded by ICAO
considered for Directory Services deployment in the EDS operational concept
EATMN is illustrated in Figure 9. It comprises a set of description.
DSAs grouped in Directory Management Domains
(DMD): one for each State or Organisation and one
for the common shared data. Each
State/Organisation DMD is composed of at least one
Border DSA that exports “public” data and retrieves
“public” data from other States or Organisations or
the DMD containing common shared data. with
description of EDS operational concept
4.2.6 – 36 Subsections describing central database & future Superseded by ICAO
4.2.7 European DSA removed, including Figures 9 & 10. EDS operational concept
description.
4.3.4 37 Appended text “, and is therefore recommended in Update DISP status
the EDS”.
4.4.3 38 Added LDAP cross-reference [39]. Replaced “the Include reference. Clarify
ICAO specifications” with “ICAO Doc 9880 Part IV”. LDAP status.
Appended text ‘ICAO EUR Doc 020 [8] Appendix G
notes that: “Use of LDAP Version 3 is optional for
end users with limited needs.”’
4.5.1 38 Entire subsection including Figure 11 deleted. Align with ICAO
Replaced with: “The general DIT structure to be documentation.
supported by ATN DSAs is specified in ICAO Doc
9880 Part IV [7] Chapter 2. The DIT subtree to
support AMHS in the EATMN is part of the EDS
specified in ICAO Doc 020 [8] Appendix G.”
4.5.2 39 Entire subsection including graphic deleted. Avoid possible conflict
with ICAO schema
definition
4.6.1 41 Text replaced: “For the time being, it is assumed that Update to refer to ICAO
version control of the directory information is a local EUR EDS specification
matter, to be managed by the local directory system
administrator in the framework of common AMC
procedures. In the future, specific directory attributes
supporting version control may be specified” “The
EDS specified in ICAO EUR Doc 020 supports Pre-
operational and Operational versions of the shared
DIT and defines an EDS-specific Object Class
containing version identification.”

Appendix 4-4 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

4.7.1 42 In bullet b) replaced “It is possible to use the existing Update to refer to ICAO
Directory schema, specifically the BOOLEAN EUR EDS specification.
attribute atn-ipm-heading-extensions to determine New attributes defined in
user capabilities, as follows” with “The EDS can be 2nd edition of Doc 9880.
used to determine AMHS user capabilities, as
described in ICAO EUR Doc 020 [8] Appendix G-B,
Section 5.2:”
After “SEC supported”, inserted: “if the ‘atn-use-of-
amhs-security’ attribute is TRUE. Note that “
4.7.2 42 Deleted subsection: Interoperability will only be Redundant text
achieved if all systems make the same assumptions
and configure directories in the same way.
4.7.3 42 Renumbered as 4.7.2. Replaced “The ICAO Clarify reference
documentation” with “ICAO Doc 9880 Parts II [5],
Chapter 3.4”
4.7.4 42 Renumbered as 4.7.3. Replaced “will support” with Use of “will”
“by implication supports”
5.1.6 43 Replaced “section 4.5.2.4.15.b.1.iii” with “section Correct reference
4.5.2.4”
6.1.1 46 Replaced “would form part of” with “could Terminology
accompany”. Added DoC abbreviation.
6.1.2 46 Replaced: “covering the Basic ATSMHS Align with latest edition of
requirements. There is the need to augment the test ICAO EUR Doc 020
coverage in such a way as to include the additional
functionality of the relevant elements of the Extended
ATSMHS” “, with testing guidelines for the European
Directory Service in Appendix G. Testing procedures
for SEC are yet to be developed.”
7.1.1 47 Deleted “other” before elements of the Extended Editorial
ATSMHS
7.2.1 48 Replaced “may be implemented” with “has been Update implementation
implemented” status.
Reworded Note: “It is intended that eventually Align with Doc 9880
the Eextended ATSMHS ATS Message Handling
Service will eventually be supported by all
ATSMHS ATS Message Handling Service users, so
that the Bbasic ATSMHS ATS Message Handling
Service will not no longer be required anymore.
However,”
7.3.1 48 Replaced: “At present, updates to European ATS Align with EDS
messaging configuration and addressing information specification
are published each AIRAC cycle and distributed by
the AMC using procedures described in ICAO EUR
Doc 021” with reference to EDS process
7.3.2 48 Replaced “distributed using these same procedures” Align with EDS
with distributed using the EDS” specification
7.3.3 – 48 Deleted subsections referring to “final state” with Align with EDS
7.3.4 migration to allow synchronisation with a highly specification
available and secure centralised directory system in
the AMC.
8.1.5 Replaced “EC declaration of conformity / verification” Consistent use of
with abbreviations “DoC / DoV”. abbreviations
9.1.2 to 51 Section on document update procedures replaced Current EUROCONTROL
9.1.5 with reference to new Appendix 3. Standards development
process
10.1.1 53 Replaced “current versions” with “referenced Better describe Appendix
versions” 2

Edition: 2.1 Released Issue Appendix 4-5

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

10.2 [1] 53 Regulation (EC) No 552/2004, appended: “, Include amendment
31.3.2004, Amended by Regulation (EC) No
1070/2009, OJ L 300/34, 14.11.2009”
10.2 [2] 53 Regulation (EU) No 910/2014 of the European Replace repealed
Parliament and of the Council of 23 July 2014 on directive with current
Electronic Identification and Trust Services for regulation ref.
Electronic Transactions in the Internal Market and
Repealing Directive 1999/93/EC of the European
Parliament and of the Council of 13 December 1999
on a Community framework for electronic signatures,
OJ L 13, 19.1.2000, p. 12–20, OJ L 257/73,
28.8.2014
10.2 [3] 53 Replaced: Sixth edition – October 2001, Latest version
incorporating Amendment 83 (20/07/2008) with: 7th
edition, incorporating Amendments 44–90 (July
2016) ISBN 978-92-9249-967-9
10.2 [4] 53 Replaced: Thirteenth edition - July 2001, Latest version
incorporating Amendment 45 (16/07/2007) with 14th
edition, incorporating Amendments 1–50-A (July
2016) ISBN 978-92-9249-972-3
10.2 [5] 53 ICAO Doc. 9880-AN/466 Manual on Detailed Latest edition, update title
Technical Specifications for the Aeronautical
Telecommunication Network (ATN) using
ISO/OSI sStandards and pProtocols, Part IIB II –
Ground-Ground Applications – ATS Air Traffic
Services mMessage hHandling sServices
(ATSMHS), 1st edition (unedited), December 2007-
Second Edition (2016) ISBN 978-92-9258-141-1
10.2 [6] 53 Added ISBN reference & footnote: Partially replaced Include ISBN, add
by ICAO Doc 10094: Manual of the ATN Secure footnote to justify
Dialogue Service (planned publication 2020). See retention & point to future
also Doc9880 Part IV – ref [7] – which states only: document
Chapter 3 - SECURITY - (Under development by
update of Doc 9705 Sub-Volume VIII)
10.2 [7] 53 Capitalised “sStandards and pProtocols”, replaced Latest edition, update title
Part IVA with Part IV, added “Security and Identifier
Registration” Replaced: 1st edition (unedited) with
Second Edition (2016) ISBN 978-92-9258-143-5
10.2 [8] 54 ICAO EUR Doc 020 EUR AMHS Manual, Version 4.0 Latest version (pending
(April 2009) 13.0 (April 2018) publication). Replace
Updated hyperlink broken link.
10.2 [9] 54 ICAO EUR Doc 021 Replaced: 5.0 (May 2009) with Latest version. Replace
12.0 (April 2016) Updated hyperlink broken link.
10.2 [10] 54 ICAO EUR Doc 022 Replaced: 1.0 (April 2008) with Latest version. Replace
7.0 (April 2015) Updated hyperlink broken link.
10.2 [12] 54 EUROCAE Document ED-111, Deleted: Ground Correct title
10.2 [13] 54 Pluralised “Telecommunications” Added hyperlink Correct title, add link
10.2 [14] 54 ETSI TS 101 456 v1.4.3 (2007-05)EN 319 411-2 Replace historical
v2.2.0 (2017-08) Electronic Signatures and reference with current
Infrastructures (ESI) Policy and security requirements equivalent.
for Trust Service Providers issuing certificates: Part
2: Requirements for trust service
providers certification authorities issuing EU qualified
certificates.
Added hyperlink
10.2 [15] 54 Updated version from 2 (2002) to 4 (2015). Updated Latest version, correct
hyperlink. title, link updated.

Appendix 4-6 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

10.2 [16] 54 ISO/IEC ISP 15126-1:1999 Added footnote: ISP ISPs withdrawn - no
Withdrawn by ISO longer in ISO catalogue
10.2 [17] 54 ISO/IEC ISP 11189 reference removed. Not referred to

10.2 [18] 54 ISO/IEC 10021-n | ITU-T X.400 Series of Equivalence of ITU-T

Recommendation (1999). Deleted “alternatively” Recommendations
10.2 [19] 54 ISO/IEC ISP 10611-n:2003 Added footnote: Generic ISPs withdrawn - no
reference to the whole series of ISO/IEC ISP 10611 longer in ISO catalogue
standardised profiles, now Withdrawn by ISO
10.2 [20] 54 ISO/IEC ISP 12062-n:2003 Added footnote: Generic ISPs withdrawn - no
reference to the whole series of ISO/IEC ISP 12062 longer in ISO catalogue
standardised profiles, now Withdrawn by ISO
10.2 [21] 54 IETF RFC 3647. Added hyperlink Add link
10.2 [22] 54 ICAO Doc 9896-AN/469 Manual for the Aeronautical Latest version, updated
Telecommunication Network (ATN) using Internet title, add ISBN
Protocol Suite (IPS) ATN using IPS Standards and
Protocols, 1st 2nd edition (2015 unedited) ISBN 978-
92-9249-876-4
10.3 [23] 55 Appended:, Amended by Regulation (EC) No Include amending
1070/2009, OJ L 300/34, 14.11.2009 regulation
10.3 [24] 55 Commission Regulation (EC) No 482/2008: Added Note that 482/2008 is
footnote: Regulation 482/2008 remains in force until being repealed.
01/01/2020; …
10.3 [25] 55 Commission Implementing Regulation (EUC) No Refer to latest version as
1035/2011 of 17 October 2011 2096/2005 of 20 amended and note
December 2005 laying down common requirements pending repeal
for the provision of air navigation services and
amending Regulations (EC) No 482/2008 and (EU)
No 691/2010 (Text with EEA relevance) (OJ L 271,
18.10.2011, p. 23) Amended by: Commission
Implementing Regulation (EU) No 923/2012 of 26
September 2012 OJ L 281/1, 13.10.2012 and
Commission Implementing Regulation (EU) No
448/2014 of 2 May 2014 OJ L 132/53, 3.5.2014, OJ L
335/13, 21.12.2005
Added footnote: To be repealed by Commission
Implementing Regulation (EU) 2017/373 effective
02.01.2020
10.3 [26] 55 incorporating Amendments 70-90 83 (20/11/2008), Latest edition
ISBN 978-92-9258-278-4 92-9194-953-1,
10.3 [27] 55 Routing Directory for COM Centres in the EUR/NAT Add link
Regions, added hyperlink
10.3 [28] 55 ICAO Register of AMHS Management Domains: Replace broken link
updated hyperlink
10.3 [29] 55 ICAO Convention on International Civil Aviation, Latest edition
Annex 17 – Security, 10th 8th edition - April 2017
ISBN 978-92-9249-884-9 2006, Reprinted August
2007, incorporating Amendments 1–11. ISBN 92-
9194-949-3
10.3 [30] 55 ICAO Doc 7910 reference removed Not referred to
10.3 [31] 55 EUROCAE Document ED-109A, Software Integrity Update to Revision A,
Assurance Considerations for Communication and updated title
Navigation and Surveillance and Air Traffic
Management (CNS/ATM) Systems, January
2012, Guidelines for CNS/ATM Systems Software
Integrity Assurance., March 2002

Edition: 2.1 Released Issue Appendix 4-7

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

10.3 [32] 55 ETSI TR 102 040 v1.32.1 (2004-02 2005-03) Latest version, complete
Electronic Signatures and Infrastructures (ESI); title, add link
International Harmonization of Policy Requirements
for CAs issuing Certificates. Added hyperlink.
10.3 [33] 55 ETSI TS 119 312 V1.2.1 (2017-05) 102 176-1 v2.0.0. Superseded standard –
(2007-11) Electronic Signatures and Infrastructures refer to replacement
(ESI); Algorithms and Parameters for Secure
Electronic Signatures; Part 1: Hash functions and
asymmetric algorithmsCryptographic Suites.
10.3 [34] 55 ISO/IEC 9594-n | ITU-T X.500 Series of Equivalence of ITU-T
Recommendations), deleted: Edition 5 (2005) Recommendations. Add
(alternatively. Added footnote: This is a generic note regarding different
reference … versions of parts
10.3 [35] 55 ISO/IEC 9594-8:2005 2017 | ITU-T Recommendation Latest version, include
X.509 (10/201608/2005) Information technology - Part number
Open Systems Interconnection - The Directory – Part
8: Public-key and attribute certificate frameworks.
10.3 [36] 55 ISO/IEC 8825-1:2002 2015 | ITU-T Recommendation Latest version
X.690 (07/200208/2015)
10.3 [37] 56 ECIP reference removed Not referred to
10.3 [38] 56 X/Open Technical Standard "API to Electronic Mail Latest version, add link
(X.400)" Issue 3 (1996) 2 (available from The Open
Group) Added hyperlink.
10.3 [39] 56 [LDAP] IETF RFC 4510 Added hyperlink Add link
10.3 [40] 56 [SNMP] IETF RFC 3411 Added hyperlink Add link
10.3 [41] 56 [OCSP] IETF RFC 2560 Added hyperlink Add link
10.3 [42] 56 IETF RFC 2849 Added hyperlink Add link
10.3 [44] 56 EUROCONTROL ATM Strategy for the Years 2000+ Document no longer
reference removed referred to
10.3 [45] 56 Roadmap on Enhanced Civil-Military CNS Updated document, new
Interoperability and Technology Convergence, title
Edition 2.0, Reference: EUROCONTROL 13/10/17-
07 (October 2013)EUROCONTROL Civil-Military
CNS/ATM Interoperability Roadmap (January 2006)
10.3 [46] 56 Replaced SASAR definition phase deliverable 5 with Update Master Plan
reference to European ATM Master Plan, including reference
hyperlink
10.3 [47] 56 IETF RFC 2789 Added hyperlink Add link
10.3 56 Added ref [48] PKI Assessment Guidelines (PAG Referred to in Annex D
v1.0), including hyperlink
ALL ANNEXES
x.1.1 x-1 MOC_Edition updated from 1 to 2 Revised requirements
x.1.2 x-1 MOC Element change record: V1, Ed 2 Configuration control
x.1.3 x-1 New row: V1 Ed 2 with reference to interoperability Point to 552/2004 as
Regulation (as modified) modified
x.3 PRL tables: Legend moved to main body 1.7.5. Consistency
Consistent use of lower case m, o, etc.
ANNEX A
A.2.1.1 A-2 AMHS-BAS-A06 split into 2 requirements: (1) Separate base standards
Implementations of AMHS Components shall from ISPs. Equivalence of
conform to the 2003 version of the ISO/IEC MHS ITU-T and ISO/IEC
base standards or the 1999 version of the ITU-T standards.
equivalents [18].

Appendix 4-8 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

A.2.1.1 A-2 AMHS-BAS-A06 split into 2 requirements: (2) Status of ISPs
[AMHS-BAS-A06A] and the 2003 version of the
referenced Although the International Standardized
Profiles (ISPs) [19], [20] referenced in ICAO Doc
9880 and ICAO EUR Doc 020 have been withdrawn
and are no longer maintained by ISO/IEC,
implementations of AMHS Components shall
conform to the last published versions of the ISPs or
equivalent provisions which may be published
elsewhere.
A.2.1.1 A-3 2003 ISO/IEC base standards Clarification
A.2.1.3 A-4 AMHS0-SAF-A03 Note: inserted link to SAM as Add reference
footnote.
A.2.1.3 A-4 AMHS-SAF-A04, AMHS-SAF-A05, AMHS-SAF-A06: Clarify source of
Prefixed with “In accordance with the SES requirement &
interoperability Regulation [1],” consistency with SES
A.2.1.3 A-4 ANSPs will have responsibility ANSPs do have this
responsibility
A.2.1.3.1 A-4 Replaced “Regulation (EC) No. 482/2008 [24]” with 482/2008 is being
“relevant EC/EU Regulations [24]” repealed. Ref [24] in Main
Body gives current status.
A.2.1.3.1 A-5 In Note 2, replaced ED-109 with ED-109A (3 times). ED-109 current edition.
Replaced “Regulation (EC) No. 482/2008 [24]” with 482/2008 is being
“EC/EU Regulations [24]” repealed
A.2.1.4 A-5 AMHS-PER-A05: Prefixed with “In accordance with Clarify source of
the SES interoperability Regulation [1],” requirement &
consistency with SES
A.2.1.4 A-5 AMHS-PER-A07: Prefixed with “In accordance with Clarify source of
the SES interoperability Regulation [1],” Replace requirement &
“such as way” with “such a way” consistency with SES &
typo
A.2.1.4 A-6 Note referring to SPACE project predictions deleted Historical note based on
early pre-deployment
estimates.
A.2.1.5 A-6 Added requirement to include entry in ICAO Register Include reference to ICAO
of AMHS MDs. Note revised accordingly. Register
A.2.1.7.3 A-7 Replace ED-109 [31] Section 4.1 with ED-109A [31] Update reference
Section 12.4
A.2.2 A-9 In Note, replace “sections 3.2.2 to 3.2.4” with “section Update reference
3.2.2”
A.2.2 A-10 [AMHS-AMS-A06] Replace “MTAs shall support a P1 Update requirement with
message length of at least 2 Mbyte” with “MTAs shall reference to EUR AMHS
support at least the minimum P1 message length profile
specified in Appendix B Annex F of ICAO EUR Doc
020 [8]”
A.2.2 A-10 [AMHS-AMS-A10] Replaced “section 5.2.2” with Specific reference to EUR
“section 5.2 and Appendix B Annex F.2.4.1” AMHS profile
A.2.2 A-10 [AMHS-AMS-A11] appended “, as specified in Clarify source of
Appendix B Annex J of ICAO EUR Doc 020 [8].” requirement &
consistency with EUR
AMHS profile
A.2.2.1 A-10 Appended “, Chapter 3” after “Annex 10, Volume III, More specific reference
Part 1”
A.2.3 A-11 [AMHS-AMU-A01] Replace “AMH21 as specified Remove ISP reference.
ISO/IEC ISP 12062-2 [20]” with “AMH21 as specified Consistency with EUR
in Appendix B Annex A of ICAO EUR Doc 020 [8]“ AMHS profile.

Edition: 2.1 Released Issue Appendix 4-9

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

A.2.3 A-11 [AMHS-AMU-A02] Appended “ | ITU-T” after Equivalence of ITU-T and
“ISO/IEC 10021” ISO/IEC standards.
A.2.3 A-11 [AMHS-AMU-A03] appended “, in accordance with Clarify source of
Appendix B Annex A.2.3.8 of ICAO EUR Doc 020 requirement &
[8].” consistency with EUR
AMHS profile
A.2.3 A-11 [AMHS-AMU-A05] Appended “ | ITU-T Equivalence of ITU-T and
Recommendation X.419” after “ISO/IEC 10021-6” ISO/IEC standards.
A.2.4 A-12 [AMHS-MST-A01] Appended “-6 | ITU-T Equivalence of ITU-T and
Recommendation X.419” after “ISO/IEC 10021” ISO/IEC standards.
A.2.4 A-12 [AMHS-MST-A02] Appended “-6 | ITU-T Equivalence of ITU-T and
Recommendation X.419” after “ISO/IEC 10021” ISO/IEC standards.
A.2.4 A-12 [AMHS-MST-A04] Replaced “”MS implementations Consistency with EUR
may support the Distribution List (DL) functional AMHS profile
group” with “MS implementations shall support the
Distribution List (DL) functional group, in accordance
with Appendix B of ICAO EUR Doc 020 [8].”
A.2.5 A-12 Capitalised “Chapter” (twice) Editorial
A.2.5 A-13 [AMHS-GWY-A02] replaced “ATS Messaging Column heading updated
Service” with “ATSMHS” in ICAO doc
A.2.5 A-13 In Notes, deleted “originates from the SPACE project. Historical notes. SPACE
It ”(twice) is not referenced.
A.2.5 A-12 [AMHS-CA-A03] Replaced “section” with “Chapter” ICAO terminology
A.3 A-14 Append “Completed conformance statements can be Clarify purpose.
used in support of the DoC and/or part of Technical
File accompanying the DoV.”
A.3.1 A-15 Table A-1 row 3.2.2, replaced “4.5.2.2.6.2.1” with Update cross reference
“4.5.2.2.8”
A.3.1 A-16 Corrected spacing in Note Editorial
A.3.1 A-16 [AMHS-CA-A04] Replaced section” with “Chapter” ICAO terminology
A.3.1 A-17 Table A-2, rows 1-4 and 6-10: Replaced “ATS Mess. Column heading updated
Service” with “ATSMHS” (9 times) in ICAO doc
A.3.1 A-17 Table A-2, row 5 (Ref Table 4-9): Replaced “ATS Column heading updated
Mess. Service” with “Basic ATSMHS support” in ICAO doc
ANNEX B
B.2.1.1 B-2 Deleted Note regarding cross-domain management XMIB no longer
referenced in Doc 9880
Ed 2
B.2.1.2 B-3 AMHS-GEN-B03: Prefixed with “In accordance with Clarify source of
the SES interoperability Regulation [1],” requirement &
consistency with SES
B.2.2.1 B-3 Replaced “sections 3.2.2 to 3.2.5” with “sections Update cross-reference
3.2.4 and 3.2.5”
B.2.2.4 B-5 Replaced “ISO/IEC ISP 10611-1 [19]” with “ICAO Dereference ISP
Doc 9880 Part II [5]”
B.2.3.1 B-5 Note 3: replaced 3.1.4.2.1.2 with 3.1.4.2.3 Update cross-reference
B.2.3.1 B-5 AMHS-AMU-B01. Replaced “ISO/IEC ISP 12062-2 Dereference ISP. Detailed
[20]” with “Appendix B Annex A of ICAO EUR Doc profile is specified in EUR
020 [8]” AMHS profile.
B.2.3.1 B-5 AMHS-AMU-B01. Deleted “as specified in ISO/IEC Dereference ISP
ISP 12062-2 [20]”
B.2.3.1 B-5 AMHS-AMU-B01. Replaced “ISO/IEC ISP 12062 [20] Dereference ISP. Detailed
parts 4, 5 and 6” with “Appendix B Annexes C, D and profile is specified in EUR
E of ICAO EUR Doc 020 [8]” AMHS profile.
B.2.3.2 B-6 AMHS-AMU-B04 Note 2. Replaced “ISO/IEC ISP Dereference ISP. Detailed
12062-2 [20], paragraph A.2.5” with “Appendix B profile is specified in EUR
Annex A of ICAO EUR Doc 020 [8]” AMHS profile.

Appendix 4-10 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

B.2.3.2 B-6 Table B-1. Replaced heading “ISP” with “AMH21”. Profile reference &
Expanded “Orig.” & “Rec.” editorial
B.2.3.5 B-8 AMHS-AMU-B15 Note 2. Deleted “As noted in Remove unnecessary ISP
ISO/IEC ISP 10611-1 [19], “. references
Replace “outside the scope of the ISP” with “not
within scope”
B.2.4.2 B-9 AMHS-MST-B02. Replaced 3.2.4.3 with 3.2.4.4. Update cross-reference
B.2.5.1 B-10 Capitalised “Chapter” Editorial
B.3 B-12 Append “Completed conformance statements can be Clarify purpose.
used in support of the DoC and/or part of Technical
File accompanying the DoV.”
B.3.1 B-12 AMHS-CA-B03. Replaced “section” with “Chapter” ICAO terminology
B.3.1 B-13 Table B-2 Row 3.10. Replaced 4.2.2.4.1 with 4.2.2.4 Update cross-reference
B.3.1 B-14 Table B-2 Row 8. Replaced 4.5.2.2.6.2.1 with Update cross-reference
4.5.2.2.8
B.3.1 B-14 Note after Table, replace 9980 with 9880 Correct typo.
B.3.1 B-15 AMHS-CA-B04. Replaced “section” with “Chapter” ICAO terminology
B.3.1 B-15 Table B-3, rows 1-4 and 6-10: Replaced “ATS Mess. Column heading updated
Service” with “ATSMHS” (9 times) in ICAO doc
B.3.1 B-16 Table B-3, row 5 (Ref Table 4-9): Replaced “ATS Column heading updated
Mess. Service” with “Basic ATSMHS support” in ICAO doc
ANNEX C
C.1.4 C-1 Added ICAO EUR Doc 020 (Appendix G) to table. EDS schema elements
are included
C.2.1 C-2 Note 2: Replaced “currently the only access protocol Allow for other access
specified by ICAO” with “required by ICAO” protocols including LDAP
C.2.1 C-2 Note 3: Deleted “Due to operational requirements Update to refer to EDS
which have yet to be resolved, the Directory structure specification, which
in Europe may include additional elements beyond includes version control.
those specified in current ICAO documentation. This
would include, for example, additional attributes for
version control.”
Replaced with “ICAO EUR Doc 020 [8] includes
requirements for a European Directory Service
(EDS), in which a Central European DSA shares
information with DSAs operated by participating
States or Organisations. The EDS defines a workflow
concept supporting incremental versions of pre-
operational and operational shared data.”
C.2.1 C-2 AMHS-DIR-C02. Deleted “and ISPs” Redundant: ISPs are
standards
C.2.1 C-2 AMHS-DIR-C03. Replaced 5.7.6.3 with 2.5.7.6 ICAO document
restructured in Ed 2
C.2.1.1 C-3 AMHS-DIR-C06. Inserted: Note: For DSAs Update to refer to EDS
participating in the EDS described in ICAO EUR Doc specification and clarify
020 [8] Appendix G and using DISP, the co-operating shadowing role
or adjacent DSA always acts in the consumer role.
C.2.1.1 C-3 Note: This is required to enable implementation of Deprecate “initial” vs
the initial directory architecture simple uploads of “future” architecture,
directory information (e.g. the Initial Step of EDS which are ill-defined.
deployment described in ICAO EUR Doc 020 [8] Clarify LDIF requirement.
Appendix G).
C.2.1.2 C-3 AMHS-DIR-C13. Appended text after Note: “The Update to refer to EDS
EDS specified in ICAO EUR Doc 020 [8] discourages specification and clarify
the use of referral.” referral usage

Edition: 2.1 Released Issue Appendix 4-11

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

C.2.1.3 C-4 Replaced “supported by DUAs and DSAs” with Correction – All DUAs do
“supported by DSAs and selectively by DUAs not support all operation
depending upon the type of DUA as defined in Table types.
2-18 of ICAO Doc 9880 Part IV Chapter 2 [7].”
C.2.2.1.c C-4 Replaced DUA with UA Correction
C.2.2.2 C-6 AMHS-DIR-C22: It is recommended that the DSA Rewording of ambiguous
should export only atn-amhs-user and atn-amhs- text. Add reference to
distribution-list object-classes for only the eds-amhs- EDS-defined object class.
user object class, as specified in Annex G-B of ICAO
EUR Doc 020 [8], should be used to represent users
C.2.2.2 C-6 AMHS-DIR-C24: The DSA shall use this DIT Over-specification. Refer
structure to support the name resolution function, to EDS specification
using Country, Organization, atn-organization and instead.
atn-amhs-user object-classes specified in Annex G-B
of ICAO EUR Doc 020 [8].
C.2.2.2 C-6 AMHS-DIR-C26: The DSA shall use this DIT Over-specification. Refer
structure to support the AFTN/AMHS address to EDS specification
conversion function performed by the AFTN/AMHS instead.
Gateway based on the “Simple AMHS address
conversion directory algorithm” described below,
using object classes specified in Annex G-B of ICAO
EUR Doc 020 [8]Country, Organization, atn-
organization, atn-amhs-user, atn-amhs-distribution-
list and atn-amhsMD.
C.2.2.2 C-6 AMHS-DIR-C27: [Requirement deleted] The attribute Obsolete requirement.
description of the object classes Country and
Organization used as the root of the exported sub-
tree shall be used as follows to store the current
version of this sub-tree:
Format of the description attribute: “<version
number> - <description of the object>”.
C.2.2.2 C-7 AMHS-DIR-C28: [Requirement deleted] The country Obsolete requirement.
or the organization shall maintain the version of its Version control is
exported sub-tree. described in EUR AMHS
Note: The “Common Off-line function” or the “Europe Manual.
DSA” will be responsible to maintain the version of
the sub-tree starting with the organization “O=ICAO-
MD-Registry”.
C.2.2.3 C-7 Delete Note: Based on the DIT structure outlined in Update to align with EDS
section 4 of the Main Body the following algorithm is specification
applicable for the AFTN/AMHS address conversion
function:

Appendix 4-12 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

C.2.2.3 C-7 AMHS-DIR-C29: Each State or organisation Update to align with EDS
participating in the EDS shall implement a DSA specification
containing a DIT sub tree shadowed from the Central
European DSA based on a member of the
organization object-class named O=European-
Directory, as specified in Appendix G-B of ICAO EUR
Doc 020 [8].shall include:
a) the subtree for its own ANSP containing local
AMHS user information relative to AFTN/AMHS
address translation,
b) Note: the MD-registry sub tree starting with a
member of the organization object-class named
O=ICAO-MD-Registry and containing atn-amhsMD
objects is contained within this sub tree.(ideally
replicated from a master DSA managed by ICAO),
c) a replicated sub tree or a reference to the other
ANSP exported DIT.
C.2.2.3 C-8 to AMHS-DIR-C32: Deleted requirement and following 3 Update to align with EDS
C-9 Notes describing an algorithm for AFTN – AMHS specification
address conversion.
Replaced with: For AFTN to AMHS address
conversion, the algorithm described in Appendix G-B,
section 5.1 of ICAO EUR Doc 020 [8] shall be
supported.
C.2.2.3 C-10 Note after AMHAS-DIR-C33: The above The 8-character limitation
recommendation is for backwards compatibility with a does not exist in
previous version requirement is good practice to published versions of
accommodate an initial limitation of the defined ATN standards.
Directory schema, whereby the. The atn-
FacilityName attribute (of the atn-organization
object) is limited to 8 characters while the
"Organization Name" field permits up to 64
characters. atn-FacilityName is used by the
AFTN/AMHS address translation algorithm to
construct the field "Organization Name" of an AMHS
O/R-address for CAAS countries.
C.3 C-11 Delete “Note”. Replace “this Annex” with “Annex C”. Consistency. Clarify
Append “Completed conformance statements can be purpose.
used in support of the DoC and/or part of Technical
File accompanying the DoV.”
C.3.1 C-11 AMHS-CA-C01: DSAs shall implement as a minimum Update to align with EDS
the object classes specified in Table C-3 to Table C- specification
6, and, for DSAs participating in EDS, the EDS-
specific object classes specified in ICAO EUR Doc
020 [8] in order to guarantee correct understanding of
the data
C.3.1 C-11 Table C-3. Caption: DSA Supported ISO/IEC 9594-7 Equivalent ITU-T
| ITU-T Rec. X.521 [34]:1995 Object Classes as standard. Unnecessary
Specified in ISO/IEC ISP 15126-1 [16] ISP reference. “ATN DSA”
Deleted ATN DSA & Comments columns. no longer in Doc 9880.
C.3.1 C-11 Table C-3 Correct syntax
ref 6: organizationUnit -> organizationalUnit
ref 11: groupofuniqueNames ->
groupOfUniqueNames
ref 15: dSa -> dSA
C.3.1 C-11 Table C-3 ref 9: changed organizationalRole support Required for EDS
from o to m

Edition: 2.1 Released Issue Appendix 4-13

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

C.3.1 C-11 Table C-3: appended new rows for object classes: Update for later standard
userSecurityInformation, certificationAuthority-V2, edition.
dMD and userPwdClass – all “o” in support column.
C.3.1 C-11 Table C-4: Caption: Additional DSA Supported Clarification. Refer to
Object Classes Defined in ISO/IEC ISP 15126- profile by name instead of
1profile FDY11 [16] ISP reference.
Deleted ATN DSA & Comments columns
C.3.1 C-11 Table C-5: Caption: DSA Object Classes Defined for Insert base standard
Message Handling System (MHS) in ISO/IEC 10021- reference & remove
2 | ITU-T Rec. X.402 [18]ISO/IEC ISP 11189 (FDI2) unnecessary ISP
[17] reference.
Renamed ATN DSA column as Doc 9880, deleted
Comments column.
C.3.1 C-11 Table C-5: Correct syntax
ref 1: mhs-distributionList -> mhs-distribution-list
C.3.1 C-12 Table C-6: caption: ATN-specific DSA Object Clarification.
Classes Defined in ATN DirectoryICAO Doc 9880
Part IV [7]
Renamed ATN DSA column as Doc 9880, deleted
Comments column
C.3.1 C-12 Table C-6 ref 1, 4, 11, 12, 15: Indicate EDS support Update to align with EDS
requirements. specification
Changed Support for atn-organizational-role and atn-
facility from o to c
C.3.2 C-12 In Note, deleted Versioning of the directory data will Versioning is described in
be handled by local means. referenced EDS
specification
C.3.2 C-12 Table C-7. Deleted Comments column. Applied Editorial
consistent support notation instead of Y/N. Improved
formatting.
C.3.2 C-12 Table C-7. Replaced aliasEntityName with Correct syntax
aliasedEntryName
C.3.2 C-12 Table C-7. Under atn-amhs-user, deleted in ISO/IEC Unnecessary cross-
10021-2 reference
C.3.2 C-12 Table C-7. Under atn-amhs-user, deleted row Update for later standard
containing mhsPreferredDeliveryMethods edition
Appended new rows for attributes: atn-
maximum_number-of-body-parts, atn-
maximum_text_size, atn-maximum_file_size, atn-
use-of-amhs-security, atn-use-of-directory, atn-
group-of-addresses – all with Y in Support column
C.3.2 C-13 Table C-7. Under atn-certification-authority, deleted “, Unnecessary cross-
which is defined in X.521” reference
C.3.2 C-13 Table C-7. Under atn-amhs-distribution-list, deleted “, Unnecessary cross-
defined in ISO/IEC 10021-2” reference
C.3.2 C-13 Table C-7. Under atn-amhs-distribution-list, deleted Update for later standard
row containing mhs-PreferredDeliveryMethods edition.
Appended new rows for attributes: atn-
maximum_number-of-body-parts, atn-
maximum_text_size, atn-maximum_file_size, atn-
use-of-amhs-security, atn-use-of-directory, atn-
group-of-addresses – all with Y in Support column
C.3.2 C-13 Table C-7. Under atn-amhsMD, Correction
atn-amhsMD-addressing-scheme -> atn-amhs-
addressing-scheme
C.3.2 C-13 Table C-7. Under atn-organization, deleted “, which is Unnecessary cross-
defined in X.521” reference

Appendix 4-14 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

C.3.2 C-13 Table C-7. Under atn-organization, Correct syntax
organizationalAttributeSet ->
OrganizationalAttributeSet
C.3.2 C-13 Table C-7. Added object classes atn-organizational- Object classes required
role and atn-facility, with associated attributes for EDS
C.3.3 C-14 In Note, replaced 1.3.12 with 2.1.3.12 ICAO document
restructured in Ed 2
C.3.3 C-14 Table C-8, in DSA column for DISP Operations, Clarify status for EDS
replaced “o” with “c1” and added after table:
c1: m if DISP supported, else o. Strongly
recommended for participation in EDS
C.3.3 C-15 Table C-8. Appended rows for Administer Password Latest X.519 edition
and Change Password.
C.3.4 C-15 AMHS-CA-C04: replaced 5.2.1 with 2.5.2.1 ICAO document
restructured in Ed 2
C.3.4 C-15 In Note, deleted (2005) after X.519 Publication date is given
in References list.
C.3.4 C-16 Table C-9: Deleted Notes column.
C.3.4 C-16 Table C-9, row b), added “Is the userPwd supported Latest X.519 edition
for password policy?”
C.3.4 C-16 Table C-9, row c), inserted “in” before “Table 1”. Include reference. Update
Added cross-reference [34] for X.511. Added for latest X.500 editions
reference numbers for all extensions.
Replaced “useContexts” with “use of Contexts”
Replaced “hierarchySelection” with
“hierarchySelections”
Deleted:
Security parameters – Response, SPKM Credentials,
Bind token – Response, Bind token - Bind Int. Alg,
Bind Int Key, Conf Alg and Conf Key Info, Bind token
- DIRQOP
Added:
friend attributes, Abandon of paged results, Paged
results on the DSP, replaceValues
C.3.4 C-16 Table C-9, row d), deleted “19.4 of “ and add cross- Correct section number
reference [34] for X.501 for latest standard.
Include reference.
C.3.4 C-16 Table C-9, row e), added cross-reference [35] for Include reference. Table
X.509. Moved list of supported extensions from format. Update for latest
column 2 to column 1 and added reference to extra X.500 editions
optional extensions.
C.3.5 C-17 AMHS-CA-C05: replaced “section 5” with “section ICAO document
2.5.2.2” restructured in Ed 2
C.3.5 C-17 In Note, deleted (2005) after X.519 Publication date is given
in References list.
C.3.5 C-17 Table C-10. Deleted column “initial Directory service” Deprecate “initial” vs
to C- and changed column heading “future Directory “future” service, which are
20 service” to “Profile” ill-defined. Merge
requirements into single
column.
C.3.5 C-17 Table C-10. Added reference [34] after all Include reference
to C- occurrences of 9594-x.
20
C.3.5 C-17 Table C-10 row a). In Profile column, inserted “c1 – “ Reflect conditionality
for directorySystemAC.
C.3.5 C-17 Table C-10 row e). added: “or the userPwd is Update for latest X.500
supported for password policy” editions

Edition: 2.1 Released Issue Appendix 4-15

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

C.3.5 C-17, Table C-10 rows d), f), m), n). In Profile column, Reflect conditionality
C-19 Replaced “m –“ with “c1 – “
C.3.5 C-17 - Table C-10 row g). State which of the The selected Update for large number
C-19 attribute types defined in Section 2 (paragraphs 6.1 of optionally supported
to 6.17) of ITU-T Rec. X.520 | ISO/IEC 9594-6 [34] attribute types in latest
are supported X.500 editions
Deleted list of attribute types
Appended “above” after C.3.2
C.3.5 C-19 Table C-10 row h). Appended “above” after C.3.1 Clarify cross-ref. Update
Insert User Password. for latest X.500 editions
C.3.4 C-19 Table C-10, row i), in Profile column, clarified that all Consistency with Table C-
are optional & refer to extensions list in Table C-9. 9.
C.3.5 C-19 Table C-10 row j). Replaced 8.9 with 8.10.2, replaced Update for latest X.500
9.2.2 with 12.3.2 editions
C.3.5 C-19 Table C-10 row k). Replaced “7.6, 7.8.2 and 9.2.2” Update for latest X.500
with “7.9 and 11.2.2” editions
C.3.5 C-19 Table C-10 row o). Replaced 11.3.2 with 12.3.2 Update for latest X.500
editions
C.3.5 C-20 Table C-10: Deleted rows w), y) and z). Relabelled x) Obsolete requirements
as w), aa) as x), bb) as y), cc) as z) and dd) as aa). not in current standards.
C.3.5 C-20 Table C-10: In relabelled row w), replaced 7.13 with Update reference.
7.12.
C.3.5 C-20 Table C-10: In relabelled row aa), Moved list of Update for latest X.500
extensions from column 2 to column 1 and added editions. Consistency with
reference to extra optional extensions. Table C-9.
C.3.5 C-20 Table C-10: Add new row for subjectAltName (same Consistency
as Table C-9)
C.3.5 C-20 Table C-10: Inserted after table: “c: [same as for Define conditionality
Table C-9]; c1: m in final ATN directory deployment;
could be omitted in initial transition step.”
C.3.6 C-20 AMHS-CA-C06: Replaced “the directory information Consistency
shadowing protocol” with “DISP”
C.3.6 C-20 AMHS-CA-C06: Replaced “section 5.5” with “section ICAO document
2.5.5” restructured in Ed 2
C.3.6 C-20 In Note, deleted (2005) after X.519 Publication date is given
in References list.
C.3.6 C-21 Table C-11. Deleted column “initial Directory service” Deprecate “initial” vs
and changed column heading “future Directory “future” service, which are
service” to “Profile” ill-defined. Merge
requirements into single
column.
C.3.6 C-21 Table C-11, row a). Deleted: “If claiming disp-ip (direct mapping to
conformance to disp-ip, it shall be stated whether the TCP/IP) is out of scope.
implementation is capable of invoking the
requestShadowUpdate operation, responding to a
coordinateShadowUpdate, or both.”
C.3.6 C-21 Table C-11, row a). In Profile column, added “For the Update to align with EDS
EDS described in ICAO EUR Doc 020 [8] Appendix specification
G the Central European DSA conforms to
shadowSupplierInitiatedAC“
C.3.7 C-21 AMHS-CA-C07: Replaced “the directory information Consistency
shadowing protocol” with “DISP”
C.3.7 C-21 AMHS-CA-C07: Replaced “section 5.5” with “section ICAO document
2.5.5” restructured in Ed 2
C.3.7 C-21 In Note, deleted (2005) after X.519 Publication date is given
in References list.

Appendix 4-16 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

C.3.7 C-22 Table C-12. Deleted column “initial Directory service” Deprecate “initial” vs
and changed column heading “future Directory “future” service, which are
service” to “Profile” ill-defined. Merge
requirements into single
column.
C.3.7 C-22 Table C-12, row a). Deleted: “If claiming disp-ip (direct mapping to
conformance to disp-ip, it shall be stated whether the TCP/IP) is out of scope.
implementation is capable of invoking the
requestShadowUpdate operation, responding to a
coordinateShadowUpdate, or both.”
C.3.7 C-22 Table C-12, row a). In Profile column, added “For Update to align with EDS
DSAs participating in the EDS described in ICAO specification
EUR Doc 020 [8] Appendix G, conformance to
shadowSupplierInitiatedAC is required if DISP is
implemented.“
ANNEX D
D.2.1 D-2 Appended to Note 1: “Completed conformance Clarify relationship to EC
statements can be used in support of the DoC and/or Declarations.
part of Technical File accompanying the DoV.”
D.2.2.1 D-2 In Note, replaced ISPs with “referenced standards” De-reference ISPs &
generalise
D.2.2.1 D-3 AMHS-SEC-D09: CAs shall be conformant Superseded reference.
with Directive 1999/93/EC [2], which defines athe
Community framework for electronic signatures
specified in the Regulation on electronic identification
and trust services for electronic transactions [2].
D.2.2.1 D-3 AMHS-SEC-D10: replaced ETSI TS 101 456 ETSI documents updated,
reference with document title & ref to updated EN. include PAG in list of
Note 1: replaced Directive 1999/93/EC with updated references.
EU Regulation reference. Reword ETSI TR 102 040
cross-reference.
Note 2: removed obsolete ETSI TS 101 456
reference, inserted reference to PAG.
D.2.2.1 D-3 AMHS-SEC-D11: deleted “in section 8.4” Generalise.
D.2.2.1 D-4 AMHS-SEC-D15: replaced “ETSI TS 101 456” with Superseded reference.
“the ETSI policy and security requirements for Trust
Service Providers issuing certificates”
D.2.2.1 D-4 AMHS-SEC-D19: According toWhere item 8.3.1.2.7 Clarification
of the ATN Security provisions [6] refers to use of: “If
a directory service is used for certificate and CRL
distribution, this the service shall conform to the ATN
directory service as specified in […ICAO Doc 9880
Part IVA [7]]”. This shall be taken to mean …
D.2.2.1.1 D-5 AMHS-SEC-D20: In bullet d), replaced “directive” Align with updated
with “Regulation” reference
D.2.2.2 D-6 AMHS-SEC-D21 Note 1: replaced “ETSI Superseded reference.
recommendation TS 102 176-1” with “ETSI
recommendations for cryptographic suites”
D.2.2.2 D-7 AMHS-SEC-D23: replaced “FIPS 180-2” with “the Expand acronym, remove
Federal Information Processing Standard for “ specific version from text.
D.2.2.2 D-7 AMHS-SEC-D24: deleted “(section 8.7)” Obsolete section
reference
D.2.3.1 D-7 AMHS-SEC-D27 Note 1: requirements of various Correct typo & update
international standards, including ICAO Annex 17 reference
[29], ICAO EUR Security Guidelines [10],
and Regulation (EC) 2096/2005EU Common
Requirements for air navigation services [25]

Edition: 2.1 Released Issue Appendix 4-17

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

D.2.3.1 D-7 AMHS-SEC-D28 Note: ”as defined in section 7 of ISP Include definition here
10611-1 [19]” replaced with “, which only requires instead of reference to
support of end-to-end security services between UAs Withdrawn ISP.
(content integrity, message origin authentication,
proof of delivery), and hence can be used to provide
some protection even in the case of transit through
an intermediary MTS which may not be trusted.”
D.2.3.2 D-8 AMHS-SEC-D31: deleted . “Note: ICAO Doc 9880 Remove superseded
Part IIB [5] section 3.1.2.1.2.3.3 notes that it is only note.
possible to perform asymmetric authentication of a
direct AMHS user by an AFTN/AMHS Gateway.
D.2.3.2 D-8 AMHS-SEC-D34:Replaced “§3.1.4.3.2.2.1” with Update Doc 9880 section
“§3.1.3.4” numbers
D.2.3.2 D-9 AMHS-SEC-D37:Replaced Ҥ4.5.2.4.12 to Update Doc 9880 section
4.5.2.4.16” with “§4.5.2.4.16 to 4.5.2.4.22” numbers
D.2.3.5 D-15 AMHS-SEC-D51: Replaced “as claimed in ISO/IEC Equivalence of ITU-T
10021-4 [18]” with “according to ISO/IEC 10021-4 | Recommendation, provide
ITU-T Recommendation X.411 [18], section specific reference
8.2.1.1.1.26.”
D.2.3.5 D-15 AMHS-SEC-D51: As stated in ISO/IEC 10021-4 [18], Remove unnecessary
the The first occurrence of a message sequence cross-reference, align
number can may be a random number terminology
App 1 to D-17 Deleted: have been incorporated into the Draft ICAO Remove obsolete
Annex D Doc 9705 Edition 4, but this will not be published by reference.
ICAO; it
App 1 to D-17 After “ICAO ACP website”, inserted Clarify source.
Annex D footnote: https://www.icao.int/safety/acp/repository/A
CFF6F3.zip
APPENDIX 1
A1.1 Ap 1-2 Replaced “on the” with “for the” Change document title
A1.2 Ap 1-2 Deleted “552/2004” Ref [1] updated for
amendment to 552/2004
A1.2.1 Ap 1-3 A-1-P1: Added [AMHS-BAS-A06A],[AMHS-N&A- New requirements.
A01], [AMHS-DIR-C29] and [AMHS-CA-C01] in Additional traceability re
column 3 information sharing
A1.2.1 Ap 1-4 A-2-P1: added “, sustainability” after “quality” Ref [1] Amendment
Deleted Note on SES II proposed amendment. incorporated.
Added [AMHS-BAS-A01], [AMHS-BAS-A03], [AMHS- Comments received.
BAS-A04], [AMHS-BAS-A05], [AMHS-BAS-A06] and
[AMHS-BAS-A07] in column 3
A1.2.1 Ap 1-5 A-3-P4: Removed shading. Add [AMHS-SAF-A05] in Existing traceability to
column 3. A1.2.1. Definition of
Replaced Note: “This is assumed to apply only to “control staff”
ATC systems, where the “control staff” are ATCOs”
with “In the case of AMHS, the “control staff” are
those persons responsible for managing and
operating the constituent systems”
A1.2.2 Ap 1-9 B-3-1.2-P1: appended “, in particular as envisaged in Ref [1] Amendment
the ATM Master Plan” incorporated.
Deleted Note on SES II proposed amendment.
A1.2.2 Ap 1-9 Section 4 heading: “communication” made plural. Correct typo
A1.2.2 Ap 1- B-4.2-P1: appended “, in particular as envisaged in Ref [1] Amendment
10 the ATM Master Plan” incorporated.
Deleted Note on SES II proposed amendment. Comment received.
In column 3, added [AMHS-AMU-B05], deleted Remove deleted reqs.
[AMHS-DIR-C27] and [AMHS-DIR-C28]. Changed Correct typo.
first [AMHS-DIR-C29] to [AMHS-DIR-C20]

Appendix 4-18 Released Issue Edition: 2.1

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

A1.3.1 Ap 1- AMHS-BAS-A06: Aligned with revised Annex A Annex A amended
12 requirement
A1.3.1 Ap 1- Added new row for [AMHS-BAS-A06A] to align with Annex A amended
12 new Annex A requirement
A1.3.1 Ap 1- AMHS-SAF-A04, AMHS-SAF-A05, AMHS-SAF-A06: Annex A amended
13 Aligned with revised Annex A requirements
A1.3.1 Ap 1- AMHS-PER-A05, AMHS-PER-A07: Aligned with Annex A amended
14 revised Annex A requirements
A1.3.1 Ap 1- AMHS-PER-A08: Changed “B-4.1-P2” to “B-4.1-P1” Comment received.
14
A1.3.1 Ap 1- Added AMHS-N&A-A01 with traceability to A-1-P1 Requirement added in
14 Annex A
A1.3.1 Ap 1- AMHS-AMS-A06, AMHS-AMS-A10, AMHS-AMS- Annex A amended
18 A11: Aligned with revised Annex A requirements
A1.3.1 Ap 1- AMHS-AMU-A01, AMHS-AMU-A02, AMHS-AMU- Annex A amended
19 A03, AMHS-AMU-A05, AMHS-MST-A01, AMHS-
MST-A02, AMHS-MST-A04: Aligned with revised
Annex A requirements
A1.3.1 Ap 1- AMHS-GWY-A01, AMHS-GWY-A02: Aligned with Annex A amended
20 revised Annex A requirements (editorial)
A1.3.1 Ap 1- AMHS-CA-A03, AMHS-CA-A04: Aligned with revised Annex A amended
21 Annex A requirements (editorial)
A1.3.2 Ap 1- AMHS-GEN-B03: Aligned with revised Annex B Annex B amended
22 requirements
A1.3.2 Ap 1- AMHS-AMU-B01: Aligned with revised Annex B Annex B amended
24 requirements
A1.3.2 Ap 1- AMHS-AMU-B04: In column 3, added “A-2-P2” Correct traceability
24
A1.3.2 Ap 1- AMHS-AMU-B05: In column 3, replaced “A-2-P2” Annex B amended
24 with “B-4.2-P1”
A1.3.2 Ap 1- AMHS-MST-B02: Aligned with revised Annex B Annex B amended
25 requirements
A1.3.2 Ap 1- AMHS-CA-B03, AMHS-CA-B04: Aligned with revised Annex B amended
27 Annex B requirements (editorial)
A1.3.3 Ap 1- AMHS-DIR-C01, AMHS-DIR-C03: Aligned with Annex C amended
27 revised Annex C requirements (editorial)
A1.3.3 Ap 1- AMHS-DIR-C15, AMHS-DIR-C16: Aligned with Annex C amended
28 revised Annex C requirements
A1.3.3 Ap 1- AMHS-DIR-C20, AMHS-DIR-C22, AMHS-DIR-C24, Annex C amended
29 AMHS-DIR-C26: Aligned with revised Annex C
requirements
A1.3.3 Ap 1- AMHS-DIR-C27, AMHS-DIR-C28: Deleted rows Annex C amended
29
A1.3.3 Ap 1- AMHS-DIR-C29: Aligned with revised Annex C Annex C amended.
30 requirements. In column 3, add “A-1-P1” Additional traceability re
information sharing
A1.3.3 Ap 1- AMHS-DIR-C32: Aligned with revised Annex C Annex C amended
30 requirements.
A1.3.3 Ap 1- AMHS-CA-C01: Aligned with revised Annex C Annex C amended.
30 requirements. In column 3, add “A-1-P1” Additional traceability re
information sharing
A1.3.3 Ap 1- AMHS-CA-C04, AMHS-CA-C05, AMHS-CA-C06, Annex C amended
31 AMHS-CA-C07: Aligned with revised Annex C
requirements (editorial)
A1.3.4 Ap 1- AMHS-SEC-D09, AMHS-SEC-D10, AMHS-SEC-D11, Annex D amended
32 AMHS-SEC-D15: Aligned with revised Annex D
requirements.

Edition: 2.1 Released Issue Appendix 4-19

 EUROCONTROL SPECIFICATION FOR THE AIR TRAFFIC SERVICES MESSAGE HANDLING SYSTEM (AMHS)

Section Page Change proposal Reason, Justification

A1.3.4 Ap 1- AMHS-SEC-D19, AMHS-SEC-D20, AMHS-SEC-D23, Annex D amended
33 AMHS-SEC-D24: Aligned with revised Annex D
requirements.
A1.3.4 Ap 1- AMHS-SEC-D33, AMHS-SEC-D34: Aligned with Annex D amended
34 revised Annex D requirements.
A1.3.4 Ap 1- AMHS-SEC-D37: Aligned with revised Annex D Annex D amended
35 requirements.
A1.3.4 Ap 1- AMHS-SEC-D51: Aligned with revised Annex D Annex D amended
36 requirements.
APPENDIX 2
Appendix References to Doc 9705 Sub-Volume I deleted. List Align with ICAO
2 of standards updated & broken down per ICAO documentation
document. Historical notes deleted. Tables
numbered. Hyperlinks updated.
APPENDIX 3
Appendix New Appendix “Specification Update Procedures” Current EUROCONTROL
3 standardisation process
APPENDIX 4
Appendix New Appendix “Amendments to Specification” Current EUROCONTROL
4 standardisation process

Appendix 4-20 Released Issue Edition: 2.1

EUROCONTROL

© September 2018 – European Organisation for the Safety of Air Navigation (EUROCONTROL)
This document is published by EUROCONTROL for information purposes. It may be copied
in whole or in part, provided that EUROCONTROL is mentioned as the source and it is not used for
commercial purposes (i.e. for financial gain). The information in this document may not be modified
without prior written permission from EUROCONTROL.

www.eurocontrol.int