0% found this document useful (0 votes)

135 views74 pages

Oasis 200305 XCBF Specification 1.1

Biometrics are automated methods of recognizing a person based on physiological or behavioral characteristics. They are used to recognize the identity of an individual, or to verify a claimed identity. This specification defines a common set of secure XML encodings for the patron formats specified in CBEFF.

Uploaded by

Luis Macaya Macaya

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOC, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

135 views74 pages

Oasis 200305 XCBF Specification 1.1

Uploaded by

Luis Macaya Macaya

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOC, PDF, TXT or read online on Scribd

You are on page 1/ 74

1

XML Common Biometric Format

3OASIS

Standard, approved August 2003

4Document identifier:
5
{OASIS Standard}-{XML Common Biometric Format}-{XCBF}-{1.1} (PDF, Word)
6Location:
7
http://www.oasis-open.org/specs/index.php
8Edited by:
9
John Larmouth, Individual Member
10Contributors:
11
Tyky Aichelen (Technical Committee Chair), IBM
12
Ed Day, Objective Systems
13
Dr. Paul Grme, Individual Member
14
Phillip H. Griffin, Individual Member
15
John Larmouth, Individual Member
16
Monica Martin, Sun Microsystems
17
Bancroft Scott, OSS Nokalva
18
Paul Thorpe, OSS Nokalva
19
Alessandro Triglia, OSS Nokalva
20
Rick Randall, Booz Allen Hamilton
21
John Messing, American Bar Association
22
Clifford Thompson, Individual Member
23
John Aerts, LA County Information Systems Advisory Body
24
Michael Nguyen, The Infocomm Development Authority of Singapore
25Abstract:
26
Biometrics are automated methods of recognizing a person based on physiological or
27
behavioral characteristics. They are used to recognize the identity of an individual, or to
28
verify a claimed identity. This specification defines a common set of secure XML
29
encodings for the patron formats specified in CBEFF, the Common Biometric Exchange
30
File Format (NISTIR 6529) [17]. These XML encodings are based on the ASN.1 schema
31
defined in ANSI X9.84 Biometric Information Management and Security [14]. For security
32
purposes, they make use of the Canonical XML Encoding Rules (CXER) for ASN.1
33
defined in ITU-T Rec. X.693, and rely on the security and processing requirements
34
specified in the X9.96 XML Cryptographic Message Syntax (XCMS) [15] and X9.73
35
Cryptographic Message Syntax (CMS) [13] standards .
36
37

NOTE Other ASN.1 Encoding Rules are also employed, see 7.4 Encodings to
be employed.

3
4
38Status:
39
If you are on the xcbf@lists.oasis-open.org list for committee members, send comments
40
there. If you are not on that list, subscribe to the xcbf-comment@lists.oasis-open.org list
41
and send comments there. To subscribe, send an email message to xcbf-comment42
request@lists.oasis-open.org with the word "subscribe" as the body of the message.
43Copyright 2002, 2003 The Organization for the Advancement of Structured Information
44Standards (OASIS)

5XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 2

7
8

45Table

of Contents

461 Introduction................................................................................................................................. 4
472 Terminology................................................................................................................................ 5
483 Acronyms and Abbreviations...................................................................................................... 6
494 Glossary...................................................................................................................................... 7
505 X9.84 and BioAPI 1.1 Interoperability......................................................................................... 9
51 5.1 BiometricSyntaxSets............................................................................................................. 9
52
5.1.1 BiometricObjects......................................................................................................... 10
53
5.1.2 IntegrityObjects............................................................................................................ 26
54
5.1.3 PrivacyObjects............................................................................................................. 33
55
5.1.4 PrivacyAndIntegrityObjects......................................................................................... 42
566 References................................................................................................................................ 45
57 6.1 Normative........................................................................................................................... 45
587 XCBF Schema.......................................................................................................................... 47
59 7.1 X9-84-Biometrics Module.................................................................................................... 47
60 7.2 X9-84-CMS Module............................................................................................................ 51
61 7.3 X9-84-Identifiers Module..................................................................................................... 54
62 7.4 Encodings to be employed.................................................................................................. 62
63
7.4.1 Encodings used for calculation of digital signatures and MACs..................................62
64
7.4.2 Octet Strings with Certificates and Certificate Revocation Lists..................................62
65
7.4.3 Outer-level encodings.................................................................................................. 63
668 Examples.................................................................................................................................. 64
67 8.1 BiometricSyntaxSets (CXER, DER) ...................................................................................64
68 8.2 SignedData ........................................................................................................................ 65
69 8.3 EncryptedData (fixedKey) .................................................................................................. 68
70Appendix A. Acknowledgments.................................................................................................... 72
71Appendix B. Revision History....................................................................................................... 73
72Appendix C. Notices.................................................................................................................... 74
73

9XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 3

11
12

741

Introduction

75Biometrics are automated methods of recognizing a person based on physiological or behavioral

76characteristics. They are used to recognize the identity of an individual, or to verify a claimed
77identity. This specification defines a common set of secure XML encodings for the patron formats
78specified in CBEFF, the Common Biometric Exchange File Format (NISTIR 6529). These
79CBEFF formats currently include the binary biometric objects and information records in two ANSI
80standards.
81
82These XML encodings are based on the ASN.1 [2] [3] [4] [5] schema defined in ANSI
83X9.84:2003 Biometric Information Management and Security. They use, for security purposes,
84the Canonical XML Encoding Rules (CXER) for ASN.1 defined in ITU-T Rec. X.693 [7], and rely
85on the same security and processing requirements specified in X9.96 XML Cryptographic
86Message Syntax (XCMS). Values of the Biometric Information Record (BIR) defined in
87ANSI/INCITS 358-2002 - Information technology - BioAPI Specification [16] that can be
88represented in the X9.84 biometric object format can also be represented using XML markup and
89secured using the techniques in this standard.
90
91This standard defines cryptographic messages represented in XML markup for the secure
92collection, distribution, and processing, of biometric information. These messages provide the
93means of achieving data integrity, authentication of origin, and privacy of biometric data in XML
94based systems and applications. Mechanisms and techniques are described for the secure
95transmission, storage, and integrity and privacy protection of biometric data.

13XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 4

15
16

962

Terminology

97The key words must, must not, required, shall, shall not, should, should not, recommended, may,
98and optional in this document are to be interpreted as described in [18].

17XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 5

19
20

993

Acronyms and Abbreviations

100

Term

Definition

ANSI

American National Standards Institute

ASN.1

Abstract Syntax Notation One

BASIC-XER

Basic XML Encoding Rules for ASN.1

BER

Basic Encoding Rules for ASN.1

BioAPI

Biometric Application Programming Interface

BIR

Biometric Information Record

CBC

Cipher Block Chaining

CBEFF

Common Biometric Exchange File Format

CMS

Cryptographic Message Syntax

CRL

Certificate Revocation List

CXER

Canonical XML Encoding Rules

DER

Distinguished Encoding Rules

DES

Digital Encryption Algorithm

DSA

Digital Signature Algorithm

HMAC

Hashed Message Authentication Code

IBIA

International Biometrics Industry Association

MAC

Message Authentication Code

NIST

National Institute of Science and Technology

SHA

Secure Hash Algorithm

TDES

Triple DES

URL

Uniform Resource Locator

UTC

Universal Coordinated Time

Accredited Standards Committee X9 Financial Services

XCMS

XML Cryptographic Message Syntax

XER

XML Encoding Rules

XML

Extensible Markup Language

101

21XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 6

23
24

1024

Glossary

Term

Definition

Attacker

Any individual who is attempting to subvert the operation of the

biometric system. The intention may be either to subsequently
gain illegal entry to the portal or to deny entry to legitimate users.

Biometric

A measurable biological or behavioral characteristic, which reliably

distinguishes one person from another, used to recognize the
identity, or verify the claimed identity, of an enrollee.

Biometrics

Biometrics are automated methods of recognizing a person based

on a physiological or behavioral characteristic.

Biometric Data

The extracted information taken from the biometric sample and

used either to build a reference template or to compare against a
previously created reference template.

Biometric Object

A data record taken from a biometric source or a logical piece of

biometric information, which may stand for either a template, or
one or more samples. The header is a set of associate attributes
that belong with the opaque data, and can include additional
information about the purpose, quality, etc. This must be in line
with the information content in X9.84 BiometricObject type.

Biometric Sample

Captured data that represents a biometric characteristic of a user

of a biometric system.

Canonical Form

The complete, unambiguous and unique encoding of an abstract

value obtained by the application of encoding rules that allow one
and only one way to encode the abstract value.

Capture

The collection of a biometric sample from a user.

Enrollee

A person who has a biometric reference template stored in a

biometric system.

Hash

A mathematical function which evenly and randomly distributes

values from a large domain into a smaller range.

HMAC

A mechanism for message authentication using a cryptographic

hash function and a specific key.

MAC

A cryptographic value resulting from passing a message through

the message authentication algorithm using a specific key.

Octet

A sequence of binary digits of length eight that can be represented

as two hexadecimal digits, the first hexadecimal digit representing
the four most significant bits of the octet, and the second
hexadecimal digit representing the four least significant bits.

Octet String

A sequence of octets.

Private Key

A key of an entitys key pair known only to that entity.

Public Key

A key of an entitys key pair known publicly.

25XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 7

27
28

Template

Reference data formed from the biometric measurement of an

enrollee and used by a biometric system for comparison against
subsequently submitted biometric samples.

103

29XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 8

31
32

1045

X9.84 and BioAPI 1.1 Interoperability

105This standard defines a set of cryptographic messages represented in XML markup that can be
106used for the secure collection, distribution, and processing, of biometric information. All of the
107cryptographic operations provided in this standard are applied to a set of values of the ASN.1
108type BiometricObject defined in the ANSI X9.84 standard.
109
110This document describes the process for translating between an X9.84 BiometricObject and a
111BioAPI-1.1 Biometric Information Record (BIR). The X9.84 schema is the same as the schema
112defined in this standard and provides a common means of representing in XML markup the binary
113values described in the X9.84 and BioAPI-1.1 standards. Once BIR format values are
114represented as values of type BiometricObject they can be secured using the techniques
115described in this standard.

1165.1 BiometricSyntaxSets
117Type BiometricSyntaxSets is a series of one or more values of type BiometricSyntax. This
118type is defined as
119
120

BiometricSyntaxSets ::= SEQUENCE SIZE(1..MAX) OF BiometricSyntax

121
122Type BiometricSyntax is a choice type with four choice alternatives, biometricObjects,
123integrityObjects, privacyObjects and privacyAndIntegrityObjects.
124
125
126
127
128
129
130

BiometricSyntax ::= CHOICE {

biometricObjects
integrityObjects
privacyObjects
privacyAndIntegrityObjects
}

BiometricObjects,
IntegrityObjects,
PrivacyObjects,
PrivacyAndIntegrityObjects

131
132The choice alternatives of type BiometricSyntax have the following meanings:
133
134biometricObjects

a set of unprotected biometric values

135integrityObjects

a digitally signed set of biometric values

136privacyObjects

an encrypted set of biometric values

137privacyAndIntegrityObjects

a digitally signed and encrypted set of biometric values

138
139Type BiometricSyntaxSets is a series of one or more choice alternatives. Since each of these
140alternatives is itself a set of one or more biometric objects, BiometricSyntaxSets is a set of sets.
141Using these choice alternatives useful collections of biometric information can be constructed.
142The message sender controls the order of the items in each set, so that records can be ordered
143for any purpose needed. This includes ordering records by likelihood of matching, by vendor
144format, type of biometric, data quality, or record age.
145

33XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 9

35
36
146The BioAPI specification defines a single format, a BIR, composed of three fields: a record
147Header, an opaque BiometricData field, and an optional Signature. Ignoring the Signature field,
148the BIR format corresponds closely to the single unprotected biometric value defined in this
149standard as the BiometricSyntax choice alternative biometricObjects when it is constrained to
150contain a single BiometricObject. There is no definition for representing sets of biometric
151records in BioAPI.
152
153The other BiometricSyntax choice alternatives are not supported in the BioAPI specification.
154These alternatives are cryptographic messages used to provide integrity, authentication and
155privacy services. When a BIR value is represented in biometricObjects format, XCBF security
156services can be used to protect BioAPI biometric information.
157
158A value of type BiometricSyntaxSets can be represented in XML markup as
159
160
161
162

163
164Here an ellipsis is used as a placeholder for the elements of the choice alternative of type
165BiometricSyntax which are not shown.

1665.1.1 BiometricObjects
167The biometricObjects choice alternative of type BiometricSyntax is a value of type
168BiometricObjects., a series of one or more values of type BiometricObject. These types are
169defined as
170
171

BiometricObjects ::= SEQUENCE SIZE(1..MAX) OF BiometricObject

172
173
174
175
176

BiometricObject ::= SEQUENCE {

biometricHeader BiometricHeader,
biometricData
BiometricData
}

177
178All of the cryptographic processing in this standard is performed on a value of type
179EncodedBiometricObjects. This is a value of type BiometricObjects with the cryptographic
180transformations performed on the CXER encoding, as specified in 5.1.2.1.1 Digital Signature
181Process.
182
183

EncodedBiometricObjects ::= BIOMETRIC.&Type( BiometricObjects )

184
185Type BiometricObject is composed of two components, biometricHeader and biometricData,
186which correspond to the BIR Header and BiometricData fields defined in the BioAPI bioapi_bir
187structure as
188
189
190
191
192

typedef struct bioapi_bir {

BioAPI_BIR_HEADER
BioAPI_BIR_BIOMETRIC_DATA_PTR
BioAPI_DATA_PTR

Header;
BiometricData;
Signature;

37XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 10

39
40
193

} BioAPI_BIR, *BioAPI_BIR_PTR ;

194
195The bioapi_bir.Signature field is optional and opaque. Since this field does not provide any
196standard formats, no means of identifying cryptographic algorithms and associated parameters,
197and no facilities for key management, it is simply ignored for the purposes of XCBF.
198
199A value of the biometricObjects choice alternative of type BiometricSyntax can be represented
200in XML markup as
201
202
203
204
205
206
207
208
209
210
211
212
213

214
215Here an ellipsis is used as a placeholder for the biometric header elements and data which are
216not shown.
217

2185.1.1.1 BiometricHeader
219The biometricHeader component of type BiometricObject is a value of type BiometricHeader
220defined as
221
222
223
224
225
226
227
228
229
230

BiometricHeader ::= SEQUENCE {

version
BiometricVersion DEFAULT hv1,
recordType
RecordType OPTIONAL,
dataType
DataType OPTIONAL,
purpose
Purpose OPTIONAL,
quality
Quality OPTIONAL,
validityPeriod ValidityPeriod OPTIONAL,
format
Format OPTIONAL
}

231
232A value of type BiometricHeader corresponds closely to the BIR Header field in the BioAPI
233bioapi_bir structure, which is defined as
234
235
236
237
238
239
240
241
242

typedef struct bioapi_bir_header {

uint32 Length;
BioAPI_BIR_VERSION
BioAPI_BIR_DATA_TYPE
BioAPI_BIR_BIOMETRIC_DATA_FORMAT
BioAPI_QUALITY
BioAPI_BIR_PURPOSE
BioAPI_BIR_AUTH_FACTORS

HeaderVersion;
Type;
Format;
Quality;
Purpose;
FactorsMask;

41XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 11

43
44
243

} BioAPI_BIR_HEADER, *BioAPI_BIR_HEADER_PTR ;

244
245The BiometricHeader definition describes abstract values that are independent of an
246implementations choice of programming language, operating system, hardware or transfer
247representation. This approach provides applications with maximum flexibility and more than one
248concrete representation of the same abstract values, making it possible to encode these values in
249compact binary formats or as XML markup.
250
251The BiometricHeader definition does not need a prefix with a length component as required by
252the BIR C programming language format. Some ASN.1 encoding rules will provide length fields
253and others will not. The BiometricHeader definition contains optional fields that need not be
254included in a record. This can reduce the record size of encoded ASN.1 values when making
255them more compact than the same values represented in the BioAPI BIR format.
256
257A value of the biometricHeader component of type BiometricObject can be represented in XML
258markup as
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280

281
282This markup specifies a high quality reference template used for audit purposes. A vendor
283specific payload is carried in the header.

2845.1.1.1.1 BiometricVersion
285The version component of type BiometricHeader is a value of type BiometricVersion defined
286as
287
288

BiometricVersion ::= INTEGER { hv1(0) } (0..MAX)

289
290Type BiometricVersion specifies the integer version number of the BiometricHeader and has
291no relationship to the BIR HeaderVersion field in the BioAPI bioapi_bir_header structure.
292
45XML Common Biometric Format (XCBF) Committee Specification 1.1
46Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 12

47
48
293This definition includes a constraint on the valid values of the version component. Values of type
294BiometricVersion are constrained to be integers greater than or equal to zero. The version
295number shall be zero in this standard. The biometric header version number zero is identified by
296the constant hv1.
297
298A value of the version component of type BiometricHeader can be represented in XML markup
299as
300
301

302
303This markup specifies the zero header version number used in this standard.

3045.1.1.1.2 RecordType
305The recordType component of type BiometricHeader is a value of type RecordType defined as
306
307

RecordType ::= BIOMETRIC.&name({BiometricTypes})

308
309Valid values of RecordType are constrained by the list of objects in the BiometricTypes
310information object set. This set is defined as
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332

BiometricTypes
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC

333
334
335

...

BIOMETRIC ::= {
id : unknown-Type
id : body-Odor
id : dna
id : ear-Shape
id : facial-Features
id : finger-Image
id : finger-Geometry
id : hand-Geometry
id : iris-Features
id : keystroke-Dynamics
id : palm
id : retina
id : signature
id : speech-Pattern
id : thermal-Image
id : vein-Pattern
id : thermal-Face-Image
id : thermal-Hand-Image
id : lip-Movement
id : gait

} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
},

-- expect additional biometric types --

336
337The BiometricTypes information object set contains an extension marker () indicating that
338message recipients should expect additional values of biometric types not currently in the set.
339This allows the set to change as new biometric technology types are developed and used.
340
341A value of this type corresponds closely to the BIR FactorsMask field in the BioAPI
342bioapi_bir_header structure, which is defined as
49XML Common Biometric Format (XCBF) Committee Specification 1.1
50Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 13

51
52
343
344

typedef sint8 BioAPI_BIR_AUTH_FACTORS;

345
346
347
348
349
350
351
352
353
354
355
356
357
358
359

#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

BioAPI_FACTOR_MULTIPLE (0x00000001)
BioAPI_FACTOR_FACIAL_FEATURES (0x00000002)
BioAPI_FACTOR_VOICE (0x00000004)
BioAPI_FACTOR_FINGERPRINT (0x00000008)
BioAPI_FACTOR_IRIS (0x00000010)
BioAPI_FACTOR_RETINA (0x00000020)
BioAPI_FACTOR_HAND_GEOMETRY (0x00000040)
BioAPI_FACTOR_SIGNATURE_DYNAMICS (0x00000080)
BioAPI_FACTOR_KEYSTOKE_DYNAMICS (0x00000100)
BioAPI_FACTOR_LIP_MOVEMENT (0x00000200)
BioAPI_FACTOR_THERMAL_FACE_IMAGE (0x00000400)
BioAPI_FACTOR_THERMAL_HAND_IMAGE (0x00000800)
BioAPI_FACTOR_GAIT (0x00001000)
BioAPI_FACTOR_PASSWORD (0x80000000)

360
361Any other unrecognized value or settings in this BIR field can be represented by an XCBF
362application by the unknownType without changes to the XCBF schema. Values that are defined
363in XCBF but not supported in the BioAPI specification cannot be represented in a BIR field in a
364standard way. These include the values defined for body-Odor, dna, ear-Shape, finger365Geometry, palm, and thermal-Image.
366

RecordType

Value

BioAPI FactorsMask

Value

unknownType

BioAPI_FACTOR_MULTIPLE

0x00000001

body-Odor

dna

ear-Shape

facial-Features

BioAPI_FACTOR_FACIAL_FEATURES

0x00000002

finger-Image

BioAPI_FACTOR_FINGERPRINT

0x00000008

finger-Geometry

hand-Geometry

BioAPI_FACTOR_HAND_GEOMETRY

0x00000040

iris-Features

BioAPI_FACTOR_IRIS

0x00000010

keystroke-Dynamics

BioAPI_FACTOR_KEYSTOKE_DYNAMICS

0x00000100

palm

retina

BioAPI_FACTOR_RETINA

0x00000020

signature

BioAPI_FACTOR_SIGNATURE_DYNAMICS

0x00000080

speech-Pattern

BioAPI_FACTOR_VOICE

0x00000004

thermal-Image

vein-Pattern

53XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 14

55
56

thermal-Face-Image

BioAPI_FACTOR_THERMAL_FACE_IMAGE

0x00000400

thermal-Hand-Image

BioAPI_FACTOR_THERMAL_HAND_IMAGE

0x00000800

lip-Movement

BioAPI_FACTOR_LIP_MOVEMENT

0x00000200

gait

BioAPI_FACTOR_GAIT

0x00001000

BioAPI_FACTOR_PASSWORD

0x80000000

367
368The recordType component of type BiometricHeader allows the specification of a single type of
369biometric record. The BioAPI specification uses a bit mask and allows multiple biometric record
370types to be specified in the opaque biometric data. In BioAPI, the BioAPI_FACTOR_MULTIPLE
371bit must be set when multiple record types are specified.
372
373BioAPI does not define a standard way to identify how each type in a multiple type BIR value is
374delineated, leaving these details to the biometric vendor. When these details are known to an
375XCBF application, multiple biometric record types may be represented as a value of type
376BiometricObjects, a series of biometric objects.
377
378A value of the recordType component of type BiometricHeader can be represented in XML
379markup as
380
381

<recordType> <id> 9 </id> </recordType>

382
383This markup specifies a keystroke dynamics record type using the relative object identifier choice
384alternative value.

3855.1.1.1.3 DataType
386The dataType component of type BiometricHeader is a value of type DataType defined as
387
388
389
390
391
392

DataType ::= ENUMERATED {

raw
(0),
intermediate (1),
processed
(2)
}

393
394A value of this type corresponds closely to the BIR Type field in the BioAPI bioapi_bir_header
395structure, which is defined as
396
397

typedef uint8 BioAPI_BIR_DATA_TYPE;

398
399
400
401

#define BioAPI_BIR_DATA_TYPE_RAW (0x01)

#define BioAPI_BIR_DATA_TYPE_INTERMEDIATE (0x02)
#define BioAPI_BIR_DATA_TYPE_PROCESSED (0x04)

402
403The following two flags are defined in the BIR Type field in the BioAPI bioapi_bir_header
404structure. These are related to the bioapi_bir.Signature field and are ignored for the purposes of
57XML Common Biometric Format (XCBF) Committee Specification 1.1
58Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 15

59
60
405constructing a value of type BiometricHeader, though this information may be used by XCBF
406applications for determining security requirements where the details of the key management
407techniques allied to the opaque biometric data can be determined.
408
409
410

#define BioAPI_BIR_DATA_TYPE_ENCRYPTED (0x10)

#define BioAPI_BIR_DATA_TYPE_SIGNED (0x20)

411

X9.84 DataType

Value

BioAPI Type

Value

raw

BioAPI_BIR_DATA_TYPE_RAW

0x01

intermediate

BioAPI_BIR_DATA_TYPE_INTERMEDIATE

0x02

processed

BioAPI_BIR_DATA_TYPE_PROCESSED

0x04

BioAPI_BIR_DATA_TYPE_ENCRYPTED

0x10

BioAPI_BIR_DATA_TYPE_SIGNED

0x20

412
413A value of the dataType component of type BiometricHeader can be represented in XML
414markup as
415
416

417
418This markup specifies processed biometric data using an enumerated value.

4195.1.1.1.4 Purpose
420The purpose component of type BiometricHeader is a value of type Purpose defined as
421
422
423
424
425
426
427
428

Purpose ::= ENUMERATED {

verify
(1),
identify
(2),
enroll
(3),
enrollVerify
(4),
enrollIdentify (5),
audit
(6),

429
430
431

...

-- expect others --

432
433A value of this type corresponds closely to the BIR Purpose field in the BioAPI bioapi_bir_header
434structure, which is defined as
435
436

typedef uint8 BioAPI_BIR_PURPOSE;

437
438
439
440
441

#define
#define
#define
#define

BioAPI_PURPOSE_VERIFY
BioAPI_PURPOSE_IDENTIFY
BioAPI_PURPOSE_ENROLL
BioAPI_PURPOSE_ENROLL_FOR_VERIFICATION_ONLY

61XML Common Biometric Format (XCBF) Committee Specification 1.1

(1)
(2)
(3)
(4)

June 2003
Page 16

63
64
442
443

#define BioAPI_PURPOSE_ENROLL_FOR_IDENTIFICATION_ONLY (5)

#define BioAPI_PURPOSE_AUDIT
(6)

444
445

9.84 Purpose

Value

BioAPI Purpose

Value

verify

BioAPI_PURPOSE_VERIFY

identify

BioAPI_PURPOSE_IDENTIFY

enroll

BioAPI_PURPOSE_ENROLL

enrollVerify

BioAPI_PURPOSE_ENROLL_VERIFICATION_ONLY

enrollIdentify

BioAPI_PURPOSE_ENROLL_IDENTIFICATION_ONLY

audit

BioAPI_PURPOSE_AUDIT

446
447A value of the purpose component of type BiometricHeader can be represented in XML
448markup as
449
450

<purpose> <audit/> </purpose>

451
452This markup specifies that the purpose of the biometric data is auditing.

4535.1.1.1.5 Quality
454The quality component of type BiometricHeader is a value of type Quality defined as
455
456
457
458
459
460
461
462

Quality ::= INTEGER {

lowest
( 0),
highest
(100),
notSet
( -1),
notSupported ( -2)
}
(-2..100,...)

463
464A value of this type corresponds closely to the BIR Quality field in the BioAPI bioapi_bir_header
465structure, which is defined as
466
467

typedef sint8 BioAPI_QUALITY;

468
469XCBF, X9.84 and BioAPI all define biometric quality as an integer in the range of negative two to
470one hundred. X9.84 specifies named integer constants for the lowest quality, highest quality,
471quality not set, and quality not supported. These values are presented in the following table:
472

Value
-2

Value Range

Meaning of Value
Not supported by Biometric Service Provider

65XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 17

67
68

-1

Not set by Biometric Service Provider

0 -

Unacceptable

26 -

Marginal

51 -

Adequate

76 - 100

Excellent

473
474A value of the quality component of type BiometricHeader can be represented in XML markup
475as
476
477

<quality> 100 </quality>

478
479This markup specifies that the quality of the biometric data is excellent.

4805.1.1.1.6 ValidityPeriod
481The validityPeriod component of type BiometricHeader is a value of type ValidityPeriod
482defined as
483
484
485
486
487
488

ValidityPeriod ::= SEQUENCE {

notBefore DateTime OPTIONAL,
notAfter
DateTime OPTIONAL
}
(ALL EXCEPT({ -- none; at least one component is present -- }))

489
490The notBefore and notAfter components of type ValidityPeriod are values of type DateTime
491defined as
492
493

DateTime ::= RELATIVE-OID

-- { yyyy mm dd hh mm ss z }

494
495These date and time values are a variable length series of integers delimited by the full stop
496character. No more than seven fields are allowed, and each trailing zero valued field can be
497omitted. Values of type DateTime represent a Universal Coordinated Time (UTC) value and the
498Zulu indicator is represented by the integer zero.
499
500 A value of the validityPeriod component of type BiometricHeader can be represented in XML
501markup as
502
503
504
505
506

507
508This markup specifies that the biometric data is valid on or after October 4, 1980 and is not valid
509at midnight October 3, 2003 or thereafter.
69XML Common Biometric Format (XCBF) Committee Specification 1.1
70Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 18

71
72
510
511When the optional validityPeriod component is present in a value of type BiometricHeader,

512either of the <notBefore> or <notAfter> elements of <validityPeriod> may be omitted in

513a valid value of type ValidityPeriod, but not both.

5145.1.1.1.7 Format
515The format component of type BiometricHeader is a value of type Format defined as
516
517
518
519
520

Format ::= SEQUENCE {

formatOwner BIOMETRIC.&name({Owner}),
formatType
BIOMETRIC.&Type({Owner}{@formatOwner})
}

OPTIONAL

521
522A value of this type corresponds closely to the BIR Format field in the BioAPI
523bioapi_bir_biometric_data_format structure, which defined as
524
525
526
527
528
529
530

BioAPI bioapi_bir_biometric_data_format
typedef struct bioapi_bir_biometric_data_format {
uint16 FormatOwner;
uint16 FormatID;
} BioAPI_BIR_BIOMETRIC_DATA_FORMAT,
*BioAPI_BIR_BIOMETRIC_DATA_FORMAT_PTR;

531
532Type Format is composed of two components, formatOwner and formatType, which are
533defined in terms of the &name and &Type fields of the BIOMETRIC information object class.
534This class is defined as
535
536
537
538
539
540

BIOMETRIC ::= CLASS {

&name BIOMETRIC-IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { BIOMETRIC &name [ DATA &Type ] }

541
542The type of the formatOwner component is defined in terms of the &name field. This field is
543defined as a value of type BIOMETRIC-IDENTIFIER, a choice type with two alternatives, oid and
544id. These alternatives allow a vendor specific format to be identified using a complete object
545identifier or an object identifier fragment:
546
547
548
549
550

BIOMETRIC-IDENTIFIER ::= CHOICE {

oid OBJECT IDENTIFIER, -- complete object identifier
id
RELATIVE-OID
-- object identifier fragment
}

551
552The type of the optional formatType component is an open type, which can carry the value of
553any type that can be defined using ASN.1.
554
555A value of the format component of type BiometricHeader can be represented in XML markup
556as
73XML Common Biometric Format (XCBF) Committee Specification 1.1
74Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 19

75
76
557
558
559
560
561
562
563
564
565

<format>
<formatOwner>
<oid> 2.23.42.9.10.4.2 </oid>
</formatOwner>
<formatType>
<URL> http://asn-1.com/biolojava.htm </URL>
</formatType>
</format>

566
567This markup associates the biometric data with a specific vendor product using a complete object
568identifier value. The optional formatType component is present and contains a value of a user
569defined type named URL. Type URL is a Uniform Resource Locator, character string type, but
570given only the <URL> tag and the element contents, it is not possible to determine the actual
571ASN.1 schema definition of this type.
572
573While it is easy for human readers to see that the content of the formatType open type is a
574hypertext link, application tools are likely to treat this content as an opaque string. A recipient of
575this information, without access to the complete ASN.1 Schema and an understanding of the
576intended semantics, may be able to parse this XML markup, but will not be able to understand or
577act on the information it provides.
578
579Adopters of this standard can obtain an object identifier and register an associated type for use in
580their systems and applications. These object identifiers are globally unique and can be used to
581identify the version of vendor hardware and software needed to process a given biometric object.

5825.1.1.1.7.1 Biometric Format Registration

583There are three registration authorities for vendor specific formats recognized in this standard,
584NIST, IBIA and X9. Each organization controls a unique arc under which it may assign vendor
585specific format identifiers and associated information.
586
587These identifiers and associated types are used to constrain the valid values that may be used in
588the components of type Format. This constraint is specified by objects defined in the Owner
589information object set defined as
590
591

592
593
594
595
596
597

Owner BIOMETRIC ::= {

CBEFF-Formats | -- http://www.nist.gov/ -IBIA-Formats
| -- http://www.ibia.org/ -X9-Formats,
-- http://www.x9.org/ -...

-- expect additional vendor specific formats --

598

5995.1.1.1.7.2 CBEFF-Formats
600All CBEFF registered vendor specific format types are identified by the object identifier
601id-x984BioInfo or the object identifier fragment x984BioInfo defined as:
602
603

id-x984BioInfo

OID ::= { cbeff-Owner x984BioInfo(0) }

77XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 20

79
80
604
605

x984BioInfo

RelOID ::= { x984BioInfo(0) }

-- CBEFF owner

606
607These identifier values are used in the information object sets, CBEFFoidFormats and
608CBEFFidFormats, to identify a value of type BiometricInformationSets. This type biometric
609serves as a placeholder for possible future standardization, which will identify commonly
610accepted processing algorithms and matching methods.
611
612
613
614

CBEFF-Formats BIOMETRIC ::= {

CBEFFoidFormats | -- Complete object identifiers
CBEFFidFormats,
-- Object identifier fragments

615
616
617

618
619
620

CBEFFoidFormats BIOMETRIC ::= {

{ BIOMETRIC oid : id-x984BioInfo DATA BiometricInformationSets },

621
622
623

624
625
626

CBEFFidFormats BIOMETRIC ::= {

{ BIOMETRIC id : x984BioInfo DATA BiometricInformationSets },

627
628
629

...

-- Expect additional CBEFF vendor specific formats --

-- Expect other objects --

630
631Type BiometricInformationSets is defined as one or more instances of BiometricInformation:
632
633
634

BiometricInformationSets ::=
SEQUENCE SIZE(1..MAX) OF BiometricInformation

635
636
637
638
639
640

BiometricInformation ::= SEQUENCE {

processingAlgorithms ProcessingAlgorithms OPTIONAL,
matchingMethods
MatchingMethods OPTIONAL
}
(ALL EXCEPT({ -- none; at least one component is present -- }))

641
642Type ProcessingAlgorithms specifies one or more biometric processing algorithms that are to
643be used to process biometric sample data or which have been used to create a biometric
644reference template. This type is defined as one or more instances of ProcessingInformation:
645
646

ProcessingAlgorithms ::= SEQUENCE SIZE(1..MAX) OF ProcessingInformation

647
648
649
650
651

ProcessingInformation ::= SEQUENCE {

id
BIOMETRIC.&name({ProcessingAIDs}),
parms BIOMETRIC.&Type({ProcessingAIDs}{@id})
}

OPTIONAL

652
653Type ProcessingInformation is composed of two components, id and parms, which are defined
654in terms of the fields &name and &Type of the BIOMETRIC information object class. The valid
655values of these two components are constrained by the objects specified in the information object
656set ProcessingAIDs.
81XML Common Biometric Format (XCBF) Committee Specification 1.1
82Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 21

83
84
657
658The ProcessingAIDs information object set contains no objects, as no biometric processing
659algorithms have been assigned by NIST under their CBEFF program.
660
661

ProcessingAIDs BIOMETRIC ::= {

662
663
664

...

-- Expect CBEFF assignments in BiometricInformationSets --

665
666Type MatchingMethods specifies one or more biometric matching methods that can be used to
667associate a biometric sample to a stored reference template. This type is defined as one or more
668instances of MatchingInformation:
669
670

MatchingMethods ::= SEQUENCE SIZE(1..MAX) OF MatchingInformation

671
672
673
674
675

MatchingInformation ::= SEQUENCE {

id
BIOMETRIC.&name({MatchingAIDs}),
parms BIOMETRIC.&Type({MatchingAIDs}{@id})
}

OPTIONAL

676
677Type MatchingInformation is composed of two components, id and parms, which are defined in
678terms of the fields &name and &Type of the BIOMETRIC information object class. The valid
679values of these two components are constrained by the objects specified in the information object
680set MatchingAIDs.
681
682The MatchingAIDs information object set contains no objects, as no biometric matching methods
683have been assigned by NIST under their CBEFF program.
684
685

MatchingAIDs BIOMETRIC ::= {

686
687
688

...

-- Expect CBEFF assignments in BiometricInformationSets --

689

6905.1.1.1.7.3 IBIA-Formats
691All IBIA registered vendor specific format types are identified by the object identifier
692
693

ibia-Owner OID ::= { format-Owner ibia(1) }

694
695This base object identifier is not used in practice in BioAPI based applications, as all of the
696vendor specific formats registered under this arc are restricted to small, sixteen bit integers for
697compatibility with the fixed format requirements of the BioAPI specification. These are values of
698type BirInt16 defined as
699
700

BirInt16 ::= INTEGER (0..65535)

701

85XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 22

87
88
702In XCBF, the BIR format owner is modeled as a relative object identifier restricted to a single
703node and must comply with the fixed format requirements of the BioAPI specification.
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731

ibia-SAFLINK
ibia-Bioscrypt
ibia-Visionics
ibia-InfineonTechnologiesAG
ibia-IridianTechnologies
ibia-Veridicom
ibia-CyberSIGN
ibia-eCryp
ibia-FingerprintCardsAB
ibia-SecuGen
ibia-PreciseBiometric
ibia-Identix
ibia-DERMALOG
ibia-LOGICO
ibia-NIST
ibia-A4Vision
ibia-NEC
ibia-STMicroelectronics
ibia-Ultra-Scan
ibia-Aurora-Wireless
ibia-Thales
ibia-IBG
ibia-Cogent-Systems
ibia-Cross-Match
ibia-Recognition-Systems
ibia-DIN
ibia-INCITS-M1

RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID

::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=

{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}

732
733These identifiers are associated with a restriced sixteen bit integer value.
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760

IBIAidFormats BIOMETRIC ::= {

{ BIOMETRIC id : ibia-SAFLINK
{ BIOMETRIC id : ibia-Bioscrypt
{ BIOMETRIC id : ibia-Visionics
{ BIOMETRIC id : ibia-InfineonTechnologiesAG
{ BIOMETRIC id : ibia-IridianTechnologies
{ BIOMETRIC id : ibia-Veridicom
{ BIOMETRIC id : ibia-CyberSIGN
{ BIOMETRIC id : ibia-eCryp
{ BIOMETRIC id : ibia-FingerprintCardsAB
{ BIOMETRIC id : ibia-SecuGen
{ BIOMETRIC id : ibia-PreciseBiometric
{ BIOMETRIC id : ibia-Identix
{ BIOMETRIC id : ibia-DERMALOG
{ BIOMETRIC id : ibia-LOGICO
{ BIOMETRIC id : ibia-NIST
{ BIOMETRIC id : ibia-A4Vision
{ BIOMETRIC id : ibia-NEC
{ BIOMETRIC id : ibia-STMicroelectronics
{ BIOMETRIC id : ibia-Ultra-Scan
{ BIOMETRIC id : ibia-Aurora-Wireless
{ BIOMETRIC id : ibia-Thales
{ BIOMETRIC id : ibia-IBG
{ BIOMETRIC id : ibia-Cogent-Systems
{ BIOMETRIC id : ibia-Cross-Match
{ BIOMETRIC id : ibia-Recognition-Systems

DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA

89XML Common Biometric Format (XCBF) Committee Specification 1.1

BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16
BirInt16

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

June 2003
Page 23

91
92
761
762
763
764
765

{ BIOMETRIC id : ibia-DIN
{ BIOMETRIC id : ibia-INCITS-M1
...

DATA BirInt16 } |
DATA BirInt16 },

-- Expect others --

766
767Note that additional registry entries are expected and that the associated type is optional in XCBF
768and need not be present.
769
770When these vendor specific format values are expressed as complete object identifiers as
771allowed in XCBF messages, they can be associated with any ASN.1 type needed by an
772implementation.
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801

IBIAoidFormats
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC
{ BIOMETRIC

802
803
804
805

806
807

Any ::= TYPE-IDENTIFIER.&Type

...

BIOMETRIC ::= {
oid : id-ibia-SAFLINK
oid : id-ibia-Bioscrypt
oid : id-ibia-Visionics
oid : id-ibia-InfineonTechnologiesAG
oid : id-ibia-IridianTechnologies
oid : id-ibia-Veridicom
oid : id-ibia-CyberSIGN
oid : id-ibia-eCryp
oid : id-ibia-FingerprintCardsAB
oid : id-ibia-SecuGen
oid : id-ibia-PreciseBiometric
oid : id-ibia-Identix
oid : id-ibia-DERMALOG
oid : id-ibia-LOGICO
oid : id-ibia-NIST
oid : id-ibia-A4Vision
oid : id-ibia-NEC
oid : id-ibia-STMicroelectronics
oid : id-ibia-Ultra-Scan
oid : id-ibia-Aurora-Wireless
oid : id-ibia-Thales
oid : id-ibia-IBG
oid : id-ibia-Cogent-Systems
oid : id-ibia-Cross-Match
oid : id-ibia-Recognition-Systems
oid : id-ibia-DIN
oid : id-ibia-INCITS-M1

DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA

Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any

} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
},

-- Expect additional vendor specific formats --- Application constrained

808

8095.1.1.1.7.4 X9-Formats
810All X9 registered vendor specific format types are identified by the object identifier
811
812

x9-Owner OID ::= { format-Owner x9(2) }

813

93XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 24

95
96
814Under this X9 arc, both complete and relative object identifier values can be registered for use by
815biometric application vendors. This base object identifier may be used to form complete object
816identifiers in practice. Use of this arc can occur at the application level above the BioAPI layer.
817For applicatons that require compatibility with BioAPI formats, the details of the fields in the BIR
818can be ignored and the entire BIR can be carried in a BiometricObject as the value of the
819biometricData component.
820
821None of the vendor specific formats registered under the x9-Owner arc are restricted to the
822small, sixteen bit integers required for field level compatibility with the fixed format requirements
823of the BioAPI specification. Any type needed by the application can be registered under this arc.
824This capability gives biometric vendors complete control over the content that can be bound to
825the biometric information in a BiometricObject. and the flexibility needed to create biometric
826applications complete control and flexibility.
827
828
829
830
831

X9-Formats BIOMETRIC ::= {

X9oidFormats |
X9idFormats,

832
833
834

835
836
837
838

X9oidFormats BIOMETRIC ::= {

... -- Expect X9 assigned objects -}

839
840
841
842

X9idFormats BIOMETRIC ::= {

... -- Expect X9 assigned objects of the form { 2 x } -}

...

-- Expect additional X9 vendor specific formats --

843

8445.1.1.2 BiometricData
845The biometricData component of type BiometricObject is a value of type BiometricData
846defined as
847
848

BiometricData ::= OCTET STRING (SIZE(1..MAX))

849
850A value of this type corresponds to the BIR BiometricData field in the BioAPI bioapi_bir structure
851and is defined as
852
853

typedef uint8 BioAPI_BIR_BIOMETRIC_DATA;

854
855Both of these data types are opaque strings that for the purpose of transfer have no internal
856structure. They contain unprotected binary biometric samples aligned in 8-bit words.
857

97XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 25

99
100

8585.1.2 IntegrityObjects
859The integrityObjects choice alternative of type BiometricSyntax is a value of type
860IntegrityObjects. Type IntegrityObjects is a sequence of two components, biometricObjects
861and integrityBlock, and is defined as
862
863
864
865
866

IntegrityObjects ::= SEQUENCE {

biometricObjects EncodedBiometricObjects,
integrityBlock
IntegrityBlock
}

867
868The biometricObjects component is a value of type EncodedBiometricObjects, a series of one
869or more values of type BiometricObject in their encoded form. This is the form needed for input
870to digital signing and signature verification processes. Type BiometricObject is a sequence
871composed of two components, a biometric header and biometric data.
872
873The integrityBlock component is a value of type IntegrityBlock, a choice type with four
874alternatives,
digitalSignature,
messageAuthenticationCode,
signedData
and
875authenticatedData. This type is defined as:
876
877
878
879
880
881
882

IntegrityBlock ::= CHOICE {

digitalSignature
messageAuthenticationCode
signedData
authenticatedData
}

DigitalSignature,
MessageAuthenticationCode,
SignedData,
AuthenticatedData

883
884The choice alternatives of type IntegrityBlock have the following meanings:
885

DigitalSignature

A simple digital signature using a fixed key pair

messageAuthenticationCode

A simple MAC or HMAC [12]

SignedData

A simple digital signature using a fixed key pair with origin

authentication information

AuthenticatedData

A simple MAC or HMAC with origin authentication

information

886

8875.1.2.1 DigitalSignature
888The digitalSignature choice alternative of the integrityBlock component of type
889IntegrityObjects is a value of type DigitalSignature. This type is a sequence of two
890components, an algorithm identifier and a digital signature. Type DigitalSignature is defined as
891
892
893
894
895
896

DigitalSignature ::= SEQUENCE {

algorithmID SignatureAlgorithmIdentifier,
signature
OCTET STRING
( CONSTRAINED BY { -- signature on a value of -EncodedBiometricObjects })

101XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 26

103
104
897

898
899Here EncodedBiometricObjects is a value of type BiometricObjects in its encoded form. Type
900BiometricObjects is a series of one or more values of type BiometricObject. It is a value of type
901EncodedBiometricObjects that is digitally signed.
902
903A value of the digitalSignature choice alternative of the integrityBlock component of type
904IntegrityObjects can be represented in XML markup as
905
906
907
908
909
910
911
912
913
914
915
916

917

918
919This markup uses the digitalSignature choice alternative of the integrity block, a value of type
920DigitalSignature. This type provides a simple digital signature on a value of type
921EncodedBiometricObjects. The Digital Signature Algorithm (DSA) [8] with Secure Hash
922Algorithm (SHA1) [9] and its associated parameters, <NullParms/> is used for signing a value
923of EncodedBiometricObjects. An ellipsis is used as a placeholder where part of the signature is
924not shown.

9255.1.2.1.1 Digital Signature Process

926A message digest is used to create the digital signature carried in the signature component of
927DigitalSignature. The message digest and signature are calculated using the algorithm and
928parameters specified in the algorithmID component of DigitalSignature. The digest is performed
929on the complete CXER encoding of a value of type BiometricObjects.
930
931
932

NOTE This encoding is always used for the digest, whether the same encoding
is used for transfer or not (see 7.4.1: Encodings used for calculation of digital
signatures and MACs).

933
934When a value of type DigitalSignature is represented as XML markup, the starting and ending
935EncodedBiometricObjects tags are excluded from the message digest process. Only the
936"value" portion of the complete CXER encoding of EncodedBiometricObjects is digested. The
937<EncodedBiometricObject> and </EncodedBiometricObject> tags are excluded from
938the message digest process, and the digest is calculated starting with the
939<BiometricObjects> tag and ending with the </BiometricObjects> tag.
940
941The result of the message digest process is then digitally signed using the signers private key
942and the signature algorithm and parameters specified in the algorithmID component of
943DigitalSignature. The result of the signature process is an octet string, which becomes the value
944of the signature component of DigitalSignature.

105XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 27

107
108
945
946
947

NOTE The value of this octet string is encoded according to the encoding rules
used for transfer (see 7.4.3 Outer-level encodings). A BASE64 encoding is not
employed.

948

9495.1.2.1.2 Digital Signature Verification

950To verify the signature in a digital signature choice alternative of the integrityBlock component of
951type IntegrityObjects, a message digest is computed over the complete CXER encoding of the
952value of the biometricObjects component of type IntegrityObjects using the algorithm and any
953associated parameters indicated in the algorithmID component of DigitalSignature. The
954resulting message digest value is compared to the value of the hash obtained from applying the
955signature verification key to the signature component of type DigitalSignature to determine if
956this signature is valid.

9575.1.2.2 MessageAuthenticationCode
958The messageAuthenticationCode choice alternative of the integrityBlock component of type
959IntegrityObjects is a value of type MessageAuthenticationCode. This type is a sequence of
960two components, an algorithm identifier and a message authentication code (or hashed message
961authentication code). Type MessageAuthenticationCode is defined as
962
963
964
965
966
967
968
969

MessageAuthenticationCode ::= SEQUENCE {

keyName
OCTET STRING OPTIONAL,
algorithmID MACAlgorithmIdentifier,
mac
OCTET STRING
( CONSTRAINED BY { -- MAC or HMAC on a value of -EncodedBiometricObjects })
}

970
971A MessageAuthenticationCode provides a way to verify the integrity of biometric information
972using a secret authentication key. This secret key is shared between a sender and recipient. An
973HMAC is a message authentication method based on a cryptographic hash function, a keyed974hash method. The cryptographic strength of an HMAC depends on the strength of the underlying
975hash function. For this reason, the Secure Hash Algorithm (SHA1) is widely used.
976
977For both MAC and HMAC, cryptographic keys shall be chosen at random when created, and shall
978be protected and kept secret, and exchanged securely. The minimum length of the key used with
979HMAC depends on the choice of underlying hash function. Good security practices demand that
980keys be refreshed periodically to guard against weaknesses in keys and to minimize exposure
981from an attack.
982
983A
value of the messageAuthenticationCode choice alternative of the integrityBlock
984component of type IntegrityObjects can be represented in XML markup as
985
986
987
988
989
990
991
992
993

<integrityBlock>
<messageAuthenticationCode>
<keyName> 9FCD...AB45 </keyName>
<algorithmID>
<algorithm>1.3.6.1.5.5.8.1.2</algorithm>
</algorithmID>
<mac>
DEA7B ... 59ABD3

109XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 28

111
112
994
995
996

</mac>
</messageAuthenticationCode>
</integrityBlock>

997
998This markup uses the message authentication code choice alternative. The hashed MAC with
999SHA1 algorithm and a shared secret key are used to compute an HMAC on a value of
1000EncodedBiometricObjects. An ellipsis is used as a placeholder for part of the HMAC results.

10015.1.2.2.1 Message Authentication Process

1002A sender prepares a value of type EncodedBiometricObjects, a named cryptographic key
1003previously created at random and known by the recipient, and uses these as input to a MAC or
1004HMAC process. This results in a message authentication code over the specified biometric
1005information. The biometric information and processing results are sent to a recipient who shares
1006the secret key used in the message authentication code process.
1007
1008To verify the message authentication code, the user computes a MAC or HMAC on the biometric
1009information using the same shared secret key identified by its key name, and compares this result
1010to the message authentication value received to determine the integrity of the biometric
1011information.

10125.1.2.3 SignedData
1013The signedData choice alternative of the integrityBlock component of type IntegrityObjects is
1014a value of type SignedData. This sequence type is defined as
1015
1016
1017
1018
1019
1020
1021
1022
1023

SignedData ::= SEQUENCE {

version
CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates
[0] CertificateSet OPTIONAL,
crls
[1] CertificateRevocationLists
signerInfos
SignerInfos
}

OPTIONAL,

1024
1025The components of type SignedData have the following meanings:
1026

version

An integer version number of the syntax definition. The version shall be

84 in this standard.

digestAlgorithms

The set of message digest algorithms used by the signers. This set
contains only one element since there is only one signer of the content in
this standard.

encapContentInfo

An identifier of the type of content signed and optionally, the signed

content. In this standard the signed content is not present. The type of
content is always ordinary data as the nesting of cryptographic types is
neither required nor supported.

certificates

An optional set of one or more X.509 [1] or X9.68 [11] certificates. When
present, this set may contain more certificates or less than needed to
verify the signature on the signed data. This component shall be encoded
as specified in 7.4.2 Octet Strings with Certificates and Certificate
Revocation Lists.

113XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 29

115
116

crls

An optional set of one or more X.509 certificate revocation lists (CRLs).

When present, there may be more CRLs or less than needed to
determine whether or not the certificate of the signer is valid. This
component shall be encoded as specified in 7.4.2 Octet Strings with
Certificates and Certificate Revocation Lists.

signerInfos

A set of information for each signer of the content. This set contains only
one element since there is only one signer of the content in this standard.

1027
1028

SignerInfos ::= SET SIZE(1) OF SignerInfo

1029
1030
1031
1032
1033
1034
1035
1036

SignerInfo ::= SEQUENCE {

version
CMSVersion,
sid
SignerIdentifier,
digestAlgorithm
DigestAlgorithmIdentifier,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature
SignatureValue
}

1037
1038The SignerIdentifier type is used to identify the public key certificate associated with the private
1039key used to create the signature component of SignerInfo. This type is defined in XCBF as a
1040choice type having only one alternative:
1041
1042
1043
1044

SignerIdentifier ::= CHOICE {

certHash [1] EXPLICIT Hash
}

1045
1046The certHash choice alternative of SignerIdentifier provides a single, simple mechanism that
1047allows any type of digital certificate to be identified. The hash is computed over the complete
1048encoding of the certificate. This allows any type of certificate, regardless of its format or encoding,
1049to be identified.
1050
1051When X.509 certificates or attribute certificates are used, the hash will be computed over the
1052complete DER [6] encoding of the certificate, as X.509 only supports these encoding rules. When
1053X9.68 domain certificates are used, the hash may be computed over the DER or XER encoding
1054of the certificate, as either encoding format is supported by that standard. In any case, such
1055details are hidden from an application if the certificates is properly treated as an opaque series of
1056octets.
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068

Hash ::= CHOICE {

ietf
CertHash, -- SHA-1 hash of entire certificate
withAlgID DigestInfo
}
CertHash ::= OCTET STRING (ENCODED BY sha-1)
DigestInfo ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
digest
OCTET STRING
}

1069
117XML Common Biometric Format (XCBF) Committee Specification 1.1
118Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 30

119
120

10705.1.2.3.1 Message digest and signature process

1071A message digest is used to create the digital signature carried in the SignerInfo component of
1072SignedData. The message digest is calculated using the algorithm and parameters specified in
1073the digestAlgorithm component of SignerInfo, and the value of the eContent component of
1074EncapsulatedContentInfo. The eContentType component of EncapsulatedContentInfo
1075identifies the type of value being signed. This is always the object identifier value id-data in
1076XCBF.
1077
1078When a value of type SignedData is represented as XML markup, the starting and ending
1079eContent tags are excluded from the message digest process. Only the "value" portion of the
1080complete canonical XER encoding of eContent is digested. The <eContent> and </eContent>
1081tags are excluded from the message digest process, and the digest is calculated starting with the
1082<BiometricObjects> tag and ending with the </BiometricObjects> tag.
1083
1084The result of the message digest process is then digitally signed using the signers private key
1085and the signature algorithm and parameters specified in the signatureAlgorithm component of
1086SignerInfo. The result of the signature process becomes the value of the signature component
1087of the SignerInfo component of SignedData.
1088

10895.1.2.3.2 Signature Verification

1090To verify the signature in a signed data choice alternative of the integrityBlock component of
1091type IntegrityObjects, a message digest is computed over the complete canonical XER
1092encoding of the value of the biometricObjects component of type IntegrityObjects. This digest
1093is computed using the digestAlgorithm component of type SignerInfo.
1094
1095The public key of the signer is the signature verification key. This key is used to verify the digital
1096signature on the signed data created with the signers private key. The signature is carried in the
1097SignerInfo component of type SignedData. The value of the sid component of SignerInfo
1098identifies the public key certificate associated with the private key used to create the digital
1099signature on the signed data.
1100
1101The message digest value computed by the signature verifier is compared to the value of the
1102hash obtained from applying the signers public key to the signature component of type
1103SignerInfo to determine if this signature is valid. There is only one signer of the content in this
1104standard.
1105
1106Complete trust in the validity of the signature on the signed data by the signer must be
1107determined by validation of the chain of certificates associated with the signers public key
1108certificate. The optional certificates and crls components of type SignedData may be used by
1109the signer to provide information needed to validate the signers certificate.

11105.1.2.4 AuthenticatedData
1111The messageAuthenticationCode choice alternative of the integrityBlock component of type
1112IntegrityObjects is a value of type AuthenticatedData. This sequence type provides a MAC with
1113key establishment and is defined as
1114
1115
1116

AuthenticatedData ::= SEQUENCE {

version
CMSVersion,

121XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 31

123
124
1117
1118
1119
1120
1121

recipientInfos
macAlgorithm
encapContentInfo
mac

RecipientInfos,
MACAlgorithmIdentifier,
EncapsulatedContentInfo,
MessageAuthenticationCode

1122
1123Type AuthenticatedData uses a key transport mechanism to convey a one-time MAC key along
1124with biometric information. Since a key agreement mechanism is not supported, only data
1125integrity is provided by use of this type and not origin authentication. There is only a single
1126recipient of this encrypted MAC key present in the recipientInfos component of type
1127AuthenticatedData, and the optional content is not present in the encapContentInfo
1128component.
1129
1130A message authentication code is calculated on biometric information. This biometric information
1131is a value of type EncodedBiometricObjects, which is a value of type BiometricObjects in its
1132encoded form. The calculation is performed using the MAC algorithm and any associated
1133algorithm parameters indicated in the macAlgorithm component of type AuthenticatedData,
1134the biometric information, and an authentication key that is conveyed in the recipientInfos
1135component. The result of this calculation is a message authentication code, which becomes the
1136value of the mac component.
1137
1138A value of the privacyObjects choice alternative of type BiometricSyntax can be represented
1139in XML markup as
1140
1141
1142
1143
1144
1145
1146
1147

1148
1149This markup illustrates the wrapper for a typical privacy object. The optional privacy object
1150biometric headers are not present. An ellipsis is used as a placeholder and the details of the
1151privacy block choice alternative are not shown.
1152

11535.1.2.5 Biometric Certificate Extensions

1154Digital signature data integrity protection and origin authentication can be achieved by including
1155biometric information in digital certificates. A set of one or more biometric reference templates
1156can be cryptographically bound to the public key associated with the private key of an entity, by
1157including a value of type EncodedBiometricObjects in a certificate extension. In the XCBF
1158standard, biometric certificate extension values can be encoded in either BER or BASIC-XER
1159depending on the outer-level encoding (see 7.4.3 Outer-level encodings).
1160
1161XCBF supports the version three certificates and version two attribute certificates defined in the
1162X.509 standard and the compact domain certificate format defined in X9.68. One extension is
1163defined for use in each standard, and these are defined as
1164
1165

biometricTemplates EXTENSION ::= {

125XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 32

127
128
1166
1167
1168

1169
1170
1171
1172
1173

domainBiometricTemplates PRIVATE-X ::= {

NAME oid : x968-biometricTemplates
TYPE EncodedBiometricObjects -- CXER -}

SYNTAX
IDENTIFIED BY

EncodedBiometricObjects
x509-biometricTemplates

-- CXER --

1174
1175When biometric information is included in a certificate extension stored in a certificate repository,
1176the repository becomes a biometric storage subsystem, and the biometric information may need
1177to be protected by encryption or other means. Measures should be taken to prevent an attacker
1178from using a certificate repository as a large, searchable public database of biometric reference
1179templates that could be used to find templates that match a given biometric sample. Finding such
1180a match would allow an attacker to focus its efforts on that user.

11815.1.3 PrivacyObjects
1182The privacyObjects choice alternative of type BiometricSyntax is a value of type
1183PrivacyObjects. This type is defined as a sequence of two components, biometricHeaders and
1184privacyBlock.
1185
1186
1187
1188
1189

PrivacyObjects ::= SEQUENCE {

biometricHeaders BiometricHeaders
privacyBlock
PrivacyBlock
}

OPTIONAL,

1190
1191The biometricHeaders component is a series of one or more values of type BiometricHeader.
1192
1193

BiometricHeaders ::= SEQUENCE SIZE(1..MAX) OF BiometricHeader

1194
1195This optional biometricHeaders component is not protected by encryption and should be present
1196only when a privacy object is used in a secure environment, or when the information contained in
1197the biometricHeaders component does not compromise security or assist an attacker. In a
1198secure setting these biometric headers may be used as a convenience, to assist in searches of
1199biometric information and in database management operations.
1200
1201The encrypted content in the privacy block contains a series of one or more values of type
1202BiometricObject, including their biometric headers. To be useful, the biometricHeaders
1203component need only provide an indication of the information contained in the encrypted privacy
1204block. But this component need not contain exactly the same information as the headers in the
1205encrypted privacy block, and may contain only a single BiometricHeader value when present.
1206The biometricHeaders component is not protected in any way.
1207
1208The privacyBlock component of type PrivacyObjects offers three choice alternatives, fixedKey,
1209namedKey and establishedKey.
1210
1211
1212
1213

PrivacyBlock ::= CHOICE {

fixedKey
EncryptedData,
namedKey
NamedKeyEncryptedData,

129XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 33

131
132
1214
1215

establishedKey

EnvelopedData

1216
1217The fixedKey and namedKey choice alternatives are based on the EncryptedData type. The
1218establishedKey alternative is based on type EnvelopedData. Each of these alternatives has
1219different characteristics, and the alternative chosen will depend upon application requirements
1220and the key management scheme being used.
1221
1222A value of the privacyObjects choice alternative of type BiometricSyntax can be represented
1223in XML markup as
1224
1225
1226
1227
1228
1229
1230
1231

1232
1233This markup illustrates the wrapper for a typical privacy object. The optional privacy object
1234biometric headers are not present. An ellipsis is used as a placeholder and the details of the
1235privacy block choice alternative are not shown.

12365.1.3.1 Encrypted Content Information

1237All three of the privacy block choice alternatives contain a value of type EncryptedContentInfo
1238defined as
1239
1240
1241
1242
1243
1244

EncryptedContentInfo ::= SEQUENCE {

contentType
ContentType,
contentEncryptionAlgorithm ContentEncryptAlgorithmIdentifier,
encryptedContent
[0] EncryptedContent
}

1245
1246The contentType component identifies the type of encrypted content. In XCBF, the type of
1247encrypted content is always a value of EncodedBiometricObjects, a series of one or more
1248values of type BiometricObject encoded using CXER. The type of encrypted content is identified
1249as ordinary data by the information object identifier value id-data, defined in the PKCS #7
1250Cryptographic Message Syntax Standard [19]. The encoding of this component is
1251
1252

<contentType> 1.2.840.113549.1.7.1 </contentType>

1253
1254The contentEncryptionAlgorithm component identifies the content encryption algorithm and
1255any associated parameters used to encrypt and decrypt the EncodedBiometricObjects. This
1256content encryption algorithm is a value of type ContentEncryptionAlgorithmIdentifier defined
1257as
1258
1259
1260

ContentEncryptAlgorithmIdentifier ::=
AlgorithmIdentifier {{ContentEncryptionAlgorithms}}

133XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 34

135
136
1261
1262The definition of type ContentEncryptionAlgorithmIdentifier is based on the parameterized
1263type AlgorithmIdentifier {} and the information object set ContentEncryptionAlgorithms,
1264defined as
1265
1266
1267
1268
1269

ContentEncryptionAlgorithms ALGORITHM ::= {

{ OID des-ede3-cbc PARMS IV },
... -- Expect other content encryption algorithms -}

1270
1271

IV ::= OCTET STRING (SIZE(8))

1272
1273ContentEncryptionAlgorithms specifies an extensible set of ALGORITHM information objects.
1274The fields of these information objects are used to constrain the valid values of the components
1275of type ContentEncryptionAlgorithmIdentifier. Though only one content encryption algorithm
1276object is defined explicitly in this set, implementations should expect additional algorithms.
1277
1278The ContentEncryptionAlgorithms information object set contains a single object that identifies
1279the encryption algorithm described in ANSI X9.52 [10] as Triple DES (TDES) in CBC (cipher
1280block chaining) mode. Only the two key and three key variants of TDES are supported in XCBF.
1281The single key variant of TDES is simply the DES algorithm and is generally used only for
1282backwards compatibility with existing DES based applications and is considered vulnerable to
1283attack.
1284
1285The Triple DES algorithm consists of three sequential DES operations, encrypt, decrypt, and
1286encrypt. For three key TDES a different key is used for each DES operation. For two key TDES
1287one key is used for both DES encrypt operations, and the second key is used for the DES decrypt
1288operation.
1289
1290The encryptedContent component contains a value of type EncodedBiometricObjects
1291encrypted using the content encryption algorithm given in the contentEncryptionAlgorithm
1292component. A value of encryptedContent is an opaque string of octets treated as having no
1293discernable structure. This string is a value of type EncryptedContent defined as
1294
1295

EncryptedContent ::= OCTET STRING

1296
1297A value of the encryptedContentInfo component of any of the privacy block choice alternative
1298types can be represented in XML markup as
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311

137XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 35

139
140
1312
1313This markup illustrates a typical value. The encrypted content type is identified as ordinary data.
1314The Triple DES content encryption algorithm is identified along with its associated parameters, an
1315initialization vector, <IV>. An ellipsis is used as a placeholder for part of the encrypted content.

13165.1.3.2 Fixed Key EncryptedData

1317The fixedKey choice alternative of the privacyBlock component of type PrivacyObjects is a
1318value of type EncryptedData. This type is a sequence of two components, an integer version
1319number and a value of type EncryptedContentInfo. Type EncryptedData is defined as
1320
1321
1322
1323
1324

EncryptedData ::= SEQUENCE {

version
CMSVersion,
encryptedContentInfo EncryptedContentInfo
}

1325
1326The fixedKey alternative assumes that the recipient of the EncryptedData value knows the key
1327used to encrypt the biometric information, perhaps by prior agreement or as the result of a key
1328exchange. The version component of type EncryptedData is always the integer value eighty1329four. The components of type EncryptedContentInfo are described in section 4.1.3.1 Encrypted
1330Content Information.
1331
1332A
value of the fixedKey choice alternative of the privacyBlock component of type
1333PrivacyObjects can be represented in XML markup as
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349

1350
1351This markup uses the fixed key choice alternative of the privacy block, a value of version number
1352eighty-four of the cryptographic message type EncryptedData. The encrypted content type is
1353identified as ordinary data. The Triple DES content encryption algorithm is identified along with its
1354associated parameters, an initialization vector, <IV>. An ellipsis is used as a placeholder and the
1355encrypted content is not shown.

13565.1.3.2.1 Encryption Process

1357A value of type EncryptedData is created by encrypting a series of one or more values of type
1358BiometricObject in their encoded form using a content encryption algorithm and a fixed content
1359encryption key known to the sender and recipient. The content to be encrypted is a value of type
1360EncodedBiometricObjects. This value is always encoded using CXER. The content encryption
141XML Common Biometric Format (XCBF) Committee Specification 1.1
142Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 36

143
144
1361algorithm used to encrypt the biometric objects is one of the algorithms specified in the
1362information object set ContentEncryptionAlgorithms.
1363
1364The contentType component of type EncryptedContentInfo is set to indicate ordinary data. The
1365associated contentEncryptionAlgorithm value is set to identify the algorithm used to encrypt
1366the content, and the encryptedContent value is set to the results of encrypting the content using
1367this content encryption algorithm.

13685.1.3.2.2 Decryption Process

1369To decrypt a value of type EncryptedData, the content encryption algorithm specified in the
1370contentEncryptionAlgorithm component of type EncryptedContentInfo is applied to the
1371associated encryptedContent component using a known fixed key to recover a value of type
1372EncodedBiometricObjects. This recovered value will contain one or more values of type
1373BiometricObject encoded using CXER.

13745.1.3.3 Named Key EncryptedData

1375The namedKey choice alternative of the privacyBlock component of type PrivacyObjects is a
1376value of type NamedKeyEncryptedData. This type is sequence with two components, keyName
1377and encryptedData. Type NamedKeyEncryptedData is defined as
1378
1379
1380
1381
1382

NamedKeyEncryptedData ::= SEQUENCE {

keyName
OCTET STRING (SIZE(1..MAX)),
encryptedData EncryptedData
}

1383
1384The keyName component explicitly identifies the key used to encrypt and decrypt the content by
1385name. The encryptedData component is a value of type EncryptedData. This type contains two
1386components, an integer version number that is always eighty-four in this standard, and an
1387encryptedContentInfo that is a value of type EncryptedContentInfo as described in section
13884.1.3.1 Encrypted Content Information.
1389
1390A value of the namedKey choice alternative of the privacyBlock component of type
1391PrivacyObjects can be represented in XML markup as
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410

145XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 37

147
148
1411
1412This markup uses the named key choice alternative of the privacy block, a sequence of a key
1413name and a value of version number eighty-four of the cryptographic message type
1414EncryptedData. The encrypted content type is identified as ordinary data. The Triple DES
1415content encryption algorithm is identified along with its associated parameters, an initialization
1416vector, <IV>. An ellipsis is used as a placeholder and the encrypted content is not shown.

14175.1.3.3.1 Encryption Process

1418A value of type EncryptedData is created by encrypting a series of one or more values of type
1419BiometricObject in their encoded form using a content encryption algorithm and a named key
1420that is known to the recipient of the encrypted biometric information. The content to be encrypted
1421is a value of type EncodedBiometricObjects. This value is always encoded using CXER. The
1422content encryption algorithm used to encrypt the biometric objects is one of the algorithms
1423specified in the information object set ContentEncryptionAlgorithms.
1424
1425The keyName component of type NamedKeyEncryptedData is set to the name of the content
1426encryption key. The contentType component of type EncryptedContentInfo is set to indicate
1427ordinary data. The associated contentEncryptionAlgorithm value is set to identify the algorithm
1428used to encrypt the content, and the encryptedContent value is set to the results of encrypting
1429the content using this content encryption algorithm.

14305.1.3.3.2 Decryption Process

1431To decrypt a value of type NamedKeyEncryptedData, the content encryption algorithm specified
1432in the contentEncryptionAlgorithm component of type EncryptedContentInfo is applied to the
1433associated encryptedContent component using the key identified by the keyName component
1434of type NamedKeyEncryptedData to recover a value of type EncodedBiometricObjects. This
1435recovered value will contain one or more values of type BiometricObject encoded using CXER.

14365.1.3.4 Established Key EnvelopedData

1437The establishedKey choice alternative of the privacyBlock component of type PrivacyObjects
1438is a value of type EnvelopedData. Using this type, a message sender can encrypt content that
1439only the intended message recipient can decrypt.
1440
1441EnvelopedData is defined as a sequence of four components, an integer version number,
1442message sender information, message recipient information, and a value of type
1443EncryptedContentInfo which is described in section 4.1.3.1 Encrypted Content Information.
1444Type EnvelopedData is defined as
1445
1446
1447
1448
1449
1450
1451

EnvelopedData ::= SEQUENCE {

version
CMSVersion,
originatorInfo
[0] OriginatorInfo OPTIONAL,
recipientInfos
RecipientInfos,
encryptedContentInfo EncryptedContentInfo
}

1452
1453The combination of encrypted content and an encrypted content encryption key forms a digital
1454envelope. The establishedKey alternative uses a randomly generated content encryption key to
1455encrypt digital content. The same key is used to decrypt the content. The content encryption key
1456shall be protected during transport, so the recipients public and private key pair is used to
1457encrypt and decrypt the content encryption key.
1458
149XML Common Biometric Format (XCBF) Committee Specification 1.1
150Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 38

151
152
1459The encrypted content is value of type EncodedBiometricObjects. This type is a series of one
1460or more values of type BiometricObject in their encoded form. In XCBF these values are
1461encoded using CXER.
1462
1463The version component of type EnvelopedData is the integer value eighty-four. The optional
1464originatorInfo component facilitates distribution of digital certificates and certificate revocation
1465lists. The recipientInfos component contains information needed to recover the encrypted
1466content encryption key used to encrypt the biometric information. The encryptedContentInfo
1467component is a value of type EncryptedContentInfo. This type is described in section 4.1.3.1
1468Encrypted Content Information.
1469
1470A value of the establishedKey choice alternative of the privacyBlock component of type
1471PrivacyObjects can be represented in XML markup as
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508

1509
1510This markup uses the established key choice alternative of the privacy block, a value of version
1511number eighty-four of the cryptographic message type EnvelopedData. The optional originator
1512information is not present. The recipient information uses the key transport choice alternative.
1513The recipient public and private key pair is indicated by a SHA1 hash of a public key certificate.
1514The content encryption key is encrypted using the rsaEncryption algorithm, which has no
1515associated parameters indicating that no initialization vector is required. The encrypted content
153XML Common Biometric Format (XCBF) Committee Specification 1.1
154Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 39

155
156
1516type is identified as ordinary data. The Triple DES content encryption algorithm is identified along
1517with its associated parameters, an initialization vector, <IV>. An ellipsis is used as a placeholder
1518and the encrypted content encryption key and the encrypted content are not shown.
1519

15205.1.3.4.1 Certificates and CRLs

1521Type OriginatorInfo is a sequence of two components that may contain sets of digital certificates
1522and certificate revocation lists (CRLs). This type is defined as
1523
1524
1525
1526
1527
1528

OriginatorInfo ::= SEQUENCE {

certs [0] CertificateSet OPTIONAL,
crls
[1] CertificateRevocationLists OPTIONAL
}
(ALL EXCEPT({ -- none; at least one component is present -- }))

1529
1530Any combination of X9.68 domain certificates, X.509 certificates and attribute certificates may be
1531included in the CertificateSet type in any order. There may be more or fewer certificates needed
1532for any purpose. Certificates are provided as needed to support content key encryption in the key
1533transport key management technique used in XCBF. Use of the CertificateSet type to distribute
1534certificates is not required. They may be obtained by other means, or an online certificate
1535validation service may be used instead. Only version one X9.68 domain certificates, version three
1536X.509 certificates and version two attribute certificates are supported in this standard. The value
1537of the CertificateSet octet string shall be the concatenation of the DER encodings of one or more
1538X.509 certificate and attribute certificate types. The encoding of this octet string is specified in
15397.4.2: Octet Strings with Certificates and Certificate Revocation Lists.
1540
1541Any number of CRLs may be included in the CertificateRevocationLists type in any order.
1542There may be more or fewer CRLs needed for any purpose. CRLs are provided as needed to
1543support certificate validation. Use of the CertificateRevocationLists type to distribute CRLs is
1544not required. CRLs may be obtained by other means, or an online certificate validation service
1545may be used instead. Only version two certificate revocation lists are supported in this standard.
1546The value of the CertificateRevocationList octet string shall be the concatenation of the DER
1547encodings of one or more X.509 CRLs. The encoding of this octet string is specified in 7.4.2:
1548Octet Strings with Certificates and Certificate Revocation Lists.
1549
1550The X.509 certificates and certificate revocation lists used in XCBF are signed binary objects,
1551whose digital signatures have been calculated on values encoded using the Distinguished
1552Encoding Rules (DER) of ASN.1. In order to verify the signatures on these objects, their original
1553encodings must be used. This is not affected by any representation (such as a base 64
1554encoding) used for transfer (see 7.4.2: Octet Strings with Certificates and Certificate Revocation
1555Lists).

15565.1.3.4.2 Recipient Information

1557Type RecipientInfos is a series of values of type RecipientInfo, one value for each recipient of a
1558digital envelope in EnvelopedData. In XCBF there is always a single digital envelope recipient,
1559and type RecipientInfos is constrained to a series of one RecipientInfo and defined as
1560
1561

RecipientInfos ::= SET SIZE(1) OF RecipientInfo

1562

157XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 40

159
160
1563Several key management techniques can be used in EnvelopedData. In XCBF, only key
1564transport is supported. Other techniques such as constructive key management may be
1565employed by an application, but such use in not defined in this standard. Type RecipientInfo is
1566restricted to a single choice alternative and defined as
1567
1568
1569
1570

RecipientInfo ::= CHOICE {

ktri KeyTransRecipientInfo
}

1571
1572Key transport information is provided to the recipient of a digital envelope so that the envelope
1573can be opened and the protected content encryption key recovered. The content encryption key
1574may then be used to decrypt the content.
1575
1576The information needed by the recipient to recover the content encryption key is contained in a
1577value of type KeyTransRecipientInfo defined as
1578
1579
1580
1581
1582
1583
1584

KeyTransRecipientInfo ::= SEQUENCE {

version
CMSVersion,
rid
RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey
EncryptedKey
}

1585
1586This type is a sequence of four components. The integer version number is always set to eighty1587four in XCBF. The rid component is used to identify the public key used to encrypt the content
1588encryption key. This public key is bound to a key encryption algorithm in a public key certificate. It
1589is associated with the recipient private key needed to decrypt the content encryption key used by
1590the sender to encrypt the content.
1591
1592A hash of the public key certificate uniquely identifies the recipient certificate.
1593
1594
1595
1596

RecipientIdentifier ::= CHOICE {

certHash [73] EXPLICIT Hash
}

1597
1598The keyEncryptionAlgorithm component identifies the key encryption algorithm and any
1599associated parameters used to encrypt the content encryption key.
1600
1601
1602

KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{KeyEncryptionAlgorithms}}

1603
1604
1605

KeyEncryptionAlgorithms ALGORITHM ::= {

{ OID rsaEncryption PARMS NullParms },

1606
1607
1608

...

-- expect other key encryption algorithms --

1609
1610The encrypted content encryption key is an opaque string, a value of type EncryptedKey defined
1611as
161XML Common Biometric Format (XCBF) Committee Specification 1.1
162Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 41

163
164
1612
1613

EncryptedKey ::= OCTET STRING

1614

16155.1.3.4.3 Digital Envelope Processing

1616To create a digital envelope, a content encryption algorithm is selected. The content encryption
1617algorithm identifier and any associated parameters form the contentEncryptionAlgorithm value
1618of the encryptedContentInfo component of type EnvelopedData. The recipient uses this value
1619to recover the encrypted content.
1620
1621The content encryption key is encrypted using the key encryption algorithm and key transport
1622public key from the recipients public key certificate. This certificate must contain a key usage
1623extension which asserts the keyEncipherment bit. The key encryption algorithm identifier and
1624any associated parameters used to encrypt the content encryption key with the key transport
1625public key form the keyEncryptionAlgorithm component of type KeyTransRecipientInfo.
1626
1627The result of encrypting the content encryption key forms the encryptedKey component of type
1628KeyTransRecipientInfo. A hash of the complete DER encoding of the recipients public key
1629certificate is used to populate the rid component, and the version component is set to the integer
1630eighty-four. This certificate hash mechanism provides a single way to uniquely identify any type of
1631certificate. This is the only form of certificate identification supported in XCBF.
1632
1633The content encryption key is used to encrypt a value of type EncodedBiometricObjects. This
1634type is a series of one or more values of type BiometricObject in their encoded form. These
1635values are encoded using CXER.
1636
1637To retrieve the encrypted content, the recipient first decrypts the value of the encryptedKey
1638component of type KeyTransRecipientInfo to recover the content encryption key using the
1639private key associated with the public key used to encrypt the content encryption key. This private
1640key is indicated by the hash of the associated public key certificate in the rid component of type
1641KeyTransRecipientInfo. The recovered content encryption key is then used to decrypt the
1642content to recover a value of type EncodedBiometricObjects.

16435.1.4 PrivacyAndIntegrityObjects
1644The privacyAndIntegrityObjects choice alternative of type BiometricSyntax is a value of type
1645PrivacyAndIntegrityObjects. This type is defined as a sequence of three components, optional
1646biometricHeaders, a privacyBlock, and an integrityBlock.
1647
1648
1649
1650
1651
1652

PrivacyAndIntegrityObjects ::= SEQUENCE {

biometricHeaders BiometricHeaders OPTIONAL,
privacyBlock
PrivacyBlock,
integrityBlock
IntegrityBlock
}

1653
1654The biometricHeaders component is optional and is composed of a series of one or more values
1655of type BiometricHeader. The privacyBlock component is a value of type PrivacyBlock. The
1656BiometricHeader and PrivacyBlock types are described in section 4.1.3. PrivacyObjects. The
1657integrityBlock component is a value of type IntegrityBlock. This type is described in section
16584.1.2. IntegrityObjects.
165XML Common Biometric Format (XCBF) Committee Specification 1.1
166Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 42

167
168
1659
1660The input to all cryptographic process is a value of type EncodedBiometricObjects, a series of
1661one or more values of type BiometricObject in their encoded form using CXER. The order of the
1662components in type PrivacyAndIntegrityObjects facilitates one pass processing for both sender
1663and recipient.
1664
1665For the sender, a value of type EncodedBiometricObjects is created and then used as input to
1666the cryptographic processing of both the privacyBlock and integrityBlock components. For the
1667recipient, the privacyBlock component is first processed to recover the encrypted content, a
1668value of type EncodedBiometricObjects. This recovered value is then used to validate the
1669signature in the integrityBlock component.
1670
1671A value of the privacyAndIntegrityObjects choice alternative of type BiometricSyntax can be
1672represented in XML markup as
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706

1707
1708This markup combines a privacy block and integrity block. The named key choice alternative of
1709the privacy block and the digital signature choice alternative of the integrity block are used. The
1710optional biometric headers are not present.
1711
1712The named key alternative is a sequence containing a key name and a value of version number
1713eighty-four of the cryptographic message type EncryptedData. The encrypted content type is
1714identified as ordinary data, and is computed on a value of type EncodedBiometricObjects. The
169XML Common Biometric Format (XCBF) Committee Specification 1.1
170Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 43

171
172
1715Triple DES content encryption algorithm is identified along with its associated parameters, an
1716initialization vector, <IV>. An ellipsis is used as a placeholder and the encrypted content is not
1717shown.
1718
1719The digital signature choice alternative is a simple digital signature on a value of type
1720EncodedBiometricObjects. The Digital Signature Algorithm (DSA) with Secure Hash Algorithm
1721(SHA1) and its associated parameters, <NullParms/> are used for signing a value of
1722EncodedBiometricObjects. An ellipsis is used as a placeholder and the signature is not shown.

173XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 44

175
176

17236

References

17246.1 Normative
1725
1726These references or an understanding of the materials within them are required to implement this
1727XCBF standard. They are intended to include any amendments and technical corrigenda issued
1728after their publication. Users of this standard are encouraged to seek the latest versions of these
1729referenced materials before initiating any serious work.
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769

1
2

8
9
10
11
12
13
14
15
16
17

ISO/IEC 9594-8: Information technology | ITU-T Recommendation X.509, Open

Systems Interconnection -- The Directory: Authentication framework.
ISO/IEC 8824-1:2002 | ITU-T Recommendation X.680 (2002), Information Technology
- Abstract Syntax Notation One (ASN.1): Specification of Basic Notation,
http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf.
ISO/IEC 8824-2:2002 | ITU-T Recommendation X.681 (2002), Information Technology
- Abstract Syntax Notation One (ASN.1):
Information Object Specification,
http://www.itu.int/ITU-T/studygroups/com17/languages/X681_0702.pdf.
ISO/IEC 8824-3:2002| ITU-T Recommendation X.682 (2002), Information Technology Abstract
Syntax
Notation
One
(ASN.1):
Constraint
Specification,
http://www.itu.int/ITU-T/studygroups/com17/languages/X682_0702.pdf .
ISO/IEC 8824-4:2002| ITU-T Recommendation X.683 (2002), Information Technology Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 Specifications,
http://www.itu.int/ITU-T/studygroups/com17/languages/X683_0702.pdf.
ISO/IEC 8825-1:2002| ITU-T Recommendation X.690 (2002), Information Technology ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical
Encoding
Rules
(CER)
and
Distinguished
Encoding
Rules
(DER),
http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf.
ISO/IEC 8825-4:2002 | X.693 ITU-T Recommendation X.693 (2002) |, Information
Technology - ASN.1 Encoding Rules: XML Encoding Rules (XER),
http://www.itu.int/ITU-T/studygroups/com17/languages/X693_0702.pdf.
ANSI X9.30-1997 Public Key Cryptography for the Financial Services Industry - Part 1:
The Digital Signature Algorithm (DSA), http://webstore.ansi.org/.
ANSI X9.30-1997 Public Key Cryptography for the Financial Services Industry - Part 2:
The Secure Hash Algorithm (SHA-1), http://webstore.ansi.org/.
ANSI X9.52-1998 Triple Data Encryption Algorithm Modes of Operation,
http://webstore.ansi.org/.
ANSI X9.68:2001 Digital Certificates for Mobile/Wireless and High Transaction Volume
Financial Systems: Part 2: Domain Certificate Syntax, http://webstore.ansi.org/.
ANSI X9.71-1999 Keyed Hash Message Authentication Code (HMAC),
http://webstore.ansi.org/.
ANSI X9.73:2002 Cryptographic Message Syntax (CMS), http://webstore.ansi.org/.
ANSI X9.84:2003 Biometric Information Management and Security For The Financial
Services Industry, http://webstore.ansi.org/.
ANSI X9.96:2003 (draft) XML Cryptographic Message Syntax (XCMS).
ANSI INCITS 358-2002
- Information technology - BioAPI Specification,
http://webstore.ansi.org/.
CBEFF
Common
Biometric
Exchange
File
Format,
NISTIR-6529,
http://oasis-open.org/committees/xcbf/docs/NISTR6529-CBEFF.pdf, January 3, 2001.

177XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 45

179
180
1770
1771
1772
1773
1774
1775
1776

18
19
20

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
PKCS
#7

Cryptographic
Message
Syntax
Standard,
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/, 1 November 1993.
N. Freed and N. Borenstein, Multipurpose Internet Mail Extensions (MIME)
Part 1: Format of Internet Message Bodies, http://www.ietf.org/rfc/rfc2045.txt,
IETF RFC 2045, November 1996.

181XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 46

183
184

17777

XCBF Schema

1778The following ASN.1 modules provide the schema for all of the XML markup defined in this
1779standard.
1780

17817.1 X9-84-Biometrics Module

1782
1783
1784
1785
1786

X9-84-Biometrics {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9Standards(9) x9-84(84) module(0) biometrics(1) rev(1) }
DEFINITIONS AUTOMATIC TAGS ::= BEGIN

1787
1788

-- EXPORTS All;

1789
1790

IMPORTS

1791
1792

-- X9.84 Biometrics Information Management and Security IDs --

1793
1794
1796
1797
1798
1799
1800

BiometricTypes, CBEFF-Formats, IBIA-Formats, MatchingAIDs,

ProcessingAIDs, x509-biometricTemplates,
x968-biometricTemplates, X9-Formats
FROM X9-84-Identifiers {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9Standards(9) x9-84(84) module(0)
ids(3) rev(1) }

1801
1802

-- X9.84 Biometrics Information Management and Security CMS --

1803
1804
1805
1806
1807
1808
1809
1810
1811

AuthenticatedData, EncryptedData, EnvelopedData,

MACAlgorithmIdentifier, SignatureAlgorithmIdentifier,
SignedData
FROM X9-84-CMS {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9Standards(9) x9-84(84) module(0)
cms(2) rev(1) } ;

1795

1812
1813
1814

BiometricSyntaxSets ::= SEQUENCE SIZE(1..MAX) OF BiometricSyntax

1815
1816
1817
1818
1819
1820
1821

BiometricSyntax ::= CHOICE {

biometricObjects
integrityObjects
privacyObjects
privacyAndIntegrityObjects
}

1822
1823

BiometricObjects ::= SEQUENCE SIZE(1..MAX) OF BiometricObject

1824
1825
1826
1827
1828

BiometricObject ::= SEQUENCE {

biometricHeader BiometricHeader,
biometricData
BiometricData
}

1829
1830

BiometricObjects,
IntegrityObjects,
PrivacyObjects,
PrivacyAndIntegrityObjects

185XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 47

187
188
1831
1832
1833
1834

-- All of the cryptographic processing in this standard is performed

-- on a value of type EncodedBiometricObjects. This is a sequence of
-- one or more values of type BiometricObject in its encoded form.
--

1835
1836

EncodedBiometricObjects ::= BIOMETRIC.&Type( BiometricObjects )

1837
1838
1839
1840
1841
1842
1843
1844
1845
1846

BiometricHeader ::= SEQUENCE {

1847
1848

BiometricVersion ::= INTEGER { hv1(0) } (0..MAX)

1849
1850

RecordType ::= BIOMETRIC.&name({BiometricTypes})

1851
1852
1853
1854
1855
1856

DataType ::= ENUMERATED {

raw
(0),
intermediate (1),
processed
(2)
}

1857
1858
1859
1860
1861
1862
1863
1864

Purpose ::= ENUMERATED {

verify
(1),
identify
(2),
enroll
(3),
enrollVerify
(4),
enrollIdentity (5),
audit
(6),

1865
1866
1867

1868
1869
1870
1871
1872
1873
1874

Quality ::= INTEGER {

lowest
( 0),
highest
(100),
notSet
( -1),
notSupported ( -2)
} (-2..100,...)

1875
1876
1877
1878
1879
1880

ValidityPeriod ::= SEQUENCE {

notBefore DateTime OPTIONAL,
notAfter
DateTime OPTIONAL
}
(ALL EXCEPT({ -- none; at least one component is present --

1881
1882

DateTime ::= RELATIVE-OID

1883
1884
1885
1886
1887

Format ::= SEQUENCE {

formatOwner BIOMETRIC.&name({Owner}),
formatType
BIOMETRIC.&Type({Owner}{@formatOwner})
}

1888
1889
1890
1891
1892

Owner BIOMETRIC ::= {

CBEFF-Formats | -- http://www.nist.gov -IBIA-Formats
| -- http://www.ibia.org -X9-Formats,
-- http://www.x9.org
--

...

-- Expect other values --

}))

-- { yyyy mm dd hh mm ss z } --

OPTIONAL

1893

189XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 48

191
192
1894
1895

1896
1897

-- Integrity --

1898
1899
1900
1901
1902

IntegrityObjects ::= SEQUENCE {

biometricObjects EncodedBiometricObjects,
integrityBlock
IntegrityBlock
}

1903
1904
1905
1906
1907
1908
1909

IntegrityBlock ::= CHOICE {

digitalSignature
messageAuthenticationCode
signedData
authenticatedData
}

1910
1911
1912
1913
1914
1915

DigitalSignature ::= SEQUENCE {

algorithmID SignatureAlgorithmIdentifier,
signature
OCTET STRING( CONSTRAINED BY {
-- signature on -- EncodedBiometricObjects })
}

1916
1917
1918
1919
1920
1921
1922

MessageAuthenticationCode ::= SEQUENCE {

keyName
OCTET STRING OPTIONAL,
algorithmID MACAlgorithmIdentifier,
mac
OCTET STRING (CONSTRAINED BY {
-- MAC or HMAC on -- EncodedBiometricObjects })
}

1923
1924

-- Privacy --

1925
1926
1927
1928
1929

PrivacyObjects ::= SEQUENCE {

biometricHeaders BiometricHeaders
privacyBlock
PrivacyBlock
}

1930
1931

BiometricHeaders ::= SEQUENCE SIZE(1..MAX) OF BiometricHeader

1932
1933
1934
1935
1936
1937

PrivacyBlock ::= CHOICE {

fixedKey
EncryptedData,
namedKey
NamedKeyEncryptedData,
establishedKey EnvelopedData
}

1938
1939
1940
1941
1942

NamedKeyEncryptedData ::= SEQUENCE {

keyName
OCTET STRING (SIZE(1..MAX)),
encryptedData EncryptedData
}

1943
1944

-- Privacy and integrity --

1945
1946
1947
1948
1949
1950

PrivacyAndIntegrityObjects ::= SEQUENCE {

biometricHeaders BiometricHeaders OPTIONAL,
privacyBlock
PrivacyBlock,
integrityBlock
IntegrityBlock
}

1951
1952

-- Authentication Information (AI) --

1953
1954
1955

BiometricInformationSets ::=
SEQUENCE SIZE(1..MAX) OF BiometricInformation

...

-- expect additional vendor specific formats --

DigitalSignature,
MessageAuthenticationCode,
SignedData,
AuthenticatedData

OPTIONAL,

1956

193XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 49

195
196
1957
1958
1959
1960
1961

BiometricInformation ::= SEQUENCE {

processingAlgorithms ProcessingAlgorithms OPTIONAL,
matchingMethods
MatchingMethods OPTIONAL
}
(ALL EXCEPT({ -- none; at least one component is present -- }))

1962
1963

-- Biometric processing algorithms --

1964
1965

ProcessingAlgorithms ::= SEQUENCE SIZE(1..MAX) OF ProcessingInformation

1966
1967
1968
1969
1970

ProcessingInformation ::= SEQUENCE {

id
BIOMETRIC.&name({ProcessingAIDs}),
parms BIOMETRIC.&Type({ProcessingAIDs}{@id})
}

1971
1972

-- Biometric matching methods --

1973
1974

MatchingMethods ::= SEQUENCE SIZE(1..MAX) OF MatchingInformation

1975
1976
1977
1978
1979

MatchingInformation ::= SEQUENCE {

id
BIOMETRIC.&name({MatchingAIDs}),
parms BIOMETRIC.&Type({MatchingAIDs}{@id})
}

1980
1981

BiometricData ::= OCTET STRING(SIZE(1..MAX))

1982
1983

-- Biometrics information object class --

1984
1985
1986
1987
1988
1989

BIOMETRIC ::= CLASS {

&name BIOMETRIC-IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { BIOMETRIC &name [ DATA &Type ] }

1990
1991
1992
1993
1994

BIOMETRIC-IDENTIFIER ::= CHOICE {

oid OBJECT IDENTIFIER, -- complete object identifier
id
RELATIVE-OID
-- object identifier fragment
}

1995
1996

-- Biometric certificate extension --

1997
1998
1999
2000
2001
2002
2003

-------

2004
2005
2006
2007
2008

biometricTemplates EXTENSION ::= {

SYNTAX
EncodedBiometricObjects
IDENTIFIED BY x509-biometricTemplates
}

2009
2010
2011
2012
2013
2014

EXTENSION ::= CLASS {

&id
OBJECT IDENTIFIER UNIQUE,
&ExtnType
}
WITH SYNTAX { SYNTAX &ExtnType IDENTIFIED BY &id }

2015
2016
2017
2018
2019

--- A domainBiometricTemplates information object can be used to extend

-- the information bound to a public key in an value of ASN.1 type
-- DomainCertificate as defined in the X9.68 Domain Certificate Syntax

OPTIONAL

A biometricTemplates information object can be used to extend the

information bound to a public key in an value of types Certificate
or AttributeCertificate as defined in The Directory series of
standards, to include biometric identity information.

-- CXER --

197XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 50

199
200
2020
2021

-- standard, to include biometric identity information.

2022
2023
2024
2025
2026

domainBiometricTemplates PRIVATE-X ::= {

NAME oid : x968-biometricTemplates
TYPE EncodedBiometricObjects -- CXER -}

2027
2028
2029
2030
2031
2032

PRIVATE-X ::= CLASS {

&name Identifier UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { NAME &name [TYPE &Type] }

2033
2034
2035
2036
2037

Identifier ::= CHOICE {

oid OBJECT IDENTIFIER,
id
RELATIVE-OID
}

2038
2039

END

-- complete object identifier

-- object identifier fragment

-- X9-84-Biometrics --

2040

20417.2 X9-84-CMS Module

2042
2043
2044
2045
2046

X9-84-CMS {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9Standards(9) x9-84(84) module(0) cms(2) rev(1) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN

2047
2048

-- EXPORTS All;

2049
2050

IMPORTS

2051
2052

-- ANSI X9.84 Biometric Information Management & Security IDs --

2053
2054
2055
2056
2057
2058
2059
2060

des-ede3-cbc, dsa-with-sha1, ecdsa-with-SHA1, hmac-with-SHA1,

id-data, NullParms, OID, rsaEncryption, SHA-Algorithms,
sha1WithRSAEncryption, sha-1
FROM X9-84-Identifiers {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9Standards(9) x9-84(84) module(0)
ids(3) rev(1) };

2061
2062
2063
2064
2065
2066
2067
2068
2069

SignedData ::= SEQUENCE {

2070
2071

CMSVersion ::= INTEGER { v84(84) } (v84,...)

2072
2073
2074

DigestAlgorithmIdentifiers ::=
SET SIZE(1) OF DigestAlgorithmIdentifier

2075
2076

DigestAlgorithmIdentifier ::= AlgorithmIdentifier {{DigestAlgorithms}}

2077
2078

DigestAlgorithms ALGORITHM ::= {

203XML Common Biometric Format (XCBF) Committee Specification 1.1

OPTIONAL,

June 2003
Page 51

205
206
2079

SHA-Algorithms,

2080
2081
2082

2083
2084
2085
2086
2087

EncapsulatedContentInfo ::= SEQUENCE {

eContentType ContentType,
eContent
[0] EXPLICIT OCTET STRING
}

2088
2089

ContentType ::= CONTENTS.&id({Contents})

2090
2091

CONTENTS ::= TYPE-IDENTIFIER

2092
2093
2094
2095

Contents CONTENTS ::= {

{ Data IDENTIFIED BY id-data }
}

2096
2097

Data ::= OCTET STRING

2098
2099

CertificateSet ::= --[XER:BASE64]1-- OCTET STRING

2100
2101

CertificateRevocationLists ::= --[XER:BASE64] -- OCTET STRING

2102
2103

SignerInfos ::= SET SIZE(1) OF SignerInfo

2104
2105
2106
2107
2108
2109
2110
2111

SignerInfo ::= SEQUENCE {

version
CMSVersion,
sid
SignerIdentifier,
digestAlgorithm
DigestAlgorithmIdentifier,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature
SignatureValue
}

2112
2113
2114
2115

SignerIdentifier ::= CHOICE {

certHash [1] EXPLICIT Hash
}

2116
2117
2118
2119
2120

Hash ::= CHOICE {

ietf
CertHash, -- SHA-1 hash of entire certificate
withAlgID DigestInfo
}

2121
2122

CertHash ::= OCTET STRING (ENCODED BY sha-1)

2123
2124
2125
2126
2127

DigestInfo ::= SEQUENCE {

hashAlgorithm DigestAlgorithmIdentifier,
digest
OCTET STRING
}

2128
2129
2130

SignatureAlgorithmIdentifier ::=
AlgorithmIdentifier {{SignatureAlgorithms}}

2131
2132
2133
2134
2135

SignatureAlgorithms ALGORITHM ::= {

{ OID dsa-with-sha1
PARMS NullParms } |
{ OID ecdsa-with-SHA1
PARMS NullParms } |
{ OID sha1WithRSAEncryption PARMS NullParms },

2136
2137
2138

... -- Expect other digest algorithms

...

OPTIONAL

-- ISO/IEC 8824-2:1998, Annex A

-- Expect other signature algorithms --

2011 The use of [BASE64] in comment anticipates amendments to the ASN.1 standards that will permit such
202notation without comment marks.
207XML Common Biometric Format (XCBF) Committee Specification 1.1
208Copyright OASIS Open 2003. All Rights Reserved.

June 2003
Page 52

209
210
2139
2140

SignatureValue ::= OCTET STRING

2141
2142
2143
2144
2145

EncryptedData ::= SEQUENCE {

version
CMSVersion,
encryptedContentInfo EncryptedContentInfo
}

2146
2147
2148
2149
2150
2151

EncryptedContentInfo ::= SEQUENCE {

contentType
ContentType,
contentEncryptionAlgorithm ContentEncryptAlgorithmIdentifier,
encryptedContent
[0] EncryptedContent
}

2152
2153
2154

ContentEncryptAlgorithmIdentifier ::=
AlgorithmIdentifier {{ContentEncryptionAlgorithms}}

2155
2156
2157

ContentEncryptionAlgorithms ALGORITHM ::= {

{ OID des-ede3-cbc PARMS IV },

2158
2159
2160

2161
2162

IV ::= OCTET STRING (SIZE(8))

2163
2164

EncryptedContent ::= OCTET STRING

2165
2166
2167
2168
2169
2170
2171

EnvelopedData ::= SEQUENCE {

version
CMSVersion,
originatorInfo
[0] OriginatorInfo OPTIONAL,
recipientInfos
RecipientInfos,
encryptedContentInfo EncryptedContentInfo
}

2172
2173
2174
2175
2176
2177

OriginatorInfo ::= SEQUENCE {

certs [0] CertificateSet OPTIONAL,
crls
[1] CertificateRevocationLists OPTIONAL
}
(ALL EXCEPT({ -- none; at least one component is present -- }))

2178
2179

RecipientInfos ::= SET SIZE(1) OF RecipientInfo

2180
2181
2182
2183

RecipientInfo ::= CHOICE {

ktri KeyTransRecipientInfo
}

2184
2185
2186
2187
2188
2189
2190

KeyTransRecipientInfo ::= SEQUENCE {

version
CMSVersion,
rid
RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey
EncryptedKey
}

2191
2192
2193
2194

RecipientIdentifier ::= CHOICE {

certHash [73] EXPLICIT Hash
}

2195
2196
2197

KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{KeyEncryptionAlgorithms}}

2198
2199
2200

KeyEncryptionAlgorithms ALGORITHM ::= {

{ OID rsaEncryption PARMS NullParms },

...

-- Expect other content encryption algorithms --

2201

211XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 53

213
214
2202
2203

2204
2205

EncryptedKey ::= OCTET STRING

2206
2207
2208
2209
2210
2211
2212
2213

AuthenticatedData ::= SEQUENCE {

version
CMSVersion,
recipientInfos
RecipientInfos,
macAlgorithm
MACAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
mac
MessageAuthenticationCode
}

2214
2215

MACAlgorithmIdentifier ::= AlgorithmIdentifier {{MACAlgorithms}}

2216
2217
2218

MACAlgorithms ALGORITHM ::= {

{ OID hmac-with-SHA1 },

2219
2220
2221

2222
2223

MessageAuthenticationCode ::= OCTET STRING

2224
2225
2226

-- Cryptographic algorithm identification --

2227
2228
2229
2230
2231
2232

ALGORITHM ::= CLASS {

&id
OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }

2233
2234
2235
2236
2237

AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {

algorithm
ALGORITHM.&id( {IOSet} ),
parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL
}

2238
2239
2240

END

...

-- expect other key encryption algorithms --

-- expect other MAC or HMAC algorithms --

-- X9-84-CMS --

2241

22427.3 X9-84-Identifiers Module

2243
2244
2245
2246
2247

X9-84-Identifiers {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9Standards(9) x9-84(84) module(0) ids(3) rev(1) }
DEFINITIONS AUTOMATIC TAGS ::= BEGIN

2248
2249

-- EXPORTS All;

2250
2251

IMPORTS

2252
2253

-- X9.84 Biometrics Information Management and Security --

2254
2255
2256
2257
2258
2259

BIOMETRIC, BiometricInformationSets
FROM X9-84-Biometrics {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9Standards(9) x9-84(84) module(0)
biometrics(1) rev(1) }

2260

215XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 54

217
218
2261

-- X9.84 Biometrics Information Management and Security CMS --

2262
2263
2264
2265
2266
2267

ALGORITHM
FROM X9-84-CMS {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9Standards(9) x9-84(84) module(0)
cms(2) rev(1) };

2268
2269
2270

OID ::= OBJECT IDENTIFIER

2271
2272

RelOID ::= RELATIVE-OID

2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323

---------------------------------------------------

-- Alias
-- Alias

x9-84
x9-84-Module
x9-84-Biometrics
x9-84-CMS
x9-84-Identifiers
biometric
id-unknown-Type
id-body-Odor
id-dna
id-ear-Shape
id-facial-Features
id-finger-Image
id-finger-Geometry
id-hand-Geometry
id-iris-Features
id-keystroke-Dynamics
id-palm
id-retina
id-signature
id-speech-Pattern
id-thermal-Image
id-vein-Pattern
id-thermal-Face-Image
id-thermal-Hand-Image
id-lip-Movement
id-gait
processing-algorithm
matching-method
format-Owner
cbeff-Owner
ibia-Owner
id-ibia-SAFLINK
id-ibia-Bioscrypt
id-ibia-Visionics
id-ibia-InfineonTechnologiesAG
id-ibia-IridianTechnologies
id-ibia-Veridicom
id-ibia-CyberSIGN
id-ibia-eCryp
id-ibia-FingerprintCardsAB
id-ibia-SecuGen
id-ibia-PreciseBiometric
id-ibia-Identix
id-ibia-DERMALOG
id-ibia-LOGICO
id-ibia-NIST
id-ibia-A4Vision
id-ibia-NEC
id-ibia-STMicroelectronics
id-ibia-Ultra-Scan

{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3

133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133
133

16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16
16

840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840

9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9

219XML Common Biometric Format (XCBF) Committee Specification 1.1

84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84
84

0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
3
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4

1
2
3
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}

June 2003
Page 55

221
222
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335

-------------

2336
2337

-- X9.84 arc; base object identifier --

2338
2339
2340
2341
2342

x9-84 OID ::= {

iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9Standards(9) x9-84(84)
}

2343
2344

-- X9.84 ASN.1 modules --

2345
2346

x9-84-Module OID ::= { x9-84 modules(0) }

2347
2348

x9-84-Biometrics

OID ::= { x9-84-Module biometrics(1) rev(1) }

2349
2350

x9-84-CMS

OID ::= { x9-84-Module cms(2) rev(1) }

2351
2352

x9-84-Identifiers OID ::= { x9-84-Module ids(3) rev(1) }

2353
2354

-- X9.84 biometric technologies --

2355
2356

biometric OID ::= { x9-84 biometrics(1) }

2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377

id-unknown-Type
id-body-Odor
id-dna
id-ear-Shape
id-facial-Features
id-finger-Image
id-finger-Geometry
id-hand-Geometry
id-iris-Features
id-keystroke-Dynamics
id-palm
id-retina
id-signature
id-speech-Pattern
id-thermal-Image
id-vein-Pattern
id-thermal-Face-Image
id-thermal-Hand-Image
id-lip-Movement
id-gait

2378
2379

-- X9.84 biometric technology object identifier fragments --

2380
2381
2382
2383
2384
2385
2386

unknown-Type
body-Odor
dna
ear-Shape
facial-Features
finger-Image

id-ibia-Aurora-Wireless
id-ibia-Thales
id-ibia-IBG
id-ibia-Cogent-Systems
id-ibia-Cross-Match
id-ibia-Recognition-Systems
id-ibia-DIN
id-ibia-INCITS-M1
x9-Owner
certificate-Extensions
x968-biometricTemplates
x509-biometricTemplates

OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID

RelOID
RelOID
RelOID
RelOID
RelOID
RelOID

::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=

{
{
{
{
{
{
{
{
{
{
{
{

::=
::=
::=
::=
::=
::=

{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{

1
1
1
1
1
1
1
1
1
1
1
1

3
3
3
3
3
3
3
3
3
3
3
3

133
133
133
133
133
133
133
133
133
133
133
133

biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric
biometric

{
{
{
{
{
{

16
16
16
16
16
16
16
16
16
16
16
16

840
840
840
840
840
840
840
840
840
840
840
840

9
9
9
9
9
9
9
9
9
9
9
9

84
84
84
84
84
84
84
84
84
84
84
84

4
4
4
4
4
4
4
4
4
5
5
5

1
1
1
1
1
1
1
1
2

20
21
22
23
24
25
26
27

0
1

}
}
}
}
}
}
}
}
}
}
}
}

unknownType(0) }
bodyOdor(1) }
dna(2) }
ear-Shape(3) }
facialFeatures(4) }
fingerImage(5) }
fingerGeometry(6) }
handGeometry(7) }
irisFeatures(8) }
keystrokeDynamics(9) }
palm(10) }
retina(11) }
signature(12) }
speech-Pattern(13) }
thermalImage(14) }
veinPattern(15) }
thermalFaceImage(16) }
thermalHandImage(17) }
lipMovement(18) }
gait(19) }

unknownType(0) }
bodyOdor(1) }
dna(2) }
earShape(3) }
facialFeatures(4) }
fingerImage(5) }

223XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 56

225
226
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400

finger-Geometry
hand-Geometry
iris-Features
keystroke-Dynamics
palm
retina
signature
speech-Pattern
thermal-Image
vein-Pattern
thermal-Face-Image
thermal-Hand-Image
lip-Movement
gait

2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422

2423
2424
2425

2426
2427
2428

-- X9.84 biometric processing algorithms --

2429
2430

processing-algorithm OID ::= { x9-84 processingAlgorithms(2) }

2431
2432

-- X9.84 biometric matching methods --

2433
2434

matching-method OID ::= { x9-84 matchingMethods(3) }

2435
2436

-- X9.84 vendor specific formats --

2437
2438

format-Owner OID ::= { x9-84 format-owners(4) }

2439
2440

cbeff-Owner OID ::= { format-Owner cbeff(0) }

2441
2442

ibia-Owner

OID ::= { format-Owner ibia(1) }

2443
2444

x9-Owner

OID ::= { format-Owner x9(2) }

2445
2446

-- IBIA vendor specific formats registered at http://www.ibia.org

2447
2448
2449

id-ibia-SAFLINK
id-ibia-Bioscrypt

...

RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID

::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=

{
{
{
{
{
{
{
{
{
{
{
{
{
{

fingerGeometry(6) }
handGeometry(7) }
irisFeatures(8) }
keystrokeDynamics(9) }
palm(10) }
retina(11) }
signature(12) }
speechPattern(13) }
thermalImage(14) }
veinPattern(15) }
thermalFaceImage(16) }
thermalHandImage(17) }
lipMovement(18) }
gait(19) }

} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
},

-- expect additional biometric types --

OID ::= { ibia-Owner

227XML Common Biometric Format (XCBF) Committee Specification 1.1

1 }
2 }

June 2003
Page 57

229
230
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474

id-ibia-Visionics
id-ibia-InfineonTechnologiesAG
id-ibia-IridianTechnologies
id-ibia-Veridicom
id-ibia-CyberSIGN
id-ibia-eCryp
id-ibia-FingerprintCardsAB
id-ibia-SecuGen
id-ibia-PreciseBiometric
id-ibia-Identix
id-ibia-DERMALOG
id-ibia-LOGICO
id-ibia-NIST
id-ibia-A4Vision
id-ibia-NEC
id-ibia-STMicroelectronics
id-ibia-Ultra-Scan
id-ibia-Aurora-Wireless
id-ibia-Thales
id-ibia-IBG
id-ibia-Cogent-Systems
id-ibia-Cross-Match
id-ibia-Recognition-Systems
id-ibia-DIN
id-ibia-INCITS-M1

2475
2476
2477
2478
2479

-- When represented as values of type OBJECT IDENTIFIER, these

-- IBIA vendor specific formats may be associated with any ASN.1
-- type.

2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508

2509
2510
2511

...

OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID
OID

::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=

{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{

ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner
ibia-Owner

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}

DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA

Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any
Any

} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
} |
},

-- Expect additional vendor specific formats --

2512

231XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 58

233
234
2513

Any ::= TYPE-IDENTIFIER.&Type

2514
2515
2516
2517
2518
2519

------

2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547

2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575

IBIAidFormats BIOMETRIC ::= {

-- Application constrained

Relative object identifier representations of the identical

IBIA vendor specific formats defined as OBJECT IDENTIFIER
values above are used to identify these formats when they must
comply with the fixed format requirements of the BioAPI 1.1
specification and are associated with a two byte integer value.
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID
RelOID

::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=

{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}

DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA

235XML Common Biometric Format (XCBF) Committee Specification 1.1

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

June 2003
Page 59

237
238
2576
2577

{ BIOMETRIC id : ibia-DIN
{ BIOMETRIC id : ibia-INCITS-M1

DATA BirInt16 } |
DATA BirInt16 },

2578
2579
2580

2581
2582

BirInt16 ::= INTEGER (0..65535)

2583
2584
2585
2586
2587

IBIA-Formats BIOMETRIC ::= {

IBIAoidFormats | -- Complete object identifiers
IBIAidFormats,
-- Object identifier fragments

2588
2589
2590

2591
2592

id-x984BioInfo

2593
2594
2595
2596

CBEFFoidFormats BIOMETRIC ::= {

{ BIOMETRIC oid : id-x984BioInfo DATA BiometricInformationSets },

2597
2598
2599

2600
2601

x984BioInfo

2602
2603
2604

CBEFFidFormats BIOMETRIC ::= {

{ BIOMETRIC id : x984BioInfo DATA BiometricInformationSets },

2605
2606
2607

2608
2609
2610
2611

CBEFF-Formats BIOMETRIC ::= {

CBEFFoidFormats | -- Complete object identifiers
CBEFFidFormats,
-- Object identifier fragments

2612
2613
2614

2615
2616

MatchingAIDs BIOMETRIC ::= {

2617
2618
2619

2620
2621

ProcessingAIDs BIOMETRIC ::= {

2622
2623
2624

2625
2626
2627
2628

X9-Formats BIOMETRIC ::= {

X9oidFormats |
X9idFormats,

2629
2630
2631

2632
2633
2634
2635

X9oidFormats BIOMETRIC ::= {

... -- Expect X9 assigned objects -}

2636
2637
2638

X9idFormats BIOMETRIC ::= {

... -- Expect X9 assigned objects of the form { 2 x } --

...

-- Expect others --

-- Expect additional IBIA vendor specific formats -OID ::= { cbeff-Owner x984BioInfo(0) }

-- Expect other objects -RelOID ::= { x984BioInfo(0) }

-- CBEFF owner

-- Expect other objects --

-- Expect additional CBEFF vendor specific formats --

-- Expect CBEFF assignments in BiometricInformationSets --

-- Expect additional X9 vendor specific formats --

239XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 60

241
242
2639

2640
2641

certificate-Extensions OID ::= { x9-84 certificate-Extensions(5) }

2642
2643
2644

x968-biometricTemplates OID ::= { certificate-Extensions 0 }

x509-biometricTemplates OID ::= { certificate-Extensions 1 }

2645
2646

-- RSA PKCS #7 Content type

2647
2648
2649
2650
2651

id-data OID ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs7(7) data(1)
}

2652
2653

-- Security object identifiers

2654
2655
2656

-- FIPS 180-1 and FIPS 180-2 Secure Hash Algorithm --

2657
2658
2659
2660
2661
2662

sha-1 OID ::= {

iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26
}

2663
2664
2665
2666
2667

sha2Algorithm OID ::= {

joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) hashAlgs(2)
}

2668
2669

id-sha256 OID ::= { sha2Algorithm sha256(1) }

2670
2671

id-sha384 OID ::= { sha2Algorithm sha384(2) }

2672
2673

id-sha512 OID ::= { sha2Algorithm sha512(3) }

2674
2675
2676
2677
2678
2679

SHA-Algorithms ALGORITHM ::= {

{ OID sha-1
PARMS NullParms }
{ OID id-sha256 PARMS NullParms }
{ OID id-sha384 PARMS NullParms }
{ OID id-sha512 PARMS NullParms},

2680
2681
2682

2683
2684

NullParms ::= NULL

2685
2686

-- X9.57 DSA signature generated with SHA-1 hash (DSA X9.30)

2687
2688
2689

dsa-with-sha1 OID ::= {

iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }

2690
2691

2692
2693
2694
2695

hmac-with-SHA1 OID ::= {

iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) 8 1 2 }

2696
2697

-- RSA PKCS #1 signature generated with SHA-1 hash & encryption scheme

2698
2699
2700

sha1WithRSAEncryption OID ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 5 }

...

|
|
|

-- Expect others --- No initialization vector

X9.71 HMAC with SHA-1 algorithm

2701

243XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 61

245
246
2702
2703

rsaEncryption OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 1 }

2704
2705

-- ANSI X9.52 Triple DES Modes of Operation --

2706
2707
2708
2709
2710

des-ede3-cbc OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 7
}

2711
2712

-- X9.62 ECDSA signature with SHA-1

2713
2714
2715

ecdsa-with-SHA1 OID ::= {

iso(1) member-body(2) us(840) ansi-x962(10045) signatures(4) 1 }

2716
2717
2718

END

-- X9-84-Identifiers --

27197.4 Encodings to be employed

27207.4.1 Encodings used for calculation of digital signatures and MACs
2721All digital signatures and Message Authentication Codes shall be calculated using the binary
2722values obtained by applying a CXER encoding to a value of EncodedBiometricObect (see
27235.1.2.1.1 Digital Signature Process).
2724
2725
2726

NOTE 1 A CXER encoding is defined by X.693 as an initial character

representation, followed by the application of the UTF8 transformation to those
characters to produce a set of binary octets.

2727
2728

NOTE 2 This is the only use of CXER in this specification, and is independent
of any encoding used for transfer.

2729

27307.4.2 Octet Strings with Certificates and Certificate Revocation Lists

2731All values of the CertificateSet type (and CertificateRevocationLists type) octet strings shall be
2732the concatenation of the octets of the DER encodings of one or more X.509 certificates or
2733attribute certificates (or certificate revocation lists, respectively).
2734If the outer level encoding is BER (see 7.4.3 below) then the value of these octet string types
2735shall be encoded as specified in BER.
2736
2737
2738
2739

NOTE A formal specification of the types forming the contents of these octet
strings is not possible, as they are the concatenation of self-delimited encodings
of multiple ASN.1 types, not the encoding of a single ASN.1 type. This is for
historical reasons.

2740If the outer level encoding is BASIC-XER then the value of these octet strings shall not be
2741encoded as specified in BASIC-XER (a UTF8 transform of a hexadecimal encoding), but shall be
2742encoded as specified in the following paragraph.
2743The UTF8 transformation shall be applied to the Content-Transfer-Encoding specified in IETF
2744RFC 2045, 6.8, except that the 76 character limit does not apply, and XML escape sequences for
2745white-space can be present in any position within the encoding.
2746
2747
2748
2749
2750

NOTE - IETF RFC 2045 mandates the presence of line breaks dividing the
encoding into lines of at most 76 characters, but this is not required in XCBF
encodings. It also allows "white-space" to be inserted in any position within the
base64 encoding. This is extended in this specification to allow the inclusion of
XML escape sequences for white-space.

247XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 62

249
250
2751

27527.4.3 Outer-level encodings

2753The outer-level encoding used for XCBF shall by default be the BASIC-XER encoding specified
2754by X.693 (but see 7.4.2 above for the use of base64).
2755By implementor agreement, the outer-level encoding may be BER.
2756
2757
2758

NOTE 1 If the outer-level encoding is BER, the CXER encoding specified in

7.4.1 is still employed for cryptographic transformations, but is not used for
transfer.

2759
2760
2761
2762

NOTE 2 If the outer-level encoding is BER, the concatenation of DER

encodings specified in 7.4.2 is still employed for encoding the set of X.509 types,
but the base64 encoding is not used, as there is no requirement for an initial
character encoding.

2763

251XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 63

253
254

27648

Examples

2765Three examples are included in this section to assist readers and implementors of this standard,
2766and with the goal of promoting secure, interoperable biometric applications and systems.

27678.1 BiometricSyntaxSets (CXER, DER)

2768This example illustrates a value of type BiometricSyntaxSets encoded in XML markup using the
2769basic XML Encoding Rules (BASIC-XER), a canonical variant of the XML Encoding Rules
2770(CXER) and a compact, canonical, binary format using the ASN.1 Distinguished Encoding Rules
2771(DER). The XER, CXER and DER representations use exactly the same abstract values, based
2772on the same XCBF ASN.1 schema.
2773Two representations are well-formed XML markup. The third representation is a compact, binary
2774DER encoding. Both CXER and DER are suitable for use in cryptographic applications involving
2775digital signatures, since these encoding rules provide one and only one way to encode any given
2776value.
2777The BiometricSyntaxSets value encoded in basic XER:
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801

2802The same abstract value encodes in 517 octets using canonical XER:
2803
2804
2805
2806
2807
2808
2809
2810
2811

2812
2813The same abstract value encodes in 57 octets using DER:
2814

3037A0353033A02BA103810104820102830106

255XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 64

257
258

2815
2816

8401FFA50F80048F3C0A0481078F530A03173B
3BA60AA0088006672A090A040281040A0B0C0D

2817

28188.2 SignedData
2819This example illustrates how to encode one or more biometric samples or templates for
2820cryptographic enhancement to provide authentication of origin and data integrity services for
2821biometric samples or templates.
2822
2823The SubjectPublicKeyInfo value from the signer's X.509 Public Key Certificate is shown here in
2824the hexadecimal representation of a DER encoded sequence:

2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844

308201B73082012C06072A8648CE3804013082011F028181
00FD7F53811D75122952DF4A9C2EECE4E7F611B7523CEF44
00C31E3F80B6512669455D402251FB593D8D58FABFC5F5BA
30F6CB9B556CD7813B801D346FF26660B76B9950A5A49F9F
E8047B1022C24FBBA9D7FEB7C61BF83B57E7C6A8A6150F04
FB83F6D3C51EC3023554135A169132F675F3AE2B61D72AEF
F22203199DD14801C70215009760508F15230BCCB292B982
A2EB840BF0581CF502818100F7E1A085D69B3DDECBBCAB5C
36B857B97994AFBBFA3AEA82F9574C0B3D0782675159578E
BAD4594FE67107108180B449167123E84C281613B7CF0932
8CC8A6E13C167A8B547C8D28E0A3AE1E2BB3A675916EA37F
0BFA213562F1FB627A01243BCCA4F1BEA8519089A883DFE1
5AE59F06928B665E807B552564014C3BFECF492A03818400
028180476ACACB486186A153E25AE0E243FAAF0CD9105CF4
DCF63412F36ABF671F53637E5F9FA7C5ADC78288FDB9FA3C
FAFDEBFDD7A7C3FF2BD63D32F4773413EBD9EAB3CA03BA2D
ED583187763181CB376954FD13F1F8E046D4E3D40652CA8D
4645439A3ADB8D964F98F81E57147BDF4C009885CAD55D13
B38DBAA2F9CBF13DC525F6

2845
2846The biometric objects to be signed with the signer's private key associated with the public key
2847provided above shown in the canonical form used as input to the message digest process used to
2848create the digital signature on the signed content:

2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870

2871

259XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 65

261
262
2872The complete integrity object represented as an XML document:
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933

<?xml version="1.0" encoding="UTF-8"?>

263XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 66

265
266

2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997

<notBefore> 1998.10.3 </notBefore>

267XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 67

269
270

2998
2999
3000

</integrityObjects>
</BiometricSyntaxSets>

3001

3002

30038.3 EncryptedData (fixedKey)

3004This example illustrates how to encode a series of one or more biometric samples or templates
3005for cryptographic enhancement. A group of three biometric objects is used here, though XCBF
3006allows any number of objects to be included. The optional, cleartext biometric headers are not
3007included in the example message. The group of three biometric objects is encrypted for privacy
3008using a fixed Triple DES key.
3009
3010As shown in this example, XCBF users can create and exchange arbitrary collections of biometric
3011information to suit the needs of their security applications. This capability provides the application
3012designer complete flexibility. The order of the biometric objects is determined in the application by
3013the sender, allowing them to prioritize or order biometric information for purposes such as aging
3014of data, or grouping records by quality or data type or entity.
3015
3016Collections of useful biometric information include:

3017
3018
3019
3020
3021
3022

3023

pairs of iris image templates for an individual; one for each eye
collections of paired iris image templates for a group of individuals
collections of finger print image templates, one per digit for an individual
sets of individual finger print image template collections for a group of persons
a collection of mixed biometric templates for an individual; say, retina, hand geometry, and
DNA
collections of templates for groups of individuals, such as:

3024

all employees at work today, or

3025

all of the passengers on Flight 12, or

3026

all of the finger print samples collected on Tuesday

3027
3028The hex encoding of a two key Triple DES key used to encrypt a series of three values of type
3029BiometricObject is represented in hexadecimal notation as:

3030
3031

D02523B3E561313B

511516297C52A846

D02523B3E561313B

3032

3033The biometric objects to be encrypted are shown here for ease of reading, and are not in the
3034canonical form used as input to the encryption process in this example:

3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046

271XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 68

273
274

3047
3048
3049
3050
3051
3052
3053
3054
3055
3056

<notAfter> 2008.10.1 </notAfter>

</validityPeriod>
<format>
<formatOwner> <oid> 2.23.42.9.10.4.2 </oid> </formatOwner>
</format>
</biometricHeader>
<biometricData>
0102030405060708090A0B0C0D0E0F11
</biometricData>
</BiometricObject>

3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077

3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098

3099
3100

</BiometricObjects>

3101
3102The complete XCBF privacy message formed after cryptographic processing of the series of
3103three biometric objects:

3104
3105
3106
3107
3108

275XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 69

277
278

3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171

<version> 84 </version>
<encryptedContentInfo>
<contentType> 1.2.840.113549.1.7.1 </contentType>
<contentEncryptionAlgorithm>
<algorithm> 1.2.840.113549.3.7 </algorithm>
<parameters>
<IV> 0102030405060708 </IV>
</parameters>
</contentEncryptionAlgorithm>
<encryptedContent>
2C75078EE885D7EE52321E80971A2B8E5C5A646B12CF2F90
7BAFA6FA16BDB6FA949898183762A05AB2A488B24D9397B2
E63D1885BAEFABD0A24E501EB612CE0118E435C4EEE70230
A0D74D766A795C0A23B454A3E6E5DFE60C0F31B3BABCDF23
5E1D4B2D7EDAD144BA38A63058ED211368A6887921973C7D
BCD1A53CBA2CD36819B488CDEB5008B546F0A7E9EE631D14
409A32EA7D784444EF2A8ABD0B54C99A5C0D5070A3A25D36
7303C359D4387D12DB2449FB73FC40D850B01555BAF8F86D
937A60256E0FDDAF52690CCF8D76770EBE7E359EFF6510A0
E39B09E6A8EA0FB844522364E66696965B37382061152D54
69332C7D1BF9C2A311D117583AE740DED8849777C3CE56DE
EABA687B936693292858CA67CD5D7C2BCD918A736B044173
1DDBBB077C348CA6524BEA30FADED63CE76BB47F43232A3C
5FA6ABFFE5234C108C6B903DB724B478CD647F52E98A5A28
071E881321CA7AAD4F7F1F911C4666F5746A1090FB076251
24F4E521BCD78C61C6AB1AC0C142D9CB32E08B1B0C7E8F51
07826C883D92963F547F62373CD6CACD791877293E2937EA
E93D78FAD09479990BC8488D067C8203A43D9AC132A75712
A1A86A4E527FBE941E7E7CAC8CCEADCA72C9853D5FDBFECF
972450E13461DD688AB412FAABC912838ED5850A9FF85FC4
2D311834670D11FBBB7BE732D7FC44D0326AFD17B92A8353
747E3A04065E553901A8C5EA531AC644D204F9209EECD151
FF7D623DE5671FC4C07325593D0D442E66C872CC7BB214D5
88F01A90C8ECFC19BC9DEA06065C954B673B101EFEFC8FFC
E97DBBDFABEE9AE20FFE0927E4F59928CD9E2A0F1D538527
2A5C78CE1E6A669B18AAD2498731730FFBDFD72D13EB390E
82C402F3033E0201089DFF7758F1C76E1578AE7CF6AC4742
631B1743141CD0A29D32F6B7D50C37EC8BC55754FA6D7FF5
5B0E1B0E075CF1F7EB0DB0468152BE079703BA71485CA891
7EA7CF6ED69CD0AC88AB5E93824B337FDB748542D6A2D1B9
96C4634CA52536A25C123D9791173F8668404AE30CA701F0
5FF77B976369F7C1F48B834952082BA92E7772C717305E70
8E51C89E445C88423E378262315E951A207C30B5E03E805C
9C538E9856DBDCF84489BF58757E332BFA01625F76C04A23
2271BF4FC985209B51A7CC0E747426007617649ABC75818C
A68911E497266E717042EEE6747D9A874F9F174713F8751F
2AE5B3D7991299A83F85E78F99C5B01B1FCD8A9EC072F763
669854D74CC915611181440305AB483E4A2BE21C516561DC
B6E25C5D1DCD5FF84B3740B3BB337BF78585A8395EAB3357
132541794115D48BCC37B5B0405201C9CDA503C2641E0283
3651CD5E55F442C6E7E8D1EA8D83F9FAE370DA6ADC653651
4441C6831E4F1B42A056672EC5152B8BA0D31C6F3603801D
C50028562D81055915088D6798E4900481B1C86D35888AC0
6E9B61CEBA302BD1A0CB0AC002B640455B14072F9E654E87
43AE15F7C46DE69BB2F11408CE22133B9C04D3F097300780
DCF653414DA95BF7A1DE0B57E72616BC014108828CE7B027
5C391516A9D9AD26A59F9D2D46BE59D93B7DD2525CFAC948
9DDA026F4CF7BADF4552F47B64CC1C65D705697251DC92B9
486A53159E9AD9D9C149EDAF78636F6F090763E6C826F9FE
EBEE49D8FCCC526BDBB4B2513FB355DC05994DFD9D1B581D
DD69C904584E5BDFF9593C9A4AFD9E1FD2FA7056755F9079
4F1988F103C7F1EEE9A8BE719B401078E504F56E3B6931C3
AC1A4392860367E46F008FFB919B8F1DF0B0D0CE41BF1786

279XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 70

281
282

3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184

9313B14B0E556F94E5573106B7050862B4158BB1C87CEB29
B939873D514474D72840B96E70D2661249B856DF2775AE7F
1A3378AD9030FD10A1CB5E8EF150808DEC94101449DAADE6
4D16EA79E4578FA996AEBFA1E3918A485EFB85364282CCA4
073A565C64B8A8704CC95ADA4A9B8796679BD89DAA6A7B0E
01E4903080875A3208769CE4B1BDD1B874F5B4E2607FBB72
2411F0CAFCF14D7FA870EBE87903D5B583D5C231F95912D5
</encryptedContent>
</encryptedContentInfo>
</fixedKey>
</privacyBlock>
</privacyObjects>
</BiometricSyntaxSets>

283XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 71

285
286

3185Appendix

A. Acknowledgments

3186The following individuals were members of the committee during the development of this
3187standard:
3188

3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213

Tyky Aichelen (Technical Committee Chair), IBM

Lieutenant John Aerts, LA County Information Systems Advisory Body
Karl Best, OASIS
Taylor Boon, BioNetrix Systems
Jamie Clark, OASIS
Robin Cover, Isogen
Ed Day, Objective Systems
Dr. Paul Grme, Individual Member
Phillip H. Griffin, Individual Member
Todd Harbour, FGM
William Koenig, Bank of America
John Larmouth, Individual Member
Monica Martin, Sun Microsystems
John Messing, American Bar Association
Michael Nguyen, The Infocomm Development Authority of Singapore
Rob Philpott, RSA Security
Rick Randall, Booz Allen Hamilton
Stefan Ri, Microsoft
William Riippi, MTG Management Consultants, LLC.
Darran Rolls, Waveset
Bancroft Scott, OSS Nokalva
Clifford Thompson, Individual Member
Paul Thorpe, OSS Nokalva
Alessandro Triglia, OSS Nokalva
Per Vorm, BEA Systems

287XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 72

289
290

3214Appendix

B. Revision History

Rev

Date

By Whom

What

CS-1.0

2003-03-03

Phil Griffin

Committee Specification

CS-1.1

2003-06-09

John Larmouth

Committee Specification

OASIS
Standard
1.1

2003-08-03

Tyky Aichelen

OASIS Standard

3215

291XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 73

293
294

3216Appendix

C. Notices

3217OASIS takes no position regarding the validity or scope of any intellectual property or other rights
3218that might be claimed to pertain to the implementation or use of the technology described in this
3219document or the extent to which any license under such rights might or might not be available;
3220neither does it represent that it has made any effort to identify any such rights. Information on
3221OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS
3222website. Copies of claims of rights made available for publication and any assurances of licenses
3223to be made available, or the result of an attempt made to obtain a general license or permission
3224for the use of such proprietary rights by implementers or users of this specification, can be
3225obtained from the OASIS Executive Director.
3226OASIS invites any interested party to bring to its attention any copyrights, patents or patent
3227applications, or other proprietary rights, which may cover technology that may be required to
3228implement this specification. Please address the information to the OASIS Executive Director.
3229Copyright 2003 OASIS Open, Inc. All Rights Reserved.
3230This document and translations of it may be copied and furnished to others, and derivative works
3231that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
3232published and distributed, in whole or in part, without restriction of any kind, provided that the
3233above copyright notice and this paragraph are included on all such copies and derivative works.
3234However, this document itself does not be modified in any way, such as by removing the
3235copyright notice or references to OASIS, except as needed for the purpose of developing OASIS
3236specifications, in which case the procedures for copyrights defined in the OASIS Intellectual
3237Property Rights document must be followed, or as required to translate it into languages other
3238than English.
3239The limited permissions granted above are perpetual and will not be revoked by OASIS or its
3240successors or assigns.
3241This document and the information contained herein is provided on an AS IS basis and OASIS
3242DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
3243ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
3244ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
3245PARTICULAR PURPOSE.

295XML Common Biometric Format (XCBF) Committee Specification 1.1

June 2003
Page 74

CBEFF - Document
No ratings yet
CBEFF - Document
39 pages
XML Security
No ratings yet
XML Security
30 pages
Adopted International Standards
No ratings yet
Adopted International Standards
20 pages
CBEFF Tilton 2009 Short
No ratings yet
CBEFF Tilton 2009 Short
13 pages
Biometrics Standards Financial
No ratings yet
Biometrics Standards Financial
19 pages
Linux Commands
No ratings yet
Linux Commands
10 pages
Computer Basics Worksheet
100% (2)
Computer Basics Worksheet
8 pages
Summer Training Report: Bachelor of Technology
No ratings yet
Summer Training Report: Bachelor of Technology
37 pages
R12 Intvq
No ratings yet
R12 Intvq
51 pages
4 TAD-T24Updates PDF
100% (3)
4 TAD-T24Updates PDF
38 pages
Oops in Sap Abap - 2
No ratings yet
Oops in Sap Abap - 2
117 pages
Debug Code
No ratings yet
Debug Code
27 pages
List of Ms Dos Commands PDF
100% (1)
List of Ms Dos Commands PDF
34 pages
Active Learning Methods For Interactive Image Retrieval
No ratings yet
Active Learning Methods For Interactive Image Retrieval
78 pages
Rs-Gis r13 Syllabus
No ratings yet
Rs-Gis r13 Syllabus
1 page
Week 4 Programming Language
No ratings yet
Week 4 Programming Language
24 pages
Template Security For Management
100% (3)
Template Security For Management
9 pages
MNFST
No ratings yet
MNFST
13 pages
History of Cisc & Risc
0% (1)
History of Cisc & Risc
10 pages
PMBusGUI Manual
No ratings yet
PMBusGUI Manual
81 pages
Opensap Extending Sap Products With Sap Hana Cloud Platform: Week 1, Unit 1
No ratings yet
Opensap Extending Sap Products With Sap Hana Cloud Platform: Week 1, Unit 1
32 pages
LogMeIn Free UserGuide
No ratings yet
LogMeIn Free UserGuide
51 pages
Icp SVD
No ratings yet
Icp SVD
37 pages
Data Protection For Microsoft SQL Server Installation and User's Guide
No ratings yet
Data Protection For Microsoft SQL Server Installation and User's Guide
3 pages
Indiviual Assignment: Smart Home Control System
No ratings yet
Indiviual Assignment: Smart Home Control System
23 pages
Ericsson AXE 810 Offer en
No ratings yet
Ericsson AXE 810 Offer en
4 pages
O/I Knapsack Problem: Design and Analysis of Algorithms Unit V Branch and Bound
No ratings yet
O/I Knapsack Problem: Design and Analysis of Algorithms Unit V Branch and Bound
11 pages
Products t1 Brochure Trio
No ratings yet
Products t1 Brochure Trio
8 pages
Santosh Kumar Punnam
No ratings yet
Santosh Kumar Punnam
4 pages
Type Object Pattern
No ratings yet
Type Object Pattern
16 pages
Import Export
No ratings yet
Import Export
3 pages
Network Management 001
No ratings yet
Network Management 001
7 pages
Azada 2 Ancient Magic Setup Log
No ratings yet
Azada 2 Ancient Magic Setup Log
3 pages
Ruby in Twenty Minutes: Download
No ratings yet
Ruby in Twenty Minutes: Download
3 pages
Question 1 (40 PTS) : ITEM523 Practical Exam On XLST
No ratings yet
Question 1 (40 PTS) : ITEM523 Practical Exam On XLST
2 pages
CISSP Certification Exam Study Guide: (Cerified Information Systems Security Professional)
From Everand
CISSP Certification Exam Study Guide: (Cerified Information Systems Security Professional)
Kumud Kumar
No ratings yet
Micropolis Data Storage Primer: Micropolis Handbooks
From Everand
Micropolis Data Storage Primer: Micropolis Handbooks
Micropolis Handbooks
No ratings yet
Mastering the Art of Unix Programming: Unraveling the Secrets of Expert-Level Programming
From Everand
Mastering the Art of Unix Programming: Unraveling the Secrets of Expert-Level Programming
Steve Jones
No ratings yet
PowerShell Essentials: Definitive Reference for Developers and Engineers
From Everand
PowerShell Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Essential Shell Scripting and Automation: Definitive Reference for Developers and Engineers
From Everand
Essential Shell Scripting and Automation: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Entity-Component System Design Patterns: Definitive Reference for Developers and Engineers
From Everand
Entity-Component System Design Patterns: Definitive Reference for Developers and Engineers
Richard Johnson
1/5 (1)
Programming Systems with Hare: The Complete Guide for Developers and Engineers
From Everand
Programming Systems with Hare: The Complete Guide for Developers and Engineers
William Smith
No ratings yet
Safety of Computer Architectures
From Everand
Safety of Computer Architectures
Jean-Louis Boulanger
No ratings yet
Secure Scuttlebutt Protocol Design and Implementation: The Complete Guide for Developers and Engineers
From Everand
Secure Scuttlebutt Protocol Design and Implementation: The Complete Guide for Developers and Engineers
William Smith
No ratings yet
Provisioning and Lifecycle Management with Airship: The Complete Guide for Developers and Engineers
From Everand
Provisioning and Lifecycle Management with Airship: The Complete Guide for Developers and Engineers
William Smith
No ratings yet
Gvisor-seccomp Security Profiles: The Complete Guide for Developers and Engineers
From Everand
Gvisor-seccomp Security Profiles: The Complete Guide for Developers and Engineers
William Smith
No ratings yet
Cortex for Scalable Multi-Tenant Metrics: The Complete Guide for Developers and Engineers
From Everand
Cortex for Scalable Multi-Tenant Metrics: The Complete Guide for Developers and Engineers
William Smith
No ratings yet
Embedded Systems Design Essentials: Definitive Reference for Developers and Engineers
From Everand
Embedded Systems Design Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Boost.Asio Techniques and Applications: Definitive Reference for Developers and Engineers
From Everand
Boost.Asio Techniques and Applications: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Chia Blockchain: Proof-of-Space and Time Protocols and Implementation
From Everand
Chia Blockchain: Proof-of-Space and Time Protocols and Implementation
William Smith
No ratings yet
Efficient Shell Automation with Bash: Definitive Reference for Developers and Engineers
From Everand
Efficient Shell Automation with Bash: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Verilog for Digital Design and Simulation: Definitive Reference for Developers and Engineers
From Everand
Verilog for Digital Design and Simulation: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Essential Techniques for Rust Programming: Definitive Reference for Developers and Engineers
From Everand
Essential Techniques for Rust Programming: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
POSIX Threads Programming Essentials: Definitive Reference for Developers and Engineers
From Everand
POSIX Threads Programming Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
BSD Systems and Administration: Definitive Reference for Developers and Engineers
From Everand
BSD Systems and Administration: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Filecoin Technical Reference: The Complete Guide for Developers and Engineers
From Everand
Filecoin Technical Reference: The Complete Guide for Developers and Engineers
William Smith
No ratings yet
Filecoin Protocol and Applications: Definitive Reference for Developers and Engineers
From Everand
Filecoin Protocol and Applications: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
COBOL Essentials: Definitive Reference for Developers and Engineers
From Everand
COBOL Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
FCIP Protocols and Implementation: Definitive Reference for Developers and Engineers
From Everand
FCIP Protocols and Implementation: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
AIX Systems Administration and Architecture: Definitive Reference for Developers and Engineers
From Everand
AIX Systems Administration and Architecture: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
ESXi Administration and Automation: Definitive Reference for Developers and Engineers
From Everand
ESXi Administration and Automation: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Logstash Essentials: Definitive Reference for Developers and Engineers
From Everand
Logstash Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
IPFS Protocol Engineering: Definitive Reference for Developers and Engineers
From Everand
IPFS Protocol Engineering: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
OpenBSD Reference Guide: Definitive Reference for Developers and Engineers
From Everand
OpenBSD Reference Guide: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
ARM Architecture and Programming Essentials: Definitive Reference for Developers and Engineers
From Everand
ARM Architecture and Programming Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Developing Embedded Systems with Zephyr OS: Definitive Reference for Developers and Engineers
From Everand
Developing Embedded Systems with Zephyr OS: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Essential Avro: Definitive Reference for Developers and Engineers
From Everand
Essential Avro: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Container Infrastructure and Operations: Definitive Reference for Developers and Engineers
From Everand
Container Infrastructure and Operations: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Developing Applications on EOSIO: Definitive Reference for Developers and Engineers
From Everand
Developing Applications on EOSIO: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Comprehensive Logging Strategies: Definitive Reference for Developers and Engineers
From Everand
Comprehensive Logging Strategies: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Blowfish Cryptography in Practice: Definitive Reference for Developers and Engineers
From Everand
Blowfish Cryptography in Practice: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
RISC-V Architecture and Implementation Guide: Definitive Reference for Developers and Engineers
From Everand
RISC-V Architecture and Implementation Guide: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
IPFIX Protocol and Implementation: Definitive Reference for Developers and Engineers
From Everand
IPFIX Protocol and Implementation: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
VyOS Configuration and Deployment Guide: Definitive Reference for Developers and Engineers
From Everand
VyOS Configuration and Deployment Guide: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Advanced Encryption Standard: Algorithm and Applications
From Everand
Advanced Encryption Standard: Algorithm and Applications
Richard Johnson
No ratings yet
Comprehensive Guide to Aircrack-ng: Definitive Reference for Developers and Engineers
From Everand
Comprehensive Guide to Aircrack-ng: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
NetBSD Systems and Architecture: Definitive Reference for Developers and Engineers
From Everand
NetBSD Systems and Architecture: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Cortex-M Architecture and Programming Reference: Definitive Reference for Developers and Engineers
From Everand
Cortex-M Architecture and Programming Reference: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
SystemTap Essentials: Definitive Reference for Developers and Engineers
From Everand
SystemTap Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Practical iSCSI Deployment and Management
From Everand
Practical iSCSI Deployment and Management
Richard Johnson
No ratings yet
Log Engineering: Definitive Reference for Developers and Engineers
From Everand
Log Engineering: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Quorum Protocols in Distributed Systems: Definitive Reference for Developers and Engineers
From Everand
Quorum Protocols in Distributed Systems: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
ZooKeeper Systems and Techniques: Definitive Reference for Developers and Engineers
From Everand
ZooKeeper Systems and Techniques: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
BitKeeper Essentials: Definitive Reference for Developers and Engineers
From Everand
BitKeeper Essentials: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
QuickNode Technical Reference: Definitive Reference for Developers and Engineers
From Everand
QuickNode Technical Reference: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Kerberos Protocol Security and Implementation: Definitive Reference for Developers and Engineers
From Everand
Kerberos Protocol Security and Implementation: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
ESP32 Development and Applications: Definitive Reference for Developers and Engineers
From Everand
ESP32 Development and Applications: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Cortex-A Architecture and System Design: Definitive Reference for Developers and Engineers
From Everand
Cortex-A Architecture and System Design: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
BeagleBone Systems and Applications: Definitive Reference for Developers and Engineers
From Everand
BeagleBone Systems and Applications: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Design and Implementation with i.MX Processors: Definitive Reference for Developers and Engineers
From Everand
Design and Implementation with i.MX Processors: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet