Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD2.mdf / ccitt / 1992 / t / t410.asc < prev next >

Wrap

Text File | 1991-12-31 | 185KB | 3,864 lines

IMPORT R:\\ART\\W INTERNATIONAL TELECOMMUNICATION UNION MF\\ITU.WM F \* mergeforma t CCITT T.410 Series THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE TERMINAL EQUIPMENT AND PROTOCOLS FOR TELEMATIC SERVICES FIRST EXTENSION (JANUARY 1991) TO THE T.410 SERIES (1988) OF RECOMMENDATIONS CONTAINED IN THE CCITT BLUE BOOK, FASCICLE VII.6: I ù Tiled raster graphics II ù Annex E to T.411 III ù Alternative representation IV ù Styles extension V ù Security Recommendations: T.410 Series IMPORT Geneva, 1991 R:\\ART\\ WMF\\CCIT TRUF.WMF \* mergeform at Printed in Switzerland FOREWORD The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommunication Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations prepared by its Study Groups. The approval of Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988). The first Extension (January 1991) to the T.410 Series (1988) was prepared by Study Group VIII and was approved under the Resolution No. 2 procedure on the 18 of January 1991. ___________________ CCITT NOTE concise conciseness to indicate both a telecommunication Administration and a recognized private operating agency. c ITU 1991 All rights reserved. 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 ITU. PAGE BLANCHE I Addendum to the T.410-Series of Recommendations (1988) on the subject of tiled raster graphics Add the following definition after S 3.167 of Recommendation T.411. 3.168 Tile One element of a two dimensional array of non-overlapping rectangular regions of a pel array. Add the following paragraphs after S 5.3.2 (Discarded pels) of Recommendation T.417. 5.4 Tiling The pel array may e segmented into a two dimensional array of non- overlapping rectangular regions called tiles. The content information of each tile is coded independently of the content information of the other tiles of the same pel array. Tiling facilitates convenient access to, and/or processing of portions of the pel array independent of access to, and/or processing of other portions. The capability to encode each tile separately as bitmap, compressed or null maximizes the possible compression of the tiled pel array. Note ù Tiling provides an alternative method for coding of raster graphics content and therefore does not affect the positioning of the clipped pel array. The basic concepts, pel image model and positioning of pels in a basic layout object continue to apply. Furthermore the attributes for pel array clipping continue to apply to the pel array. The location of pel array content relative to the tile content is specified by the "tiling offset" attribute. Figure 3 illustrates the location of the pel array in the set of tiles. Tiled raster graphics content information consists of a sequence of tiles ordered in the direction of the pel path and line progression as illustrated in Figure 4. The content of each tile may be T.4, T.6 or bitmap encoded as specified by the coding attributes. Alternatively, it may be omitted if the pels within the tile are either all foreground or all background. PAGE55 FIGURE 3 = 11,5 cm FIGURE 4 = 8 cm Renumber subsequent paragraphs to take account of the insertion of the new S 5.4. In the second paragraph of S 5 (Principles of positioning pels) of Recommendation T.417, replace . . . in S 5.4.1. Paragraphs 5.4.2 and 5.4.3 then . . . by . . . in S 5.5.1. Paragraphs 5.5.2 and 5.5.3 then . . . In the third paragraph of what was S 5.4.1 (Positioning parameters) of Recommendation T.417, replace . . . in SS 5.4.2 and 5.4.3 respectively by . . . in SS 5.5.2 and 5.5.3 respectively. Add the following to the end of the permissible value list in S 7.1.1 (Type of coding) of Recommendation T.417. {2 8 3 7 5} for "tiled encoding". Add the following to the end of the list of dashed items in the definition area of clause 7.1.1 (Type of coding) of Recommendation T.417. ù "tiled encoding" according to the tiling scheme defined herein, the bitmap encoding scheme, the two dimensional encoding scheme defined in Recommendation T.6, or the one or two dimensional encoding scheme defined in Recommendation T.4. Add the following paragraph after the line beginning "An explanation of these coding schemes . . ." in S 7.1.1 (Type of coding) of Recommendation T.417. The value "tiled encoding" indicates that the tiles in the content portion are each encoded per the value of the associated "tile types" attribute as defined in S 7.2.8. Add the following paragraph to the definition of S 7.1.1 (Type of coding) of Recommendation T.417. The relationship between the order of pels, the order of encoded bits and the order of encoded octets is the same for tiled, as for untiled bitmap, T.4 and T.6 encoding. Add the following text at the end of the last sentence of S 7.2.1 of Recommendation T.417. . . . or "tiled encoding". Add the following four paragraphs after S 7.2.4 (Number of discarded pels) of Recommendation T.417. 7.2.5 Number of lines per tile Classification: Defaultable; Applicability: Formatted processable content architecture class; Permissible value: Positive integer; Default value: 512 Definition: This attribute specifies the tile dimension in units of "line spaces" in the direction of line progression. This attribute is only applicable if the value of the attribute "type of coding" is "tiled encoding". PAGE54 7.2.6 Number of pels per tile line Classification: Defaultable; Applicability: Formatted processable content architecture class; Permissible value: Positive integer; Default value: 512 Definition: This attribute specifies the tile dimension in units of "pel spaces" in the pel path direction. This attribute is only applicable if the value of the attribute "type of coding" is "tiled encoding". 7.2.7 Tiling offset Classification: Defaultable; Applicability: Formatted processable content architecture class; Structure: Coordinate pair: X coordinate; Y coordinate. Permissible values: Coordinate pair: non-negative integer less than "number of pels per tile line" non-negative integer less than"number of lines per tile"; Default value: (0,0); Definition: This attribute specifies the location of the pel array within the tile space by defining the offset of the first pel of the pel array from the first pel position of the first tile. The offset is specified in pel spaces in the direction of the pel path and line spaces in the direction of the line progression. All tiles cover a portion of the pel array. Portions of the tile space outside the pel array are artifacts of tiling and contain no information. This attribute is only applicable if the value of the attribute "type of coding" is "tiled encoding". 7.2.8 Tile types Classification: Defaultable; Applicability: Formatted processable content architecture class; Permissible values: A sequence of one or more data elements with one of the following values: "null background", "null foreground", "bitmap encoded" "T.6 encoded" "T.4 one dimensional encoded" "T.4 two dimensional encoded"; Default value: All tiles are T.6 encoded. Definition: This attribute indicates the types of coding of tiles in the content portion as a sequence of values. Each value specifies the type of coding of the corresponding tile (see Figure 4) in the content portion as follows: ù "null background", indicating that all pels in the tile are known to be background and the tile has no encoded content; ù "null foreground", indicating that all pels in the tile are known to be foreground and the tile has no encoded content; ù "T.6 encoded", indicating that the pels in the tile are encoded as a T.6 octet string; PAGE55 ù "T.4 one dimensional encoded", indicating that the pels in the tile are encoded as a T.4 one dimensional octet string; ù "T.4 two dimensional encoded", indicating that the pels in the tile are encoded as a T.4 two dimensional octet string; ù "bitmap encoded", indicating that the pels in the tile are encoded as a bitmap octet string. The number of values is equal to the number of tiles. This attribute is only applicable if the value of the attribute "type of coding" is "tiled encoding". In S 8.2 of Recommendation T.417, replace EXPORTS Raster-Graphics-Attributes, One-Of-Four-Angles, One-Of-Two-Angles, Pel-Transmission-Density, Measure-Pair, Clipping, Pel-Spacing, Spacing-Ratio, Image-Dimensions; by EXPORTS Raster-Graphics-Attributes, One-Of-Four-Angles, One-Of-Two-Angles, Pel-Transmission-Density, Pel-Spacing, Spacing-Ratio, Coordinate-Pair; In S 8.3 of Recommendation T.417, replace EXPORTS Raster-Gr-Coding-Attributes, Compression; by EXPORTS Raster-Gr-Coding-Attributes, Compression, Tile-Type; Add the following below the list of EXPORTS in S 8.3 (Representation of coding attributes) of Recommendation T.417. IMPORTS Coordinate-Pair FROM Raster-Gr-Presentation-Attributes; Add the following to "Raster-Gr-Coding-Attribute" in S 8.3 (Representation of coding attributes) of Recommendation T.417. number-of-pels-per-tile-line [6] IMPLICIT INTEGER OPTIONAL, number-of-lines-per-tile [7] IMPLICIT INTEGER OPTIONAL, tiling-offset [8] IMPLICIT Coordinate-Pair OPTIONAL, tile-types [9] IMPLICIT SEQUENCE OF Tile-Type OPTIONAL PAGE54 Add the following after the "Compression" definition in S 8.3 (Representation of coding attributes) of Recommendation T.417. Tile-Type ::= INTEGER { null-background (0), null-foreground (1), T.6-encoded (2), T.4-one-dimensional-encoded (3), T.4-two-dimensional-encoded (4), bitmap-encoded (5) } In S 8.4 of Recommendation T.417 replace IMPORTS One-Of-Four-Angles, One-Of-Two-Angles, Pel-Transmission-Density, Measure-Pair, Clipping, Pel-Spacing, Spacing-Ratio, Image-Dimensions, FROM Raster-Gr-Presentation-Attributes, Compression, FROM Raster-Gr-Coding-Attributes; by IMPORTS One-Of-Four-Angles, One-Of-Two-Angles, Pel-Transmission-Density, Pel-Spacing, Spacing-Ratio, Coordinate-Pair, FROM Raster-Gr-Presentation-Attributes, Compression, Tile-Type, FROM Raster-Gr-Coding-Attributes; In S 8.4 (Representation of non-basic features and non-standard defaults) of Recommendation T.417, replace compression [0] IMPLICIT Compression } by compression [0] IMPLICIT Compression, number-of-pels-per-tile-line [6] IMPLICIT INTEGER, number-of-lines-per-tile [7] IMPLICIT INTEGER, tiling-offset [8] IMPLICIT Coordinate-Pair, tiling-types [9] IMPLICIT Tile-Type } In S 8.4 (Representation of non-basic features and non-standard defaults) of Recommendation T.417, replace compression [8] IMPLICIT Compression OPTIONAL } PAGE55 by compression 1[8] IMPLICIT Compression OPTIONAL, number-of-pels-per-tile-line [11] IMPLICIT INTEGER OPTIONAL, number-of-lines-per-tile [12] IMPLICIT INTEGER OPTIONAL, tiling-offset [13] IMPLICIT Coordinate-Pair OPTIONAL, tiling-types [14] IMPLICIT Tile-Type OPTIONAL } In S 9 (Coding schemes) of Recommendation T.417, replace ù bitmap encoding scheme. by ù bitmap encoding scheme; ù tiled encoding scheme. Add the following paragraph after S 9.3 (Bitmap encoding scheme) of Recommendation T.417. 9.4 Tiled encoding scheme Tiled content information is coded as a structured octet string composed of a sequence of independently coded tiles. Each tile is encoded as one octet string which may be structured or unstructured. All the pels of a tile may be coded according to one of the following coding schemes: ù Group 4 facsimile encoding scheme; ù Group 3 facsimile encoding schemes; ù bitmap encoding scheme. Alternatively the pels of a tile may be all background or all foreground, and not be coded. Add the following to Table 6 in S 12 (Definition of raster graphics content architecture classes) of Recommendation T.417. include 410-T01E Number of pels per tile ù D 3) line Number of lines per tile ù D 3) Tiling offset ù D 3) Tile types ù D 3) Note 3 ù This attribute is only applicable if the value of the attribute "type of coding" is "tiled encoding". Add the following to S A.2.2 of the annexes of Recommendation T.417. include 410-T02E [Type of coding] Tiled encoding PAGE54 Number of pels per tile Any positive integer 512 line Number of lines per tile Any positive integer 512 Tiling offset DécCoordinate Pair (Any non-negative integer, (0,0) less than "number of pels per tile line", Any non-negative integer less than "number of lines per tile") Tile types Sequence of positive integers compressed as in T.6 In S A.2.2 of the annexes of Recommendation T.417, replace Note ù The attribute "compression" is only applicable if the value of the attribute "type of coding" is "T.6 encoding" or "T.4 two dimensional encoding". by Note ù The attribute "compression" is only applicable if the value of the attribute "type of coding" is "T.6 encoding", "T.4 two dimensional encoding" or "tiled encoding". II Revision of Recommendation T.411 (Reference List and Annex E) II.1 Reference List: ù Recommendation T.414 (1988): Open document architecture (ODA) and interchange format ù Document profile; ù Recommendation T.415 (1988): Open document architecture (ODA) and interchange format ù Open document interchange format (ODIF); ù Recommendation T.416 (1988): Open document architecture (ODA) and interchange format ù Character content architectures; ù Recommendation T.417 (1988): Open document architecture (ODA) and interchange format ù Raster graphics content architectures; ù Recommendation T.418 (1988): Open document architecture (ODA) and interchange format ù Geometric graphics content architecture; PAGE55 ù Recommendation X.411 (1988): Message handling systems: Message transfer system: Abstract service definition and procedures; ù Recommendation X.420 (1988): Message handling systems: Interpersonal messaging system; ù ISO 2022 (1986): Information processing ù ISO 7-bit and 8-bit coded character sets ù Code extension techniques; ù ISO 6429 (1988): Information processing Control functions for 7-bit and 8-bit coded character sets; ù ISO 6937-1 (1983): Information processing ù Coded character sets for text communication ù Part 1: General introduction; ù ISO 6937-2 (1983): Information processing ù Coded character sets for text communication ù Part 2: Latin alphabetic and non-alphabetic graphic characters; ù ISO 6937-3 (1983): Information processing ù Coded character sets for text communication ù Part 3: Control functions for page-image format;1) ù ISO 8601 (1988): Data elements and interchange formats ù Information interchange ù Representation of dates and times;2) ù ISO 8632-1 (1987): Information processing systems ù Computer graphics ù Metafile for the storage and transfer of picture description information ù Part 1: Functional specification; ù ISO 8632-3 (1987): Information processing systems ù Computer graphics ù Metafile for the storage and transfer of picture description information ù Part 3: Binary encoding; ù ISO 9541-1: Information processing ù Font and character information interchange ù Part 1: Introduction2); ù ISO 9541-2: Information processing ù Font and character information interchange ù Part 2: Registration and naming procedures1); ù ISO 9541-5: Information processing ù Font and character information interchange ù Part 5: Font attributes and character model1); ù ISO 9541-6: Information processing ù Font and character information interchange ù Part 6: Font and character attribute subsets and applications1). II.2 ANNEX E (to Recommendation T.411) (Normative) Use of MHS to interchange documents conforming to the T.410-Series of Recommendations E.1 ODA identification in the P.1 Protocol of MHS Documents shall be identified by a set of ASN.1 object identifiers as externally-defined encoded-information types. One member shall always be the ASN.1 object identifier for ODA, the other members shall be one or more ASN.1 object identifiers for the document application profiles to which the message body parts conform. ODA document {2800Nte2 } Document application profile {see Note 2} . . . . . . . . . { . . . . } . . . . . . . . . { . . . . } . . . . . . . . . { . . . . } 1) Under revision. 2) To be published. PAGE54 Note 1 ù When using [MHS/MOTIS] to transfer documents conforming to ODA, the MTS may perform format conversion. Format conversion of ODA documents may result in loss of information. If format conversion is not appropriate, this should be indicated by the sender when submitting a message with ODA body parts to [MHS/MOTIS]. Note 2 ù These document application profiles ASN.1 object identifiers are those defined for CCITT. Other organizations shall use object identifiers as appropriate. E.2 ODA identification in the P.2 protocol of MHS Documents conforming to ODA shall be identified as ODA extended body parts. Each extended body part shall contain parameter information about the applicable document application profile and the document architecture class. Note ù ODA body parts can be mixed with non-ODA body parts in a P.2 body. The module for specifying the ODA body parts is described below: IPMSExtendedBodyPartTypeOda {joint-iso-ccitt(2) oda(8) modules(1) part(0) extended-body-part-type-oda(0) } Definitions implicit tags ::= Begin -- prologue EXPORTS oda-body-part, OdaBodyPartParameters, OdaData; IMPORTS Interchange-Data-Element, FROM Interchange-Data-Elements {2 8 1 5 5}, EXTENDED-BODY-PART-TYPE, FROM IPMSInformationObjects {joint-iso-ccitt(2) mhs-motis(6) ipms(1) modules(0) information-objects(2) }; oda-body-part EXTENDED-BODY-PART-TYPE PARAMETERS OdaBodyPartParameters IDENTIFIED BY id-et-oda-param DATA OdaData ::= id-et-oda-data -- Abstract syntax for ODA bodypart parameters shall appear in the parameter elements of an IPM ExternallyDefinedBodyPart -- OdaBodyPartParameters ::= SET { document-application-profile [0] OBJECT IDENTIFIER -- This object identifier value shall also be used in the MTS ExternalEncodedInformationType in addition to the id-et-oda-data object identifier --, document-architecture-class [1] INTEGER { [1] formatted (0), [1] processable (1), [1] formatted processable (2) }} PAGE55 -- Abstract syntax for ODA data shall appear in the data element of an IPM ExternallyDefinedBodyPart -- OdaData ::= SEQUENCE OF ::= Interchange-Data-Element id-et-oda-param OBJECT IDENTIFIER ::= {2 8 1 1 2} -- Identifies the Abstract Syntax for ODA bodypart parameters using the ASN.1 basic encoding rules --, id-et-oda-data OBJECT IDENTIFIER ::= {2 8 1 1 1} -- Identifies the Abstract Syntax for ODA data using the ASN.1 basic encoding rules -- END -- of IPMSExtendedBodyPartTypeOda -- III Addendum to the T.410-Series of Recommendations (1988) on the subject of alternative representation [Recommendation T.411/Part 1] Add to the definitions the clause of [Recommendation T.411/Part 1]: ù alternative description: A description that represents a basic object that is intended to be used by the recipient in lieu of the primary description of that basic object when the primary description cannot be processed; ù alternative subtree: An alternative basic object description in conjunction with its associated content portion description, if any; ù primary description: A description that represents a basic object that best represents the intent of the originator; ù primary subtree: The basic object description in conjunction with its associated content portion descriptions, with the potential to be replaced by an alternative subtree. Add to the definition of description: Note ù A basic object may have several descriptions when alternative descriptions are used. [Recommendation T.412/Part 2] Add to the end of S 2.3.3: An object description may also be referred to as a primary object description, in particular when it is required to distinguish between object descriptions and alternative descriptions [see S 2.3.5a)]. Add after S 2.3.5 (Styles): 2.3.5a) Alternative descriptions In addition to its primary description, a basic logical object or a basic layout object may be represented by one or more alternative descriptions. An alternative description is intended by the originator to be used by the recipient of a document in lieu of the primary description when the recipient is not capable of processing the primary description. In the case that these are multiple alternative descriptions, a preference order is defined between these alternative descriptions. An alternative description for a basic object may specify the same or a different set of attributes as those specified by the primary description. Alternative descriptions provide fallback mechanisms in this International Standard. Possible uses include: fallback content architecture classes (e.g., providing a raster image as a fallback for geometric graphics), compatibility with several versions of ODA, compatibility with several document application profiles, and fallback for non-basic values within a document application profile. PAGE54 Using an alternative description for an object implies using a different set of associated content portion descriptions, if any. An alternative description for an object in conjunction with any associated content portion description is collectively called an alternative subtree. The basic object description in conjunction with its content portion descriptions which could be replaced by an alternative subtree is called the primary subtree. A fallback for a content portion description can be supplied by providing an alternative description for a basic object with which the content portion is associated, and associating the fallback content portion description with this alternative basic object description. Alternative subtrees must satisfy the constraint that substituting the alternative subtree for its primary subtree must result in a valid document for the purposes of performing a layout process and/or an imaging process. Add at the end of S 2.5.1 (Editing process): 2.5.1.8 Alternative descriptions Alternative descriptions usually play no direct role in the editing process but may be derived automatically by the originating system from the primary descriptions. It is then the responsibility of the originating system to keep the alternative descriptions consistent with the primary description. Alternative descriptions may also have to be manually derived from the primary description (for example, descriptive text indicating the contents of the primary description); in this case it is the responsibility of the originator to maintain consistency during the editing process. At the end of S 2.5.2 (Layout process): 2.5.2.9 Alternative descriptions Alternative descriptions do not influence the reference layout process. If a system is to lay out a document that contains primary descriptions it is not capable of processing, it may substitute alternative descriptions for those primary descriptions prior to the layout process. A system that provides a layout process where both primary and alternative descriptions influence the layout process, is outside the scope of this International Standard. Add at the end of S 2.5.3 (Imaging process): 2.5.3.6 Alternative descriptions Alternative descriptions do not influence the reference imaging process. If a system is to image a document that contains primary descriptions it is not capable of processing, it may substitute alternative descriptions for these primary descriptions prior to the imaging process. S 5.3.3.2 Subordinates Add at the end of the first paragraph of definition of Subordinates: In the case of subordinate basic objects this attribute identifies their primary descriptions. Add a new clause 5.3.3x (Alternative): 5.3.3x Alternative Constituent: Basic object descriptions Classification: Non-mandatory Permissible values: The identifier of an alternative description of a basic object PAGE55 Definition: For a primary description of an object this attribute refers to the first alternative description, in the order of preference. For an alternative description this attribute refers to the next alternative description, in the order of preference. Note ù Thus, the specification of this attribute establishes a chain of alternative descriptions to a primary description of a basic object in the order of decreasing preference. Add a new S 5.3.3y (Primary): 5.3.3y Primary Constituents: Basic object descriptions. Applicable only to alternative descriptions Classification: Mandatory for alternative descriptions Permissible values: The identifier of a basic object Definition: This attribute refers from an alternative description to its primary description. Add to the end of the first paragraph in S 6.1: If necessary, the logical structure is derived from the set of descriptions, including alternative descriptions present in the document, by a process called initialization [see S 6.1a)]. Add a new S 6.1a): 6.1a Initialization Before the layout process commences, the logical structure of the document is derived conceptually from the set of primary and alternative descriptions in the document by the following initialization of the layout process. First, a logical structure is created from the primary descriptions in the document, i.e., the root logical object description and all those descriptions which are referred to by the attribute "subordinates" of composite object descriptions. If any of the primary descriptions cannot be decoded by the recipient, the initialization can substitute one or more primary descriptions by one or more alternative descriptions. If the resulting logical structure cannot be processed by the recipient (e.g., edited) or may result in layout that cannot be processed by the recipient, the initialization can substitute one or more primary or alternative descriptions by one or more alternative descriptions. These substitutions take account of the preference order for substitution specified by the attribute "alternative". Note ù For a more implementation-oriented description of the initialization see Annex G (this information is informative rather than normative). Add to the end of the first paragraph in S 7.1: If necessary, the layout structure is derived from the set of descriptions including alternative descriptions present in the document by a process called initialization; this process is performed analogously to the initialization of the layout process [see S 6.1a)]. PAGE54 [Recommendation T.414/Part 4] Add to the document profile: 5.3.6a Alternative feature sets This attribute lists combinations of identified features, so that any one combination is sufficient to process a particular selection of primary descriptions and alternative descriptions in the document. This attribute consists of a set of sets of ASN.1 object identifiers. Each set lists a set of object identifiers for features such as content architecture classes that is sufficient to process a particular set of alternatives in the document. Various parts of this International Standard define ASN.1 object identifiers for features. In particular, content architectures specify an ASN.1 object identifier for each architecture class. Note 1 ù In the T.410-Series of Recommendations no other features are defined. Note 2 ù No provision is made for alternative sets of non-basic values. [Recommendation T.415/Part 5] Add at the end of S 5.2: For basic objects for which alternative descriptions have been specified there is one descriptor representing the primary description and one descriptor for each alternative description. In the data stream, the descriptors for alternative descriptions of basic object descriptions follow immediately after the descriptors for their primary description, in the order of decreasing preference. The text units representing the content portions associated to alternative subtrees follow immediately after the text units representing the content portions associated to the primary subtree, in the order of decreasing preference. Add in S 5.6 in the definition of "Document-Characteristics" after the lines "ODA-Version": Alternative-feature-sets [11] IMPLICIT SET OF [11] SET OF OBJECT IDENTIFIER OPTIONAL In SS 5.8 and 5.9 in the definition of "Layout-Object-Descriptor-Body" and "Logical-Object-Descriptor-Body": change the terminating brace into a comma, and append primary [26] IMPLICIT Object-or-class-identifier OPTIONAL, alternative [27] IMPLICIT Object-or-class- identifier OPTIONAL} [Recommendation T.412/Part 2] Add a new informative Annex G: ANNEX G (Informative) Overview of alternative description, technical and implementation aspects G.1 Substituting basic objects The basic mechanism employed by alternative descriptions is the substitution of entire basic objects in an ODA document based on the presence or absence of capabilities of either the layout or the imaging process. PAGE55 G.2 Independence of substitutions All these substitutions are made independently of each other, i.e., the fact that a particular subtree is used instead of a different subtree would have no relation to the fact that at a different place in the document another subtree is used instead of a different subtree applicable at that point. G.3 Selection of alternatives The decision to use a primary subtree or an alternative subtree has been called selection. Selection can happen at two conceptual places: 1) in the initialization phase of the layout process; and 2) in the initialization phase of the imaging process. In both cases the actual implementation is likely to perform the selection during the respective process, but from a conceptual view it is preferable to think about selection taking place before the process is commenced. This allows use of the semantics of the ODA layout and imaging processes without any change. G.4 Substitution in the initialization process Once an alternate substitution has been made this substitution proceeds as follows: The primary description is ignored in the layout and imaging processes. All content portion descriptions associated with the primary description are ignored in the layout and imaging processes. An alternative description which refers to the primary description is processed instead. Its object identifier is changed to that of the primary description. In the content portion descriptions the matching change of identifiers is performed. Such substitutions can be performed repeatedly. The alternative descriptions for each primary description are considered in the orders of preference specified by the values of the attribute "alternative". If no logical structure can be created that can be processed by the recipient, the initialization process fails. Implementations that perform the initialization process directly from an ODIF stream need not use the attribute "alternative". G.5 Syntactical selection of alternatives Sometimes fallbacks may be required because a recipient system cannot even decode a constituent, e.g., because a new format for this constituent or even a new type of constituent is used. This means that only providing pointers to the alternative descriptions in the primary descriptions would have been contrary to the purpose of providing alternative descriptions, since the reason that the alternative description is needed may be that the primary cannot be syntactically understood. An association of an alternative to a primary thus was made by identifying the alternative to be a substitute for the primary. This also means that a system trying to read a document cannot immediately give up upon not being able to decode a description but needs to continue reading for possible alternatives. To simplify this, [Recommendation T.415/Part 5] specifies that alternative descriptions immediately follow the primary description in PAGE54 the interchange data stream. Because of this constraint on the sequential order of alternative descriptions in the interchange format it is not necessary to make use of the attribute "alternate" for finding alternative descriptions. It is also possible that a description that could not be parsed and for which no alternative is present is a class or style description used by an object for which an alternative is provided that uses a different style or class; in that case not being able to parse the style or class is not an error condition (this is in accordance with general robustness principles). The resulting decoding strategy for ODIF documents could be called "read until you understand": if a descriptor cannot be decoded the recipient should continue reading the data stream in the hope for an alternative for this description. Only if the result of reading in the data stream is not a complete ODA document even after taking all alternatives into account should the recipient give up decoding the document. This also means that a document that completely misses a particular primary description should not be considered to be in error since that primary description may have been in a part of the document that could be not be decoded. A special case should be allowed for object class descriptions: If an object class description cannot be decoded (more precisely: if, after completely reading a data stream, there are references to an object class that do not seem to be present in the part of the data stream that could be understood), an error should only be raised if the object class was actually used by an object for which there is no valid alternative description. This special case also obviates the need for alternative descriptions for classes; if an alternative description is to be provided for a class it should be included in all generators for subordinates in a choice together with the primary object class and alternative descriptions should be provided for all objects using the primary class. G.6 Preference between several alternatives When several alternatives are made available in a document and the recipient can process more than one of them, inability to use the primary description leads to the question which alternative should be used by the recipient. A simple linear priority is provided by the chain created by the "alternate" attribute. This linear priority can also be obtained from the sequence of the alternatives in the interchange stream for the reasons of syntactical fallback given above. To allow for use of the "read until you understand" strategy, [Recommendation T.415/Part 5] also specifies that the alternatives shall be ordered in the data stream by order of their decreasing preference. IV Addenda to the T.410-Series of Recommendations (1988) on the subject of Styles extension Within existing S 2.3.5 of Recommendation T.412, add the following text following the last sentence of the second paragraph: Styles may be derived from other styles. The derived style will only specify the attributes and/or attribute values that differ from the style from which it is was derived. Within existing S 2.3.10 of Recommendation T.412, add the following paragraph following the fifth paragraph: Styles may be present in both the interchange docume t and the resource- document. If styles in the interchange document and the resource-document have the same identifier then references from the resource-document are to the style in the resource-document, and references from the interchange document are to the style in the interchange document. Within existing S 5.1.1.2 of Recommendation T.412, add the following text following the second paragraph of the subclause: A style that explicitly specifies all of the appropriate attributes that relate to that style is termed a root style. Any number of additional styles may be derived from a root style. The derived styles will specify only the attributes and/or attribute values that differ from the root style. This provides a means for factoring attributes thus preventing the necessity of copying the same attributes in similar styles. Any number of levels of derived styles may be provided by the first specifying a style derived from the root style and then specifying other styles derived from derived styles. PAGE55 Within existing S 5.1.1.2 of Recommendation T.412, replace the last sentence of the fourth paragraph with the following text: Precedence rules are specified in SS 5.1.2.4, 5.1.2.6 and 5.7.12. Within existing subclause 5.1.1.3 of Recommendation T.412, add the following text following the third paragraph of the subclause: A style that explicitly specifies all of the appropriate attributes that relate to that style is termed a root style. Any number of additional styles may be derived from a root style. The derived styles will specify only the attributes and/or attribute values that differ from the root style. This provides a means for factoring attributes thus preventing the necessity of copying the same attributes in similar styles. Any number of levels of derived styles may be provided by first specifying a style derived from the root style and then specifying other styles derived from derived styles. Within existing S 5.1.1.3 of Recommendation T.412, replace the last sentence of the fifth paragraph with the following text: Precedence rules are specified in SS 5.1.2.4 and 5.1.2.6. Within existing S 5.1.2.4 of Recommendation T.412, replace item b) of S 7 with the following text: If the object description concerned refers to a style then the value of the attribute specified or derived for that style is used (see S 5.1.2.6). Within existing S 5.1.2.4 of Recommendation T.412, replace item d) of S 7 with the following text: If the object description concerned refers to an object class description which contains a reference to a style then the value of the attribute specified or derived for that style is used (see S 5.1.2.6). Within existing S 5.1.2.4 of Recommendation T.412, replace item f) of S 7 with the following text: If the object description concerned refers to an object class description which refers to an object class description in the resource-document which contains a reference to a style then the value of the attribute specified or derived for that style is used (see S 5.1.2.6). Insert the following new subclause immediately after existing S 5.1.2.5 of Recommendation T.412: 5.1.2.6 Determining values for attributes of styles To determine the value of an attribute in a layout style or presentation style, the value is determined by the first of the following rules which is applicable: a) if an attribute value is specified in the style concerned, then that value is used; b) if the style concerned is derived from another style, and that style contains a value for the attribute, then that value is used; c) if the style concerned is derived from another style, and that style is derived from other styles at any number of levels including the root style, then the attribute value determined for the lowest style level is used; d) if no value is determined by the preceding steps a) to c), then no value is determined for the attribute. (For defaultable attributes see S 5.1.2.4.) Within existing S 5.6.2 of Recommendation T.412, add the following text at the end of the list in the first paragraph: ù derived from (see S 5.10). PAGE54 Within existing S 5.8.2 of Recommendation T.412, add the following text at the end of the list in the first paragraph: ù derived from (see S 5.10). Insert the following new subclause immediately after S 5.9 of Recommendation T.412: 5.10 Derived from Constituents: Layout styles and presentation styles Classification: Non-mandatory Permissible values: A presentation style identifier or a layout style identifier Definition: This attribute is used to establish a relationship between a layout or presentation style and another style of the same type. Attributes and their values from the referenced style are used along with the directly specified attributes. Values of directly specified attributes take precedence over values obtained from referenced styles. Within existing S 5.10 f Recommendation T.415, in "Presentation-Style- Descriptor" and "Layout-Style-Descriptor" replace the closing brace (}) with a comma (,) followed by the following line of text: derived from [x] IMPLICIT Style-Identifier OPTIONAL} Note ù The value of "x" is to be assigned by the editor of Recommendation T.415. V Extensions on security V.1 Changes to Recommendation T.411 V.2 Changes to Recommendation T.412 V.3 Changes to Recommendation T.414 V.4 Changes to Recommendation T.415 V.1 Changes to Recommendation T.411 Amend three definitions in Recommendation T.411 as follows: 3.32 Constituent: A set of attributes that is one of the following types: a document profile, an object description, an object class description, a presentation style, a layout style, a content portion description, or a protected part description. 3.47 Descriptor: A data structure representing the document profile, an object class description, a layout style, a presentation style, an object description, or a protected part description. 3.53 Document body: The part of a document that may include a generic logical and layout structure, specific logical and layout structure, layout and presentation styles, protected parts but excludes the document profile. Amend the new definitions as follows: The following definitions shall be merged into S 3. 3.1 Authenticity: The property that the claimed data source can be verified to the satisfaction of the recipient. 3.2 Confidentiality: The property that information is not made available or disclosed to unauthorized individuals, entities or processes. PAGE55 Note ù This property is limited here to preventing unauthorized semantic knowledge of a document or specified parts of it. 3.3 Data integrity: The property that data has not been altered or destroyed in an unauthorized manner. 3.4 Digital signature: A form of seal associated with a specified part of a document which provides proof of uniqueness of the identity of the originator (source) who applied the seal; it supports non-repudiation of origin of the sealed (signed) part. 3.5 Fingerprint: A short and compact code that may be computed in order to characterize some specified information, with the property that it is not practicable to construct different information which would yield the same output. 3.6 Integrity: Used here synonymously with data integrity. 3.7 Intended recipient: An intended recipient of a document is a recipient that is expected to receive or have access to the document. 3.8 Non-repudiation of origin: The property that an originator can be proved to the satisfaction of a third party to be the source of a document or specified parts of it. 3.9 Privileged recipient: A privileged recipient of a document is a recipient that in addition to being an intended recipient, has the right to perform certain security-related operations intended for that particular recipient, such as, to interpret specified enciphered parts of the document, and to perform integrity and authenticity checks on specified parts of the document. 3.10 Recipient: A recipient of a document is any object or user receiving or having access to a document. 3.11 Seal (noun): Data associated with a specified part of a document by an originator, which a recipient (privileged recipient) may use to verify the integrity and authenticity of the specified part. 3.12 Seal (verb): To associate a seal with a specified part of a document. 3.14 Security domain: The set of resources subject to a single security policy. 3.15 Security label: A marking of a document, which specifies the handling of the document according to the security policy in force. 3.16 Security policy: The set of rules that specify the procedures and services required to maintain the intended level of security of a set of resources. Add a definition to S 3. 3.xx Protected part: A constituent consisting of a part of the document that is sealed or enciphered, e.g., a sealed document profile or a pre-enciphered document body part. Insert the following text before the last paragraph of S 5.1: It also supports security aspects such as ù protection against unauthorized semantic knowledge of parts of a document; ù detection of discrepancies between the claimed and actual source and content of parts of the document. Add a new S 5.2.9 to Recommendation T.411: 5.2.9 Protected parts Protected parts enables protection to be provided for parts of a document, offering confidentiality, integrity, authenticity and non-repudiation of origin. Protected parts cannot provide for the protection of a document as a whole. Treatment of the complete document as an object is outside the scope of this Recommendation. Parts of a document can be protected before layout in its processable form, or after the layout process in formatted or formatted processable forms. PAGE54 V.2 Changes to Recommendation T.412 Add a bullet item in S 1.1 as follows: ù defines the reference model of the document layout process; ù defines the reference model of the document imaging process; ù defines the reference model for protecting parts of a document; ù defines three document architecture classes; ù defines a notation used for illustrating and describing document structures; ù provides examples of document architecture levels; ù provides examples of document structures; ù provides examples of particular document attributes. Add to the bulleted list in S 2.3.1 ù sealed document profile description; ù enciphered document profile description; ù pre-enciphered document body part description; ù post-enciphered document body part description. Add a new paragraph between SS 2.3.6 and 2.3.7 2.3.6.a Protected part descriptions A protected part description is a set of attributes which may be referred to from the document profile. There are four kinds of protected part descriptions: ù sealed document profile description; ù enciphered document profile description; ù pre-enciphered document body part description; ù post-enciphered document body part description. Change in S 2.3.12 in the bullet b): 1) constituents representing the generic structure, optionally style constituents, and optionally constituents representing protected parts of the document; 2) constituents representing the specific structure, optionally style constituents, and optionally constituents representing protected parts of the document; 3) constituents representing the generic structure, the specific structure, optionally style constituents, and optionally constituents representing protected parts of the document; 4) constituents representing protected parts of the document. Add to the bullet list in S 2.3.12: l) the constituents representing the protected parts of the document consist of sealed document profile descriptions and/or enciphered document profile descriptions and/or pre-enciphered document body part descriptions and/or post-enciphered document body part descriptions. PAGE55 Replace Figure 2 by: Figure page entière PAGE54 Add a new S 2.6 2.6 Security protection of parts of a document This Recommendation distinguishes between the following two sets of security protected parts of a document: a) parts of a document profile description; b) parts of the document body consisting of complete object descriptions, object class descriptions, layout styles and presentation styles. A complete composite object description implies its complete substructure including the content portions. Two concepts of document security exist: a) Information indicating how the whole document should be handled as a single unit, according to the security policy of the security domain to which the originator belongs. The originator is responsible for making the indication; the actual security handling of the document is outside the scope of both originator and recipient, and outside the scope of the T.410 Series Recommendations. b) Information to be interchanged between the originator and the recipient on how security aspects of parts of the document should be handled. The handling of this component of security is under the control of the originator and the recipient. For parts of the document, case b) covers the properties of: ù confidentiality; ù integrity; ù authenticity, including signature and non-repudiation of origin. It is not the purpose of the T.410 Series Recommendations to specify any particular security scheme or method, but rather to provide the means in the document for a variety of possible security implementations as required by various security policies. Two cryptographic techniques may be used to provide the security protections in the T.410 Series Recommendations: ù encipherment of clear text to provide confidentiality and possibly integrity of data; ù production of cryptoghraphically derived information to provide integrity and authenticity of data. There are two phases, a generation phase and an interpretation phase involved with security protection of parts of a document. The generation phase enciphers or seals parts of the document and creates security information that is added to the document. The protected part descriptions are created in this phase. These descriptions contain the enciphered and the sealed versions of protected parts of the document. The interpretation phase deciphers enciphered protected parts or validates seals that have been created in the generation phase. 2.6.1 Intended and privileged recipients Two categories of recipients, namely intended recipients and privileged recipients are defined. An intended recipient of a document is a recipient that is expected to receive or have access to the document. A privileged recipient of a document is a recipient that, in addition to being an intended recipient, has the right to perform certain security-related operations intended for that particular recipient, such as to interpret certain parts of the document and to perform certain integrity and authenticity checks. 2.6.2 Protecting parts of the document profile Protected parts of a document profile are specified in two sets of document profile descriptions, the set of enciphered document profile descriptions and the set of sealed document profile descriptions. PAGE55 The sealed document profil s are for integrity, authenticity and non- repudiation of origin, one for each seal of parts of the document profile. The enciphered document profiles are for confidentiality, one for each encipherment of parts of the document profile. All information about each sealed or enciphered document profile is found in the document profile. 2.6.3 Protecting parts of the document body The parts of the document body that may be protected are object class descriptions, object descriptions, layout styles and presentation styles. Confidentiality is based on encipherment and integrity, authenticity and non-repudiation are based on a seal. For encipherment: The protection of a composite object description implies that not itself, but all its subordinates including the content portions directly referred to from any of its subordinates are protected. The protection of a basic object description implies that all the content portions directly referred to from it are protected. The protection of a basic object description implies that for processable form and form documents, all the content portions directly referred to from it are protected. In a formatted processable form document whereas all content portions directly referred to from a basic object description in one of the structures are protected it may be that only some of the content portions directly referred to from a basic object description in the other structure are protected. The protection of a composite object class description, layout style or presentation style implies that all of it is protected. Any component or style that is enciphered shall not be present in the document in its unenciphered form. For sealing: The protection of a composite object description implies that itself and all its subordinates including the content portions directly referred to from any of its subordinates are protected. The protection of a basic object class description implies that the basic component itself and all content portions directly referred to from it are protected. The protection of a basic object description implies that for processable form and formatted form documents, itself and all the content portions directly referred to from it are protected. In a formatted processable form document whereas all content portions directly referred to from a protected basic object in one of the structures will be protected, it may be that only some of the content portions referred to from a basic object description in the other structure are protected. The protection of a composite object class description, layout style or presentation style implies that all of it is protected. For confidentiality enciphered document body parts are defined. There are two sets of enciphered document body part descriptions: one set for pre-enciphered document body parts and one set for post-enciphered document body parts. A pre-enciphered document body part description is provided for each encipherment performed before the layout process, and a post-enciphered document body part description is provided for each encipherment performed after the layout process. PAGE54 All information about each pre- or post-enciphered document body part is found in the document profile. For integrity, authenticity and non-repudiation of origin seals are provided. The seals and all information about them are found in the document profile. Add to the bullet list in S 5.1.1: ù protected part attributes. Change 5.3 ù 5.9 in S 5.1.1 to: 5.3 ù 5.10. Add to the bullet list in S 5.1.1.2: ù sealed. Add to the bullet list in S 5.1.1.3: ù sealed. Add S 5.1.1.6 as follows: 5.1.1.6 Protected part attributes There are four kinds of descriptions of protected parts of a document, one for sealed information and three for enciphered information. They are: A sealed document profile description consists of: ù sealed document profile identifier; ù sealed document profile information, which is a document profile, with an identical structure to regular document profile. The differences are that: ù every attribute is optional; ù only the attributes that are sealed should be present. It is also possible to seal absent attributes. The enciphered document profile description consists of two attributes: ù enciphered document profile identifier; ù enciphered document profile information. The value of this attribute is the result of an encipherment of the confidentially protected part of the document profile. The confidentially protected part of the document profile has the same structure as a regular document profile. The differences are that: ù every attribute is option; ù only the attributes that are confidential should be enciphered. A pre-enciphered document body part description consists of two attributes: ù pre-enciphered document body part identifier; ù pre-enciphered body part information. The value of this attribute is the result of encipherment of the confidential part of the document body applied before the layout process has been performed. A post-enciphered document body part description consists of two attributes: ù post-enciphered document body part identifier; ù post-enciphered body part information. The value of this attribute is the result of encipherment of the confidential part of the document body applied after the layout process has been performed. PAGE55 Amend the table in S 5.3.5.5 as follows: include 410-T03ETABLE 1 Defaultable attributes that can be specified in defaut value lists Object type Defaultable attributes that can be specified Document layout root Document logical root (No attributes can be Page set specified) Composite or Basic page Presentation style Content architecture class Content type Dimensions Transparency Colour Page position Medium type Presentation attributes Sealed Frame Position Dimensions Border Layout path Permitted categories Transparency Colour Sealed Block Presentation style Content architecture class Content type Position Dimensions Border Transparency Colour Presentation attributes Sealed Composite logical object Protection Layout style Sealed Basic logical object Presentation style Content architecture class Content type Protection Layout style Sealed PAGE54 Insert a new S 5.3.6 5.3.6 Security attributes 5.3.6.1 Enciphered Constituents: Basic component descriptions and composite object descriptions Classification: Non-mandatory. Structure: Two parameters, "enciphered subordinates" and "protected part identifier". Permissible values: For the parameter "enciphered subordinates" "none", "all" or when "partial", a sequence of one or more non-negative integers. The value "partial" is only applicable to a basic object description in a document of the formatted processable form. For the parameter "protected part identifier", which is optional, the identifier of a pre- or a post-enciphered document body part. Definition: This attribute specifies if the object descriptions and content portions subordinate to this object component description are enciphered, and where the enciphered parts are found. When for a composite object description, the parameter "enciphered subordinates" has the value "all", then all subordinates object descriptions and all content portions directly referred to from any of them are enciphered. When for a composite object description, this attribute is not specified or the parameter "enciphered subordinates" has the value "none", then none of its immediate subordinate object descriptions are enciphered. When for a basic component description, the parameter "enciphered subordinates" has the value "all", then all content portions directly referred to from it are enciphered. When for a basic component description, this attribute is not specified or the parameter "enciphered subordinates" has the value "none", then none of the content portions directly referred to from it are enciphered. When for a basic object description in a formatted processable form document the parameter "enciphered subordinates" has the value "partial" in the form of a sequence of content portion identifiers, then only the specified content portions are enciphered. Each content portion identifier is represented by its last integer. When the parameter "enciphered subordinates" has a value other than "none" the parameter "protected part identifier" may specify the identifier of the pre- or post-enciphered document body part where the enciphered part is found. The layout process shall ignore the subtree of the logical structure for which the parameter "enciphered subordinates" has a value different from "none". The imaging process shall ignore the subtree of the . . . . . . layout structure for which the parameter "enciphered subordinates" has a value different from "none". Note ù This attribute specifies the current encipherment status. This attribute shall thus be updated at every encipherment and every decipherment of a document body part. PAGE55 Paragraph 5.3.6.2, replace the text after "Classification:" by: 5.3.6.2 Sealed Constituents: Component descriptions, and styles. Classification: Non-mandatory for object class descriptions; Non-mandatory for styles; Defaultable for object descriptions. Structure: Two parameters, "sealed status" and "seal identifiers". Permissible values: For the parameter "sealed status", "no" or "yes". For the optional parameter "seal identifiers", a list of seals in which this component or style is incorporated. Default value: Only the parameter "sealed status" has a default value. The default value is "no". Definition: This attribute specifies if this component description or style is incorporated in a seal for integrity, authenticity or non-repudiation of origin. The value "no" of the parameter "sealed status" implies that this component description or style is not incorporated in any seal for integrity, authenticity or non-repudiation of origin. When for a composite object description the parameter "sealed status" has a value "yes", then it and all its subordinates and all content portions directly referred to from any of them are included in one or more seals. When for a composite object class description or style the parameter "sealed status" has a value "yes", then it is included in one or more seals. When for a basic component description the parameter "sealed status" has a value "yes" then it and all content portions directly referred to from it are included in one or more seals. The parameter "seal identifier" specifies the seals in which the specified part of the document body is included. Note ù This attribute specifies the current sealing status. This attribute shall thus be updated at every sealing or deletion of a seal of a document body part. Add to the list in S 5.6.2: ù sealed (see S 5.3.6.2) Add to the list in S 5.8.2: ù sealed (see S 5.3.6.2) PAGE54 Insert a new S 5.10. 5.10 Protected part attributes 5.10.1 Protected part identifier Constituents: Protected part descriptions. Classification: Mandatory. Permissible values: A sequence of two non-negative integers. The values assigned to the first integer are: ù 6, if the protected part is a sealed document profile description; ù 7, if the protected part is an enciphered document profile description; ù 8, if the protected part is a pre-enciphered document body part description; ù 9, if the protected part is a post-enciphered document body part description; Representation: A character string consisting of decimal numerals and space characters. The decimal numerals are in one to one correspondence with the integers constituting the identifier; a space character is used as a separator between successive numerals. ` Definition: This attribute identifies a protected part description uniquely within the context of the document. 5.10.2 Sealed document profile information Constituents: Sealed document profile description. Classification: Non-mandatory. Permissible values: Any subset of a document profile. Representation: A document profile descriptor, with the additional property of allowing the value "null" for any attribute in the document profile that is not classified as mandatory. Definition: This attribute consists of the subset of the attributes of a document profile that is sealed for integrity, authenticity or non-repudiation of origin. A value "null" in an attribute of the sealed document profile indicates that this attribute is sealed as absent. 5.10.3 Enciphered information Constituents: Enciphered document profile description, pre-enciphered document body part description, post-enciphered document body part description. PAGE55 Classification: Non-mandatory. Permissible values: Enciphered information. Representation: An octet string Definition: For an enciphered document profile description, this attribute contains the result from a cryptographic algorithm applied to a confidential part of the document profile. For a pre-enciphered document body part description, this attribute contains the result from a cryptographic algorithm applied to a sequence of constituents of the document body before the layout process has been performed. For a post-enciphered document body part description, this attribute contains the result from a cryptographic algorithm applied to a sequence of constituents of the document body after the layout process has been performed. Add a new paragraph between SS 7 and 8 (after S 7.3.5): 7b Reference model for protecting parts of a document This paragraph provides a description of an abstract reference model for protecting parts of a document. The purpose of this clause is to aid the understanding of the semantics of the attributes related to the different aspects of security described in the T.410-Series Recommendations. It does not imply an actual implementation or definition of a standardized process. The document security processing consists of two phases. One phase enciphers or seals parts of the document and creates security information that is added to the document. The other phase makes use of security information in the document for deciphering a part of the document or checking a seal of a part of the document. These may occur during several phases of document processing, e.g., during the editing process, before the layout process or after the layout process. The description of the document security model is made in two steps: first an overall model covering the interchange of a document between an originator and a recipient (see S 7b.1); secondly covering the local systems of the originator and the recipient (see S 7b.2). The local system is here defined as those parts of a system for interchanging documents on which the originator or the recipient have a direct influence, i.e., preparing the document resulting in a valid data stream on the originator's side and after receiving an appropriate data stream on the recipient's side. The rest of the system consists of parts that are responsible for the actual transfer of the document and those security facilities that implement the security policy of the security domains to which the originator and the recipient belong. A more detailed description is found in the informative Annex G. 7b.1 The overall model Throughout the following the distinction is drawn between the handling of the complete document by the system and its security facilities and mechanisms, and the handling of specified parts of the document in the possession of the user, an originator or a recipient. PAGE54 The processes used for the preparation of the data stream belong to the local system of the originator. The processes used for handling the received data stream belong to the local system of the recipient. The two local systems are assumed to be able to provide and utilize the security information described here concerning the parts of the document. The local system may generate information concerning the handling of the complete document by a security facility outside the local system, but this is advisory. This information, an ODA security label, will be interpreted by the security facility in the context of the security policy in force in the security domain to which the originator belongs. 7b.2 The local system The model of the local system describes the security processes involved and their relations to the three processes (editing process, layout process and imaging process) described in the document processing model (see S 2.4). The local system of the originator prepares the document including the interchange of security information intended either for the recipient or for the security facility of the security domain of the originator (see Figure 2). Those aspects of the security information intended for the recipient are dealt with by the local system of the recipient and only deal with security protected parts of the document. Those aspects intended for the security facility of the security domain of the originator not belonging to the local system are specified in the ODA security label of the document profile and this facility will handle the document according to the security policy in force. It can only handle the document as a single unit, i.e., the whole of the document. The originator can: ù encipher certain parts of the document in order to provide confidentiality, i.e., encipherment; ù provide a seal which allows the recipient to perform checks for: ù content integrity; ù origin authenticity; ù non-repudiation of origin. Note ù Sealing has no influence on the content itself, whereas encipherment will change the content. The recipient can: ù decipher enciphered parts of the document; ù perform a check on content integrity; ù perform a check on origin authenticity; ù perform a check on non-repudiation of origin. Security protection can be applied to a document in either processable (PDA), formatted processable (FPDA) or formatted (FDA) form. In other words, the security protection can be performed either before, after or both before and after the layout process. Depending on which form the security protection is applied to, the protection will be different. Sealing of a document before or after the layout process is called pre- sealed and post-sealed, respectively. Sealing has no impact on the layout process or the imaging process. A seal, that has been made on a document can be only checked when the document is in the same form. Encipherment of a document before or after the layout process has quite different effects. Pre-encipherment is the term used for encipherment of parts of a document before the layout process and post-encipherment when it is performed after the layout process. PAGE55 Pre-encipherment of a document in processable form will resu t in a pre- enciphered processable document interchange format. A layout process will ignore all pre-enciphered parts in a pre-enciphered processable form document. The created layout structure will thus have no knowledge or indication of the existence of any pre-enciphered parts. A document in processable form or pre-enciphered processable form can serve as input to a layout process. This process will result in one of the forms: formatted processable form, formatted form, pre-enciphered formatted processable form, or pre-enciphered formatted form. These four forms can be post-enciphered, resulting in the four forms: post enciphered formatted processable form, post-enciphered formatted form, pre- and post-enciphered formatted processable form, or pre- and post-enciphered formatted form. The imaging process will ignore all pre- and post-enciphered parts of the document. But since the size and positions of a post-enciphered layout object is specified explicitly in the specific layout structure, the post-enciphered parts within the laid out areas will not be imaged. The imaging process receiving any of these documents will present them such that: ù all clear text parts will be imaged; ù the pre-enciphered parts will be completely lost in the imaging process; ù the post-enciphered parts will have claimed areas of correct dimensions, but their content is not imaged. All combinations of protection can be applied to a document, but not all combinations are possible for an individual part of the document. Add new Annex G to T.412: ANNEX G (to Recommendation T.412) (informative) Further information on security aspects within a document G.1 What can in principle be protected within a document? This Recommendation provides two categories of security aspects, namely: ù the incorporation of a security label which provides information of how the originator wants the system to handle the document as a whole; and ù the incorporation of security protections of parts of a document. The intended protection that is provided by this Recommendation on the document as a whole is the presence of the ODA security label. Although the security label is not sealed, an integrity protection of it can be achieved by sealing that particular part of the document. It is outside the scope of this Recommendation to provide any other protection mechanism on the document as a whole. The rest of this paragraph is constrained to the security aspects of parts of a document conforming to the T.410-Series Recommendations. G.1.1 What does a document contain? A document structured according to the T.410-Series Recommendations always contains the document profile. In addition it may contain styles, generic structures and specific structures. A characteristic feature of such a document is that if a structure is present in the document, it is always present in its entirety. A document that happens to get into the hands of a recipient will thus always contain the document profile. If it is a specific document, it will also always contain a complete document body. PAGE54 G.1.2 What can an unauthorized recipient do with a document? A recipient can, in principle, do anything that his local system allows with the document. It is here assumed that the recipient has access to a system in which any bit can be accessed, analysed, deleted, changed or added. In such a case, the recipient can delete and modify any part of the received document as well as adding any part to it. If the generic structure(s) is (are) also interchanged, the recipient can furthermore operate on the document according to the rules specified by the originator. It is thus not possible to provide any kind of access control to parts of a document. G.1.3 What protection can be made in a document? There are two aspects to consider, namely the protection against an unauthorized recipient getting semantic knowledge about a part of a document and the protection against an unauthorized recipient modifying a part of a document. ù What information can be protected? If the document contains any enciphered parts, the semantic content can be kept unknown to the recipient as long as the information for decipherment of that content is not known to that recipient. A recipient can, however, replace the content and the information that the document once contained in enciphered parts, and can change any clear text by deleting, changing or adding anything to it. Any information in the document profile can be deleted, modified or added. ù What manipulations can be protected against? If the unintended recipient, after any of the manipulations discussed under G.1.2, submits the document to the intended recipient, it is natural to ask what protection against such modifications can be made. First we observe that since any bit can be deleted, added or changed by the unintended recipient, the only mode of protection is in the form of detection of such modifications. Since the authenticity control and/or integrity control of any part of the document is specified in the interchanged document, in our case in the document profile, only changes, not replacements can be protected against. This implies that if the document contained any authenticity, integrity or enciphered part(s), the recipient can only perform a control against a modification if: a) either the information about the authenticity, integrity and encipherment is still retained in the document profile; or b) the intended recipient knows in advance, e.g. by the security policy, that such a document shall contain such protected parts. G.1.4 Summary G.1.4.1 What can be protected within a document? It is thus possible to protect a document against the following threats: a) against semantic knowledge of the content of parts of the document to an unauthorized recipient by means of encipherment; b) against unauthorized changes to, but not replacements of, parts of a document by means of detection that something, but not what, has been changed (integrity and authenticity controls); c) against unauthorized replacements of parts or the whole document by means of a pre-agreed security policy between the originator and the intended recipient. G.1.4.2 What cannot be protected within a document? It is thus not possible to protect a document against the following threats: a) against detection of replacements of parts or the whole document in an open interchange, i.e. in which no pre-agreed security policies have been made; PAGE55 b) against deletions, changes or additions to parts of a document by an unauthorized recipient. A feature that cannot be fulfilled in an open interchange according to the above analysis is the possibility to interchange access control information for parts of a document such that some (intended) recipients may do certain manipulations on that object, e.g. read only, whereas other recipients may have the right to modify it etc. The reason why these security aspects cannot be achieved is that such access cannot be controlled outside a closed environment as seen in S G.1.2 above. In a closed environment, however, such a protection can be achieved. This can, for example, be done in the form of an application comment, which specifies information that can be interpreted and enforced by all equipment within a particular environment in which the security policy is such that all equipment must be able to interpret and obey that information. Since such information cannot be enforced outside that environment, it cannot belong to this Recommendation, which deals with security aspects that can be relied upon anywhere in an open environment. It is more like editing instructions (application dependent) that can only be correctly understood and handled in a closed environment. It specifies the intentions rather than the constraints. G.2 Security features supported by the T.410-Series Recommendations The T.410-Series Recommendations support the interchange of information related to security aspects associated with a document conforming o the T.410- Series Recommendations. This includes the provisions: ù to hide parts of the document from unauthorized persons (confidentiality); ù to check the correctness of parts of the content of the received document (integrity); ù to prove the origin of parts of the received document (authenticity, non-repudiation of origin). The security aspects of the T.410-Series Recommendations complement the security facilities provided by the OSI and Telematic services. These security aspects are applicable to parts of a document. In addition, the T.410-Series Recommendations also provide an indication to the system for the handling of the complete document. The T.410-Series Recommendations do not address the broader aspects of security of systems, including those of the network, or security of workstations and terminals, which are local matters. G.2.1 Features provided to an originator The T.410-Series Recommendations provide the following security related features for an originator of a document: ù that any intended recipients can interpret the clear text parts of the document, but that only privileged recipients can interpret the clear text and certain additional specified parts of the document (confidentiality); ù that privileged recipients can obtain confirmation that specified parts of the document are intact, i.e. received exactly as originated (integrity); ù that privileged recipients can prove to a third party that specified parts of the document are intact, i.e. exactly as originated (integrity); ù that privileged recipients can obtain confirmation that the claimed originator is the source of specified parts of the document (authenticity); ù that privileged recipients can prove to a third party that the claimed originator is the source of specified parts of the document (authenticity, non-repudiation of origin). These protection mechanisms are further described in S G.3. PAGE54 In addition to these requirements on parts of the document, this Recommendation provides a support of the intentions of the originator for the complete document. The security policy of the security domain to which the originator belongs determines what actions to perform on the document, based on the information provided by the originator. This can incorporate topics such as confidentiality, integrity and authenticity for the whole document. G.2.2 Features provided to a privileged recipient The T.410-Series Recommendations provide the following security related features for a privileged recipient of a document: ù the ability of a privileged recipient to interpret all relevant parts of the document, including those specified parts that are not interpretable by a non-privileged recipient (confidentiality); ù the ability of a privileged recipient to confirm that specified parts of the document are intact, i.e. received exactly as originated (integrity); ù the ability of a privileged recipient to confirm that the claimed originator is the source of specified parts of the document (authenticity); ù the ability of a privileged recipient to prove to a third party that the claimed originator is the source of specified parts of the document, i.e. the purported originator cannot deny being the claimed source of those parts (authenticity, non-repudiation of origin). G.3 The kinds of protection mechanisms supported G.3.1 Confidentiality Confidentiality in a document concerns the prevention of non-privileged recipients from obtaining semantic knowledge about specified parts. Confidentiality of parts of a document is provided by the use of encipherment methods controlled by the originator and the privileged recipient. Confidentiality of the complete document may be indicated (ODA security label) or requested by the originator, but is to be provided by the system, in accordance with the security policy of the domain to which the originator belongs. G.3.2 Integrity Integrity in a document concerns the provision of information whereby a privileged recipient may verify that the document or specified parts of it have not been changed since the originator requested them to be sealed for that purpose. The sealing of parts of the document, and the provision of the appropriate seal for use by privileged recipients, is under the control of the originator. The checking of those parts is under the control of the privileged recipient. Production and checking of integrity information for the complete document may be indicated or requested by the originator, but is to be provided by the system, in accordance with the security policy of the domain to which the originator belongs. The assurance provided by integrity alone is limited to detection of change; replacement of the complete sealed parts, whether suitably sealed or not, would be undetected. Some assurance of integrity may also be derived from the valid successful decipherment of parts marked as confidential. G.3.3 Authenticity Authenticity in a document concerns the provision of information whereby a recipient may verify that the source of the document or specified parts of it, is as claimed. This property is provided when the integrity seal is such that the privileged recipient can determine the source of the sealed content. PAGE55 G.3.4 Non-repudiation of origin The property that an originator can prove to a third party to be the source of a document, or specified parts of it, is called non-repudiation of origin. This property is provided when the integrity and authenticity seal is produced using a digital signature technique such as outlined below (see S G.4.2). G.4 Techniques supported by the T.410-Series Recommendations G.4.1 Techniques for confidentiality Encipherment: A document or any part of a document may be enciphered. The encipherment algorithm and information relating to the key(s) for decipherment is specified or indirectly referenced in the document profile. If part of a specific structure in a document is enciphered, this is also marked in the appropriate structure. The T.410-Series Recommendations support the use of encipherment techniques in which all protected parts of the document can be grouped together in such a way that a privileged recipient only needs to perform a single instance of decipherment, i.e. knowledge of only a single key is required by that recipient. For a set of different privileged recipients, however, the encryption algorithms and keys may be different, so that each specified part of the document can be read exclusively by a certain privileged recipient. But by use of a symmetric key algorithm and exchanging the symmetric key, e.g. by means of an asymmetric key algorithm, several separate privileged recipients can decipher the same parts. When enciphering styles or object classes, caution should be made that none of these constituents are referred to from any part of the document that is not belonging to the same encipherment. G.4.2 Techniques f r sealing for content integrity, authenticity and non- repudiation Fingerprint: For sealing, it is convenient to introduce the concept of fingerprint. A fingerprint is obtained by processing the specified part of the document using a specified algorithm. The main property of the algorithm is that it is computationally infeasible to construct another input to the algorithm resulting in the same output. In general, the fingerprint will be shorter than the information it characterizes (i.e. of the order of bytes rather than kilobytes). Seal: A seal for a specified part of the document may be produced by the originator taking the fingerprint for the specified information together with other optional data such as the identity of the originator applying the seal, location, time, etc. and enciphering this using an identified algorithm. The recipient may decipher the seal, and, depending on the particular qualities of the encipherment algorithm and key, may verify to a known level of assurance the integrity of the information and the authenticity of the claimed source, as follows: ù Integrity of the specified information may be checked by, firstly, re running the fingerprint process and comparing the result with the associated fingerprint received in the document, and secondly, that the same fingerprint being used in calculating the seal. ù Authenticity of origin of the specified information may be checked as for integrity, and that the seal is composed such that the recipient can, to his own satisfaction, verify the originator. PAGE54 ù Non-repudiation of origin of the specified information, as a special case of origin authenticity, may be provided if a digital signature process is used for sealing; in this case, the integrity of the information and the authenticity of the source may be proven to a third party, and the source who applied the seal cannot deny responsibility for it; the particular quality of the digital signature is most readily provided by the use of an asymmetric key crypto-system, where the secret ("private") key is allocated to a single originator by a trusted key certification authority, and the corresponding ("public") key may be made available by an authority to authorized recipients. G.5 Further details on the reference model for protecting parts of a document G.5.1 The overall model This clause provides a more detailed description of the model than found in S 7b.1. Figure G.1/T.412 illustrates the processes involved in the interchange of a document between the local system of the originator and the transfer system. The local system of the originator exports a document with the data stream (A). This document may contain protected parts. It may also contain an ODA security label. In the case where the originator belongs to a security domain in which the security policy requires documents to be associated with a security label, then a security label envelope enclosing the document will be generated. This generation is performed by a security facility immediately outside the local system. When determining the value of the security label, the ODA security label can be taken into account. The process applied to the exported data stream is completely directed by the security policy of the security domain to which the originator belongs. The responsibility of the process is to take appropriate actions on the whole document, e.g. encipher it. According to the security policy in force, an operation F on the data stream will take place. If no action takes place, F is the identity operator I with the result that F(A) = I(A) = A. The transfer system does not need to have any understanding of ODA. It is responsible for the physical interchange of the document. Typically this may be achieved by MHS/MOTIS, FTAM, a floppy disk, etc. Figure G.2/T.412 illustrates the processes involved in the interchange of a document between the transfer system and the local system of the recipient. The data stream delivered by the transfer system is identical to that entering it, i.e. F(A) in Figures G.1/T.412 and G.2/T.412. The process applied to the received data stream F(A) serves the purpose of transforming the data stream back to the format of A. This implies finding the inverse function F-1 and also to perform this operation on the data stream. Depending on the security policy it may provide a new security label envelope. It finally also provides the document without an envelope to, e.g. an editor. The resulting data stream from this process is the one imported by the local system of the recipient. G.5.2 The local system This clause provides a more detailed description of the local system than found in S 7b.2. If an ODA security label shall be specified in the document, the security policy of the security domain of the originator specifies: a) the ODA security label to be associated with the document according to the content of the document; b) how the security facility shall handle a document according to its ODA security label. PAGE55 In our reference model of the local system, the security attributes other than the ODA security label are processed by a Security Handler in the local system. The originator of a document will use the security handler in a different way than the recipient of the document. Figure G.3/T.412 illustrates the aspects of handling confidentiality in the local system. The editing process, layout process and imaging process are illustrated as in Recommendation T.411. The Security Handlers for enciphering parts of a document are marked by rectangles with a bold solid border and those for deciphering parts of a document with double borders. It should be pointed out that a document that bypasses the Security Handler on the recipient side will still be interpretable as a normal document with the exception that any enciphered parts will not be imaged and that no check on seals has been made. The security handler can be applied to a document in either processable, formatted processable or formatted form. In other words, the security processing can be performed either before, after or both before and after the layout process. Depending on which form the Security Handler is applied to, the protection will be different. A recipient may check for integrity and origin authenticity by means of a seal. This seal, which is provided by the originator, is composed of a fingerprint of the parts of the document to be validated together with optional additional information, such as time, place, name, etc. It is then enciphered such that the authenticity can be verified to the satisfaction of the recipient. If the encipherment method used in the seal is performed by means of some "public key" method, it provides a digital signature. A digital signature may be checked by any recipient having access to the public key. In cases based on a symmetric crypto system, the check may only be done by privileged recipients in possession of appropriate key and algorithm information. This latter method is less powerful in the sense that it cannot be used to convince a third party of the authenticity, or to protect against forgery by the recipient. Since the Security Handler did not change the content itself when evaluating a seal, it is quite possible to perform this processing on a document both before and after the layout process without constraints. This is not true for encipherment. A privileged recipient receiving a document in a pre-enciphered form can perform a pre-decipherment before the layout process acts on the document. If this is not done, e.g. by an intended but not privileged recipient, the resulting document interchan e format pre-enciphered formatted processable or pre- enciphered formatted form will be presented by an imaging process with invisible enciphered parts. Not even empty areas of the enciphered parts will be visible. In the pre-enciphered formatted form all information about the enciphered data is lost and it is not possible to recover the information. Thus, this document interchange format is in fact a formatted form document, but smaller than that originally prepared by the originator. All forms can be used as interchange formats. These are illustrated in Figure G.3/T.412. The figure also illustrates how the different interchanged formats should be handled in order to retrieve the full information of the document as well as what will be the result of an imaging process handling a non deciphered version of the document. G.6 Document application profiles This Recommendation provides a great variety of ways to protect parts of a document. As for other properties of this Recommendation it is the task of the document application profiles to specify for each requirement the optimum solution. Figure G.1 = 16 cm Figure G.2 = 16 cm PAGE54 Figure G.3 page entière PAGE55 V.3 Changes to Recommendation to T.414 Insert the following clauses between S 5.2.6 and 5.2.7 5.2.6a Sealed document profiles This attribute is used if and only if the document contains any sealed document profile descriptions. The value of this attribute (if specified) is "present". 5.2.6b Enciphered document profiles This attribute is used if and only if the document contains any enciphered document profile descriptions. This value of this attribute (if specified) is "present". 5.2.6c Pre-enciphered document body parts This attribute is used if a d only if the document contains any pre- enciphered document body part descriptions. The value of this attribute (if specified) is "present". 5.2.6d Post-enciphered document body parts This attribute is used if and on y if the document contains any post- enciphered document body part descriptions. The value of this attribute (if specified) is "present". Add a new S 5.5 5.5 Security attributes These attributes provide information about those parts of the document that are protected in a secure manner, i.e. provide confidentiality, integrity, authenticity or non-repudiation. The first attribute is concerned with an indication to the system on how to treat the document as a whole. All the other attributes in this paragraph are concerned with protected parts of the document. The attributes described in SS 5.5.2 to 5.5.4 are concerned with integrity, authenticity and non-repudiation. The attributes described in SS 5.5.5 to 5.5.7 are concerned with confidentiality. When any of these attributes are specified, they must be present in the regular document profile preceding the document body. 5.5.1 ODA security label This attribute specifies the ODA security label associated with this document. It has two parameters: ù ODA label text; the value consists of a string of characters from the document profile character set; ù ODA label data; the value consists of an octet string. 5.5.2 Sealed document profiles This attribute specifies information associated with each sealed document profile; where to find the sealed document profile, the privileged recipients associated with it and the information needed to check its seal. PAGE54 It consists of a sequence of parameters, one for each sealed document profile. The sequence of parameters are: ù "sealed document profile identifier", which uniquely identifies the constituent of the sealed document profile; ù "privileged recipients", which consist of a list of names of privileged recipients associated with this sealed document profile; ù "document profile seal", which consists of three sub-parameters: ù "seal method", which identifies the seal algorithm used; ù "sealed information", which identifies what has been sealed; ù "seal", which is the seal. 5.5.3 Pre-sealed document body parts This attribute specifies information associated with each pre-sealed document body part; which body parts have been sealed, the privileged recipients associated with it and the information needed to check its seal. It consists of a sequence of parameters, one for each pre-sealed document body part. The sequence of parameters are: ù "seal identifier", which identifies the seal; ù "privileged recipients", which consists of a list of the names of privileged recipients associated with this pre-sealed document body part; ù "sealed constituents", which consist of a sequence of the sealed constituents; ù "document body part seal", which consists of three sub-parameters: ù "seal method", which identifies the seal algorithm used; ù "sealed information", which identifies what has been sealed; ù "seal", which is the seal. 5.5.4 Post-sealed document body parts This attribute specifies information associated with each pre-sealed document body part; which body parts have been sealed, the privileged recipients associated with it and the information needed to check its seal. It consists of a sequence of parameters, one for each post-sealed document body part. The sequence of parameters are: ù "seal identifier", which identifies the seal; ù "privileged recipients", which consists of a list of the names of privileged recipients associated with this post-sealed document body part; ù "sealed constituents", which consists of a sequence of the sealed constituents; ù "document body part seal", which consists of three sub-parameters: ù "seal method", which identifies the seal algorithm used; ù "sealed information", which identifies what has been sealed; ù "seal", which is the seal. 5.5.5 Enciphered document profiles This attribute specifies information associated with each enciphered document profile; where to find the enciphered document profile, the privileged recipients associated with it and the information needed to decipher it. It consists of a sequence of parameters, one for each enciphered document profile. The sequence parameters are: ù "enciphered part identifier", which identifies the enciphered document profile; ù "privileged recipie t information", which consists of three sub- parameters: PAGE55 ù "privileged recipients", which consists of a list of the names of privileged recipients associated with this enciphered document profile; ù "method information", which identifies the encipherment algorithm used; ù "key information", which provides information for the privileged recipient to deduce the key needed to decipher the enciphered document profile; this parameter has two sub-sub-parameters: ù "key method", which identifies the method how to deduce the key; ù "additional information", which in combination with the previous sub-sub-parameter provides the privileged recipient with information on how to deduce the key needed for the deciphering. 5.5.6 Pre-enciphered document body parts This attribute specifies information associated with each pre-enciphered document body part; where to find the enciphered document body part, the privileged recipients associated with it and the information needed to decipher it. It consists of a sequence of parameters, one for each pre-enciphered document body part. The sequence of parameters are: ù "enciphered part identifier", which identifies the pre-enciphered document body part; ù "privileged recipie t information", which consists of three sub- parameters: ù "privileged recipients", which consists of a list of the names of privileged recipients associated with this pre-enciphered document body part; ù "method information", which identifies the encipherment algorithm used; ù "key information", which provides information for the privileged recipient to deduce the key needed to decipher the pre-enciphered document body part, this parameter has two sub-sub-parameters: ù "key method", which identifies the method how to deduce the key; ù "additional information", which in combination with the previous sub-sub-parameter provides the privileged recipient with information on how to deduce the key needed for the deciphering. 5.5.7 Post-enciphered document body parts This attribute specifies information associated with each post-enciphered document body part; where to find the enciphered document body part, the privileged recipients associated with it and the information needed to decipher it. It consists of a sequence of parameters, one for each post-enciphered document body part. The sequence of parameters are: ù "enciphered part identifier", which identifies the post-enciphered document body part; ù "privileged recipie t information", which consists of three sub- parameters: ù "privileged recipients", which consists of a list of the names of privileged recipients associated with this post-enciphered document body part; ù "method information", which identifies the encipherment algorithm used; ù "key information", which provides information for the privileged recipient to deduce the key needed to decipher the post-enciphered document body part; this parameter has two sub-sub-parameters: ù "key method", which identifies the method how to deduce the key; ù "additional information", which in combination with the previous sub-sub-parameter provides the privileged recipient with information on how to deduce the key needed for the deciphering. PAGE54 V.4 Changes to Recommendation T.415 Add four items after "- text unit" in S 5.1 ù sealed document profile descriptor; ù enciphered document profile descriptor; ù pre-enciphered document body part descriptor; ù post-enciphered document body part descriptor. Add four items after "- text unit" in S 5.2 ù sealed document profile descriptor; ù enciphered document profile descriptor; ù pre-enciphered document body part descriptor; ù post-enciphered document body part descriptor. Add four items after item i) in S 5.2 j) sealed document profile descriptors; k) enciphered document profile descriptors; l) pre-enciphered document body part descriptors; m) post-enciphered document body part descriptors. Add three items after "- text unit" in S 5.3 ù sealed document profile descriptors; ù enciphered document profile descriptors; ù post-enciphered document body part descriptors. Add three items after item d) in S 5.3 e) sealed document profile descriptors; f) enciphered document profile descriptors; g) post-enciphered document body part descriptors. Change in first paragraph of S 5.4 "or layout style descriptor" to ", layout style descriptor, sealed document profile descriptor, enciphered document profile descriptor, pre-enciphered document body part descriptor or post-enciphered document body part descriptor" Change in second paragraph of S 5.4 "and each object" to ", each object and each protected part" Add a new paragraph between SS 5.4 and 5.5. 5.4a ASN.1 encoding and cryptographic techniques 5.4a.1 Enciphered information PAGE55 The parts of the document body or the parts of the document profile which are the output of an encipherment process will form a new constituent of the document. It consists of an identifier and the enciphered information. The latter is of the ASN.1 "OCTET STRING" type, the value of which will remain unchanged in any transfer. 5.4a.2 Sealed information The ODA security attributes and ODA document parts are defined in ASN.1. To ensure a unique encoding of ASN.1, the ASN.1 Distinguished Encoding Rules are used. These rules are defined in Annex E and information on how they can be used is found in Annex F. The ASN.1 Distinguished Encoding Rules specify a set of restrictions on the ASN.1 Basic Encoding Rules, which provide a unique mapping between ASN.1 and its representation. This is required from a cryptographical point of view. The parts of the document profile and the parts of the document body subject to sealing will remain unchanged after the sealing process. The ASN.1 Distinguished Encoding Rules will assure that the same encoding of the information can be established by the recipient as that used by the originator when sealing. This is necessary in order to obtain identical fingerprints of the information, the means by which one associates the content with the seal. The seal is composed of a set of data. Three basic steps are performed to generate this seal: a) The chosen information (encoded according to the distinguished encoded rules) is input to a hashing process which generates a fingerprint. The encoded form of the fingerprint being an "OCTET STRING". b) The fingerprint together with additional optional information is called "Sealed-Information". The optional parameters are the date and time of day, in accordance with ISO 8601, the name and the location of the creator of the seal. This is (again encoded according to the ASN.1 Distinguished Encoding Rules) input to a cryptographic process which generates the seal. The encoded form of the seal being an "OCTET STRING". c) Provide information of the seal method such that the seal can be checked. This is specified in the type "Seal Method" and consists of information of both the generation of the fingerprint as well as information of how to decipher the seal. The order of the constituents is the same as the one specified by the interchange format class. When the order of the constituents is not completely specified by the interchange format class, the following rules apply: ù object classes are to be sealed in the same order as they are specified in the parameter "sealed constituents"; ù for interchange format class A, the common content portions are to be sealed in the same order as the corresponding object classes; ù presentation styles are to be sealed in the same order as they are specified in the parameter "sealed constituents"; ù layout styles are to be sealed in the same order as they are specified in the parameter "sealed constituents". Add after "FROM Text-Units" in IMPORTS in S 5.5 Sealed-Doc-Prof-Descriptor, Enciphered-Doc-Prof-Descriptor, Preenciphered-Bodypart-Descriptor, Postenciphered-Bodypart-Descriptor FROM Protected-Part-Descriptors; -- See S 5.13 -- "(Editing instruction: replace ";" by "," after "Text-Units".)" Add after the line "layout-style" in S 5.5 sealed-doc-prof-descriptor [9]0 IMPLICIT Sealed-Doc-Prof-Descriptor, enciphered-doc-prof-descriptor [10] IMPLICIT Enciphered-Doc-Prof- Descriptor, preenciphered-bodypart-descriptor [11] IMPLICIT Preenciphered-Bodypart-Descriptor, postenciphered-bodypart-descriptor [12] IMPLICIT Postenciphered-Bodypart-Descriptor } PAGE54 (Editing instructio : Change the "}" to "," after "Layout-Style- Descriptor".) Insert before ";" in EXPORTS in S 5.6: , Personal-Name Insert after "Object-or-Class-Identifier" in IMPORTS in S 5.6 Protected-Part-Identifier, Style-Identifier Insert after data item "layout-styles" in the Document-Profile-Descriptor of S 5.6 sealed-profiles [12] IMPLICIT NumericString OPTIONAL, enciphered-profiles [13] IMPLICIT NumericString OPTIONAL, preenciphered-bodyparts [14] IMPLICIT NumericString OPTIONAL, postenciphered-bodyparts [15] IMPLICIT NumericString OPTIONAL, Insert after the li e "document-management-attributes" in the Document- Profile-Descriptor of S 5.6 document-security-attributes [16] IMPLICIT Document-Security- Attributes OPTIONAL } (Editing instruction: change the " " to "," after "Document-Management- Attributes OPTIONAL".) Insert before "END" in S 5.6 Document-Security-Attributes :: = SET { oda-security-label [0] IMPLICIT Oda-Security-Label OPTIONAL, sealed-doc-profiles [1] IMPLICIT Sealed-Doc-Profiles OPTIONAL, presealed-doc-bodyparts [2] IMPLICIT Sealed-Doc-Bodyparts OPTIONAL, postsealed-doc-bodyparts [3] IMPLICIT Sealed-Doc-Bodyparts OPTIONAL, enciphered-doc-profiles [4] IMPLICIT Protected-Doc-Parts OPTIONAL, preenciphered-doc-bodyparts [5] IMPLICIT Protected-Doc-Parts OPTIONAL, postenciphered-doc-bodyparts [6] IMPLICIT Protected-Doc-Parts OPTIONAL } Oda-Security-Label :: = SEQUENCE { oda-label-text [0] IMPLICIT Character-Data OPTIONAL, oda-label-data [1] IMPLICIT OCTET STRING OPTIONAL } Seal-Data :: = SEQUENCE { seal-method [0] IMPLICIT Seal-Method OPTIONAL, sealed-information [1] IMPLICIT Sealed-Information OPTIONAL, seal [2] IMPLICIT OCTET STRING } Seal-Method :: = SEQUENCE { fingerprint-method [0] IMPLICIT Method-Information OPTIONAL, fingerprint-key-information [1] IMPLICIT Key-Information OPTIONAL, sealing-method [2] IMPLICIT Method-Information OPTIONAL, sealing-key-information [3] IMPLICIT Key-Information OPTIONAL } Sealed-Information :: = SEQUENCE { fingerprint [0] IMPLICIT OCTET STRING OPTIONAL, time [1] IMPLICIT Date-and-Time OPTIONAL, sealing-orig-id [2] IMPLICIT Personal-Name OPTIONAL, location [3] IMPLICIT Location OPTIONAL } Method-Information :: = SEQUENCE { unique-method-info [0] IMPLICIT OBJECT IDENTIFIER OPTIONAL, descriptive-method-info [1] IMPLICIT Character-Data OPTIONAL } PAGE55 Key-Information :: = SEQUENCE { method-information [0] IMPLICIT Method-Information OPTIONAL, additional-information [1] IMPLICIT Additional-Information OPTIONAL } Additional-Information :: = SEQUENCE { descriptive-information [0] IMPLICIT Character-Data OPTIONAL, octet-string [1] IMPLICIT OCTET STRING OPTIONAL } Location :: = SEQUENCE { unique-location [0] IMPLICIT OBJECT IDENTIFIER OPTIONAL, descriptive-location [1] IMPLICIT Character-Data OPTIONAL } Sealed-Doc-Profiles :: = SET OF SEQUENCE { sealed-doc-prof-descriptor-id [0] IMPLICIT Protected-Part-Identifier, privileged-recipients [1] IMPLICIT SET OF Personal-Name OPTIONAL, doc-prof-seal [2] IMPLICIT Seal-Data } Sealed-Doc-Bodyparts :: = SET OF SEQUENCE { seal-id [0] IMPLICIT INTEGER, sealed-constituents [1] IMPLICIT Sealed-Constituents, privileged-recipients [2] IMPLICIT SET OF Personal-Name OPTIONAL, doc-bodypart-seal [3] IMPLICIT Seal-Data } Sealed-Constituents :: = SEQUENCE { object-class-identifiers [0] IMPLICIT SEQUENCE OF Object-or- Class-Identifier OPTIONAL, presentation-style-identifiers [1] IMPLICIT SEQUENCE OF Style-Identifier OPTIONAL, layout-style-identifiers [2] IMPLICIT SEQUENCE OF Style- Identifier OPTIONAL, object-identifiers [3] IMPLICIT SEQUENCE OF Object-or- Class-Identifier OPTIONAL } Protected-Doc-Parts ::= SET OF SEQUENCE { protected-doc-part-id [0] IMPLICIT Protected-Part- Identifier, priv-recipients-info [1] IMPLICIT SET OF Priv-Recipients- Info } Priv-Recipients-Info :: = SEQUENCE { privileged-recipients [0] IMPLICIT SET OF Personal-Name OPTIONAL, encipherment-method-info [1] IMPLICIT Method-Information OPTIONAL, encipherment-key-info [2] IMPLICIT Key-Information OPTIONAL } Add after "style-identifier" in EXPORTS in S 5.7 , Protected-Part-Identifier Insert before the data item "Layout-Category-Name" in S 5.7 Protected-Part-Identifier :: = [APPLICATION 7] IMPLICIT PrintableString -- only digits and space are used in the present version of this [R|IS]; other characters are reserved for extensions; a "null" value is represented by an empty string -- PAGE54 Insert after "Border" in EXPORTS of S 5.8 Enciphered, Sealed. Change in IMPORTS of S 5.8 IMPORTS Object-or-Class-Identifier, Style-Identifier, to IMPORTS Object-or-Class-Identifier, Style-Identifier, Protected-Part-Identifier, -- see S 5.6 -- Insert before the data item "Layout-Object-Descriptor" in S 5.8 Enciphered :: = SEQUENCE { enciphered-subordinates CHOICE { none-all [0] IMPLICIT INTEGER { none(0), all(1) }, partial [1] IMPLICIT SEQUENCE OF Numeric String}, protected-part-id [2] IMPLICIT Protected-Part- Identifier OPTIONAL } Sealed :: = SEQUENCE { sealed-status [0] IMPLICIT INTEGER { no(0), yes(1) }, seal-ids [1] IMPLICIT SET OF INTEGER OPTIONAL } Add to both Layout-Object-Descriptor-body a d to Layout-Class-Descriptor- Body in S 5.8 enciphered [27] IMPLICIT Enciphered OPTIONAL, sealed [28] IMPLICIT Sealed OPTIONAL} (Editing instruction: Change the "}" to "," after the last "OPTIONAL" of both the "Layout-Object-Descriptor-Body" and the "Layout-Class-Descriptor-Body") Change in IMPORTS of S 5.9 IMPORTS Object-or-Class-Identifier, Style-Identifier, to IMPORTS Personal-Name FROM Document-Profile-Descriptor Object-or-Class-Identifier, Style-Identifier, -- see S 5.6 -- Insert after "Binding-Pair" in IMPORTS in S 5.9 Enciphered, Sealed. Add to both Logical-Object-Descriptor-Body and to Logical-Class-Descriptor Body in S 5.9 enciphered [27] IMPLICIT Enciphered OPTIONAL, sealed [28] IMPLICIT Sealed OPTIONAL} (Editing instruction; Change the "}" to "," after the last "OPTIONAL" of both t e "Logical-Object-Descriptor-Body" and the "Logical-Class-Descriptor- Body") Insert before "Object-or-Class-Identifier" in IMPORTS of S 5.10 Sealed Add to both Presentation-Style-Descriptor and to Layout-Style-Descriptor in S 5.10 sealed [6] IMPLICIT Sealed OPTIONAL} PAGE55 (Editing instruction: Change the "}" to "," after the last "OPTIONAL" of both the "Presentation-Style-Descriptor" and the "Layout-Style-Descriptor") Change S 5.11 of Recommendation T.415 as follows: 5.11 Default value lists Default-Value-Lists { 2 8 1 5 11 } DEFINITIONS :: = BEGIN EXPORTS Default-Value-Lists-Logical, Default-Value-Lists-Layout; IMPORTS Style-Identifier, Layout-Category-Name FROM Identifiers-and-Expressions -- see S 5.7 -- Measure-Pair, One-Of-Four-Angles, Medium-Type, Dimension-Pair, Transparency, Colour, Border, sealed FROM Layout-Descriptors -- see S 5.8 -- Protection FROM Logical-Descriptors -- see S 5.9 - - Presentation-Attributes FROM Style-Descriptors; -- see S 5.10 -- Default-Value-Lists-Layout :: = SET { page-attributes [2] IMPLICIT Page-Attributes OPTIONAL, frame-attributes [3] IMPLICIT Frame-Attributes OPTIONAL, block-attributes [4] IMPLICIT Block-Attributes OPTIONAL } Default-Value-Lists-Logical :: = SET { composite-logical-attributes [5] IMPLICIT Composite-Logical-Attributes OPTIONAL, basic-logical-attributes [6] IMPLICIT Basic-Logical-Attributes OPTIONAL } Page-Attributes :: = SET { dimensions <Attribute OPTIONAL, transparency <Attribute OPTIONAL, presentation-attributes <Attribute OPTIONAL, page-position <Attribute OPTIONAL, medium-type <Attribute OPTIONAL, presentation-style <Attribute OPTIONAL, colour <Attribute OPTIONAL, sealed <Attribute OPTIONAL } Frame-Attributes :: = SET { position <Attribute OPTIONAL, dimensions <Attribute OPTIONAL, transparency <Attribute OPTIONAL, layout-path <Attribute OPTIONAL, permitted-categories <Attribute OPTIONAL, colour <Attribute OPTIONAL, border <Attribute OPTIONAL, sealed <Attribute OPTIONAL } Block-Attributes :: = SET { position <Attribute OPTIONAL, dimensions <Attribute OPTIONAL, transparency <Attribute OPTIONAL, presentation-attributes <Attribute OPTIONAL, presentation-style <Attribute OPTIONAL, colour <Attribute OPTIONAL, border <Attribute OPTIONAL, sealed <Attribute OPTIONAL } PAGE54 Composite-Logical-Attributes :: = SET { protection <Attribute OPTIONAL, layout-style <Attribute OPTIONAL, sealed <Attribute OPTIONAL } Basic-Logical-Attributes :: = SET { presentation-attributes <Attribute OPTIONAL, -- only for use for the attribute content-architecture-class the content architecture specific attributes can only be referenced by use of presentation style -- protection <Attribute OPTIONAL, presentation-style <Attribute OPTIONAL, layout-style <Attribute OPTIONAL, sealed <Attribute OPTIONAL } Attribute :: = CHOICE { position 0[0] IMPLICIT Measure-Pair, dimensions 0[1] IMPLICIT Dimension-Pair, transparency 0[2] IMPLICIT Transparency, presentation-attributes 0[3] IMPLICIT Presentation- Attributes, layout-path 0[4] IMPLICIT One-Of-Four-Angles, page-position 0[5] IMPLICIT Measure-Pair, medium-type 0[6] IMPLICIT Medium-Type, permitted-categories 0[7] IMPLICIT SET OF Layout-Category-Name, protection 0[8] IMPLICIT Protection, presentation-style 0[9] IMPLICIT Style-Identifier, layout-style [10] IMPLICIT Style-Identifier, colour [11] IMPLICIT Colour, border [12] IMPLICIT Border, sealed [13] IMPLICIT Sealed } END 5.13 Protected part descriptors Protected-Part-Descriptors { 2 8 1 5 13 } DEFINITIONS :: = BEGIN EXPORTS Sealed-Doc-Prof-Descriptor, Enciphered-Doc-Prof-Descriptor, Preenciphered-Bodypart-Descriptor, Postenciphered-Bodypart-Descriptor; IMPORTS Document-Profile-Descriptor FROM Document-Profile-Descriptor -- see S 5.6 -- Protected-Part-Identifier FROM Identifiers-and-Expressions -- see S 5.7 - - Sealed-Doc-Prof-Descriptor :: = SEQUENCE { sealed-doc-prof-identifier Protected-Part-Identifier, sealed-doc-prof-information Document-Profile-Descriptor } Enciphered-Doc-Prof-Descriptor :: = SEQUENCE { enciphered-doc-prof-identifier Protected-Part-Identifier, enciphered-doc-prof-information Enciphered-Information } PAGE55 Preenciphered-Bodypart-Descriptor :: = SEQUENCE { preenciphered-bodypart-identifier Protected-Part-Identifier, preenciphered-bodypart-info Enciphered-Information } Postenciphered-Bodypart-Descriptor :: = SEQUENCE { postenciphered-bodypart-identifier Protected-Part-Identifier, postenciphered-bodypart-info Enciphered-Information } Enciphered-Information :: = OCTET STRING END Insert in Annex B APPLICATION 7 Protected-Part-Identifier S 5.7 Insert in Annex C { 2 8 1 5 13 } Identifies Module S 5.13 Protected-Part-Descriptors [Add two new Annexes, Annex E and Annex F|Insert two new Annexes before Annex E and rename the old Annex E and Annex F to Annex G and Annex H, respectively] ANNEX G (to Recommendation T.415) (normative) The ASN.1 Distinguished Encoding Rules G.1 Overview The following text specifies the Distinguished Encoding Rules as additional constraints on encoders of ASN.1 types. The encodings may be used for transmission when either the ASN.1 Basic Encoding Rules or the ASN.1 Distinguished Encoding Rules have been agreed as specifying the transfer syntax. They may only be assumed by a receiver if the ASN.1 Distinguished Encoding Rules has been agreed as specifying the transfer syntax. The model is based on taking values identified at the abstract syntax level and removing all options from the Basic Encoding Rules, thus providing a one-to-one mapping between abstract values and a bitstring. It is important to recognize that when applying this model we are talking about abstract syntax values, not about local representations. In particular, the abstract syntax value of a character in a character string identifies both the character and the register entry it is notionally taken from, and the abstract syntax value for a real is a (mathematical) real number (of arbitrary precision and size), capable of a finite representation using base 2 or using base 10. Where the following text makes no mention of a type, the Basic Encoding Rules provide no options, and shall be applied unchanged. G.2 String types Where the type definition specifies the zero trailing bits in a bitstring are not significant, trailing zero bits shall be eliminated before applying the rules below. Where the type definition specifies that zero trailing bits in a bitstring are significant, they shall be included in the encoding. PAGE54 Octetstrings and bitstrings (and types derived from them by tagging or subtyping) shall be encoded with a primitive encoding if they contain less than 1000 octets or 8000 bits respectively, and as a constructed encoding if they contain more octets or bits than this. The constructed encoding shall use fragments of 1000 octets or 8000 bits for all fragments except the last, and each fragment shall be encoded with a primitive encoding. Each unused bit in the final octet of the encoding of a bitstring value shall be set to zero. G.3 Length forms The indefinite length shall be used for all constructed encodings, and the definite length form shall be used for all primitive encodings. Where the definite length form is used, the short form shall be used in all cases where the contents octets are less than or equal to 127 octets. In the long form, the minimum number of octets shall be used to encode the length. G.4 Character strings For a character string type, the value is defined as a character from a specified register entry in the International Register of Character Sets. (For PrintableString and NumericString, the encoding is separately specified in the Basic Encoding Rules, and this shall be used.) Where the Distinguished Encoding Rules are being used by a sender, the choice shall be consistently made for the application of the Distinguished Encoding Rules and the choice made in determining the encoding for any subsequent transmission of the character string. Where the Distinguished Encoding Rules are being used to encode a value which has been received, the transmission will have identified the register entry for each character. The encoding shall generate escape sequences to designate and invoke a new register entry only when the register entry for the character is different from that currently designated as G0, C0 or C1. All designations and invocations shall be into the G0 set or the C0 set. G.5 Components of sets and sequences If the value of a component of a set or sequence which is marked DEFAULT is equal to the default value, it shall be absent from the encoding. The components of a set type shall be encoded in an order determined as follows: a) those with universal class tags shall be encoded first, followed by those with application class tag , followed by those with context- specific tags, followed by those with private class tags; b) within each class of tags, the components shall be encoded in the ascending order of their tags. The components of a set-of value shall be encoded in ascending order of the octet values of their encodings. G.6 Boolean type If the value of a boolean type is true, the encoding shall have its contents octets set to hexadecimal FF. G.7 Real type The encoding of a real type which is base 2 related shall proceed as follows: a) The number shall be represented as S*M*2**E Where S is plus or minus one, M is zero or is an odd integer, and E is a positive or negative integer or zero. b) The value shall then be encoded with no change to M or E, and with F set to zero. The exponent shall be encoded in the minimum number of octets, and there shall be no leading zeros in M. PAGE55 ANNEX H (to Recommendation T.415) (informative) Use of the Distinguished Encoding type H.1 The problem to be solved The Distinguished Encoding has been provided to assist in the Provision of integrity security mechanisms using authenticators for material to be transferred. The concept of an authenticator is well understood, and involves taking the bit pattern to be transferred, applying some form of hashing function to it to reduce it to a few octets, encrypting those octets to authenticate the authenticator, then transmitting the authenticator with the original material (the original material being sent in clear). On receipt, the authenticator is recalculated from the received clear text and compared with the received authenticator. If they are equal, the text was not tampered with, otherwise it was. This simple concept becomes more difficult when the ISO model, and particularly the presentation layer, is in use. Two problems arise, one of which is a question of modeling and so-called layer independence, and the second of which relates to the use of application layer relays, such as are used in X.400. On the modeling issue, the hash function and the encryption algorithm are part of the application's operation, but the application has no knowledge or control of the actual encoding which the presentation layer will use. Similarly on receipt, decoding, and hence destruction of the bit-string on receipt is a presentation layer matter. There are three solutions that have been proposed to overcome this problem: a) rule out of order the use of the actual octets produced by presentation layer for use in the authenticator; (the current philosophy being adopted by presentation and ULA experts); b) put the hashing and authenticator mechanisms into the presentation layer itself (this solution was rejected as part of the broad question of putting support for encryption into ASN.1; at the time of rejection, the reason for the rejection was that work in security was still immature, and that one did not want to prejudice the eventual result); c) model a complex interaction with the presentation layer where, on transmission, a value is presented for encoding, the encoding is produced and returned to the application layer which calculates the authenticator, then the whole is transmitted; on receipt, as well as producing the abstract value, the received encodings are passed to the application layer for authenticator checking; (this model was rejected by the ULA group); d) do the entire encoding in the application layer, and make no use of presentation services for transfer syntax negotiation; (this is really a rejection of the OSI reference model, and would not be acceptable as a wide-spread solution). It might be argued that failure to agree on a model to describe an apparently simple and workable process (produce the encoding, then the authenticator, and transmit both, check against the authenticator on receipt) is not something which should be accepted as a long-term position. Such a remark would have strong validity if it were not for the second problem of application relays, and if there were no other workable solution. (This document is outlining an alternative solution which is used in X.500 and is considered to be free from modeling and relay-system problems and workable). The second problem is that, if an application relay is in place, the transfer syntax used for the second transmission may be different from that agreed for the first (for example, use of packed encoding rules on one of them, and Basic Encoding Rules on the other). This would defeat the authenticator, unless the authenticator was opened up and recalculated at the relay, which would imply security exchanges with the relay, whereas what is required is end-to-end security. Note ù There have been suggestions that one might want to flag a presentation context as "do not decode/re-encode at application relays", but this also provides modeling and other problems. PAGE54 Thus we are led to try to work with a model in which the presentation layer (together with any intervening application relays) provides for the transfer of the abstract syntax and semantics of the information, but makes no guarantees that the actual bit-pattern encoding (the transfer syntax) will be retained end-to-end. The challenge is therefore to provide an authenticator mechanism that can operate on the abstract datatype, rather than on the transmitted bit string. The Directories group were the first to attempt to produce a solution to this problem, and it is their model that is described below. H.2 The approach to a solution The following text describes first a conceptual model of what is being done, followed by an implementation optimization that eliminates the double encoding/decoding implied in the conceptual model. The conceptual model works as follows: a) The sender, in the application layer, converts the abstract syntax value into a bitstring using the Distinguished Encoding Rules, and produces the authenticator from that bitstring, which is inserted added to the abstract syntax value, and both values transmitted using normal presentation layer mechanisms, and any transfer syntax. Conceptually, the sender is encoding twice ù once for the authenticator (using the Distinguished Encoding Rules) in the application layer, and once for the actual transfer (using the negotiated transfer syntax) in the presentation layer. Note ù The import property of the bitstring produced by the Distinguished Encoding Rules is that it is in one-to-one correspondence with the abstract value. Thus end-to-end transfer without loss of information at the abstract syntax value is equivalent to end-to-end transfer of the bitstring on which the authenticator is based. b) The receiver will decode the received bitstring in the presentation layer, using the negotiated transfer syntax (which may differ from that used by the sender of an application relay is in place), and will pass the abstract value to the application. In the application layer, the abstract value is re-encoded using the Distinguished Encoding Rules to produce the bitstring to be authenticated. Thus conceptually, we encode twice at the sending end, and decode once and then encode at the receiving end. Implementors may choose to actually do this if the code supporting presentation layer operation is from a supplier different from that producing the code to support the application. How significant an overhead this would be is not clear at this stage. Where an integrated implementation is used, however, there is the option of the optimization described below. It should also be noted that the Distinguished Encoding Rules are no harder to apply than the Basic Encoding Rules except in relation to use of set-of. If a large set-of is to be processed, the implementation may need to invoke a disk-based sorting routine. Application designers should be aware of this, and try to use sequence-of instead of set-of when use of the Distinguished Encoding Rules is envisaged. H.3 The implementation optimization The OSI model and protocol standards specify required behaviour, they do not, in any way, seek to constrain the architecture and structure of actual implementation code. Thus an implementor can produce the desired effect in whatever way he chooses. At the sending end, the bitstring which is produced (conceptually in the application layer) can be kept, and used to provide the encoding that is conceptually performed in the presentation layer. This is suitable for sending if the negotiated transfer syntax is either the ASN.1 Basic Encoding Rules or the ASN.1 Distinguished Encoding Rules. If it is neither of these, then double encoding is necessary. PAGE55 Similarly at the receiving end, the received bitstring can be retained (for any transfer syntax), and the implementation can use this to check the authenticator. If it matches, end of problem, if it does not match, then it may be a transfer syntax problem, and recoding from the abstract value is necessary to determine whether there was tampering or not. In order to maximize the chances of not having to do double encoding/decoding, systems using this mechanism would be advised to try to negotiate a transfer syntax of Distinguished Encoding Rules (using the appropriate ASN.1 Object Identifier) as their first preference, falling back onto Basic Encoding Rules (first preference) or Packed or some other encoding rules second preference. PAGE54