MACHINE READABLE TRAVEL DOCUMENTS

Transcription

1 MACHINE READABLE TRAVEL DOCUMENTS TECHNICAL REPORT Version 1.0 Date June 23, 2009 Published by authority of the Secretary General ISO/IEC JTC1 SC17 WG3/TF5 FOR THE INTERNATIONAL CIVIL AVIATION ORGANIZATION File Author : WG3TF5_N0059R5 TR- V1.0.doc : ISO/IEC JTC1 SC17 WG3/TF5

2 Release Control Release Date Description First draft discussed in TF5, Chantilly Noveber Corrections & additions after Chantilly eeting Additional coents Deceber 10 & Additional coents Deceber 14 & Review TF5 March : TF5 eail discussion results incorporated; version for PKD Board 0.61: Nae correction in TR editorial group Corrected ASN.1 specification in Updated Certificate profile in Final version delivered to ICAO PKD board Technical Report editorial group Alan Bennett Australia DFAT Christian Berczely USA L1 Sharon Boeyen Canada Entrust Doinique Gatinet France Secure Docuent Agency Sion Godwin USA Apptis Hartut Hee Gerany Bundesdrückerei Mike Holly USA State Dept. Barry Kefauver USA Fall Hill Associates Steve Kelly UK DeLaRue To Kinneging Netherlands Sdu Identification Dennis Kügler Gerany BSI Patrice Plessis France Gealto R. Rajeshkuar Singapore Netrust Bill Russell USA Mount Airey Group Steffen Scholze Gerany Bundesdrückerei Minoru Uehara Japan NTT Petri Viljanen Finland Gealto Dirk Wacker Gerany Giesecke & Devrient Bradford Wing USA Dept. of Hoeland Security 2 of 15

3 Table of contents 1. INTRODUCTION BACKGROUND OPERATIONAL EXPERIENCES MODIFIED APPROACH ASSUMPTIONS TERMINOLOGY Technical report terinology CAs, Keys and Certificates OVERVIEW GENERAL OUTLINE CSCA COUNTERSIGNING PROCESS Issuing a CSCA Master List Master List Signer revocation Receiving a CSCA Master List PUBLICATION ON THE PKD RELYING PARTIES TECHNICAL SPECIFICATIONS CSCA MASTER LIST SPECIFICATION SignedData Type ASN.1 specification for the CSCA Master List CSCA MASTER LIST SIGNING CERTIFICATE PROFILE Certificate Body Etensions ANNEX A REFERENCE DOCUMENTATION ANNEX B ABBREVIATIONS of 15

4 1. Introduction 1.1 Background The principles of PKI schees have evolved in their use to becoe highly cople in their application to odern scenarios. Their general priary use is in Internet transactions, where keys are to be trusted across a broad range of users and organizational entities; this has resulted in elaborate systes of key certificates, where public keys are issued in certificates which are digitally signed by trusted issuing organizations called Certificate Authorities (CA s). The trust in these CA organizations is further being reinforced by higher level CA s in a trust hierarchy. A coplicating factor is the need for Certificate Revocation Lists (CRL s), indicating where a key (certificate) has lost it s validity for whatever reason. In fact, by revoking a certificate and publishing this revocation in a CRL, the certificate s issuer infors receiving parties that the contents can no longer be trusted. The ICAO operating environent is different fro the above entioned coercial environents, where the question of public key revocation applies in a different way (copared to individual users), since the unlikely event of a coproise of any State s private key used during soe period to sign any MRTDs cannot deny that docuents were indeed legitiately issued and signed using that key. These (valid) docuents will reain in use by their holders for travel purposes. As a consequence, ICAO has specified a custoized approach, intended to enable the MRTD counity to fast-track ipleentation of this application for MRTDs with IC read-only access, and take advantage of its benefits without attepting to address larger PKI policy issues and cople hierarchies. The ICAO PKI schee specifies a two-layer certificate chain, enabling an inspection syste to verify the authenticity and integrity of the data stored in the MRTD s contactless IC. The (highest level) root CA in this schee is the Country Signing CA (CSCA), which authorizes Docuent Signers (DS) to digitally sign the Docuent Security Object (SO D ) on the contactless IC. The CSCA certificate is distributed bilaterally by diploatic echange to relying States. The DS certificate is published on the ICAO Public Key Directory (PKD) and/or stored on the MRTDs contactless IC. Certificate Revocation Lists are published on the PKD and echanged bilaterally. 1.2 Operational eperiences Doc 9303 specifies that the echange of CSCA certificates has to be bilateral, without providing detailed specifications on echaniss for this echange. The first years in which States issue e- passports show that the lack of such specifications has lead to wide interpretation and inefficient processes. 1.3 Modified approach The approach described in this Technical Report ais to provide an electronic eans of distributing and publishing issuing States CSCA Public Keys. The odified approach is based on countersigning the CSCA certificates of issuing States by other States, and distributing the countersigned CSCA certificates via the ICAO PKD, to support but not to replace bilateral distribution of self-signed certificates. For this purpose the countersigning State publishes a signed list of received and validated self-signed CSCA certificates. The process of countersigning keys issued by other CAs is also known as Cross Certification, but as opposed to X.509 Cross Certification in this application no assertion is ade by the countersigning State other than the fact that the countersigning State has received the CSCA certificate fro the originating State. 4 of 15

5 If a State chooses to accept a CSCA certificate through this odified approach, whithout bilateral relationship with the State that has issued the CSCA certificate, then specific arrangeents MUST be ade with this issuing State for the echange of CRLs. 1.4 Assuptions It is assued that the reader is failiar with the concepts and echaniss offered by public key cryptography and public key infrastructures. It is assued that the reader is failiar with the contents of [R2], ICAO Doc 9303, Machine Readable Travel Docuents, [R6], ICAO Suppleent to Doc 9303 and any other official docuents issued by ICAO regarding Machine Readable Travel Docuents. It is not feasible that ICAO, or any other single, central organization will assign, aintain or anage secure private keys for any State. Despite any strategic alliances aong participants this approach will not be recognized as being a trusted solution. 1.5 Terinology Technical report terinology The key words "MUST", MUST NOT, "SHALL", SHALL NOT, "REQUIRED", "SHOULD", SHOULD NOT, "RECOMMENDED", "MAY", and OPTIONAL in this docuent are to be interpreted as described in [R1], RFC 2119, S. Bradner, "Key Words for Use in RFCs to Indicate Requireent Levels", BCP 14, RFC 2119, March In case OPTIONAL features are ipleented, they MUST be ipleented as described in this Technical Report CAs, Keys and Certificates The following Keys and Certificates are relevant within the scope of this Technical Report: Nae Country Signing CA Country Signing CA Certificate Country Signing CA Private Key Country Signing CA Public Key Country Signing CA Link Certificate CSCA Master List Docuent Signer Docuent Signer Certificate Coents Docuent Signer Private Key Signing the SO D. Issued by CSCA (self-signed). Carries the Country Signing CA Public Key. Stored in the inspection syste. Signing the Docuent Signer Certificate. Stored in a Issuing State s (highly) secured environent. For verification of the authenticity of the Docuent Signer Certificate. A PKI certificate containing a Country Signing CA Public Key and other standard inforation about the Country Signing CA Public Key. A Country Signing CA Link Certificate is signed by the sae Country Signing CA using the previous Country Signing CA Private Key. A signed list of CSCA certificates Issued by the CSCA. Carries the Docuent Signer Public Key. Stored in the inspection syste AND/OR in the MRTD s chip. 5 of 15

6 Nae Coents Stored in a Issuing State s (highly) secured environent. Docuent Signer Public Key For verification of the authenticity of the SO D. Docuent Security Object A RFC3369 CMS Signed Data Structure, signed by the DS. Carries the hashed LDS Data Groups. Stored in the MRTD s chip. MAY carry the Docuent Signer Certificate. Master List Signer Copiles, signs and publishes CSCA Master Lists; authorised by the CSCA. 6 of 15

7 2. Overview 2.1 General outline The authenticity and integrity of data stored on epassports is protected by Passive Authentication. This security echanis is based on digital signatures and consists of the following Public Key Infrastructure (PKI): 1. Country Signing CA (CSCA): Every State establishes a CSCA as its national trust point in the contet of epassports. The CSCA issues public key certificates for one or ore (national) Docuent Signers. 2. Docuent Signers (DS): A Docuent Signer digitally signs data to be stored on epassports; this signature is stored on the epassport in a Docuent Security Object. Both the CSCA Certificates and Docuent Signer Certificates are associated with a (private key) usage and a (public key) validity period. The following table gives an overview on the validity periods. Private Key Usage Public Key Validity (assuing 10 year valid passports) Country Signing CA 3-5 years years Docuent Signer 3-5 onths appro. 10 years While the CSCA Certificate reains relatively static, a large nuber of Docuent Signer Certificates will be created over tie. The ICAO PKD is intended to collect, store and publish all those Docuent Signer Certificates (as described in ore detail below), there is also another way to obtain the Docuent Signer Certificate corresponding to a Docuent Security Object read fro a passport: The Docuent Security Object itself ay contain a copy of the Docuent Signer Certificate. To use Passive Authentication, the inspection syste has to perfor the following steps: 1. Read the Docuent Security Object of the epassport. 2. Retrieve the corresponding Docuent Signer Certificate. 3. Look up the corresponding CSCA Certificate in the list of trusted CSCA Certificates. 4. Check for Certificate Revocation Lists (CRLs). 5. Verify the Docuent Signer Certificate (and possibly CRLs) with the trusted CSCA public key. 6. Verify the Docuent Security Object with the Docuent Signer public key. Independent of whether the Docuent Signer Certificate is retrieved fro the PKD or directly fro the epassport being read, the security of Passive Authentication depends on the integrity and authenticity of the trusted CSCA Certificates. One of the prie tasks surrounding this PKI is establishing and aintaining trust in a state's CSCA Certificate. The current process relies heavily on the initial echange of CSCA Certificates by diploatic eans and requires that received CSCA certificates are stored securely and cannot be substituted. The potential substitution or addition of a rogue CSCA Certificate is one of the ajor risks to the schee. The addition of the CSCA Certificate of a noneistent State is however uch harder to detect than a siple substitution of a CSCA certificate: if soeone adds the CSCA Certificate of Utopia it ay not be spotted for a long tie, but 7 of 15

8 if soeone substitutes the CSCA Certificate of a large State all respective epassports becoe invalid which ay be spotted very quickly. This Technical Report itigates the risk of the substitution/addition of rogue CSCA certificates through States publishing in a verifiable way which CSCA certificates are validated and in use by a State. 2.2 CSCA countersigning process A Master List of trusted CSCAs is used in the inspection process. Each State produces its own list of CSCA certificates that is relied on in the inspection process. Copiling this list is based on diploatic echanges and subsequent verification processes. A State MAY countersign, and publish to the PKD, its Master List of received certificates as part of the diploatic echange. It is at the receiving State s discretion to deterine the way it verifies and uses the received certificates. To illustrate the idea, consider the following eaple: State A echanges CSCA certificates with States B, X, Y and Z via trusted channels. State A copiles, countersigns and publishes a Master List containing B, X, Y, Z and A. State B echanges CSCA certificates with States A, X, Y and Z. It validates the certificates it receives against the Master List published by State A. This allows State B to double-check received certificates fro X, Y and Z. State B copiles, countersigns and publishes a Master List containing A, X, Y, Z. This provides State X with the CSCA certificates of States Y and Z which it can use, based on its confidence in the validity of the inforation provided by State A and State B. This eans that for State X the schee works even though there hasn t been any certificate echange by diploatic eans between States X, Y and Z. The sae applies to States Y and Z. The following sections give soe guidelines for the handling of CSCA Master Lists Issuing a CSCA Master List CSCA Master Lists MUST NOT be issued directly by a CSCA, instead the CSCA SHALL authorize a Master Lister Signer to copile and sign and publish CSCA Master Lists by certifying the Master List Signer according to the Certificate Profile specified in par Before issuing a CSCA Master List the issuing Master List Signer SHOULD etensively validate the CSCA certificates to be countersigned; i.e. the issuing CSCA SHOULD ensure that the certificates indeed belong to these CSCAs. Diploatic echange is an eaple of a secure validation procedure, but an issuing CSCA ay also define other policies under which it issues CSCA Master Lists. The procedures to be perfored for validation and countersigning SHOULD be reflected in the published certification policies of the issuing CSCA. The Master List issuer MUST include the issuing State s CSCA certificates in the CSCA Master List. The Master List issuer MAY include CSCA link certificates at the discretion of the issuing State in the CSCA Master List. If new certificates have been received by a CSCA Master List Signer and its validation procedures have been copleted it is RECOMMENDED that a new CSCA Master List is copiled and issued Master List Signer revocation The issuing CSCA handles the Master List Signer as it handles Docuent Signers. Revoked Master List Signers will be published in a CRL, issued by the CSCA. 8 of 15

9 2.2.3 Receiving a CSCA Master List Every Receiving State defines its own policies under which it accepts certificates contained in a countersigned CSCA Master List. Those policies are in general private inforation. 2.3 Publication on the PKD The PKD operates as a central repository for CSCA Master Lists, Docuent Signer Certificates and CRLs. The procedure for publishing a CSCA Master List is as follows: 1. CSCA Master Lists are sent to the write PKD, as part of the usual certificate upload process as defined in the PKD Interface Specification and PKD Procedures Manual. 2. The ICAO PKD office validates the signatures of uploaded CSCA Master Lists as specified in the PKD Procedures Manual. 3. Valid CSCA Master Lists are oved to the read PKD. 2.4 Relying parties Everyone who has the appropriate equipent is able to read the chip contents of the MRTD, but only the parties that are provided with the appropriate public key certificates and certificate revocation lists will be able to verify the authenticity and integrity of the chip contents. CSCA certificates are public inforation and as such are regarded to be available to all interested parties, fro both public and private sector. This also applies for the CSCA Master Lists. To be able to verify a CSCA Master List, a relying party needs to have received the corresponding CSCA certificate of the countersigning State by out of band counications. It MAY use link certificates but it MUST not use self-signed CSCA certificates contained in the CSCA Master List to verify the CSCA Master List itself. It is up to the relying party to define its own policies under which it accepts certificates contained in a countersigned CSCA Master List. 9 of 15

10 3. Technical specifications 3.1 CSCA Master List specification The CSCA Master List is ipleented as a SignedData Type, as specified in [R3], RFC Cryptographic Message Synta - July All CSCA Master Lists MUST be produced in DER forat to preserve the integrity of the signatures within the SignedData Type The processing rules in RFC3852 apply. r o andatory the field MUST be present recoended - the field SHOULD be present do not use the field MUST NOT be populated optional the field MAY be present Value Coents SignedData version Value = v3 digestalgoriths encapcontentinfo econtenttype id-icao-cscamasterlist econtent The encoded contents of an cscamasterlist certificates States MUST include the Master List Signer certificate and SHOULD include the CSCA certificate, which can be used to verify the signature in the signerinfos field. crls signerinfos It is RECOMMENDED that States only provide 1 signerinfo within this field. SignerInfo version The value of this field is dictated by the sid field. See RFC3852 Section 5.3 for rules regarding this field sid subjectkeyidentifier r It is RECOMMENDED that States support this field over issuerandserialnuber. digestalgorith The algorith identifier of the algorith used to produce the hash value over encapsulatedcontent and SignedAttrs. signedattrs Producing States ay wish to include additional attributes for inclusion in the signature, however these do not have to be processed by receiving States ecept to verify the signature value. signedattrs MUST include signing tie (ref. PKCS#9). signaturealgorith The algorith identifier of the algorith used to produce the signature value, and any associated paraeters. signature The result of the signature generation process. unsignedattrs o Producing States ay wish to use this field, but receiving States ay choose to ignore the. 10 of 15

11 3.1.2 ASN.1 specification for the CSCA Master List CscaMasterList { iso-itu-t(2) international-organization(23) icao(136) rtd(1) security(1) asterlist(2)} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- Iports fro RFC 5280 [PROFILE], Appendi A.1 Certificate FROM PKIX1Eplicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) echaniss(5) pki(7) od(0) pki1-eplicit(18) }; -- CSCA Master List CscaMasterListVersion ::= INTEGER {v0(0)} CscaMasterList ::= SEQUENCE { version CscaMasterListVersion, certlist SET OF Certificate } -- Object Identifiers id-icao OBJECT IDENTIFIER ::= { } id-icao-rtd OBJECT IDENTIFIER ::= {id-icao 1} id-icao-rtd-security OBJECT IDENTIFIER ::= {id-icao-rtd 1} id-icao-cscamasterlist OBJECT IDENTIFIER ::= {id-icao-rtd-security 2} id-icao-cscamasterlistsigningkey OBJECT IDENTIFIER ::= {id-icao-rtd-security 3} END Note: Coented lines (below) to be uncoented until the TR is incorporated into id-icao OBJECT IDENTIFIER ::= { } --id-icao-rtd OBJECT IDENTIFIER ::= {id-icao 1} --id-icao-rtd-security OBJECT IDENTIFIER ::= {id-icao-rtd 1} 11 of 15

12 3.2 CSCA Master List signing certificate profile Those States conforing to the specification MUST issue certificates that confor to this profile. All security objects MUST be produced in DER forat to preserve the integrity of the signatures within the. The following profile uses the following terinology for each of the fields in the X.509 certificate: andatory the field MUST be present do not use the field SHOULD NOT be populated o optional the field MAY be present c critical the etension is arked critical, receiving applications MUST be able to process this etension Certificate Body Certificate Coponent Section in RFC 5280 Master List Signer Certificate Coents Certificate TBSCertificate see net part of the table signaturealgorith value inserted here dependent on algorith selected signaturevalue value inserted here dependent on algorith selected TBSCertificate version MUST be v3 serialnuber signature value inserted here MUST atch the OID in signaturealgorith issuer validity Ipleentations MUST specify using UTC tie until 2049 fro then on using GeneralizedTie subject subjectpublickeyinfo issueruniqueid subjectuniqueid etensions see net table on which etensions should be present Etensions Etension nae Section in RFC 5280 Master List Signer Certificate AuthorityKeyIdentifier keyidentifier authoritycertissuer o authoritycertserialnuber o SubjectKeyIdentifier o subjectkeyidentifier Coents If this etension is used this field MUST be supported as a iniu 12 of 15

13 Etension nae Section in RFC 5280 Master List Signer Certificate KeyUsage c digitalsignature nonrepudiation keyencipherent dataencipherent keyagreeent keycertsign crlsign encipheronly decipheronly CertificatePolicies o PolicyInforation policyidentifier policyqualifiers o PolicyMappings SubjectAltNae IssuerAltNae SubjectDirectoryAttributes o Basic Constraints ca PathLenConstraint NaeConstraints PolicyConstraints EtKeyUsage c CRLDistributionPoints distributionpoint reasons crlissuer InhibitAnyPolicy FreshestCRL privateinternetetensions o other private etensions N/A o Coents rfc822nae or dnsnae MUST be used. MUST be ldap, http or https, Participants of the PKD MUST include PKD-URL. If http or https is used, the url MUST point to a ldif. Note 1 - Algoriths: Refer to [R2], ICAO Doc 9303, Machine Readable Travel Docuents for approved algoriths. 13 of 15

14 Anne A Reference docuentation The following docuentation served as reference for this Technical Report: [R1] RFC 2119, S. Bradner, "Key Words for Use in RFCs to Indicate Requireent Levels", BCP 14, RFC 2119, March 1997 [R2] ICAO Doc 9303, Machine Readable Travel Docuents [R3] RFC Cryptographic Message Synta - July 2004 [R4] RFC 5280, D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk,, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008 [R5] ISO/IEC 3166, Codes for the representation of naes of countries and their subdivisions 1997 [R6] ICAO Suppleent to Doc of 15

15 Anne B Abbreviation CA CRL CSCA DER DS IC ICAO LDS MRTD PKI PKD SO D Abbreviations Certification Authority Certificate Revocation List Country Signing Certification Authority Distinguished Encoding Rule Docuent Signer Integrated Circuit International Civil Aviation Organization Logical Data Structure Machine Readable Travel Docuent Public Key Infrastructure Public Key Directory Docuent Security Object 15 of 15