Indirect references to data elements

Element lists, tag lists, header lists, extended header lists and wrappers are interindustry data elements for indirectly referencing data elements in byte strings, e.g., contents of EFs supporting data units, data fields resulting from completing commands APDU (see 8.4), byte strings to sign (see ISO/IEC 7816-8[4]). Such a data element instructs the card how to interpret a command data field or to construct a response data field.

Element list — Referenced by tag ’5F41′, this interindustry data element denotes that the information to retrieve is not presented as data objects, but under application control. It shall be used only within the wrapper template. Its structure and the returned information are outside the scope of ISO/IEC 7816.

Tag list — Referenced by tag ’5C’, this interindustry data element is a concatenation of tag fields without delimitation. The byte string consists of the data objects, in the same order as the tag list.

Header list — Referenced by tag ’5D’, this interindustry data element is a concatenation of pairs of tag fields and length fields without delimitation. The byte string consists of the value fields, in the same order as the header list.

Extended header list — Referenced by tag ’4D’, this interindustry data element is a concatenation of pairs of tag fields and length fields without delimitation. The byte string is built as follows.

 If a tag indicates a primitive encoding, then the pair of tag field and length field is replaced by data referenced by the tag. A zero length means that the complete data object / element is included in the byte string. A non-zero length means the maximum number of data bytes to be retrieved and consequently may require truncation.

 A tag indicating a constructed encoding followed by a non-zero length, except ’80′, introduces a subsequent value field that is an extended header list. A tag indicating a constructed encoding followed by a zero length is ignored. A tag indicating a constructed encoding followed by ’80′ means that the complete constructed data object / complete template is included in the byte string.

 The card shall ignore the elements of the extended header list that do not match the target structure.

The byte string consists of either

 the value fields of the primitive data objects, possibly truncated according to the indicated lengths (Case 1), or

 the primitive data objects, possibly truncated according to the indicated lengths, and nested in the respective template, the length of which complies with the BER-TLV rules (Case 2).

 If present, the length ’80′ shall be replaced by the actual length. The complete constructed data object / complete template is included in the byte string.

The encoding of the byte string, namely, data objects or data elements, is indicated by an appropriate INS code or by an appropriate parameter of the command, e.g., either an appropriate encoding of the data field (either constructed for those containing data objects or primitive for those containing data elements), or tags ‘AC’ or ‘BC’ (see Table 31) used in the PERFORM SECURITY OPERATION command (see ISO/IEC 7816-8[4]).

EXAMPLES The following extended header list references the subsequent three primitive data objects. 

Mifare DESFire 8K Smart Cards For Access Control systems,Mifare DESFire 8K Card,ISO MIFARE DESFire EV1 Smart Card 8k byte/64k bit,

Mifare DESFire EV1 8K Offset Printing Cards,Mifare DESFire EV1 8K Contactless Cards,Clamshell MIFARE DESFire EV1 8K Card,

Wrapper — Referenced by tag ’63′, this interindustry template shall consist of two data objects.

 The first data object is either an element list (tag ’5F41′), or a tag list (tag ’5C’), or a header list (tag ’5D’), or an extended header list (tag ’4D’).

 The second data object is a reference to an EF (tag ’51′, see 5.3.1.2) and / or one or more commands-toperform (tag ’52′). If several, the commands APDU shall be processed in the presented order.

A data object referenced e.g., in a tag list, or a data element referenced e.g., in a header list, either shall be contained in the referenced file, or shall be (part of) the response data field to the last command APDU. Only one indirect reference shall be given in a wrapper. There may be more than one wrapper.

EXAMPLE The following wrapper template consists of a tag list and one command-to-perform.

{’63′-L-{’5C’-L-(Tag1-Tag2-Tag3)}-{’52′-L-Command APDU}}

Card-originated byte strings

This service allows the card to originate byte strings.

For clarity, this clause speaks of a query as [part of] a card-originated byte string and of a reply as [part of] a response sent by an entity in the outside world; for example, a complete set of queries may form a command APDU and a complete set of replies a response APDU, thus allowing communication service from card to interface device and also, from card to card, possibly through a network.

This clause specifies the following three features.

 How the card shall use SW1-SW2 as a trigger indicating that the card wants to issue a byte string, for which the card possibly expects a response.

 How the interface device shall use the GET DATA command (see 7.4.2) for retrieving a query from the card and the PUT DATA command (see 7.4.3) for transmitting a reply, if any, to the card.

 How the byte strings shall be formatted.

Triggering by the card

SW1-SW2 set to ’62XX’ with the value of ‘XX’ from ’02′ to ’80′ means that the card has a query of ‘XX’ bytes that the interface device should retrieve and for which the card possibly expects a response.

SW1-SW2 set to ’64XX’ with the value of ‘XX’ from ’02′ to ’80′ means that the card aborted the command; a possible completion of the command is conditioned by the recovery of a query of ‘XX’ bytes, for which the card possibly expects a response.

If present in the historical bytes with a value such as above, SW1-SW2 shall be interpreted as above.

If a PUT DATA command (see 7.4.3) for transmitting a reply is aborted with SW1-SW2 set to ’64XX’, then

 with ’64XX’ from ’6402′ to ’6480′, the card wants to send at least one more query of ‘XX’ bytes;

 with ’64XX’ set to ’6401′, the card is expecting an immediate response.

Queries and replies

For retrieving a query of ‘XX’ bytes available in the card, the interface device shall send a GET DATA command with P1-P2 set to ’0000′ and a Le field set to ‘XX’.

 SW1-SW2 set to ’62XX’ with the value of ‘XX’ from ’02′ to ’80′ means that the interface device should

retrieve a further query of ‘XX’ bytes and concatenate it to the already retrieved query before processing

the card-originated byte string in the outside world.

 SW1-SW2 set to ’9000′ means that the card-originated byte string is complete; it may be processed in the outside world.

For transmitting a reply to the card, the interface device shall send a PUT DATA command with P1-P2 set to ’0000′. If the response is too long for a single command, then several PUT DATA commands shall be chained (see 5.1.1.1). Each PUT DATA command transmits a reply and the concatenation of the replies is the response.

Formats

The value of the first byte of the card-originated byte string indicates a format as follows.

 If the first byte is set to ‘FF’, then the subsequent bytes shall encode an initial protocol identifier according to ISO/IEC TR 9577[5]; the byte strings shall comply with the indicated protocol.

 Otherwise (i.e., when the first byte is not set to ‘FF’), the card-originated byte string and the response together shall form a command-response pair.

All conditions are relevant to the transmission protocol indicated by the card, except for the proper use of GET DATA command, PUT DATA command and status bytes SW1-SW2. This clause makes no assumption on the need for a response and on the entity responsible for the contents of the possible response.