ICAO PKD Testbench Procedures v3.2

Netrust Pte Ltd
PKD Test Bench Procedures -

ICAO PKD
Issue 3.2
ICAO PKD Issue: 3.2
PKD Test Bench Procedures Issue Date: 28 August 2013
NPL/ICAO-PKD/PKD-TBP/3.2
Netrust Pte Ltd
ICAO PKD System
PKD Test Bench Procedures
Filing Reference: NPL/ICAO-PKD/PKD-TBP/
Document Title : Test Bench Procedures
Version : 3.2
Prepared By : Andy Hing
Date Created : 28 Aug 2013

Reviewed By : R. Rajeshkumar ___________
Approved for release By : R. Rajeshkumar ___________
Document Reference: NPL/ICAO-PKD/PKD-TBP/
Distribution:
Name Organization
ICAO
PKD Board
Confidential Netrust Pte Ltd, 2006-2013 Page 2 of 27

ICAO PKD Issue: 3.2
Revision History
Date Issue Description Author
14 July 2006 0.1 First Issue Vivek Kaushik
19 July 2006 0.2 Second Issue Vivek Kaushik
10 August 2006 0.3 Changed to reflect one-way SSL during Vivek Kaushik
upload
14 August 2006 0.4 Changes to accompany Interface Vivek Kaushik
Specifications v1.4.2
27 March 2007 2.0 Changes to accompany Interface Vivek Kaushik
Specifications v2.0
Addition of the “Doc 9303” compliance
testing
Standardized to v2.0
08 May 2007 2.1 Changes to accompany Interface Vivek Kaushik
Specifications v2.1
Updates to Sec. 3.2, Compliance Tests
13 Nov 2007 2.2 Consolidated Changes from v0.6, related to Vivek Kaushik
2-way SSL for Upload, Accompany PKD
Interface Specs v2.2; Updated Registration
Form to accept PKD Upload Certificates
16 June 2009 2.3 Changes for downloader entries R. Rajeshkumar
22 February 2010 2.4 Changes:CSR for uploader certificate R. Rajeshkumar
13 February 2012 3.0 Non-conformant entries and delta LDIFs Andy Hing
08 January 2013 3.1 Updates to Sec. 3.4, Download Tests Andy Hing
28 August 2013 3.2 Changes in CRL specs, one CRL per PKD Andy Hing
participant

ICAO PKD Issue: 3.2
Table of Contents
1 Overview 5
1.1 Introduction 5
1.2 Glossary 5
2 Registration 8
3 Test Setup and Process 8

3.1 Connectivity tests 10
3.1.1 PKD Test Upload Directory 10
3.1.2 PKD Test Download Directory 10
3.2 Compliance Tests 12
3.2.1 Checking compliance of Certificates and CRLs 12
3.3 Upload Test 15
3.3.1 Upload to PKD Test Upload Directory 15
3.4 Download Tests 17
3.4.1 Download full listing 17
3.4.2 Download delta listing 19
3.4.3 PKD Query 21
4 APPENDIX A: PROJECT FORMS. 24
FORM: REGISTRATION OF COUNTRY FOR PUBLIC KEY DIRECTORY 25

REGISTRATION FOR COUNTRY FOR PUBLIC KEY DIRECTORY PARTICIPATION 26

ICAO PKD Issue: 3.2
PKD Test Bench Procedures -

ICAO PKD
1 Overview
1.1 Introduction
As part of the MRTD initiative by ICAO, participating countries will upload to and
download from a central ICAO PKD, their passport certifying credentials. A test
bench will be setup by the Operator to assist the Participating Parties in
understanding and integrating their system to the interface before proceeding to
communicate with the ICAO PKD production system.
This document outlines the procedures that will be followed by Participating

Parties, ICAO and the Operator to utilize the test bench system for the above
purpose, as indicated in Sec 5.4 of the PKD Regulations v1.9 dated 31 March
2006. Readers should be familiar with the PKD Interface Specifications v3.0 which
is the basis of the tests.
1.2 Glossary
For the purpose of these Regulations:
1. “Certificate Issuing Location” (CIL) means a location which is designated by

a Participating Party as one from which it will send Document Signer
Certificates (CDS) to the ICAO PKD;
2. “Certificate Revocation Lists (CRLs)” means the list used by a Participating

Party to revoke any of its certificates, or to signify positively with null CRLs
that no such revocations exist for any of their certificates;
3. “Country Signing CA” (CSCA) means the Certificate Authority in a

Participating Party which is responsible for managing the Country Signing CA
Certificate (CCSCA) that is used to sign all State Document Signer Certificates
(CDS). The CSCA is the highest trust authority in the Participating Party in the
context of the ICAO PKD;
4. “Country Signing CA Certificate” (CCSCA) means a PKI certificate containing

a Country Signer CA Certificate (KPuCSCA) and other standard information
about the Country Signing CA Public Key;
5. “Country Signing CA Public Key” (KPuCSCA) means the public key that is
used to decrypt and verify the digital signature on a Document Signer

ICAO PKD Issue: 3.2
Certificate (CDS);
6. “Document Signer Certificates” (CDS) means a public key infrastructure

certificate that contains a KPuDS and other standard information about the
Document Signer Public Key;
7. “Document Signer Public Key” (KPuDS) means the public key that is used to
decrypt and verify the digital signature on an eMRTD;
8. “eMRTD” means a Machine Readable Travel Document (MRTD) which

contains a contactless Integrated Circuit (IC) chip within which is stored
certain specified MRTD data, a biometric measure of the passport holder and a
security object to protect the data with PKI cryptographic technology, and
which conforms to the specifications set forth in the latest edition of Doc
9303, Part 1;
9. “eMRTD Authority” (EMA) means the main organizational entity and officer
of a Participating Party responsible for all Document Signer Certificates (CDS)
forwarded to the ICAO PKD;
10. “Fees” are the contributions to be paid by Participating Parties for

participating in the ICAO PKD, in the form of Registration Fees and Annual
Fees;
11. “Fee Schedule” means the Schedule issued and published by ICAO in
consultation with the Operator and as approved by the PKD Board, under
Article 3.1 (e) and Attachment B to the PKD Memorandum of Understanding;
12. “ICAO” means the International Civil Aviation Organization headquartered in

Montreal, Canada;
13. “ICAO Public Key Directory” (ICAO PKD) means the central database
serving as repository of document signer public keys and certificate revocation
list issued by Participating Parties, together with a system for their distribution
worldwide, maintained by ICAO on behalf of such Participating Parties in
order to facilitate validation of data contained in eMRTDs;
14. “LDAP” means Lightweight Directory Access Protocol;
15. “Operator” means the entity contracted by ICAO for the operation of the
ICAO PKD in accordance with the System Design Documentation and the
Public Key Infrastructure specifications set forth in the latest edition of Doc
9303, Part 1;
16. “Participating Parties” are those specified in Article 2.2 and 2.3 of the
Memorandum of Understanding (MoU) Regarding Participation and Cost
Sharing in the ICAO Public Key Directory (ICAO PKD);

ICAO PKD Issue: 3.2
17. “PKD Board” means the group referred to in Article 9.1 of the Memorandum
of Understanding (MoU) Regarding Participation and Cost Sharing in the
ICAO Public Key Directory (ICAO PKD), composed of up to 15
representatives designated by Participating Parties;
18. “PKD Download” means a file transfer of a complete copy of the latest
version of the PKD READ Directory in existence at any given time;
19. “PKD MoU” means the Memorandum of Understanding (MoU) Regarding

Participation and Cost Sharing in the ICAO Public Key Directory (ICAO
PKD);
20. “PKD Query” means a request for an individual CDS and any corresponding
CRLs on the PKD READ Directory, to locate a certificate reference contained
in an eMRTD;
21. “PKD Test Upload Directory” is the read-only directory version of the ICAO
PKD;
22. “PKD Test Download Directory” is the read-only directory version of the
ICAO PKD;
23. “PKD Web Site” is a web site or URL established by the Operator to enable
accessing entities to download the ICAO PKD;
24. “PKI” means Public Key Infrastructure;
25. “State Testing Contact” (STC) is designated personnel from participating

party that will communicate with the Operator during the testing process. This
personnel is designated from the “State Technical Contacts I and II” in the
Registration Form.
26. “Operator Testing Contact” (OTC) is designated personnel from the PKD
Operator that will communicate with the participating party during the testing
process.
27. “Users” means those States, territories, organizations, commercial entities, or

individuals not participants in the ICAO PKD who may access information in
the PKD READ Directory.

ICAO PKD Issue: 3.2
2 Registration
Before accessing the test bench system, Participating Parties must indicate this
intention to ICAO. This process is called “Registration”. As indicated in Sec 4.1 of the
PKD Regulations v1.9, Participating Parties will inform ICAO of the EMA and CIL.
ICAO will then inform these details to the Operator so access details can be assigned.
The procedure is:

1. Participating Party notifies ICAO of the EMA and CIL details as well as the
CCSCA that it intends to use during the integration testing. Appendix –A
includes a form pertaining to the details that will be submitted by the
Participating Party to ICAO. The state appointed “State Technical Contacts”
will act as the “State Testing Contact” (STC) to ICAO, for the purpose of
testing.
2. ICAO will then inform the Operator these details via email. This email must
include the STC designated as the contact for the integration testing on behalf
of the state.
3. The Operator will assign personnel to contact the state as “Operator Testing
Contact” (OTC). An email will be sent to the state from OTC, stating the
requirements for testing and documentation about the interface to be tested.
3 Test Setup and Process

Once the contact details between participating party and Operator have been
exchanged, testing can commence. Following outlines the testing process:
 The STC will provide a CSR (Certificate Signing Request) to the OTC. The
OTC will generate a certificate, which is used as PKI credentials to access the
Upload Directory. The certificate will be sent back to the STC. The CSR
should be generated with signatureAlgorithm: Sha1RSA and Key length:
2048.
 Operator will register the certificates and designate an “upload point” on the
“PKD Test Upload Directory” with assigned access credentials to that point,
to the STC. The access credential will consist of an LDAP ID. The server
certificate will also be sent, so that the client services can authenticate the
server. The OTC will inform these details to the STC via email.
 Operator will designate an “upload point” on the “PKD Test Upload
Directory” and assign access credentials to that point, to the STC. These
access credentials will consist of a LDAP ID and password combination. The
server certificate will also be sent, so that the client services can authenticate
the server. The OTC will inform these details to the STC via email.
 Operator will also assign access credentials to the “PKD Test Download
Directory” and the test bench webpage containing the checksum, to the STC.
These credentials consist of a LDAP UserID and password combination. The
server certificate will also be sent, so that the client services can authenticate
the server. The OTC will inform these details to the STC via email. The
participant will create their own download credentials as outlined in the “PKD

ICAO PKD Issue: 3.2
Interface specifications document, version 3.2”. Operator will create one

additional entry which can be used for the download. Participant will create
additional download entries.
 The STC will provide the CSCA used to generate the test DSCs and CRLS to
the OTC before commencement of testing.
 The state can then commence testing.
 The access credentials will be available to the participating party for a period
of 6 months or until the STC notifies to OTC via email that testing has been
completed, whichever occurs earlier. At that stage, the access credentials from
the test bench will be removed.
These tests will be done to test various usage scenarios of the PKD. For the
purpose of testing, the participating party is referred to, as the “client” and the test
bench system is referred to, as the “server”. The tests are detailed in the next
section.

ICAO PKD Issue: 3.2
3.1 Connectivity tests

3.1.1 PKD Test Upload Directory
1. The client must include the server certificate in their trusted root repository, to
verify the server certificate.
2. Client will initiate a bind operation to “PKD Test Upload Directory”. As
indicated in the interface specifications, this is a 2-way SSL protected
mechanism where the LDAP ID of the user account and the node to connect
to, are sent in the bind authentication request, along with the registered client
certificate.
3. There are two “PKD Test Upload Directories” available for the client to
initiate a bind operation. Client may choose to test one or both of the
directories.
4. During the subsequent two-way SSL process, the client will authenticate the
server and vice-versa.
5. Once the secure channel has been established, the server will authenticate the
client to the node provided and send a bind successful message back to the
client. The client would now be able to view any entries within the node
authenticated to.
For example, if the node is “c=SG, dc=pkdWrite, dc=pkdUpload” and the DN
assigned is “cn=Officer1, o=Country Upload Officer, c=SG, dc=pkdWrite,
dc=pkdUpload”, then upon a successful bind, all entries under “c=SG,
dc=pkdWrite, dc=pkdUpload” are available to be viewed by the client.
6. Do take note that client can proceed as long as there is a successful bind to
one of the directories.
7. Client should note the LDAP result code that is returned after a bind
operation. In case of any error, this information along with the DN assigned
and the node authenticating to, can be sent to the Operator to assist in any
troubleshooting.
3.1.2 PKD Test Download Directory

1. The client must include the server certificate in their trusted root repository, to
verify the server certificate.
2. Client will initiate a bind operation to “PKD Test Download Directory”. As
indicated in the interface specifications, this is a SSL protected mechanism
where the LDAP ID of the user account and the node to connect to, are sent in
the bind authentication request, along with the password.
3. There are two “PKD Test Download Directories” available for the client to
initiate a bind operation. Client may choose to test both or either of the
directories.
4. During the subsequent one-way SSL process, the client will authenticate the
server.
5. Once the secure channel has been established, the server will authenticate the
client to the node provided and send a bind successful message back to the
client. The client would now be able to view any entries within the node
authenticated to. Note that while binding to “PKD Test Download Directory”,
the client will always bind to the node “dc=pkdDownload”.

ICAO PKD Issue: 3.2
Assuming that the DN assigned is “cn=Downloader1SG”, then upon a

successful bind, all entries under “dc=pkdDownload” are available to be
viewed by the client.
6. Do take note that client can proceed as long as there is a successful bind to
one of the directories.
7. Client should note the LDAP result code that is returned after a bind
operation. In case of any error, this information along with the DN assigned
and the node authenticating to, should be sent to the Operator to assist in any
troubleshooting.

ICAO PKD Issue: 3.2
3.2 Compliance Tests

3.2.1 Checking compliance of Certificates and CRLs
1. Client can use an HTML browser to access the login page of the designated
web site. Upon login, the client can access the compliance tests.
2. Using the “Browse” button shown on the webpage, the client selects to upload
the CCSCA, CDS, CRL or CSCA Masterlist.
3. When ready, the client clicks the “Check” button, as shown below.
4. After the check is complete, a report is generated and shown to the client. In
this report, the client is shown the various criteria upon which the data was
tested, and a pass/acceptable/fail message.

ICAO PKD Issue: 3.2
5. For CDS and CRLs, the report also generated the Relative DN of the entry to
support the upload of the entry to the directory. This value is used in the
Upload Tests. An example is shown below.
6. If a certificate/CSCA Masterlist/CRL fails any compliance tests, the relevant

field is highlighted in red, as shown. Error messages, which explain why the
field failed, are printed at the bottom of the report shown below.
7. If a Certificate/CSCA Masterlist/CRL passes the compliance test with

acceptable variation(s), the relevant field is written as “ACCEPTABLE”, as
ICAO PKD Issue: 3.2
shown. Messages which explain why the field has acceptable variations are
printed at the bottom of the report shown below.

ICAO PKD Issue: 3.2
3.3 Upload Test

3.3.1 Upload to PKD Test Upload Directory
1. Once the bind operation is successful, client can create entries to upload the
desired certificate, CRL or CSCA Masterlist to the server.
2. Within the node authenticated to, there are three nodes; “o=Certificates” for
uploading CDS, “o=CRLs” for uploading CRLs, and “o=CSCAMasterList” for
uploading CSCA Masterlist.
3. When uploading a CDS, client will create a new entry under “o=Certificates” of
objectClass inetOrgPerson, with cn, sn and userCertificate attributes as
defined in the interface specifications.
For example, if the CDS was issued by “o=Issuer CA, c=SG” and the DSC
serial number is “02F45D45” then the entry’s attributes are:
dn: cn=o\=Issuer CA\,c\=SG+sn=02F45D45,
o=Certificates,c=SG,dc=pkdWrite,dc=pkdUpload
objectClass: inetOrgPerson
cn: o=Issuer CA,c=SG
sn: 02F45D45
userCertificate;binary: DER encoded binary file containing DSC
4. When the entry is successfully created in the server, an LDAP message code
of success is returned to the client. The client would now be able to view his
own entry along with any previous entries in the directory tree.
5. If there are any errors, the corresponding LDAP error code is returned to the
client. This error code and the add request data, should be noted and
forwarded to the Operator to assist in troubleshooting.
6. A similar test would be done to upload a CRL to the directory, with a
difference of, objectClass being cRLDistributionPoint, and sn being not
defined. The DN for CRLs entry consists of the issuer DN of the issuer of the
CRL, followed by “o=CRLs” and then the base DN for that country.
An example of CRL to be uploaded is:

dn: cn=o\=Issuer CA\,c\=SG,
o=CRLs,c=SG,dc=pkdWrite,dc=pkdUpload
objectClass: cRLDistributionPoint
certificateRevocationList;binary: DER encoded binary file
containing CRL
7. Another example is to upload a CSCA Masterlist to the directory, with a

difference of, objectClass being CscaMasterList, and sn being not defined.
The DN for CSCA Masterlist entry consistes of the issuer DN of the issuer of
the CSCA Masterlist, followed by “o=CSCAMasterList” and then the base
DN for that country.
An example of CSCA Masterlist to be uploaded is:

dn: cn=o\=Issuer CA\,c\=SG,
o=CSCAMasterList,c=SG,dc=pkdWrite,dc=pkdUpload

ICAO PKD Issue: 3.2
objectClass: CscaMasterList
CscaMasterListData;binary: DER encoded binary file containing CSCA
Masterlist

ICAO PKD Issue: 3.2
3.4 Download Tests

3.4.1 Download full listing
1. Once the bind operation is successful, client can send an LDAP query to
download the full listing of the PKD. The full listing is stored as an LDIF file
in a top level entry on the PKD Test Download Directory.
2. There are three types of full listing entries, each for different uses: “cn=ldif
001,ou=download,dc=pkddownload” for conformant and acceptable non-
conformant CDS and CRLs, “cn=ldif 002,ou=download,dc=pkddownload” for
conformant CSCA Masterlist and “cn=ldif
003,ou=download,dc=pkddownload” for non-conformant CDS and CRLs.
3. As specified in the interface specifications, the LDAP search query syntax for
the entry “cn=ldif 001,ou=download,dc=pkddownload” is of the form
(&(objectClass=*)(!(version=xxxxxx))) where xxxxxx refers to the
current version number of the client. At the beginning of the test, the client
must send 000000 to signify that it has no previous data. Subsequently, the
client should include the version number in the query. For example, if the
client already has version 000033 then the query sent to the server would be,
Message Type: Search Request (0x03)
Base DN: dc=pkddownload
Scope: Base (0x00)
Dereference: Searching (0x01)
Size Limit: 0
Time Limit 0
Filter: (&(objectClass=*)(!(version=000033)))
the entry “cn=ldif 002,ou=download, dc=pkddownload” is of the form
(&(objectClass=*)(!(lversion=xxxxxx))) where xxxxxx refers to the
Scope: Base (0x00)
Size Limit: 0
Time Limit 0
Filter: (&(objectClass=*)(!(lversion=000033)))
the entry “cn=ldif 003,ou=download,dc=pkddownload” is of the form
(&(objectClass=*)(!(cversion=xxxxxx))) where xxxxxx refers to the

ICAO PKD Issue: 3.2

Scope: Base (0x00)
Size Limit: 0
Time Limit 0
Filter: (&(objectClass=*)(!(cversion=000033)))
6. A new version is released every one hour by the server, containing all
certificates, CRLs and CSCA Masterlist up to that hour.
If a new version is available, the base entry containing the new LDIF file and
the new version information will be sent back to the client, together with
Search result of one entry. If no new version is available, no new data is sent
back to the client. In both cases, an LDAP code of success is returned
signifying that the query was executed successfully on the server.
An example of a successful download of the LDIF file is shown below.
dn: cn=ldif 001,ou=download,o=pkddownload
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: ldif 001
sn: 0001
version: 000034
LDIFPKD:
#version: 1
dn: dc=data,dc=pkdDownload
dc: data
objectClass: top
objectClass: domain
dn: c=CA, dc=data,dc=pkdDownload

objectClass: top
objectClass: country
c: CA
dn: o=certificates, c=CA, dc=data,dc=pkdDownload

objectClass: top
objectClass: organization
o: certificates
dn: cn=CN\=csca-canada\,OU\=pptc\,O\=gc\,C\=ca+sn=4942BE14, o=certificates, c

=CA, dc=data,dc=pkdDownload
OTDoc9303Result: WARN:DSC:Issuer: countryName is in lowercase. Please change
it to uppercase.|DSC:Issuer: organizationName is in PrintableString. Please
change it to UTF8String.|DSC:Issuer: organizationalUnitName is in PrintableS
tring. Please change it to UTF8String.|DSC:Issuer: commonName is in Printabl
eString. Please change it to UTF8String.|DSC:Subject: countryName is in lowe
rcase. Please change it to uppercase.|DSC:Subject: organizationName is in Pr
intableString. Please change it to UTF8String.|DSC:Subject: organizationalUn
itName is in PrintableString. Please change it to UTF8String.|DSC:Subject: c
ommonName is in PrintableString. Please change it to UTF8String.
userCertificate:: MIIE+DCCAqygAwIBAgIESUK+FDBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAF
lAwQCAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASAwPzELMAkGA1UEBhMCY2E
xCzAJBgNVBAoTAmdjMQ0wCwYDVQQLEwRwcHRjMRQwEgYDVQQDEwtjc2NhLWNhbmFkYTAeFw0wOTE
yMDQxNDI3MDFaFw0xNTA0MDQxNDU3MDFaMDcxCzAJBgNVBAYTAmNhMQswCQYDVQQKEwJnYzENMAs
GA1UECxMEcHB0YzEMMAoGA1UEAxMDRFMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE
AyD4bsK1TTRJU0t0toprz306HEs3rXpL4+7/eXQQsTz1M/+Rzy2vNHuSyVqurWhySaeLyk2CMJmv
p0oobObS5PvFc0K4sEnLSL5CyTAOcvzRDE3yF1Onow9SZr5wMdnX13mLimvqSJVy76f1ZRilNi7E
HmvXkSVjciEjsCHktNt354J8EN+/U/w7pfJdh6kfgdLQ7AoqJ21OiR1anLmSfGhx9dFUE8u0outk
nhTWFnp9qe0v9W/YY/BUNAmTbXUO55a02UvL8Z0CirZAg56FC9S8we0jAMgY9xfn+BjlqQUJWSI7
WkfbvdoEsaZEH8qD9+Fpan67HDl0SxMtXD/SfZwIDAQABo4GbMIGYMA4GA1UdDwEB/wQEAwIHgDA
rBgNVHRAEJDAigA8yMDA5MTIwNDE0MjcwMVqBDzIwMTAwMzMxMDk1NzAxWjAZBgNVHSAEEjAQMA4
GDGB8ZQGCGwgFAQIBATAfBgNVHSMEGDAWgBQtsW3hQwPYdcOHuaoVEAG1gRZPGDAdBgNVHQ4EFgQ
UwtWIAKAHgu74SOM4FZJOwhJAOqkwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBo
GCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgA4ICAQBhu+PoPS0ycK57oNTo/YcqjrsV0Se
S4poio7R0mz1T845Y0HxvQGTW4wKi/ASP1XB+jM6I6WSiy08QH/HJzqQuJirwjQl7o93KxWYIWYN
aRRvf13xXV1kq+xelaSKg2bVx9Y8VwQWXQzRUNkSxowhD9rmkCuQqQ+FRzddaSNUAvpzDODLaNsC

ICAO PKD Issue: 3.2
34m+wTnHbajD9vWcaZ98INjUMnBG7DprVQP8MOamKrSARARbyUahN0Ak0sqEY53VLC7J2aJMT12I
H/bML2ehcYj3udmZFxCo8M6uMC6lAQIhWgc9Q7ibRTIv+9ZTeC5KgOamowfV8sE3Or0QTpdG1VYx
ocg5GTPN+0Hz35h0wlwEgwtaGAg1Qk+l+F/g5NAqmJLrQ4HbT40YI6S4EHfIrSfOmYkrGEH51Gq6
siUOyxkx0Hwn+Zb4qqWfMDRAxYO2qSOLXbciBrw3s84CqTtKyElu8vslwDK7DKFGVLHxUtjS/qC+
LK61DEyB9cIBsxwoZqhufbMICgTsKjxxMP2/1AR1XX2nh7uPVz8eRkh66rLwoImgOH9AFZmhtAi3
bPNT+/m6oFurSkDhfK5+M1zo4PHSCBZ19pl/8sx1UAQyT71+Knd2uziXsMVhTeqxeUOuBvdodq/b
Ke6wwcXbC7ef87O/vLfEoQOj1dd5RJLjMfseMCdec3Adfiw==
objectClass: top
objectClass: person
OTDoc9303Code: WARN:DSC.ISS.11:DSC.SUB.11
sn: 4942BE14
cn: CN=csca-canada,OU=pptc,O=gc,C=ca
The LDIF file is the contents of the LDIFPKD attribute from the search result.
7. If the code returned is not “LDAP success”, clients should note the LDAP
code returned by the server. This data and the search filter used should be sent
to the Operator for troubleshooting.
Once a new LDIF file is obtained, the client should then retrieve the integrity
checksum from the test bench webpage, to be compared to a calculated
checksum of this LDIF file. The checksum is obtained by calculating a SHA-1
hash of the LDIF file, and then hex encoding the result. If the two checksums
are identical, then a successful download has concluded. If the checksums do
not match, then the LDIF file and the retrieved checksum should be preserved
and sent to the Operator to assist in troubleshooting.
3.4.2 Download delta listing

1. Client may choose to send an LDAP query to download the delta listing of the
PKD for subsequent updates excluding non-conformant entries.
2. The LDAP search query syntax is of the form cn=xxxxxx where xxxxxx refers
to the current version number of the client. The base DN used is
“ou=deltas,dc=pkddownload”, different from full listing. For example, if the
Base DN: ou=deltas,dc=pkddownload
Scope: Base (0x00)
Size Limit: 0
Time Limit 0
Filter: cn=000033
3. Client may choose to send an LDAP query to download the non-conformant

delta listing of the PKD for subsequent updates.
4. The LDAP search query syntax is of the form cn=xxxxxx where xxxxxx refers
to the current version number of the client. The base DN used is
“ou=deltasNC,dc=pkddownload”, different from delta and full listing. For
example, if the client already has version 000033 then the query sent to the
server would be,
Base DN: ou=deltasNC,dc=pkddownload
Scope: Base (0x00)

ICAO PKD Issue: 3.2
Size Limit: 0
Time Limit 0
Filer: cn=000033
5. A new version is released every one hour by the server, containing all
certificates, CRLs and CSCA Masterlist up to that hour.
If a new version is available, the base entry containing the new LDIF file and
the new version information will be sent back to the client, together with
search result of one entry. If no new version is available, no new data is sent
back to the client. In both cases, an LDAP code of success is returned
signifying that the query was executed successfully on the server.
An example of a successful download of the Delta LDIF file is shown below.
dn: cn=000033,ou=deltas,dc=pkddownload
objectClass: top
objectClass: person
cn: 000033
sn: 000033
LDIFPKD:
#Version: 1
dn: cn=CN\=e-passportCSCA\,OU\=The Ministry of Foreign Affairs\,O\=Japanese G

overnment\,C\=JP+sn=53,o=certificates,c=JP,dc=data,dc=pkddownload
changetype: delete
dn: cn=CN\=e-passportCSCA\,OU\=The Ministry of Foreign Affairs\,O\=Japanese G

overnment\,C\=JP+sn=53,o=certificates,c=JP,dc=data,dc=pkddownload
changetype: add
userCertificate:: MIIFMDCCAuSgAwIBAgIBUzBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAFlAwQ
CAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASAwbjELMAkGA1UEBhMCSlAxHDA
aBgNVBAoME0phcGFuZXNlIEdvdmVybm1lbnQxKDAmBgNVBAsMH1RoZSBNaW5pc3RyeSBvZiBGb3J
laWduIEFmZmFpcnMxFzAVBgNVBAMMDmUtcGFzc3BvcnRDU0NBMB4XDTExMDMwMTAyMzkyMloXDTI
yMDMwMTAyMzkyMlowgZMxCzAJBgNVBAYTAkpQMRwwGgYDVQQKDBNKYXBhbmVzZSBHb3Zlcm5tZW5
0MSgwJgYDVQQLDB9UaGUgTWluaXN0cnkgb2YgRm9yZWlnbiBBZmZhaXJzMRUwEwYDVQQLDAxlLXB
hc3Nwb3J0RFMxJTAjBgNVBAMMHE1pbmlzdGVyIGZvciBGb3JlaWduIEFmZmFpcnMwggEgMA0GCSq
GSIb3DQEBAQUAA4IBDQAwggEIAoIBAQDTSajyfdEQO0qaXVA2XjML/YCBoYJHlF7BKNbJvYEWZpI
eIXRcMokS58foXG4BkR4lXq178ZmRN8XLgUVP5TPDxTkm/kBxhzY7GGgc4QsTYky2Ku1nV9QuKFX
e74SeIUsv5xW5HH42gKIT4FMKPDp+dfAGUgD5crYzNxe3VLNx4yDkDWdQxovc7bx5uutrmtvLRL8
FsokDxBjlkLXDSpoekBuy3ffI8QPXP1qQiiChAw7vnoO1TbXKnUCyZjTnV7THFRU5rEO9tSgBxCp
wampAtbA0XZGz4gXCtNVvgQmb0PQt4Jql9uYuQrkL/vjZjGKklhyAB3tG8fPCDNSy6YZRAgEDo00
wSzAfBgNVHSMEGDAWgBRYEi7roynd/MKGQtIFv2dbjC9+1jAOBgNVHQ8BAf8EBAMCB4AwGAYDVR0
gBBEwDzANBgsqgwiGj34GBQEBAjBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAFlAwQCAQUAoRwwGgY
JKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASADggIBAHX9J4wKNhh7z8ypSmT3X4zfDoMqn9W
Xz5WDgT3AuEdeZqSIvA2qsOCj97+3nf2Eoz+5bm/8rPUFcO/cfUM8hWjVZe2vdOClLecgBY/xZJ/
ecVHkL+vDVlI2iBvkhweZTCFny2XQssRYfHllsu7VRhV6IxUNRl56o7B4UqI/+qP6GafBrcHH/DD
Zg617ZuQYsN29gVe7ldt7iYgXaVHnhFDiXrbBkApBYELqqtPrYA/8km2MpcFp45q2X9NG/2//ji5
Rd216YU36TuO3wG2woxaE6Fze2wIKGvCZ2bWH29EZNKRgz7Bzixhqtbqh2227dL0Ah11Ux6ubp38
KLARmXt4cR4brG8ZQNxAQBNePy34GiQ1MhmnhB0fhkEWQ0klef2vSGzeYf1UgQfGmWkbpKuksxKr
ss3UlqbL6i+Y4wRdYGDt/Vgj9fRmPz74y8tlhF2AK55z5iDKZcuT+UNIVsIBdtPW5nII1CHBGplJ
vGfGVlehMkuq5PFVpnL7Tm9mmxYD5W7FjEXVWYr8LpAz/GxblI+jx29YAhqI9AeA9jGxo9bjBmYB
skwhA9AVuREdA8YQzI9FvCKRxi3LSFyYwg/R217wAPNlxmn//VshQfS5bZfrfAJQP94VOiu5+7k7
WHr7B6qdbRYI8EPEt5rlcbn1qMpgBSAjmn5mvUxEfPaGY
objectClass: top
objectClass: person
sn: 53
cn: CN=e-passportCSCA,OU=The Ministry of Foreign Affairs,O=Japanese Governmen
t,C=JP
An example of a successful download of the Non-conformant Delta LDIF file

is shown below.
dn: cn=000033,ou=deltasNC,dc=pkddownload
objectClass: top

ICAO PKD Issue: 3.2
objectClass: person
cn: 000033
sn: 000033
LDIFPKD:
#Version: 1
dn: cn=CZE,o=CRLs,c=CZ,dc=non-conformant,dc=pkddownload
changetype: delete
dn: cn=CZE,o=CRLs,c=CZ,dc=non-conformant,dc=pkddownload
changetype: add
OTDoc9303Result: WARN:CRL:Issuer: organizationName is in PrintableString. Ple
ase change it to UTF8String.|CRL:Issuer: organizationalUnitName is in Printa
bleString. Please change it to UTF8String.|ERR:CRL:Issuer: commonName is in
TeletexString. Please change it to UTF8String.
objectClass: top
objectClass: cRLDistributionPoint
OTDoc9303Code: WARN:CRL.ISS.11:ERR:CRL.ISS.11
certificateRevocationList:: MIICuTCB7gIBATBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAFlA
wQCAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASAwVzELMAkGA1UEBhMCQ1oxF
zAVBgNVBAoTDkN6ZWNoIFJlcHVibGljMR0wGwYDVQQLExRNaW5pc3RyeSBvZiBJbnRlcmlvcjEQM
A4GA1UEAxQHQ1NDQV9DWhcNMTEwOTIxMDAwMDAwWhcNMTExMjIwMDAwMDAwWqAvMC0wHwYDVR0jB
BgwFoAUtIGZ9eyQ2j8Nb586fefgwXWUliwwCgYDVR0UBAMCAWIwQQYJKoZIhvcNAQEKMDSgDzANB
glghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgA4IBgQBfTIYIM
adXhBwq6LNLizpOEBu7Wprf++nO30dPYwG6K7Z4QpvTH1QNuuyN/wqCYH1QWZrTcfYE+NP2YVDZb
L2ANvQLAd/h0Tb4rJXpQA98ZrSpfOpUGGHUz8V1edLQ9Jqg50R+jJibFIfHOTf9rCqJnjPz9hd+u
sDJ2FUvilCr1HdRW5AjJoj70C6n4KVLpRgn7/Mphp50vF9OqPTUBEI2nLqAjOacTclL4SWA3AyHO
oBsx37XI64uQw54jwWIveTQV3mhKHeshLEvU6XjhNIQG5yyOzLkSBQXLj5EsyJaNGX5o2yHbTkJb
vmaIq6PFo3wKJSKciRxTo7zAQWoUJkvGNNoYMLpLz/xhrgK/yQzuyyxs6lpMEPAirV1Utc60Z8Yo
8cB7msQNdt8W9l3vFl/BP4R9OumGvIAdop3RT0VAswsCc9jOjQwgj43Jk9+9Lt5uAsNPqA7gucdi
wGL9uD57ZuGn6tHXwihfGGHBU29Kzu842ohmhy3HjN2/dioMK8=
cn: B48199_CN=CSCA_CZ,OU=Ministry of Interior,O=Czech Republic,C=CZ
The LDIF file is the contents of the LDIFPKD attribute from the search result.
Once a new LDIF file is obtained, the client should then retrieve the integrity
checksum from the test bench webpage, to be compared to a calculated
checksum of this LDIF file. The checksum is obtained by calculating a SHA-1
hash of the LDIF file, and then hex encoding the result. If the two checksums
are identical, then a successful download has concluded. If the checksums do
not match, then the LDIF file and the retrieved checksum should be preserved
and sent to the Operator to assist in troubleshooting.
3.4.3 PKD Query

1. Once the bind operation is successful, client can send a LDAP query to search
for filtered certificates, CRLs or CSCA Masterlist from the PKD Test
Download Directory.
2. Note that the base DN to connect to is always “dc=pkdDownload”.
For example, a search for CDS with a sn=42602b75 would be
Base DN: dc=pkdDownload
Scope: Sub (0x02)
Size Limit: 0
Time Limit: 0

ICAO PKD Issue: 3.2
Filter: (sn=42602b75)
3.
Unlike CDS, CRLs does not have the entry “sn”. The “cn” of CRL is made up
of ICAO country code as it appears in the MRZ of the Participating parties. If
this country code does not uniquely define the issuing State or entity, the “cn”
will be appended with the symbol “_” and then the ICAO assigned three letter
code for the issuing State or entity.
An example of a participating parties whose country code in the MRZ

uniquely define the issuing State or entity:
If the issuer DN for Singapore is: “o=Passport Issuer,c=SG”, then the search
would be
Scope: Sub (0x02)
Size Limit: 0
Time Limit: 0
Filter: (cn=SGP)
An example of a participating parties whose country code in the MRZ does

not uniquely define the issuing State or entity:
If the issuer DN for Hong Kong is: “o=Hong Kong Passport Issuer,c=CN”,
then the search would be
Scope: Sub (0x02)
Size Limit: 0
Time Limit: 0
Filter: (cn=CHN_HKG)
4. A search for CSCA Masterlist for Germany would be

Scope: Sub (0x02)
Size Limit: 0
Time Limit: 0
Filter: (cn=DE_Masterlist)
5. If the search results in valid results, those results will be sent back to the
client. If no matching data is found, no new data is sent back to the client. In
both cases, an LDAP code of success is returned signifying that the query was
executed successfully on the server.
For example, above query would return a search result as
Message Type: Search Entry (0x04)
DN: cn=o\=Issuer
CA\,c=\US+sn=42602b75,o=Certificates,c=US,dc=data,dc=pkdDownload
cn: o=Issuer CA,c=US
sn: 42602b75

ICAO PKD Issue: 3.2
userCertificate;binary: DER encoded binary file containing DSC

ICAO PKD Issue: 3.2
4 APPENDIX A: PROJECT FORMS.

The aim of this appendix is to present examples of the administrative forms
that will be used by the PKD system for the test bench.
These are as follows:
I. Registration for Test Bench Participation;

FORM: REGISTRATION OF COUNTRY FOR PUBLIC KEY
DIRECTORY
This is the form for registration of new countries for the public key directory
usage. The details are:
1. The “State Technical Contact I” contains details of the technical personnel

who will liaise with ICAO and Netrust as a primary, for all technical
matters pertaining to the PKD. As a backup, “State Technical Contact II”
details are also required, to ensure communication in case the first contact
is unavailable.
2. The authority responsible for the upload of PKD data is called the
“Country Upload Officer I”. This person will be an administrative
contact between ICAO, Netrust and the country for all non-technical
matters such as membership and fees. The credentials to access the
upload and download PKD will be sent to this contact person. As a
backup, “Country Upload Officer II” details are also required, to ensure
communication in case the first contact is unavailable.
3. As part of the due-diligence process, update emails are sent regularly to a

PKD member state when it’s DSC or CRL is processed. The section on
“PKD Notification Recipients” contains the email addresses of all
personnel in a country that will need to receive these emails.
4. The primary authority for e-passports for each participating state is

termed “E-MRTD Authority”. This is the same authority that signed the
MoU on behalf of the state for participation in the PKD. These details of
the e-MRTD authority will be published in the PKD so that other PKD
participants can communicate with it for diplomatic exchanges such as the
distribution of CSCA certificates.
This registration from must be signed and stamped by the e-MRTD

Authority, with the same seal as that used during the signing of PKD MoU.
REGISTRATION FOR COUNTRY FOR PUBLIC KEY DIRECTORY PARTICIPATION
STATE TECHNICAL CONTACT I
Name:
Title:
Postal Address:
Email:
 Office : Mobile/Cell: Fax:
STATE TECHNICAL CONTACT II

Name:
Title:
Postal Address:
Email:
COUNTRY UPLOAD OFFICER I

Name:
Title:
Postal Address:
Email:
COUNTRY UPLOAD OFFICER II

Name:
Title:
Postal Address:
Email:
PKD NOTIFICATION RECIPIENTS

Email(s):
E-MRTD AUTHORITY (COMMISSIONER OF PASSPORTS)

Name:
Title:
Organization:
Postal Address:
Email:
 Office : Fax:
Mobile/Cell:
PKD UPLOAD - CLIENT CERTIFICATE CSR
(Please type as Base64, DER encoded, in 10pt courier new font)
Signature Seal Date

ICAO PKD Testbench Procedures v3.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ICAO PKD Testbench Procedures v3.2

Uploaded by

Copyright:

Available Formats

Netrust Pte Ltd

PKD Test Bench Procedures -

Netrust Pte Ltd

ICAO PKD System

PKD Test Bench Procedures

Filing Reference: NPL/ICAO-PKD/PKD-TBP/

Document Title : Test Bench Procedures

Prepared By : Andy Hing

Date Created : 28 Aug 2013

Approved for release By : R. Rajeshkumar ___________

Document Reference: NPL/ICAO-PKD/PKD-TBP/

Confidential Netrust Pte Ltd, 2006-2013 Page 2 of 27

Confidential Netrust Pte Ltd, 2006-2013 Page 3 of 27

3 Test Setup and Process 8

4 APPENDIX A: PROJECT FORMS. 24

FORM: REGISTRATION OF COUNTRY FOR PUBLIC KEY DIRECTORY 25

Confidential Netrust Pte Ltd, 2006-2013 Page 4 of 27

PKD Test Bench Procedures -

This document outlines the procedures that will be followed by Participating

For the purpose of these Regulations:

1. “Certificate Issuing Location” (CIL) means a location which is designated by

2. “Certificate Revocation Lists (CRLs)” means the list used by a Participating

3. “Country Signing CA” (CSCA) means the Certificate Authority in a

4. “Country Signing CA Certificate” (CCSCA) means a PKI certificate containing

Confidential Netrust Pte Ltd, 2006-2013 Page 5 of 27

6. “Document Signer Certificates” (CDS) means a public key infrastructure

8. “eMRTD” means a Machine Readable Travel Document (MRTD) which

10. “Fees” are the contributions to be paid by Participating Parties for

12. “ICAO” means the International Civil Aviation Organization headquartered in

14. “LDAP” means Lightweight Directory Access Protocol;

Confidential Netrust Pte Ltd, 2006-2013 Page 6 of 27

19. “PKD MoU” means the Memorandum of Understanding (MoU) Regarding

24. “PKI” means Public Key Infrastructure;

25. “State Testing Contact” (STC) is designated personnel from participating

27. “Users” means those States, territories, organizations, commercial entities, or

Confidential Netrust Pte Ltd, 2006-2013 Page 7 of 27

The procedure is:

3 Test Setup and Process

Confidential Netrust Pte Ltd, 2006-2013 Page 8 of 27

Interface specifications document, version 3.2”. Operator will create one

Confidential Netrust Pte Ltd, 2006-2013 Page 9 of 27

3.1 Connectivity tests

3.1.2 PKD Test Download Directory

Confidential Netrust Pte Ltd, 2006-2013 Page 10 of 27

Assuming that the DN assigned is “cn=Downloader1SG”, then upon a

Confidential Netrust Pte Ltd, 2006-2013 Page 11 of 27

3.2 Compliance Tests

Confidential Netrust Pte Ltd, 2006-2013 Page 12 of 27

6. If a certificate/CSCA Masterlist/CRL fails any compliance tests, the relevant

7. If a Certificate/CSCA Masterlist/CRL passes the compliance test with

Confidential Netrust Pte Ltd, 2006-2013 Page 14 of 27

3.3 Upload Test

An example of CRL to be uploaded is:

7. Another example is to upload a CSCA Masterlist to the directory, with a

An example of CSCA Masterlist to be uploaded is:

Confidential Netrust Pte Ltd, 2006-2013 Page 15 of 27

Confidential Netrust Pte Ltd, 2006-2013 Page 16 of 27

3.4 Download Tests

Confidential Netrust Pte Ltd, 2006-2013 Page 17 of 27

Base DN: dc=pkddownload

dn: c=CA, dc=data,dc=pkdDownload

dn: o=certificates, c=CA, dc=data,dc=pkdDownload

dn: cn=CN\=csca-canada\,OU\=pptc\,O\=gc\,C\=ca+sn=4942BE14, o=certificates, c