AMHS Spec 2.1 - Released Issue - Web
AMHS Spec 2.1 - Released Issue - Web
Edition: 2.1
Edition date: 06/09/2018
Reference nr: EUROCONTROL-SPEC-0136
EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION
EUROCONTROL
DOCUMENT CHARACTERISTICS
TITLE
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
The following table records the complete history of the successive editions of the present
document.
Publications
EUROCONTROL Headquarters
96 Rue de la Fusée
B-1130 BRUSSELS
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
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
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
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.
compliance with the essential requirements and regulatory provisions in agreement with their
national supervisory authority.
1. INTRODUCTION
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
2
SES interoperability Regulation [1], Annex II, Part B, paragraph 4.2.
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.
EUROCONTROL SES
SES AMHS Environment
Regulations Specification
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
3
Edition 2.0 of this Specification referenced in OJ 323/24, 31.12.2009 (amended by corrigendum C
18/47, 23.1.2010
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
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]
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
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
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)
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).
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.
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.
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.
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)
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.
DAP DAP
P1 P1
P1
AFTN/AMHS AFTN/AMHS
Gateway Gateway
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)
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.
DUA
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
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].
5
The referenced ISPs are no longer available from ISO/IEC.
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.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.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.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.
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
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.
“SEC”
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.
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.
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
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.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.
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.
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.
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
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)”.
7
ISP Withdrawn by ISO.
8
Generic reference to the whole series of ISO/IEC ISP 10611 standardised profiles, now Withdrawn
by ISO.
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
12
This is a generic reference to the whole series of ISO/IEC 9594 | X.500 standards. Different parts
have different versions
EUROCONTROL
The following table records the complete history of the successive editions of the present
document.
CONTENTS
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.
1
http://www.eurocontrol.int/articles/safety-assessment-methodology-sam
• 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.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.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.
[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.
[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.
[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].
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.
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
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 A-1.
AFTN/AMHS Gateway
Message Transfer
and Control Unit
(AU)
Abstract
Service
Boundary
ATN
AFTN
Component
Component
(MTA)
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.
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.
EUROCONTROL
The following table records the complete history of the successive editions of the present
document.
CONTENTS
[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.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.
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.
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.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.
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.
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].
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.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.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
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.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.
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
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)
EUROCONTROL
The following table records the complete history of the successive editions of the present
document.
CONTENTS
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
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,
[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.
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.
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.
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.
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
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
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
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
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
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.
CRL extensions: c
cRLNumber
reasonCode
invalidityDate
deltaCRLIndicator
issuingDistributionPoint
deltaInfo
State which other optional Certificate and CRL extensions are supported. o
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
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
EUROCONTROL
The following table records the complete history of the successive editions of the present
document.
CONTENTS
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.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.
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.
CA root CA root
Nation i Nation j
European Community
CA root
CA root Nation l
Nation k
CA root
Nation x
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
“SHA-256”, but this may not be necessary for ATS messages, depending on the threat
model.
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.
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.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.
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
APPENDIX 1
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
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).
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.
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.
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.
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].
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.
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.
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.
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.
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
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.
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]
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).
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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]
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].
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]
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
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.
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
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
APPENDIX 2
TABLE OF CONTENTS
LIST OF TABLES
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.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
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)
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).
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.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
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)
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
© 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