Attachment A
Draft of Requirements
for the
Secure Dialogue Service
in
Doc 9880 Edition 3,
Part IV-B
Security Services
-2-
7
ATN SECURE DIALOGUE SERVICE
7.1 Introduction
7.1.1 The Secure Dialogue Service (sDS) is an abstract service used by an ATN Application (ATNApp) Application Service Element (ASE) at its lower service boundary. It operates on top of the Upper
Layer Communications Service (ULCS) Dialogue Service (DS) or the Internet Protocol Suite (IPS) DS
but supports the Security Requirements parameter, that is, it adds or deletes security related items to/from
the User Data.
The Secure Dialogue Service defines a set of primitives which correspond to the ULCS/IPS Dialogue
Service primitives. For example there is a secure D-START service (sD-START) which corresponds to
the D-START primitive of the ULCS/IPS Dialogue Service. The main difference is that the sD-START
primitives will perform security related processing within the sDS sub-layer transparent to the ATN-App
ASE and transparent to the ULCS/IPS Dialogue Service.
The Secure Dialogue Service supports the request of the dialogue service security types as defined in Table
7.1-1 by the secure dialogue service user.
Table 7.1-1. Dialogue Service Security Types
Dialogue Abstract Value
No Security
Description
No authentication is provided for application user data
exchanges over the dialogue.
Secured Dialogue Supporting Exchange of key agreement data is provided in dialogue
Key Management
establishment. Peer entity authentication and session key
establishment is performed in dialogue establishment. If User
Data is exchanged in dialogue establishment data origin
authentication protection is provided.
Secured Dialogue
Data origin authentication is provided for all application user
data exchanges by user applications over a secured dialogue.
Reserved
Reserved for future use.
Dialogue Abstract Value “Secured Dialogue Supporting Key Management” is used during initial dialogue
establishment by an ATN application, for example, by Context Management (CM) or Controller-Pilot Data
Link Communications (CPDLC). Subsequent user data exchanges over an established dialogue will use
the Dialogue Abstract Value “Secured Dialogue”.
Subsequent dialogues by an ATN application of the same type (e.g. the CPDLC application) in the same
domain may initiate a new dialogue using key agreement data exchanged during the initial dialogue. This
operation is signaled by the domainFlag element in the initial exchange.
Figure 7.1-1 depicts the placement of the Secure Dialogue Service Element (sDSE).
-3-
ASE
DS req
DS rsp
DS ind
DS cnf
DS ind
DS cnf
sDS req
sDS rsp
sDSE
DS req
DS rsp
sDS ind
sDS cnf
DS req
DS rsp
ULCS/IPS
DSP
DS ind
DS cnf
Figure 7.1-1 Placement of sDSE between the ASE and the ULCS/IPS DS
The Secure Dialogue Service Element, if implemented, is placed between the ASE and the ULCS or IPS
Dialogue Service abstract interface. As depicted in Figure 7.1-1 the DS primitives are mapped to
corresponding sDS primitives coming into the sDSE and are mapped back onto the DS primitives when
leaving the sDSE.
7.1.2
Operation over the ULCS Dialogue Service or IPS Dialogue Service
An ATN-App ASE may implement the Secure Dialogue Service with the ULCS Dialogue Service defined
in Doc 9880. The Secure Dialogue Service can also be used over the IPS Dialogue Service defined in
Doc 9896.
7.1.3
Applications Supported
The Secure Dialogue Service supports Air-Ground applications defined in Doc 9880. These applications
optionally invoke security based on the “local security policy”.
7.1.4
Requirement to Implement
If an ATN-App ASE does not require the services offered by the Secure Dialogue Service, then there is
no requirement to implement the Secure Dialogue Service, or to support the related services, and the
provisions in this section do not apply.
-47.1.5 The remainder of this section is organized as follows: 7.2 defines the general processing
requirements associated with the set of sDS abstract services. 7.3 describes each of the sDS primitives.
7.2 General Processing Requirements
7.2.1
Encoding Rules for sDS Data
7.2.1.1 The SSO shall use the basic unaligned variant of the Packed Encoding Rules (PER) for ASN.1, as
specified in ISO|IEC 8825-2, when encoding security-related data.
7.2.2
Error Processing Requirements
7.2.2.1 In the event that the sDS cannot complete any requested function, the sDS shall notify the sDSuser.
Note. Examples of error events requiring sDS-user notification are incompatible input, required
information not available, and failure of an SSO primitive. The means of notification of these
errors is a local matter.
-5-
7.3 sDS Entity Protocol Definition
7.3.1
sD-START Request primitive
7.3.1.1 When the sD-START Request is validly invoked with the Security Requirements parameter
absent or set to the abstract value “No Security”, the sDS shall:
a) invoke the ULCS or IPS D-START Request primitive.
7.3.1.2 When the sD-START Request is validly invoked with the Security Requirements parameter set to
the abstract value “Secured Dialogue Supporting Key Management”, the sDS shall:
a) retrieve the Called AP-title from the sD-START Request Called Peer ID.
b) retrieve the Calling AP-title from the sD-START Request Calling Peer ID.
c) if the Called AP-title identifies an airborne entity then get the signature key certificate path of
the local system by activating the SSO-GetCertificatePath function with the parameters in Table
7.3.1-1.
Table 7.3.1-1
SSO-GetCertificate Path function parameter
Entity ID
Key Usage
Target Entity ID
Value
Calling AP-title
Abstract value “digitalSignature”
Called AP-title
d) if the Called AP-title identifies an airborne entity then get the key agreement public key
certificate path of the local system by activating the SSO-GetCertificatePath function with the
parameters in Table 7.3.1-2.
Table 7.3.1-2
SSO-GetCertificate Path function parameter
Entity ID
Key Usage
Target Entity ID
Value
Calling AP-title
Abstract value “keyAgreement”
Called AP-title
e) set the type of appendix to the abstract value “Signature-appendix”
f) get the atnSignature by activating the SSO-Sign function with the parameters in Table 7.3.1-3.
Table 7.3.1-3
SSO-Sign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “Signature-appendix”
sD-START Request User Data parameter
-6-
g) construct an ATNEstablish sDS exchange item containing the following:
1) if the Called AP-title identifies an airborne entity, the compressed certificate path
retrieved in c) in the atnCertificates fields of the ATNEstablish data item,
2) if the Called AP-title identifies an airborne entity and the compressed certificate path
retrieved in d) is not the same as c), the compressed certificate path retrieved in d) in the
atnCertificates fields of the ATNEstablish data item,
3) if the Called AP-title identifies a ground entity, the atnCertificates field of the
ATNEstablish data item is omitted,
4) the atnSignature retrieved in f) as the ATNEstablish atnSignature field.
h) construct an ATNsdsAPDU from the sD-START User Data parameter, the Calling AP-title
retrieved in b), the Called AP-title retrieved in a) and the ATNEstablish data item constructed in
g) as the new User Data parameter for the D-START Request primitive
i) invoke the ULCS or IPS D-START Request primitive..
7.3.1.3 When the sD-START Request is validly invoked with the Security Requirements parameter set to
the abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the sD-START Request Called Peer ID.
b) retrieve the Calling AP-title from the sD-START Request Peer ID.
c) use the abstract value “MAC-appendix” as the appendix type to be used by the SSO.
d) get the appendix by activating the SSO-ProtectSign function with the parameters as in Table
7.3.1-4.
Table 7.3.1-4
SSO-ProtectSign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “MAC-appendix”
sD-START Request User Data parameter
e) construct an ATNProtectSign sDS exchange item containing the appendix retrieved in d)
f) construct an ATNsdsAPDU from the sD-START User Data parameter, the Calling AP-title
retrieved in b), the Called AP-title retrieved in a) and the ATNProtectSign data item constructed
in d) as the User Data parameter for the ULCS D-START Request primitive
g) invoke the ULCS or IPS D-START Request primitive.
-7-
7.3.2
sD-START Indication primitive
7.3.2.1 When the sD-START Indication is received with the Security Requirements parameter absent or
set to the abstract value “No Security”, the sDS shall:
a) Provide the D-START indication to the DS-User.
7.3.2.2 When the sD-START Indication is received with with the Security Requirements parameter set to
the abstract value “Secured Dialogue Supporting Key Management” or “Secured Dialogue” , the sDS
shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) retrieve the User Data from the sdsAPDU element,
d) retrieve the ATNAppendix from the atnSignature element,
e) If atnCertificates is not present in the ATNEstablish element, then omit the Certificate Path
parameter for SSO-SignCheck; otherwise:
1) extract from atnCertificates the peer’s compressed signature key certificate path to use
as the Certificate Path parameter for SSO-SignCheck; and
2) extract from atnCertificates the peer’s compressed key-agreement key certificate path
to use as the Certificate Path parameter for SSO-SignCheck; and make it available to the
SSO by local means,
f) verify that the atnSignature is valid by activating the SSO-SignCheck function with the
parameters as in Table 7.3.2-1,
Table 7.3.2-1
SSO-SignCheck function parameter
Source Peer
Destination Peer
User Data
Security Item
Certificate Path
Value
Calling AP-title
Called AP-title
User-data
ATNAppendix
Value retrieved in e)
g) if the atnSignature is valid then provide the D-START indication to the DS-User.
h) if the atnSignature is not valid then invoke the sD-P-ABORT Indication primitive.
-8-
7.3.3
sD-START Response primitive
7.3.3.1 When the sD-START Response is validly invoked with the Security Requirements parameter
absent or set to the abstract value “No Security”, the sDS shall:
a) invoke the ULCS or IPS D-START Response primitive.
7.3.3.1 When the sD-START Response is validly invoked with the Security Requirements parameter set
to the abstract value “Secured Dialogue Supporting Key Management”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) if the Called AP-title identifies an airborne entity then get the signature key certificate path of
the local system by activating the SSO-GetCertificatePath function with the parameters in Table
7.3.3-1.
Table 7.3.3-1
SSO-GetCertificate Path function parameter
Entity ID
Key Usage
Target Entity ID
Value
Calling AP-title
Abstract value “digitalSignature”
Called AP-title
d) if the Called AP-title identifies an airborne entity then get the key agreement public key
certificate path of the local system by activating the SSO-GetCertificatePath function with the
parameters in Table 7.3.3-2.
Table 7.3.3-2
SSO-GetCertificate Path function parameter
Entity ID
Key Usage
Target Entity ID
Value
Calling AP-title
Abstract value “keyAgreement”
Called AP-title
e) set the type of appendix to the abstract value “Signature-appendix”
f) get the atnSignature by activating the SSO-Sign function with the parameters in Table 7.3.3-3.
Table 7.3.3-3
SSO-Sign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “Signature-appendix”
sD-START Response User Data parameter
g) construct an ATNEstablish sDS exchange item containing the following:
-9-
1) if the Called AP-title identifies an airborne entity, the compressed certificate path
retrieved in c) in the atnCertificates fields of the ATNEstablish data item,
2) if the Called AP-title identifies an airborne entity and the compressed certificate path
retrieved in d) is not the same as c), the compressed certificate path retrieved in d) in the
atnCertificates fields of the ATNEstablish data item,
3) if the Called AP-title identifies a ground entity, the atnCertificates field of the
ATNEstablish data item is omitted,
4) the atnSignature retrieved in f) as the ATNEstablish atnSignature field.
h) construct an ATNsdsAPDU from the sD-START User Data parameter, the Calling AP-title,
the Called AP-title and the ATNEstablish data item constructed in e) as the User Data parameter
for the ULCS D-START Response primitive
i) invoke the ULCS or IPS D-START Response primitive.
7.3.3.2 When the sD-START Response is validly invoked with the Security Requirements parameter set
to the abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) set the type of appendix to the abstract value “MAC-appendix”.
d) get the appendix by activating the SSO-ProtectSign function with the parameters as in Table
7.3.3-4.
Table 7.3.3-4
SSO-ProtectSign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “MAC-appendix”
sD-START Response User Data parameter
e) construct an ATNProtectSign sDS exchange item containing the appendix retrieved in d)
f) construct an ATNsdsAPDU from the sD-START User Data parameter, the Calling AP-title, the
Called AP-title and the ATNProtectSign data item as the User Data parameter for the ULCS DSTART Response primitive
g) invoke the ULCS or IPS D-START Response primitive..
- 10 7.3.4
sD-START Confirmation primitive
7.3.4.1 When the sD-START Confirmation is received with the Security Requirements parameter absent
or set to the abstract value “No Security”, the sDS shall:
a) Provide the D-START Confirmation to the DS-User.
7.3.4.2 When the sD-START Confirmation is received with with the Security Requirements parameter
absent or set to the abstract value “Secured Dialogue Supporting Key Management” or “Secured
Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) retrieve the User Data from the sdsAPDU element,
d) retrieve the ATNAppendix from the atnSignature element,
e) extract from atnCertificates the peer’s compressed key-agreement key certificate path,
f) verify that the atnSignature is valid by activating the SSO-SignCheck function with the
parameters as in Table 7.3.4-1,
Table 7.3.4-1
SSO-SignCheck function parameter
Source Peer
Destination Peer
User Data
Security Item
Certificate Path
Value
Calling AP-title
Called AP-title
User-data retrieved
ATNAppendix
Value extracted from atnCertificates
g) if the atnSignature is valid then provide the D-START Confirmation to the DS-User
h) if the atnSignature is not valid then invoke the sD-P-ABORT Indication primitive.
7.3.5
sD-DATA Request primitive
7.3.5.1 When the sD-DATA Request is validly invoked on a dialogue which does not support security,
the sDS shall:
a) invoke the ULCS or IPS D-DATA Request primitive.
7.3.5.2 When the sD-DATA Request is validly invoked with with the Security Requirements parameter
set to the abstract value “Secured Dialogue”, the sDS shall:
- 11 -
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) set the type of appendix to the abstract value “MAC-appendix”.
d) get the appendix by activating the SSO-ProtectSign function with the parameters as in Table
7.3.5-1.
Table 7.3.5-1
SSO-ProtectSign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “MAC-appendix”
sD-DATA Request User Data parameter
e) construct an ATNProtectSign sDS exchange item containing the appendix retrieved in d)
f) construct an ATNsdsAPDU from the sD-DATA Request User Data parameter, the Calling APtitle, the Called AP-title and the ATNProtectSign data item constructed in e) as the User Data
parameter for the ULCS or IPS D-DATA Request primitive
g) invoke the ULCS or IPS D-DATA Request primitive.
7.3.6
sD-DATA Indication primitive
7.3.6.1 When the sD-DATA Indication is received with the Security Requirements parameter absent or
set to the abstract value “No Security”, the sDS shall:
a) Provide the D-START indication to the DS-User
7.3.6.2 When the sD-START Indication is received with with the Security Requirements parameter set to
the abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) retrieve the User Data from the sdsAPDU element and set as the D-DATA Indication User
Data parameter
d) retrieve the ATNProtectSign from the sdsProtectSign element,
h) verify that the ATNProtectSign is valid by activating the SSO-ProtectSignCheck function with
the parameters as in Table 7.3.6-1,
- 12 Table 7.3.6-1
SSO-ProtectSignCheck function parameter
Source Peer
Destination Peer
Security Item
Value
Calling AP-title
Called AP-title
ATNProtectSign
i) if the ATNProtectSign is valid then provide the D-DATA indication to the DS-User.
j) if the ATNProtectSign is not valid then invoke the sD-P-ABORT Indication primitive.
7.3.7
sD-END Request primitive
7.3.7.1 When the sD-END Request is validly invoked with the Security Requirements parameter absent or
set to the abstract value “No Security”, the sDS shall:
a) invoke the ULCS or IPS D-END Request primitive.
7.3.7.2 When the sD-END Request is validly invoked with the Security Requirements parameter set to the
abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) set the type of appendix to the abstract value “MAC-appendix”.
d) get the appendix by activating the SSO-ProtectSign function with the parameters as in Table
7.3.7-1.
Table 7.3.7-1
SSO-ProtectSign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “MAC-appendix”
sD-DATA Request User Data parameter
e) construct an ATNProtectSign sDS exchange item containing the appendix retrieved in d)
f) construct an ATNsdsAPDU from the sD-DATA Request User Data parameter, the Calling APtitle, the Called AP-title and the ATNProtectSign data item constructed in e) as the User Data
parameter for the ULCS or IPS D-DATA Request primitive
g) invoke the ULCS or IPS D-DATA Request primitive.
- 13 -
7.3.8
sD-END Indication primitive
7.3.8.1 When the sD-END Indication is received with the Security Requirements parameter absent or set
to the abstract value “No Security”, the sDS shall:
a) Provide the D-END indication to the DS-User.
7.3.8.2 When the sD-END Indication is received with with the Security Requirements parameter set to the
abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) retrieve the User Data from the sdsAPDU element and set as the D-DATA Indication User
Data parameter
d) retrieve the ATNProtectSign from the sdsProtectSign element,
h) verify that the ATNProtectSign is valid by activating the SSO-ProtectSignCheck function with
the parameters as in Table 7.3.8-1,
Table 7.3.8-1
SSO-ProtectSignCheck function parameter
Source Peer
Destination Peer
Security Item
Value
Calling AP-title
Called AP-title
ATNProtectSign
i) if the ATNProtectSign is valid then provide the D-DATA indication to the DS-User.
j) if the ATNProtectSign is not valid then invoke the sD-P-ABORT Indication primitive.
- 14 7.3.9
sD-END Response primitive
7.3.9.1 When the sD-END Response is validly invoked with the Security Requirements parameter absent
or set to the abstract value “No Security”, the sDS shall:
a) invoke the ULCS or IPS D-END Request primitive.
7.3.9.2 When the sD-END Response is validly invoked with the Security Requirements parameter set to
the abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
c) set the type of appendix to the abstract value “MAC-appendix”.
d) get the appendix by activating the SSO-ProtectSign function with the parameters as in Table
7.3.9-1.
Table 7.3.9-1
SSO-ProtectSign function parameter
Source Peer
Destination Peer
Appendix Type
User Data
Value
Calling AP-title
Called AP-title
Abstract value “MAC-appendix”
sD-DATA Request User Data parameter
e) construct an ATNProtectSign sDS exchange item containing the appendix retrieved in d)
f) construct an ATNsdsAPDU from the sD-DATA Request User Data parameter, the Calling APtitle, the Called AP-title and the ATNProtectSign data item constructed in e) as the User Data
parameter for the ULCS or IPS D-DATA Response primitive
g) invoke the ULCS or IPS D-DATA Response primitive.
7.3.10
sD-END Confirmation primitive
7.3.10.1 When the sD-END Confirmation is received with the Security Requirements parameter absent or
set to the abstract value “No Security”, the sDS shall:
a) Provide the D-END confirmation to the DS-User.
7.3.10.2 When the sD-END Confirmation is received with with the Security Requirements parameter set
to the abstract value “Secured Dialogue”, the sDS shall:
a) retrieve the Called AP-title from the calledPeerID element,
b) retrieve the Calling AP-title from the callingPeerID element,
- 15 -
c) retrieve the User Data from the sdsAPDU element and set as the D-DATA Indication User
Data parameter
d) retrieve the ATNProtectSign from the sdsProtectSign element,
h) verify that the ATNProtectSign is valid by activating the SSO-ProtectSignCheck function with
the parameters as in Table 7.3.10-1,
Table 7.3.10-1
SSO-ProtectSignCheck function parameter
Source Peer
Destination Peer
Security Item
Value
Calling AP-title
Called AP-title
ATNProtectSign
i) if the ATNProtectSign is valid then provide the D-DATA Confirmation to the DS-User.
j) if the ATNProtectSign is not valid then invoke the sD-P-ABORT Indication primitive.
7.3.11
sD-ABORT Request primitive
7.3.11.1 When the sD-ABORT Request is validly invoked invoked with the Security Requirements
parameter absent or set to the abstract value “No Security”, the sDS shall:
a) invoke the ULCS or IPS D-ABORT Request primitive.
7.3.11.2 When the sD-ABORT Request is validly invoked with the Security Requirements parameter set
to the abstract value “Secured Dialogue”, the sDS shall: the sDS shall:
a) construct an ATNsdsAPDU from the sD-ABORT User Data parameter as the User Data
parameter for the ULCS or IPS D-ABORT Request primitive
b) invoke the ULCS or IPS D-ABORT Request primitive.
7.3.12
sD-ABORT Indication primitive
7.3.12.1 When the sD-ABORT Indication is received, the sDS shall:
a) Provide the D-ABORT indication to the DS-User
- 16 -
7.3.13
sD-P-ABORT Indication primitive
7.3.13.1 When the sDS determines that an abnormal release of the dialogue is needed, the sDS shall:
a) provide the D-ABORT indication to the DS-User.
- 17 -
8
ATN SECURITY ASN.1 MODULE
This chapter contains a description of the information unique to ATN certificates, information internally
used by the SSO, and information exchanged by the sDS Entity.
The abstract syntax used by the SSO and the ATN PKI shall comply with the description contained in the
ASN.1 modules ATN-PKI and ATN-PKI-EXPLICIT (conforming to ITU-T Rec X.680), as defined here.
ATN-PKI { iso(1) identified-organization(3) icao(27)
atn-security-requirements(5) modules(1) atnPKI(3) }
DEFINITIONS AUTOMATIC TAGS ::= BEGIN
-- EXPORTS ALL -IMPORTS
AlgorithmIdentifier, Certificate, CertificateSerialNumber FROM
AuthenticationFramework { joint-iso-ccitt ds(5) module(1)
authenticationFramework(7) 3 }
KeyUsage FROM
CertificateExtensions { joint-iso-ccitt ds(5) module(1)
certificateExtensions(26) 0 }
--- Compressed Certificates
-ATNCertificates ::= SEQUENCE
{
compressedUserCertificate
CompressedUserCertificate,
certificatePath
ForwardCertificatePath OPTIONAL
}
CompressedUserCertificate ::= SEQUENCE
{
serialNumber
CertificateSerialNumber,
algorithmIdentifier AlgorithmIdentifier OPTIONAL,
validity ATNValidity,
subjectPublicKey BIT STRING,
subjectAltName ATNPeerId,
issuerAltName
ATNPeerId,
keyUsage KeyUsage,
encrypted BIT STRING,
...
- 18 }
ForwardCertificatePath ::= SEQUENCE OF CACertificates
CACertificates ::= SEQUENCE OF CompressedUserCertificate
--- Entity Identifications
-ATNPeerId ::= CHOICE
{
atn-ats-es-id ATN-es-id,
-- required for ATS app entities
atn-is-id ATN-is-id,
-- required for all intermediate systems
atn-ca-id ATN-ca-id,
-- required for all ATN CAs
atn-other-id ATN-other-id,
-- available for any non-ATS use
-- AOC can put PSAPs here
...
}
-- ATN ATS End Systems are defined by their AP-title as defined in Part IV-C
-ATN-es-id ::= CHOICE
{
rel-air-ap-title RELATIVE-OID,
-- relative to { iso(1) identified-organization(3)
-- icao(27) atn-end-system-air(1) }
rel-ground-ap-title RELATIVE-OID
-- relative to { iso(1) identified-organization(3)
-- icao(27) atn-end-system-ground(2) }
}
-- ATN Intermediate Systems are identified by their Network Entity
-- Title, a 20-octet address. The first 3 octets of this address are
-- fixed to decimal 470027. The RDF is the 8th octet of the NET and
-- is fixed to the value 0. The type below takes advantage of these
-- facts and uses only 16 octets rather than the full 20.
ATN-is-id ::= OCTET STRING (SIZE (16))
ATN-ca-id ::= RELATIVE-OID
-- relative to { iso(1) identified-organization(3) icao(27)
-- atn-ca(6) }
-- Note: this is one OID sub-identifier
ATN-other-id ::= OCTET STRING
- 19 -
--- Supporting Types
-ATNValidity ::= SEQUENCE
{
notBefore ATNSecurityDateTime,
notAfter
ATNSecurityDateTime
}
ATNSecurityDateTime ::= SEQUENCE
{
date
ATNSecurityDate,
time
ATNSecurityTime
}
ATNSecurityDate ::= SEQUENCE
{
year
Year,
month
Month,
day
Day
}
Day ::= INTEGER (1..31)
-- unit = Day, Range (1..31), resolution = 1
Month ::= INTEGER (1..12)
-- unit = Month, Range (1..12), resolution = 1
ATNSecurityTime ::= SEQUENCE
{
hours
Timehours,
minutes
Timeminutes,
seconds
Timeseconds
}
Timehours ::= INTEGER (0..23)
-- units = hour, range (0..23), resolution = 1
Timeminutes ::= INTEGER (0..59)
-- units = minutes, range (0..59, resolution = 1
Timeseconds ::= INTEGER (0..59)
-- units = seconds, range (0..59), resolution = 1
Year ::= INTEGER (1996..2095)
-- unit = Year, Range (1996..2095), resolution = 1
NET ::= OCTET STRING (SIZE (20))
- 20 -
--- SSO Data Types
-MacData ::= SEQUENCE
{
sourcePeerId
ATNPeerId,
destPeerId
ATNPeerId,
counter
INTEGER (0..MAX),
userData
OCTET STRING OPTIONAL,
random
INTEGER (0..4294967295) OPTIONAL,
-- 32-bit unsigned integer
atnSignature
ATNAppendix OPTIONAL
}
SignData ::= SEQUENCE
{
sourcePeerId
ATNPeerId,
destPeerId
ATNPeerId,
timeField
ATNSecurityDateTime,
userData
OCTET STRING OPTIONAL
}
- 21 -
--- sDS Data Types
--
ATNsdsAPDU ::=SEQUENCE {
sdsAPDU
User-data,
callingPeerId
ATNPeerId,
calledPeerId
ATNPeerId,
sdsExchangeData
CHOICE {
sdsEstablish
ATNEstablish,
sdsProtectSign ATNProtectSign,
... }
... }
ATNEstablish ::= SEQUENCE {
atnCertificates SEQUENCE OF ATNCertificates OPTIONAL,
atnSignature ATNAppendix,
... }
ATNProtectSign ::= SEQUENCE {
unprotected
OCTET STRING OPTIONAL,
appendix
ATNAppendix,
... }
ATNAppendix ::= SEQUENCE {
algorithmId
AlgorithmIdentifier OPTIONAL,
validity
CHOICE {
timeField
ATNSecurityDateTime ,
random
INTEGER (0..4294967295),
-- 32-bit unsigned integer
counter
INTEGER (0..MAX),
-- unsigned, unconstrained integer
... } OPTIONAL,
value
CHOICE {
ecdsa-Signature
ECDSA-Sig-Value,
hmac-Tag
OCTET STRING (SIZE (4, ...)),
... }
}
END -- ATN-PKI --
--- ASN.1 module containing supporting ASN.1 types that require the use of an
-- explicit tagging environment. Most of these definitions are reproduced
-- from supporting standards (e.g., ANSI-X9-62 and SEC2).
--
- 22 -
ATN-PKI-Explicit { iso(1) identified-organization(3) icao(27)
atn-security-requirements(5) modules(1) atnPKI-explicit(4) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS ALL --- IMPORTS Nothing ---- From ANSI X9.62
---- The ECDSA-Sig-Value type is used for all ATN Signature values.
-ECDSA-Sig-Value ::= SEQUENCE
{
r INTEGER,
s INTEGER
}
--- The EcpkParameters type is used in the subjectPublicKeyInfo field of ATN
-- Certificates. See 4.3.1.3.6.
-EcpkParameters ::= CHOICE {
ecParameters
[0] NULL, -- Not used in ATN, tag and type changed
namedCurve
CURVES.&id ({CurveNames}),
implicitCA
NULL -- Not used in ATN
}
--- The ECPoint type is used for all ATN public keys. See 4.3.1.3.6.3.
-ECPoint ::= OCTET STRING
--- The OID ecdsa-with-SHA256 is used to identify the signature algorithm used
-- by the ATN Signature Primitive. See 4.3.1.2.1
-ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 1 2 840 10045 3 2}
--- The OID id-ecPublicKey is used in the subjectPublicKeyInfo field of ATN
-- Certificates. See 4.3.1.3.7
-id-ecPublicKey OBJECT IDENTIFIER ::= { 1 2 840 10045 2 1 }
--
- 23 -
-- The CURVES type is an Information Object Class that is used to constrain
-- the set of valid elliptic curves. This Information Object Class is used
-- below in the CurveNames Information Object Set to identify the elliptic
-- curves that are used for the ATN.
-CURVES ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE
}
WITH SYNTAX { ID &id }
--- End From ANSI X9.62
---- From SEC2
----- The OID sect233r1 implicitly identifies the ATN
-- elliptic curve domain parameters. See 4.3.1.3.6.2.2.
-sect233r1 OBJECT IDENTIFIER ::= { 1 3 132 0 27 }
--- End From SEC2
--
--- CurveNames is the table (Information Object Set) of valid ATN curves.
-- This Information Object Set replaces the CurveNames table in ANSI X9.62
-- for the ATN.
-CurveNames CURVES ::= {
{ ID sect233r1 },
...
}
END -- ATN-PKI-Explicit –
-- END --