ISO/IEC ISP 10611-1:1994

I N T E R NAT I O NA L
ISO/IEC
STAN DAR DI Z E D
ISP
PROFILE
10611-1
First edition
1994-1 0-1 5
Information technology - International
Standardized Profiles AMHl n - Message
Handling Systems - Common
Messaging -
Part 1:
MHS Service Support
Technologies de l’information - Profils normalisés internationaux
AMHIn - Systèmes de messagerie - Messagerie commune -
Partie I: Support de service MHS
Reference number
ISOllEC ISP 1061 1-1 : 1994 (E)
Contents
Page
Foreword . . iii
Introduction. .
1 Scope . 1
................................... ...................................
2 Normative references . . 1
3 Definitions . . 2
4 Abbreviations . 4
5 Conformance . 4
6 Basic requirements . . 5
7 Functional groups . 5
8 Naming and addressing . 14
Error and exception handling . 15
Annexes
Elements of Service . 17
A
B Amendments and corrigenda . 24
C Secure messaging - rationale and implementation considerations . 25
D Additional recommended practices for 1984 interworking . .33
E AMHI - overall scope and applicability . 35
O ISOllEC 1994
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronic or mechanical, including
photocopying and microfilm, without permission in writing from the publisher.
ISOllEC Copyright Office Case Postale 56 CH-I21 1 Genève 20 0 Switzerland
Printed in Switzerland
ii
ISOllEC ISP 1061 1-1 : 1994 (E)
O ISOAEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system
for worldwide standardization. National bodies that are members of IS0
or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal
with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with IS0
and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a
joint technical committee, ISO/IEC JTC 1. In addition to developing
International Standards, ISOAEC JTC 1 has created a Special Group on
Functional Standardization for the elaboration of International
Standardized Profiles.
An International Standardized Profile is an internationally agreed,
harmonized document which identifies a standard or group of standards,
together with options and parameters, necessary to accomplish a function
or set of functions.
Draft International Standardized Profiles are circulated to national bodies
for voting. Publication as an International Standardized Profile requires
approval by at least 75% of the national bodies casting a vote.
International Standardized Profile ISOllEC ISP 1061 1-1 was prepared
with the collaboration of:
- OS1 Asia-Oceania Workshop (AOW);
- European Workshop for Open Systems (EWOS) ljointly with the
European Telecommunications Standards Institute (ETSI)];
- OSE Implementors’ Workshop (OW)
ISOAEC ISP 1061 1 consists of the following parts, under the general title
Information technology - International Standardized Profiles AMHln -
Message Handling Systems - Common Messaging:
- Part I : MHS Service Support
- Part 2 : Specification of ROSE, RTSE, ACSE, Presentation and
Session Protocols for use by MHS
- Part 3 : AMHI I - Message Transfer (PI)
- Part 4 : AMH12 - MTS Access (P3)
- Part 5 : AMHl3 - MS Access (P7)
Annexes A and B form an integral part of this part of ISO/IEC ISP 10611.
Annexes C, D and E are for information only.
iii
ISO/IEC ISP 19611-1 : 1994 (E) O ISOAEC
Introduction
This part of International Standardized Profile ISOAEC ISP 10611 is
defined within the context of Functional Standardization, in accordance
with the principles specified by ISO/IEC TR 10000, “Framework and
Taxonomy of International Standardized Profiles”. The context of
Functional Standardization is one part of the overall field of Information
Technology (IT) standardization activities, covering base standards,
profiles, and registration mechanisms. A profile defines a combination of
base standards that collectively perform a specific well-defined IT
function. Profiles standardize the use of options and other variations in the
base standards, and provide a basis for the development of uniform,
internationally recognized system tests.
One of the most important rôles for an ISP is to serve as the basis for the
development (by organizations other than IS0 and IEC) of internationally
recognized tests and test centres. ISPs are produced not simply to
‘legitimize’ a particular choice of base standards and options, but to
promote real system interoperability. The development and widespread
acceptance of tests based on this and other ISPs is crucial to the
successful realization of this goal.
The text for this part of ISOAEC ISP 10611 was developed in close
cooperation between the MHS Expert Groups of the three Regional
Workshops: the North American OSE Implementors’ Workshop (OIW),
the European Workshop for Open Systems (EWOS) (jointly with the
corresponding expert group of the European Telecommunications
- ETSI) and the OS1 Asia-Oceania Workshop (AOW).
Standards Institute
This part of ISOllEC ISP 10611 is harmonized between these three
Workshops and it has been ratified by the plenary assemblies of all three
Workshops.
iv
I
INTERNATIONAL STANDARDIZED PROFILE lS0’lEC ISO/IEC ISP 1061 1-1 : 1994 (E)
Information technology - International Standardized
Profiles AMHI n - Message Handling Systems - Common
Messaging
Part 1 : MHS Service Support
I
1 Scope
1.
1.1 General
This part of ISOAEC ISP 1061 1 contains the overall specifications of the support of MHS Elements of Service
and associated MHS functionality which are generally not appropriate for consideration only from the perspective
I
of a single MHS protocol. These specifications form part of the Common Messaging application functions, as
\
defined in the parts of ISOAEC ISP 1061 1, which form a common basis for content type-dependent International
Standardized Profiles for MHS that will be developed. Such specifications are in many cases applicable to more
than one MHS protocol or are otherwise concerned with component functionality which, although it can be
verified via protocol, is not just related to protocol support. They are therefore designed to be referenced in the
MHS Common Messaging application profiles ISO/IEC ISP 1061 1-3 (AMHI I), ISOAEC ISP 1061 1-4 (AMH12)
and ISOAEC ISP 10611-5 (AMH13), which specify the support of specific MHS protocols and associated
I functionality.
The specifications in this part of ISOAEC ISP 1061 1 cover the provision and use of features associated with the
Message Transfer (MT) Service (MTS) (as defined in clause 8 of ISOAEC 10021-I), together with those features
associated with intercommunication with Physical Delivery (PD) Services (as defined in clause 10 of ISOllEC
10021-1). Features which are associated with the Message Store (MS) and User Agent (UA) which are content
type-independent are also covered. Features which are specific to a particular content type (including the
provision of services by a UA to an MHS user) are covered in separate content type-dependent ISPs.
The specifications in this part of ISOAEC ISP 1061 1 are divided into basic requirements, which are required to
be supported by all MHS implementations, and a number of optional functional groups, which cover significant
discrete areas of related functionality which are not required to be supported by all implementations.
An overview of the scope and applicability of the AMHln set of profiles and of the structure of this multipart ISP
is provided in annex E.
1.2 Position within the taxonomy
This part of ISOAEC ISP 10611 is the first part, as common text, of a multipart ISP identified in ISO/IEC TR
10000-2 as “AMHI, Message Handling Systems - Common Messaging” (see also ISOAEC TR 10000-1, 8.2 for
the definition of multipart ISPs).
This part of ISO/IEC ISP 1061 1 does not, on its own, specify any profiles.
2 Normative references
The following documents contain provisions which, through reference in this text, constitute provisions of this
part of ISOAEC ISP 10611. At the time of publication, the editions indicated were valid. All documents are
subject to revision, and parties to agreements based on this part of ISOAEC ISP 10611 are warned against
automatically applying any more recent editions of the documents listed below, since the nature of references
ISPs to such documents is that they may be specific to a particular edition. Members of IEC and IS0
made by
ISOAEC ISP 1061 1-1 : 1994 (E)
maintain registers of currently valid International Standards and ISPs, and the Telecommunications
Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations.
Amendments and corrigenda to the base standards referenced are listed in annex B.
NOTE - References in the body of this part of ISO/IEC ISP 10611 to specific clauses of ISOllEC documents shall be
considered to refer also to the corresponding clauses of the equivalent ITU-T Recommendations (as noted below) unless
otherwise stated.
IS0 7498-2: 1989, Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2:
Security Architecture.
ISO/IEC 9594-8: 1990, Information technology - The Directory - Part 8: Authentication framework. [see also CCITT
Recommendation X. 509(1988)]
ISOiIEC TR 10000-1 : 1992, Information technology - Framework and taxonomy of International Standardized Profiles -
Part I: Framework.
ISOAEC TR 10000-2: 1992, Information technology - Framework and taxonomy of International Standardized Profiles -
Part 2: Taxonomy. O
ISOiIEC 10021 -1 : 1990, Information technology - Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) - Part 1: Service Overview. [see also CClTT Recommendation X.400(1992)]
ISOiIEC 10021 -2: 1 990, Information technology - Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) - Part 2: Overall Architecture. [see also CClTT Recommendation X.402(1992)]
ISOilEC 10021-4: 1990, Information technology - Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) - Part 4: Message Transfer System: Abstract Service Definition and Procedures. [see also CC177
Recommendation X.411(1992)]
ISO/IEC 10021-5: 1990, Information technology - Text Communication - Message-Oriented Text lnterchange Systems
- Part 5: Message Store: Abstract Service Definition. [see also CCITT Recommendation X.413(1992)]
(MOTIS)
CCITT Recommendation X.400(1992), Message handling system and service overview.
CClTT Recommendation X.402(1992), Message handling systems: Overall architecture.
CClTT Recommendation X.41 1(1992), Message handling systems: Message transfer system: Abstract service definition
and procedures.
CClTT Recommendation X.413(1992), Message handling systems: Message store: Abstract service definition.
CCITT Recommendation X.509(1988), The Directory - Authentication framework.
3 Definitions
For the purposes of this part of ISO/IEC ISP 1061 1, the following definitions apply.
Terms used in this part of ISO/IEC ISP 10611 are defined in the referenced base standards; in addition, the
following terms are defined.
3.1 General
Basic requirement : an Element of Service, protocol element, procedural element or other identifiable feature
specified in the base standards which is required to be supported by all MHS implementations.
ISOllEC ISP 10611-1 1994 (E)
Functional group : a specification of one or more related Elements of Service, protocol elements, procedural
elements or other identifiable features specified in the base standards which together support a significant
optional area of MHS functionality.
NOTE - A functional group can cover any combination of MHS features specified in the base standards for which the effect
of implementation can be determined at a standardized external interface - i.e. via a standard OS1 communications protocol
(other forms of exposed interface, such as a standardized programmatic interface, are outside the scope of this version of
ISOAEC ISP 1061 1).
3.2 Support classification
To specify the support level of Elements of Service for this part of ISOlIEC ISP 1061 1, the following terminology
is defined.
mandatory support (m) :
for origination: a service provider shall be able to make the Element of Service available to a
service user in the rôle of originator; a service user shall be able to use the Element of Service in
the rôle of originator;
a
for processing: a service provider shall implement all procedures specified in the base standards
which are associated with the provision of the Element of Service (i.e. to be able to provide the full
effect of the Element of Service);
I
for reception: a service provider shall be able to make the Element of Service available to a
t
service user in the rôle of recipient; a service user shall be able to use the Element of Service in the
1 rôle of recipient.
I
optional support (O) : an implementation is not required to support the Element of Service. If support is claimed,
I
then the Element of Service shall be treated as if it were specified as mandatory support.
I
l
conditional support (c) : the Element of Service shall be supported under the conditions specified in this part of
ISOAEC ISP 1061 1. If these conditions are met, the Element of Service shall be treated as if it were specified as
mandatory support. If these conditions are not met, the Element of Service shall be treated as if it were specified
as optional support (unless otherwise stated).
out of scope (i) : the Element of Service is outside the scope of this part of ISOllEC ISP 1061 1 - i.e. it will not be
the subject of an ISP conformance test. However, the handling of associated protocol elements may be specified
separately in the subsequent parts of this ISP.
not applicable (-) : the Element of Service is not applicable in the particular context in which this classification is
used.
3.3 Profile object identifiers
Profiles that are specified in ISOllEC ISP 1061 1 are identified by the object identifiers in table 1.
NOTE - These object identifiers are included for formal purposes and any use of them is not defined. They are not related
to any implementation of messaging and do not appear in the protocols specified in this ISP.
Table 1 - Profile obiect identifiers
I Profile I Object Identifier
I
{ iso( 1) standard(0) common-messaging( 1061 1) message-transfer(3) normal-mode( 1) }
AMHI 11
AMHl12 { iso( 1 ) standard(0) common-messaging( 1061 1) message-transfer(3) x41 O-mode(2) }
AMH12 { iso( 1) standard(0) common-messaging( 1061 1) mts-access(4) }
AMH13 { iso(1) standard(0) common-messaging(lO611) ms-access(5) }
ISOllEC ISP 10611-1 1994 (E) O ISO/IEC
4 Abbreviations
841W 84 Intenworking
AMH Application Message Handling
ASN.l Abstract Syntax Notation One
COMPUSEC Computer security
COMSEC Communications security
cv Conversion
DIR Use of Directory
DL Distribution List
DSA Directory system agent
DUA Directory user agent
of Service
EoS Element
FG Functional group
ISP International Standardized Profile
LD Latest Delivery
MHS Message Handling Systems
MLS Multi-Level Security
MS Message store
MT Message transfer
MTA Message transfer agent
MTS Message Transfer System
OS1 Open Systems Interconnection
PD Physical Delivery
PDAU Physical delivery access unit
RED Redirection
ROC Return of Content
SEC Security
UA User agent
Support level for Elements of Service (see 3.2):
m mandatory support
O optional support
C conditional support
i out of scope
- not applicable
5 Conformance
'IEC ISP 1061 1.
No conformance requirements are specified in this part of IS
NOTE - This part of ISOAEC ISP 10611 is a reference specification of the basic requirements and functional groups
covered by the AMHIn set of profiles and is additional to the protocol-specific requirements specified in the following parts
of ISO/IEC ISP 10611. Although this part of ISOAEC ISP 10611 contains normative requirements, there is no separate
conformance to this pari (i.e. it is not identified in the MHS taxonomy in ISOAEC TR 10000-2) since such requirements are
only significant when referenced in the context of a particular protocol.
Conformance requirements are specified by protocol for each MHS functional object in the following parts of
ISO/IEC ISP 1061 1 with reference to the specifications in this part. Support of functionality as specified in this
part may only be verifiable where the effect of implementation can be determined at a standardized external
interface - i.e. via a standard OS1 communications protocol. Further, the provision of Elements of Service and
other functionality at a service interface will not necessarily be verifiable unless such interface is realized in the
form of a standard OS1 communications protocol. Other forms of exposed interface (such as a human user
interface or a standardized programmatic interface) may be provided, but are not required for conformance to
this version of ISOAEC ISP 1061 1,
O ISOllEC ISOllEC ISP 1061 1-1 : 1994 (E)
6 Basic requirements
Annex A specifies the basic requirements for support of MHS Elements of Service (EoS) for conformance to
1061 1. Basic requirements specify the level of support required by all MHS implementations, as
ISOAEC ISP
to each type of MHS functional object - i.e. MTA, MS or UA (as MTS-user or MS-user, as relevant).
appropriate
NOTE - ISOAEC ISP 10611 is confined to the provision of services by MTAs and MSs, and the use of such services by
MTS-users and MS-users. It does not cover the provision of such services by UAs to MHS users, which is specified in
content type-specific profiles.
Content and encoded information types
6.1
It shall be stated in the PICS which content type and encoded information type values are supported.
6.2 Message length
If the implementation imposes any constraints on the size of the message content or envelope, then all such
constraints shall be stated in the PICS.
NOTE - Implementors are advised to avoid constraining the size of messages as far as possible. For example, any
constraint which prevents the transfer of a 2 Megaoctet message could cause problems when interworking with 1984
systems. Requirements will vary according to application and environment and could be much higher than 2 Megaoctets.
6.3 Number of recipients
It shall be stated in the PICS if there is any limit on the number of recipients that can be specified in a message
envelope.
7 Functional groups
Annex A also specifies any additional requirements for support of MHS EoS if support of an optional functional
group (FG) is claimed, as appropriate to each type of MHS functional object. The following subclauses
summarize the functionality supported by each of the optional FGs and identify any particular requirements or
implementation considerations which are outside the scope of formal conformance to ISO/IEC ISP 10611. A
summary of the functional groups, identifying which may be supported (Y) and which are not applicable (N) for
each type of MHS functional object (i.e. MTA, MS or UA - whether as MTS-user or as MS-user is not
distinguished), is given in table 2.
ISO/IEC ISP 10611-1 : 1994 (E)
Functional Group MTA MS UA
Use of Directory (DIR) Y N Y
84 lnterworking (841W) Y N NI
NOTES
I UA functionality may be further defined in content type-dependent profiles.
The conformance requirements for support of the various functional groups, covering support of additional
protocol elements and/or procedures, are specified in parts 3, 4 and 5 of this ISP, according to the protocol(s) to
which each functional group relates.
7.1 Conversion (CV)
The Conversion FG covers support of those EoS which provide the functionality required to perform the action of
encoded information type conversion. Support of the CV FG is only applicable to an MTA.
NOTE 1 - Support of EoS associated with conversion prohibition is a basic requirement, but this does !ml imply a capability
to perform conversion.
Either or both of Explicit Conversion and Implicit Conversion shall be supported. A conforming implementation
shall obey the rules specified in subclauses 14.3.5 and 14.3.9 of ISO/IEC 10021-4.
Conformance to ISO/IEC ISP 1061 1 does not require the capability to perform any specific conversions. Further
specific requirements may be included in content type-dependent International Standardized Profiles for MHS
that will be developed or may otherwise be separately specified. It shall be stated in the PICS which encoded
information type conversions the implementation can perform, for the type(s) of conversion (i.e. explicit or
implicit) for which support is claimed. The PICS shall also state the conditions under which loss of information is
determined (if at all) for each encoded information type conversion for which support is claimed.
NOTE 2 - It may not be possible to verify support of conversion in the absence of additional specification which is related to
one or more identified content types.
7.2 Distribution List (DL)
The Distribution List FG covers all issues relating to the performance of distribution list (DL) expansion. Support
of the [IL FG is only applicable to an MTA.
NOTE - Other aspects concerned with the use of DLs (e.g. the ability to submit a message specifying a recipient which is a
DL) are basic requirements. Similarly, it is a basic requirement that an MTA must be able to receive and handle correctly a
message that reflects prior DL expansion.
A conforming implementation shall obey the rules specified in subclause 14.3.10 of ISO/IEC 10021-4.
Conformance to ISO/IEC ISP 1061 1 does not require any DL management capability other than as specified in
subclaiise 14.3.1 O of ISO/IEC 10021 -4. Any further specification will be implementation-dependent.
7.3 Physical Delivery (PD)
The Physical Delivery FG is concerned with access to physical delivery (i.e. postal, courier, etc) services. The
PD FG comprises two separate and distinct parts:
a
support of PD EoS on submission;
O
support of a co-located physical delivery access unit (PDAU).
I
ISOllEC ISP 10611-1 : 1994 (E)
O ISO/IEC
Support of PD EoS on submission is applicable to an MTA or a UA. Support of a PDAU is only applicable to an
MTA. If an MTA supports a PDAU and also supports message submission, then it shall also support PD EoS on
submission.
I
Support of the PD FG also requires support of corresponding O/R address extension attributes.
I
If the PDAU generates any error on export, then the MTA shall generate a non-delivery report or take other
appropriate action (e.g. alternate recipient processing). All other processing concerned with the actual physical
rendition and delivery of the message is outside the scope of ISO/IEC ISP 1061 1.
I
7.4 Redirection (RED)
The Redirection FG covers support of those EoS which provide the functionality required to perform the actions
of a message to a recipient other than the one initially specified by the originator.
associated with the delivery
Support of the RED FG is only applicable to an MTA.
NOTE - Support of EoS associated with the prevention of redirection is a basic requirement, but this does not imply a
capability to perform redirection. Similarly, support of the Alternate Recipient Allowed EoS is a basic requirement, but this
does not imply a capability to perform alternate recipient assignment.
A conforming implementation shall obey the rules specified in subclause 14.3 of ISO/IEC 10021-4.
The means by which the Alternate Recipient Assignment EoS is achieved is outside the scope of ISO/IEC ISP
10611.
7.5 Latest Delivery (LD)
The Latest Delivery FG covers support of the Latest Delivery EoS - i.e. the functionality required to cause non-
delivery to occur if a latest delivery time specified by the originator has expired. Support of the LD FG is
applicable to an MTA or a UA. If an MTA supports the LD FG and also supports message submission, then it
shall also support the Latest Delivery EoS on submission.
NOTE - Latest delivery designation is assured only if it is supported by at least the delivering MTA.
7.6 Return of Content (ROC)
The Return of Content FG covers support of the Return of Content EoS - i.e. the functionality required to cause
the contents of a submitted message to be returned in any non-delivery notification if SO requested by the
originator. Support of the ROC FG is applicable to an MTA, an MS or a UA. If an MTA supports the ROC FG and
also supports message submission, then it shall also support the Return of Content EoS on submission.
NOTE - Return of content is assured only if it is supported by all MTAs through which the message might pass.
7.7 Security (SEC)
7.7.1 Overview
The Security FG covers the provision of secure messaging and is specified as three security classes which are
incremental subsets of the security features available in the MHS base standards:
This security class only requires security functions which are applicable between MTS-users.
so
Consequently security mechanisms are implemented within the MTS-user. An MTA is only required
to support the syntax of the security services on submission and delivery (support of the syntax on
relaying is a basic requirement). An MTA is not expected to understand the semantics of the
security services.
This security class requires security functionality within both the MTS-user and the MTS. The MTS
SI
security functionality is only required to achieve secure access management. As with SO, most of
the security mechanisms are implemented within an MTS user. SI primarily provides integrity and
O ISOIIEC
ISO/IEC ISP 10611-1 : 1994 (E)
authentication between MTS users. However, MTAs are expected to support digital signatures for
peer-to-peer authentication, security labelling and security contexts.
This security class adds security functions within MTAs and the MTS. The main security function
s2
added within this class is authentication within the MTS, and hence non-repudiation can also be
provided.
In addition, each of the three security classes has a variant (denoted as SOC, SIC and S2C) which requires
support of end-to-end content confidentiality.
Double enveloping can be used with each security class as an optional extension, but is outside the scope of
conformance to ISO/IEC ISP 1061 1 and will be subject to bilateral agreement.
Support of the SEC FG is applicable to an MTA, an MS or a UA (either as MTS-user or as MS-user) and
requires as a minimum support of security class SO.
Unless otherwise stated, symmetric or asymmetric techniques (or a combination thereof) may be used within
each security class and are identified by the registered algorithm identifier.
Various levels of assurance in trusted COMPUSEC functionality may be used within each security class, but this
is outside the scope of an ISP.
A full rationale for each of the security classes and a broader discussion of security considerations are provided
in annex C.
Table 3 summarizes the requirements of the security classes on an MTS-user and on an MTA.
Table 3 - Overview of the SEC security classes
MTS-user MTA
Security
Class
Supports relay of security EoS
Basic
~~~
Supports submission and delivery of
so Content integrity
security EoS
Proof of delivery
Origin authentication (end-to-end)
SI As SO plus: As SO plus:
Message security labelling Peer entity authentication
Message security label I i ng
Security context
Security management Security context
Security management
As SI plus:
s2 As SI plus:
Origin authentication checks
Origin authentication checks
Proof of submission
Proof of submission
SnC As Sn plus:
Content confidentiality
I
The incremental functionality of the security classes can be represented diagrammatically as shown in figure 1.
O ISOAEC ISOAEC ISP 10611-1 : 1994 (E)
Figure 1 - Incremental functionality of the SEC security classes
7.7.2 Secure interworking
lnterworking between implementations supporting different security classes can be achieved in terms of any
common class(es) supported. As specified in the base standards, an implementation which supports secure
access management shall check the label of a message, probe or report against the security context. There is
no negotiation of security class during association establishment.
The security class in force is identified using the security-policy-identifier within a security label, as specified in
table 4. Such generic security-policy-identifiers only imply support of the MHS security services as specified for
these security classes in this part of ISOAEC ISP 1061 1. No other COMSEC or COMPUSEC functionality can be
assumed by use of such security-policy-identifiers. More specific security policies may be based on one or more
of the security classes as defined in this clause but will require use of registered security-policy-identifiers for
private secure interworking.
A security label may additionally contain one or more of security-classification, security-categories and privacy-
mark. Table 4 specifies a minimum set of values for security-categories. Again, further values may be registered
for private secure interworking. However, in all cases, the precise semantics of security-categories are outside
the scope of this ISP and will require bilateral agreement.
Table 4 - Securitv label identifiers
Identifier Value
id-mhs-security { iso( 1) identified-organization(3) ewos( 16) eg(2) mhs(4) security(4) }
id-policy-identifier { id-mhs-security 1 }
security-policy-identifiers:
security -class-SO { id-policy-identifier O O }
security class SOC { id-policy-identifier O 1 }
secu rity-c1ass-S 1 { id-policy-identifier 1 O }
secu rity-class-S 1 C { id-policy-identifier 1 1 }
security-class-S2 { id-policy-identifier 2 O }
security-class-S2C { id-policy-identifier 2 1 }
id-category-identifier { id-mhs-security 2 }
security-categories:
private { id-category-identifier O }
confidence
{ id-category-identifier 1 }
commercial-in-confidence { id-category-identifier 2 }
management-in-confidence { id-category-identifier 3 }
personal-in-confidence { id-category-identifier 4 }
ISOIIEC ISP 1061 1-1 : 1994 (E:) O ISO/IEC
The Security Context security service ensures that a message security label matches at least one of the set of
labels specified in the security context established between the communicating entities. An implementation
which supports this service shall as a minimum support exact matching for equality on the security-policy-
identifier, security-classification ancl security-categories elements of the label.
NOTE - The basic support requirement is that absence of an element shall not be treated as "any value" - i.e. all
permissible combinations of occurrencle and value for the elements of the message security label will need to be elaborated
in the security context (see also annex C).
7.7.3 Description of the security classes
The following tables identify the security services covered by each of the security classes within the SEC FG.
Where the classification of a security service does not change for the higher security classes, then the security
service is not repeated in the tables; for those higher security classes.
Figure 2 explains the column headings used in the tables, which identify which MHS functional objects are
involved in the provision and use of' each security service
Figure 2 - Key to security class tables
7.7.3.1 Security class SO
Table 5 - Securitv class SO
Security Service
I'
)"
ORIGIN AUTHENTICATION
Message Origin Authentication' m
-
Probe Origin Authentication
-
Report Origin Authentication
-
Proof of Submission
Proof of Delivery m
SECURE ACCESS MANAGEMENT
-
Peer Entity Authentication2s6
-
Security Context
DATA CONFIDENTIALITY
-
Connection Confidentiality
Content Confidentiality O
Message Flow Confidentiality i
DATA INTEGRITY
-
Connection Integrity
Content Integrity m
Message Sequence Integrity4
O
O ISOAEC ISOllEC ISP 10611-1 : 1994 (E)
3 4
Security Service 1 2
MSI UA/
UA/ UA/
MTA MTA
UA MS
N ON-R E P U DI AT1 ON
- -
O I
Non-repudiation of Origin''5
- - - -
Non-repudiation of Submission
- - -
O
Non-repudiation of Delivery5
Message Security O O O O
SECURITY MANAGEMENT
- -
O
Change Credentials O
- -
O
Register O
- - -
O
MS-Register
NOTES
Only provided to the message recipient (using the Message Argument Integrity security element).
Using either asymmetric or symmetric algorithms as identified by the algorithm identifier.
When security labelling is used, the security-policy-identifier shall be included.
Allocation and management of sequence numbers is outside the scope of this ISP and is subject to bilateral
agreement.
Using either a trusted notary (symmetric) or using certificates and tokens which are not repudiable (asymmetric).
Authentication between Co-located objects is a local issue.
These services are expected to be provided by non-standard management services and are therefore outside the
scope of this ISP.
Non-repudiation of Delivery can only be provided when the Proof of Delivery service is used. However, if Proof of
Delivery and Content Confidentiality are both used, and delivery is to an MS, then proof of delivery can only be
computed on the encrypted content. It should be noted that this will not provide Non-repudiation of Delivery.
7.7.3.2 Security class SI
Table 6 - Securitv class SI
1 2 3 4 5
Security Service
As SO plus: UA/ UA/ MS/ UA/ MTA/
UA MS MTA MTA MTA
ORIGIN AUTHENTICATION
-
Message Origin Authentication* m' I i
SECUREACCESSMANAGEMENT
- m' m1 m' m1
Peer Entity A~thentication~'~
- m' m' m' ml
Security Context
DATA CONFIDENTIALITY
-
Connection Confidentiality' i i I i

ISO/IEC ISP 10611-1 : 1994 (E) O ISOAEC
____
5 6 7 8 9
Security Service
Ill2
-
I
As SO plus: UA/ UA/ MSI UA/ MTAI MTAI MTAI MSI MSI
UA MS MTA MTA MTA UA MS UA UA
DATA INTEGRITY
-
i i i
Connection integrity6 i i i
- - - - - -
m1
Content Integrity
m1 m1 m1 m1 ml ml m1 ml
Message Security Labelling3
SECURITY MANAGEMENT
-
-
i5 m m
Change Credentials m m
- - - -
i5
Register m m
- - - - - -
MS-Register m
NOTES
1 Shall always be used.
2 Only provided to the message recipient (using the Message Argument Integrity security element).
3 Using either asymmetric or symmetric algorithms as identified by the algorithm identifier.
Authentication between Co-located objects is a local issue.
5 These services are expected to be provided by non-standard management services and are therefore outside the
ISP.
scope of this
6 Shall be provided as defined in clause 10 of ISO/IEC 10021-2 and in IS0 7498-2.
7.7.3.3 Security class S2
Table 7 - Se
4 7
Security Service Il
MSI UA/ MTAI ~ MTAI MTAI
As SI plus:
MTA MTA MS
ORIGIN AUTHENTICATION
-
-
Message Origin Authentication3 m1
- -
Probe Origin Authentication ml
- -
m1
Report Origin Authentication
- - -
Proof of Submission
NON-REPUDIATION
-
Non-repudiation of Origin''5 m2
- -
Non-repudiation of Submission
- -
Non-repudiation of Delivery5
NOTES
1 Shall always be used.
Using an asymmetric mechanism (i.e. certificates and tokens which are non-repudiable) for authentication within
MTAs and the MTS.
O ISO/IEC ISOAEC ISP 10611-1 : 1994 (E)
3 Using the Message Origin Authentication Check security element.
4 Using either a trusted notary (symmetric) or non-repudiable certificates and tokens (asymmetric).
7.7.3.4 Confidential security class variants SnC
Table 8 - Confidential securitv class variants SnC
I Security Service
As Sn plus:
CONFIDENTIALITY
Content Confidentiality
~~
7.8 Use of Directory (DIR)
The Use of Directory FG covers support of the Designation of Recipient by Directory Name EoS as follows:
support of specification of a recipient by means of a directory name by an MTS-user or an MTA on
submission;
0 support of access to a directory service by an MTA to obtain one or more O/R addresses (either on
or subsequently if an O/R address is absent or determined to be invalid and a directory
submission
name is present).
NOTE I - A directory may also be used directly by MHS users to obtain information to assist in the submission of
messages. However, such use is not necessarily MHS-specific and is therefore outside the scope of this ISP.
For a UA, support of the DIR FG only requires the ability to submit a message with one or more O/R names
specified using a directory name, as specified in subclause 8.5.5 of ISO/IEC 10021-4. Whether or not the UA
also has the capability to access a directory directly is outside the scope of ISO/IEC ISP 1061 1.
An MTA may access a directory service using a Directory User Agent (DUA). The interface between the MTA
and the DUA is a local matter and is outside the scope of ISO/IEC ISP 1061 1. Similarly, the interaction between
the DUA and one or more Directory System Agents (DSAs) comprising the directory service is also outside the
scope of ISO/IEC ISP 1061 1.
The only information that is assumed to be capable of being returned by the directory service in this version of
ISO/IEC ISP 10611 is an attribute containing one or more O/R addresses. The use of a directory service to
support distribution list processing is outside the scope of this version of ISO/IEC ISP 1061 1.
NOTE 2 - The MTS may also use a directory service to obtain information, for example, that may be used in the routeing of
messages. However, such applications of a directory service are not defined by the MHS base standards and are therefore
outside the scope of ISOAEC ISP 1061 1.
7.9 84 Interworking (841W)
The 84 lnterworking functional group covers interworking between implementations conforming to ISO/IEC ISP
1061 1 (hereafter referred to as ‘1 988 systems’) and implementations conforming to the ITU X.400( 1984)
Recommendations (hereafter referred to as ‘1984 systems’). Support of the 841W FG is only applicable to an
MTA and is not applicable unless the MTA supports the PI mts-transfer-protocol-I 984 application context (see
ISO/IEC ISP 10611-3).
Support of the 841W FG requires observance of the interworking rules defined in annex B of ISO/IEC 10021-6.
Additional recommended practices for interworking with 1984 systems are described in annex D.
ISO/IEC ISP 10611-1 : 1994 (E)
8 Naming and addressing
8.1 O/R address attribute encodings
The basic rules governing different encodings (where permitted) of O/R address attributes are specified in
subclause 18.2 of ISO/IEC 10021 -2
NOTE - It is recommended that the ;alpha-2 form of the country-name attribute be used. It is recommended that the
Printable String form of the administration-domain-name and private-domain-name attributes be used.
An MTA shall be able to accept on submission, to transfer and to deliver (according to which ports are
supported) messages containing UR address attributes with any valid encoding. No character repertoire
restrictions apply - i.e. all repertoires specified for Teletex String in IS0 8824 shall be supported.
A UA shall be able to submit and io accept on delivery messages containing O/R address attributes with any
valid encoding within the mnemonic: form. However, support of particular character repertoires and the methods
by which such values are captured on origination and made available to the MHS user on reception are outside
the scope of this ISP.
8.2 O/R address attribute equivalence
The following equivalence rules apply when comparing a provided O/R address with a collection of known O/R
addresses to determine delivery, and are in addition to those specified in subclause 18.4 of ISO/IEC 10021-2:
If the provided O/R address can be determined to be an unambiguous underspecification of a
known O/R address, the O/R addresses are equivalent.
NOTE 1 - Underspecification means that some attributes (or components of structured attributes) are present
in the known O/R address but are not present in the provided O/R address. Underspecification does not
mean partial value (e.g. substring) equivalence when the same attributes are present in both OIR addresses.
Overspecified OIR addresses are not equivalent.
NOTE 2 - Overspecification means that more attributes (or components of structured attributes) are present
in the provided O/R address than are present in the known O/R address. However, unrecognized domain-
defined attributes may be ignored when determining overspecification, subject to the local policy of the
recipient domain.
Attributes that are present in both Teletex String and Printable String encodings in the same O/R
address may be considered equivalent by virtue of their registration for the same UA. MTAs are not
responsible for verifying the equivalence of different encodings of the same attribute. Either
encoding of an attribute may be used for the purposes of routeing and delivery.
Further specification of repertoire-specific matching rules is outside the scope of ISO/IEC ISP 1061 1.
8.3 Routeing capability
The capability of an MTA to determine the route to another MTA or destination MTS-user is described in clause
19 of ISOllEC 10021-2. ISO/IEC ISP 10611 does not specify any requirements with respect to which O/R
address attributes must be capable of being used for route determination purposes.
For any MTA that supports message transfer, it shall be stated in the PICS which O/R address attributes may be
used for onward route determinatioin and any constraints (e.g. whether routeing can be based on specific values
of the attribute or only on the presence of the attribute, any limitations on the range of values, character
repertoires, etc) which may apply.
For any MTA that supports message transfer, it shall be stated in the PICS whether rerouteing is supported.
ISOIIEC ISP 10611-1 : 1994 (E)
O ISO/IEC
For any MTA that supports message delivery, it shall be stated in the PICS which O/R address attributes may be
used for registration of local MTS-users (and thus may be used for delivery determination) and any constraints
(e.g. any limitations on the range of values, character repertoires, etc) which may apply.
8.4 Validation of OIR addresses
As specified in subclause 14.6.1.4 of ISO/IEC 10021-4, an MTA shall verify on submission that O/R addresses
comply with the forms def
...