CEN CWA 15264-1
WORKSHOP April 2005
AGREEMENT
ICS 35.240.15
English version
Architecture for a European interoperable eID system within a smart card infrastructure
This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement.
The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Management Centre can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.
This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.
This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels
© 2005 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.
Ref. No.:CWA 15264-1:2005 E CWA 15264-1:2005 (E)
Table of Content
Foreword ...... 4 1 Introduction ...... 5 1.1 Scope and objectives ...... 5 1.2 Informative References ...... 5 1.3 Concepts and definitions ...... 6 1.4 Abbreviation ...... 12 2 Contextual Model for IAS interoperability...... 17 2.1 Trust models ...... 17 2.2 Interoperability of IAS between schemes...... 18 3 Conceptual model for IAS interoperability...... 18 3.1 Roles ...... 19 3.2 Processes...... 21 3.3 SCMF and generic trust model ...... 24 3.4 Smart card communities and eService communities...... 24 4 The IAS functional model ...... 25 4.1 The IAS platform function ...... 25 4.2 The platform function ...... 26 4.3 The crypto function...... 26 4.4 The application function...... 26 4.5 The connectivity function...... 26 4.6 The Human Interface function...... 26 5 IAS system architecture ...... 27 5.1 The Smart Card layer ...... 27 5.2 The Infrastructure layer ...... 27 5.2 The eService layer...... 28 5.4 The layer interfaces ...... 28 6 The functional model in the IAS system architecture ...... 29 6.1 The functional model in the Smart Card Layer ...... 30 6.2 The functional model in the User Access Point sub-layer...... 31 6.3 The functional model in the eService Access Point sub-layer ...... 31 6.4 The functional model in the eService Layer...... 31 6.5 The functional model in the PKI service sub-layer...... 32 7 High level description of the primary processes - formal description...... 32 7.1 UC 1.0.: Card activation...... 32 7.2 UC.1.1.: Securing of the terminal-card link ...... 33 7.3 UC.1.2.: Component Authentication ...... 33 7.4 UC.N.3.: Certificate validation ...... 34 7.5 UC.2.0.: Connection to eService ...... 35 2 CWA 15264-1:2005 (E)
7.6 UC.2.1.: Securing of the eService link...... 35 7.7 UC.2.2.: Cardholder authentication by PKI ...... 36 7.8 UC.3.2.: Cardholder authentication by PIN/BioCode...... 36 7.9 UC.3.0.: Interaction with the eService ...... 37 7.10 UC.3.1.: Signing of a data object ...... 37 7.11 UC.4.0.: Closing of the eService Connection...... 38 7.12 UC.5.0.: Card deactivation...... 38 8 IAS interoperability ...... 39 8.1 IAS interoperability scenarios...... 39 8.2 IAS Interoperability architecture...... 39 8.3 IAS interoperability processes...... 45 9 Securing interoperability...... 45 9.1 Introduction...... 45 9.2 Securing the Card-Terminal interface (IOP#1) ...... 45 9.3 Securing the User Access Point - eService Access Point link (IOP#2)...... 46 9.4 Securing the access to PKI services (IOP#3)...... 46 9.5 Securing the eService Access Point - eService link (IOP#4) ...... 46 9.6 Securing the on-card applications – IAS function interface (IOP#5)...... 46 10 Common requirements for IAS interoperability...... 48 10.1 Requirements related to the execution of the primary processes ...... 48 10.2 Requirements on secondary processes ...... 55 Annex A Mandatory field in certificates ...... 59
Table of Figures Figure 1: Towards a smart card infrastructure based on a common eID...... 5 Figure 2: Simple 3-entity Trust model ...... 17 Figure 3: 4-entity Trust model ...... 17 Figure 4: Role modelling ...... 20 Figure 5: eAuthentication primary process high-level use cases...... 22 Figure 6: Generic trust model...... 24 Figure 7: The trust model in the SCMF ...... 24 Figure 8: Interoperability of IAS services...... 24 Figure 9: The functional box model...... 25 Figure 10: Smart card information system architecture...... 27 Figure 11: eAuthentication system architecture ...... 28 Figure 12: The functional model in the IAS system architecture ...... 30 Figure 13: Primary processes model ...... 32 Figure 14: The Card Activation use case (UC 1.0.)...... 32 Figure 15: The Connection to eService use case...... 35 Figure 16: The interaction with the eService use case...... 37 Figure 17: Summary of interoperability scenarios and levels ...... 39 Figure 18: eService IOP...... 40 Figure 19: Card IOP - case 1 ...... 41 Figure 20: Card IOP - case 2 ...... 42 Figure 21: Card IOP - case 3 ...... 42 Figure 22: On-card IOP - case 1...... 43 Figure 23: On-card IOP - case 2...... 43 Figure 24: On-card IOP - case 3...... 44
3 CWA 15264-1:2005 (E)
Foreword
The production of this CWA (CEN Workshop Agreement) was formally accepted at the e-authentication Workshop's kick-off meeting on 2003-09-16.
The document has been developed through the collaboration of a number of contributing partners in WS-e- authentication, representing smart card interests.
This CWA has received the support of representatives of each of these sectors. A list of company experts who have supported the document's contents may be obtained from the CEN/ISSS Secretariat.
This CWA consists of the following parts, under the general title CWA 15264:
• Part 1: Architecture for a European interoperable eID system within a smart card infrastructure
• Part 2: Best Practice Manual for card scheme operators exploiting a multi-application card scheme incorporating interoperable IAS services
• Part 3: User Requirements for a European interoperable eID system within a smart card infrastructure
4 CWA 15264-1:2005 (E)
1 Introduction
1.1 Scope and objectives
This part of the CWA defines the interoperability architecture for the implementation of a smart-card based interoperable public eAuthentication/eID infrastructure across Europe to be primarily used in the eGovernment domain.
The workshop considers smart cards as being Integrated Circuits contact cards, Integrated Circuits contactless cards and combined cards with either 2 or more chips on board or 1 chip with both contact and contactless communication capabilities.
Although the use of SIM cards is not considered explicitly in this document, this does not exclude the use of SIM card based eID, especially when used for authentication and digital signature purposes.
This document models the Interoperability (IOP) problematic from different perspectives in the following order:
• Context, concluding requirements • Concepts o functional ‘view’ o technical architecture for a smart card based eID system using on-line eGovernment applications o dataflows ‘view’ (description independent from technical solutions) o interoperability issues • Specifications / common requirements for interoperability
The CWA eAuthentication intends to support migration from situation 1 (see below) where each eID-card has its own infrastructure and trust services into a situation 2 where card body, microprocessor, smart card infrastructure as well as trust services may be shared between different eService providers.
ePassport eDriving license eLogical access eGov. / eBus. eHealth 1 2 on-card / on-line eSocial security services
CardCard InfrastructureInfrastructure eServiceeService eServiceeService
CardCard InfrastructureInfrastructure eServiceeService eServiceeService
CardCard CardCard InfrastructureInfrastructure eServiceeService CardCard InfrastructureInfrastructure eServiceeService
CardCard InfrastructureInfrastructure eServiceeService eServiceeService
CardCard InfrastructureInfrastructure eServiceeService eServiceeService
Figure 1: Towards a smart card infrastructure based on a common eID The CWA considers the Identification, Authentication and electronic Signature function (IAS) as a generic one to be used for accessing online eGovernment services with smart cards.
Issues regarding the content and internal way of function of an application are out of scope. The CWA does however describe the relevant interface between the generic function and the application.
1.2 Informative References
Open Smart Card Infrastructure for Europe v2, (March 2003) eESC Common Specifications for interoperable multi-application secure smart cards v2.0
5 CWA 15264-1:2005 (E)
ITU-T Recommendation X.811 (1995) Information Technology -Open Systems Interconnection - Security Frameworks For Open Systems: Authentication Framework
ITU-T Recommendation X.813 (1996) Information_Technology- Open Systems Interconnection - Security Frameworks In Open Systems: Non-Repudiation Framework
ISO/IEC 7816 – 4 (FCD 2003) Identification cards – Integrated circuit(s) cards with contacts – Part 4: Organization, security and commands for interchange
ISO/IEC 7816 -15 (2002) Identification cards – Integrated circuit(s) cards with contacts – Part 15: Cryptograpic information application
CEN/ISSS WS/E-Sign CWA 14890 1,2 Group K eEPOCH project, Deliverable D4.2IOP Demonstrator "Safelayer Secure Communications"
NICSS-Framework Scheme, NICSS Prerequisites, First Edition, Version 1.20, April 24, 2001
NIST Special Publication 800-63 (2004) – Draft Recommendation for Electronic Authentication
ISO/IEC JTC 1/SC 37 Standing Document 2, Vocabulary on Biometrics
1.3 Concepts and definitions
Abort To abnormally terminate a process
Acceptor An entity whose primary role is to provide business services/goods to a person using the smart card for accessing e-Services or receiving goods. Also known as Service Provider.
Access Provider An entity in charge of managing the infrastructure (i.e. the card readers, terminals and (AP) necessary drivers, communication network and servers) used by card holders accessing the offered services.
Accessibility Usability of a product, service, environment or facility by people with the widest range of capabilities
In the context of this CWA, "accessibility" typically addresses users who have a disability, but the concept is not limited to disability issues.
Advanced electronic An electronic signature which meets the following requirements signature Chapter 1 It is uniquely linked to the signatory;
Chapter 2 It is capable of identifying the signatory;
Chapter 3 It is created using means that the signatory can maintain under his/her sole control; and
Chapter 4 It is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.
Under certain conditions, an advanced electronic signature may be considered as a qualified digital signature (q.v.)1 according to Directive 1999/93/EC
1 q.v. stands for “Quo vide” - Which see 6 CWA 15264-1:2005 (E)
Application Identifier Data element that is used to uniquely identify an application in a card. It consists of a relative identifier (RID) and a proprietary identifier extension (PIX).
Application Provider Entity that owns or is responsible for a card application offered by a Service Provider. (AP)
Authentication The provision of assurance of the claimed identity of a person. (of a person) The identity is claimed by using a user identifier or a token and the level of verification assurance achieved is determined by validation of one or more of the following elements:
- A PIN or a Password known only by the valid claimant
- A set of biometric data related to the valid claimant
- A private key under the sole control of the valid claimant
- Verification by an appropriate relying party of the validity of the certificate to which the secret key is related.
Authorisation The process by which entitlement of a requester, to access or use a given service, is determined.
Biometric matching The algorithm that compares the biometric reference template with a live biometric template (q.v.), resulting in a determination of match or non-match.
Biometric data Information extracted from a biometric sample and used either to build a biometric reference template on enrolment, or to compare against a previously stored biometric reference template.
Biometric reference A data set which defines a biometric measurement of a person which is used as a basis template for comparison against a subsequently submitted biometric sample(s).
Biometric Template See Live biometric template
Biometric system Automated ICT system capable of
• Capturing a biometric sample from an applicant or from other biometric sources
• Extracting biometric data from that sample,
• Creating biometric template from biometric data,
• Comparing the biometric template with that contained in one or more biometric reference templates,
• Deciding how well they match or do not match,
• Indicating whether or not an authentication of identity or identification has been achieved
• Storing and managing the information dedicated to the biometric applications.
7 CWA 15264-1:2005 (E)
BioCode A set of biometric data used as a mechanisms for local one-to-one verification with the purpose to ascertain whether the card holder is in fact the natural person authorised to access or use a specific service such as the right to unlock certain information on the card.
Card holder A physical person (in the legal sense, i.e. an individual human being not a company/legal structure) who has been issued a smart card by a card issuer.
Card issuance The process by which a card is personalised and ultimately delivered to the card holder. process In the context of this CWA, this process presupposes the manufacture of unpersonalised cards and is more concentrated on their subsequent
Chapter 5 personalisation with
5.1 identification data and possibly biometrics as provided/verified by the registration authority (RA) as well as
5.2 the certificates and key pairs provided by the certification authority (CA)
5.3 the PIN code and, optionally, the biometric verification data
Chapter 6 and finally, delivery to the card holder.
Card Issuer (CI) An entity whose primary responsibility is the management of personal identities and issuance of smart cards containing the appropriate data, certificates and key pairs to the rightful card holders. Its primary task is identity management and it may subcontract or delegate some of the card/certificate issuance tasks as well as the certificate verification tasks2.
Card Scheme An entity comprising a single card issuer, and possibly other partner organizations, responsible for provision of access by registered card holders’ to contractually specified eService(s). Also known as Smart Card Community.
Card Scheme An entity that operationally manages a card scheme in support of the Card Issuer. Also Operator (CSO) known as Smart Card Community Administrator.
Card supplier The person or organisation that manufactures smart cards and provides the card issuer with such smart cards. Card suppliers include chip makers, OS manufacturers, card producers and manufacturers of common software (including libraries).
Certificate The public key of a user, together with some other information rendered unforgeable by encipherment with the private key of the issuing certification authority
Certificate A list of certificates cancelled before their periods of validity have expired. Once placed on Revocation List the certificate revocation list a certificate cannot be re-activated for use. (CRL)
Certification A trusted entity that creates and assigns certificates. Optionally the certification authority Authority (CA) may create the users keys.
Certification Service An entity or a legal or natural person who issues certificates or provides other services
2 It has to be noted that in the current state of the art, the ultimate responsibilities for the tasks of managing identities and issuing cards is to be supported by the same organisation. This may change however in the future. 8 CWA 15264-1:2005 (E)
Provider (CSP) related to electronic signatures such as registration services, certificate generation services, revocation management and revocation status services.
Challenge response A method for checking whether the party an entity is communicating with on a network is a duly authenticated entity. This method is used by a "verifier" as follows:
Chapter 7 Send random numbers to the party to be "verified,"
Chapter 8 Receive same random numbers encrypted with the other party's private key,
Chapter 9 Decrypt them with the other party's public key, and
Chapter 10 Verify result against the original random numbers.
Digital signature Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient. Digital signature is a special case of the more general concept of electronic signature.
Electronic identity Identity data (of a person) usable in an electronic environment. (of a person)
Electronic signature Data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication of that other data. Digital signature is a special case of the more general concept of electronic signature.
End-user access Component of an ICT system which includes a smart card reader such as a terminal point eService Community All natural persons authorised to access and use a specific eService. In the context of this CWA, the community comprises those registered card holders whose IAS functions are recognised by a given Service Provider. eService Communities can be contained within, or span one or more smart card communities. eServices Off line or online electronic services accessible to a person through an ICT system eServices Access Component of an ICT system which acts as a front end system for including Point eServices within a smart card Information system
IAS Set of processes, data and technology agreements required in a given environment to provide Identification, Authentication and electronic Signature services
Icon A graphic image designating an entity, state, action or input control as part of a Graphical User Interface. Also known as a Pictogram.
Identification The process of obtaining information about whom the requester claims to be without considering the “trustability” of this information.
Identification card Card identifying its holder and issuer, which may carry data required as input for the intended use of the card and for transactions based thereon [ISO/IEC 7810].
In the context of this CWA, only identification cards supporting authentication and qualified digital signature are considered.
9 CWA 15264-1:2005 (E)
Identity (of a person) The common sense notion of personal identity. A person’s name, personality, physical body and history, including such personal attributes as address etc, of an individual person.
In the context of this CWA, the concepts of identity, legal identity and electronic identity are used interchangeably.
Inclusivity Ensuring the inclusion of or taking into account the widest range of person types relating to social inclusion, physical or mental disabilities, ethnic and language differences
Interface A standardized technical component facilitating interoperability within and between systems and sub-systems
Interoperability The ability of several independent systems or sub-system components to work together.
In the context of this CWA, the ability of several systems or sub-system components to enable a cardholder to access eServices from different service providers and through different infrastructures.
Legal identity (of a Identity awarded by the relevant administration in a country. person) Since the legal names of persons (family names and given name(s)) are not necessarily unique, the identity of a person must include sufficient additional information (for example a unique identifier) to make the combination unique.
Live and wellness The process of determining if a biometric characteristic is being submitted by a living check person and if this characteristic is authentic and genuine (i.e. originating from the biometric sensor, not derived from a picture, silicon fingerprint copy or other spoofed characteristic).
Matching3 The process of comparing a biometric sample against a previously stored template (i.e. biometric reference template) and scoring the level of similarity. An accept or reject decision is then based upon whether this score exceeds the given threshold.
Match-on-card The situation where the biometric matching is performed in the chip of the card and where the biometric reference template does not leave the chip.
Multi-Application A smart card allowing the Card Issuer to host different applications that can be selected Card independently of each other. Once selected, an application can be run as if the card was mono-application with the data access restrictions imposed by the multi-application OS.
Multi-Application a contractual/legal partnership of different organizations, each possibly playing several Card Scheme roles, as defined by the multi-application scheme model.
Multi-Application a model for the operation of the multi-application scheme usually designed by the Card Card Scheme Model Issuer. It includes the roles to operate the system, the functions provided by each role, and the interfaces linking the different functional blocks of the system.
Multi-Application Any legal entity playing a role in a multi-application scheme. Card Scheme
3 This definition is only applicable in a biometric system context. 10 CWA 15264-1:2005 (E)
Partner
Multi-Application The hardware and software infrastructure which enables the management and operation Card System of the multi-application card scheme. It is made up inter alia of Server Computers, Telecommunication Networks, Terminals accepting cards and the multi-application cards themselves.
Non-repudiation The provision of assurance that a document signer cannot deny having signed it.
On-Line Certificate An on-line protocol (RFC 2560) used to determine the status of a certificate. Status Protocol (OCSP)
Personal A numeric security code used as a mechanism for local one-to-one verification with the Identification purpose to ascertain whether the card holder is in fact the natural person authorised to Number (PIN) access or use a specific service such as the right to unlock certain information on the card.
Pictogram See Icon
Proof of Possession A protocol where a claimant proves to a verifier that he/she possesses and controls a key (PoP) protocol or password.
Qualified certificate Certificate which meets the requirements laid down in annex I of the Directive 1999/93/EC on electronic signature and is provided by a certification-service-provider (CSP) who fulfils the requirements laid down in annex II of the same Directive.
Qualified digital Digital signature which meets the requirements laid down in annex I of the Directive signature 1999/93/EC and is based on a digital certificate provided by a certification-service- provider who fulfils the requirements laid down in annex II of the same Directive.
Registration A trusted entity that establishes and vouches for the identity of a subscriber to a CSP or a authority (RA) CI. The RA may be an integral part of a CSP/CI, or it may be independent of a CSP, but it has a relationship to the CSP(s) and CI.
Registered card Holders of cards issued in accordance with the rules established by a Card Scheme holder
Relying Party An entity which relies upon the data in a certificate, possibly after the verification of their validity, typically to process a transaction or grant access to information or a system. Also known as Verifier or SP
Role A set of predefined functions required to provide a service to either the cardholder or the other stakeholders. A role will consume services from the other roles of the system and combine the consumed services with its own service function in order to offer other services.
Scheme An organised set of operations and procedures in the exchange between stakeholders of a smart card information system.
Security domain A set of elements, a security policy, a security authority and a set of security-relevant activities.
This set of elements is, for specified activities, subject to a security policy administered by the security authority for the security domain]
11 CWA 15264-1:2005 (E)
Security Policy The conditions for trust relationships agreed between the card scheme’s stakeholders.
Security token A physical object that a person possesses and controls and which can be used for authenticating the person. or Token
Service Provider An entity whose primary role is to provide business services/goods to a person using the (SP) smart card for accessing eServices or receiving goods. Also known as Relying Party in a PKI context and Acceptor in the banking one.
Signature A mark uniquely and strongly linked to the bearer’s identity and which, if applied to a contract and subject to certain other criteria specified by the applicable legal system, commits the bearer to its terms.
Smart Card An electronic trusted token compliant to ISO/IEC 7810 and to either ISO/IEC 7816 (for contact cards) or ISO/IEC 14443 (for contactless cards)
Smart Card An entity comprising a single card issuer, and possibly other partner organizations, Community (SCC) responsible for provision of access by registered card holders’ to contractually specified eService(s). Also known as Card Scheme.
Smart Card A technical infrastructure including all components which enable the use of smart cards Information System for accessing eServices through an ICT system.
Smart Card A system constituted of a set of roles and functions fulfilled by entities which enable and Management make use of smart cards within a smart card information system. Framework
Smart Card Reader Component of an ICT system which is capable of electronically reading the content of a contact/contactless smart card.
Smart Card Terminal Component of an ICT system which includes a smart card reader and is capable of interpreting the data read by the reader
Symbol An icon in the context of this CWA
System Integration The degree to which cardholder-facing, internal and partner-facing systems and applications are integrated with each other.
Token A physical object under the sole control of an individual person.
Trusted Third Party A security authority or its agent that is trusted with respect to some security-relevant activities in the context of a security policy
Validation Authority An entity which validates and checks the status of credentials linking a smart card to the (VA) identity of the card holder.
Verifier An entity which relies upon the data in a certificate, possibly after the verification of their validity, typically to process an eService transaction or grant access to information or an ICT system. See also related terms Relying Party and SP 1.4 Abbreviation
AES Advanced Encryption Standard.
AFIS Automated Fingerprint Identification System
12 CWA 15264-1:2005 (E)
ANSI American National Standardization Institute
AI Application Identifier
AP Application Provider
APP On-card Application (or applet)
APDU Application Protocol Data Units
API Application Programming Interface
ATM Automated Teller Machine
BDPP Biometric Device Protection Profile
BSP Biometric Service Provider
CA Certification Authority
CBEFF Common Biometric Exchange File Format
CC Common Criteria
CEN « Comité Européen de Normalisation ». Also known as European Committee for Standardization
CEN/ISSS Comité Européen de Normalisation / Information Society Standardization System
CI Card Issuer
CID Card Identifier
CMOS Complementary Metal Oxide Semiconductor
CMP Certificate Management Protocol
CP Certificate Policy
CPS Certificate Practice Statement
CPU Central Processing Unit
CRL Certificate Revocation List
CS0 Card Scheme Operator
CSP Certificate Service Provider
CUG Closed User Group
13 CWA 15264-1:2005 (E)
CWA CEN Workshop Agreement
DES Data Encryption Standard (with symmetric keys pairs)
DIR Directory
DIS Draft International Standard
DLL Dynamic Link Library
DPI dots per inch
DS Digital Signature
DSA Digital Signature Algorithm
EAL Evaluation Assurance Level
ECDSA Elliptic Curve Digital Signature Algorithm
EC European Commission
ECC Elliptic Curve Cryptography
EEPROM Electrically Erasable Programmable Read-Only Memory e-ID and eID Electronic ID
EMV Europay Mastercard VISA chip card specification
EPROM Erasable Programmable Read Only Memory
ETSI European Telecommunications Standards Institute
HTTP Hypertext Transport Protocol
IAS Identification, Authentication, Electronic Signature
IBIA International Biometric Industry Association
ICAO International Civil Aviation Organization
ICC Integrated Circuit(s) Card
ICT Information and Communication Technology
ID Identity
ID Identification number
IEC International Electrotechnical Commission
14 CWA 15264-1:2005 (E)
IOP Interoperability
IP Internet Protocol
IPSEC IP Security
ISO International Organization for Standardization
ISP Internet Service Provider
ISSS Information Society Standardisation System
ITSO Integrated Transport Smart card Organisation
ITU International Telecommunications Union
LDAP Lightweight Directory Access Protocol
MAMS Multi-Application Management System
MAS Multi-Application System
MAP Mobile Application Part
MCU MicroController Unit
MMI Man-Machine Interface
MOC Match-on-card
MS Member State
MTBF Mean-Time Between Failure
OCR Optical Character Recognition
OCSP Online Certificate Status Protocol
OID Object Identifier
OLTP Online transaction processing
OS Operating System
OSI Open Systems Interconnection
OTBS Object to be signed
PC/SC PC Smart Card Workgroup
PIN Personal Identification Number
15 CWA 15264-1:2005 (E)
PIX Proprietary Identifier eXtension
PKCS Public Key Cryptographic Standard / Public Key Cryptographic System
PKI Public Key Infrastructure
PoP Proof of Possession
PP Protection Profile
QC Qualified Certificate
QCP Qualified Certificate Policy q.v. “quo vide” in Latin; “which see” in English
RA Registration Authority
RFC Request for Comment
RFU Reserved for Future Use
RID Relative IDentifier
ROM Read Only Memory
RSA Encryption standard with asymmetric key pairs, named after Rivest, Shamir, and Adleman
S/MIME Secure Multipurpose Internet Mail Extensions
SAM Secure Application Module
SAML Secure Assertions Markup Language
SCAD Smartcard Accepting Device
SCC Smart Card Community
SHA-1 Secure Hash Algorithm-1
SIM Subscriber Identification Module
SLA Service Level Agreement
SMS Short Message Service
SP Service Provider
SSCD Secure Signature Creation Device
SSL Secure Sockets Layer
16 CWA 15264-1:2005 (E)
TTP Trusted Third Party
UID Unique Identifier
URI Uniform Resource Identifier
URL Uniform Resource Locator
USB Universal Serial Bus
VA Validation Authority
VLA Vulnerability Level Assurance
VPN Virtual Private Network
W3C World Wide Web consortium
2 Contextual Model for IAS interoperability
The contextual model is an informal description of the systems and other relevant background context in which the model is being designed. It represents the “raw material” of the formal modelling process, similar to the “requirements gathering” phase in software engineering methodologies.
Since IAS interoperability is mostly articulated on the concept of trust, this model begins with trust scheme principles from a global perspective, and moves to focus on organised societies.
2.1 Trust models
The framework takes as its base model a 3-entity configuration for trust decisions (Figure 2), within a single security domain (single scheme). It then develops models for interoperability between security domains (schemes), which may be the 4-entity configuration (Figure 3).
In addition, reduced configurations need to be considered – these are where one or more of the on-line links are unavailable at the time that a trust decision is requested.
As defined in the figures below, interoperability of trust – and therefore IAS – is the “corner-stone” of interactions between security domains.
Trusted Third TTP in Society TTP in Society Party #2 #1 Is Referenced Asks for reference
Asks for service
Requester Decider Requester Decider Grants/denies service
Previously established relationship Current transaction
Figure 2: Simple 3-entity Trust model Figure 3: 4-entity Trust model
In the 3-entity Trust model (Figure 2), trust between the requester and decider is achieved by reference to a common third party who as a minimum:
• already trusts the requester • is already trusted by the decider
17 CWA 15264-1:2005 (E)
The third party may also:
• already trust the decider • be already trusted by the requester
The 4-entity Trust model (Figure 3) deals with interactions between 2 different security domains that have developped trust in isolation. This model is based on two trusted third parties who are described as operating in different schemes having their own security domain, with their own rules for creating and managing trust, and that have previously established some relationships e.g. at technical, administrative and legal levels.
2.2 Interoperability of IAS between schemes
As already mentioned here above, IAS stands for Identification, Authentication and electronic Signature and is used here to mean the set of digital electronic processes, data and technology agreements required in an ICT environment to provide an interoperable nucleus of trust services and enable the development of further services using this nucleus.
The scope of the interoperable IAS nucleus covers therefore:
• The creation, provision and maintenance of Identification, Authentication and digital/electronic Signature services using secure smart cards • The registration of real persons and organisations to use and provide services (including issuing them with the necessary tokens, tools and digital data in a secure manner)
For interoperability to be possible between two schemes:
• First the security policies and processes of the two schemes have to be compared. This allows the limits of trust to be established. • Then the different entities participating to the schemes must be identified and their respective role in the Trust model (and more specifically in the IOP framework) must be defined. • Performing the roles is based upon the processes they are supporting for the delivery of common IAS services and establish the trust between them. These processes are classified as primary (i.e. operational), secondary (i.e. supportive) and tertiary (i.e. business), depending from the relationship they have with the core IAS functions. They are defined below under section 3.2. • Finally, the system architecture for IOP IAS services must be built, which includes the different components contributing to the delivery of IAS services to eServices and the IOP interfaces enabling to carry out transactions across scheme boundaries in a manner which allows authentication and signature functions to be trusted according to the requirements.
Some assumptions have been made in the definition of the IAS IOP framework:
• Digital identity, attributes and signatures will be issued to natural persons by trusted organisations, and will be held in certificates which also contain public security keys • An electronic trusted (secure) token will be used to store certificates and support IAS functions • The Trusted token will contribute to the realisation of the required assurance level for Legal recognition. The most usual physical form of the trusted token is a credit-card sized smart card (but the type of electrical interface to the token – contact and/or contactless – is not considered at this stage) • On-line transaction methods must be securely implemented (including being capable of secure operation across insecure networks such as the Internet) • For the European Union, the Electronic Signature Directive 1999/93/EC (E-sign) applies, as well as the European Union Directive 1995/46/EC for personal data privacy.
3 Conceptual model for IAS interoperability
The conceptual model is the first semi-formal description of the system. It is a very high level and abstract description of the system which answers the question “What” (What is the described system supposed to do?).
The conceptual model is described using the following elements:
18 CWA 15264-1:2005 (E)
• Entities: which are conceptual units of the model • Roles: which comprise the rules and processes used both to prepare for and during interactions between entities.
From here on, the CWA restricts its scope to:
• High level (strong) security functions, using asymmetric cryptography and a Public Key Infrastructure (PKI) (although the possibility of other methods is acknowledged), and • eID smart cards issued under the control of a central administration which combines or is the ultimate responsible towards the card holder for several roles i.e. the roles of card issuer, card manufacturer, IAS function issuer (an on-card application), certificate issuer and validation authority for certificates attesting the official identity of real persons (including key pair generation).
In this context, included on the smart card as a minimum are:
• Authentication information for the card; • Identification information (name, etc) for the card holder; • Security objects, such as a PIN and/or biometric authentication information (i.e. BioCode) for the card holder, security keys; and possibly a software to perform IAS services using the card4
3.1 Roles
Preliminary remarks:
• It is important to understand that the model developed here is oriented towards schemes developed in the e-government context, where the primary purpose is to provide e-government related services to the citizen. Some of these services will be government centric (meeting requirements of local and central administrations), and others will be citizen centric (assisting them to access citizen services and information services). Third party services (such as professional services) are also expected to benefit from deployment of smart card schemes based on the model, and the model is also open for additional stakeholders to join. • One organisation (entity) may assume more than one stakeholder role. While this may seem to be an implementation issue which does not impact the roles model, merging of roles has an important consequence of the security policy recommended for adoption by central administrations for e- government schemes. • Some roles may be duplicated. Particularly important here is that it is expected that one application issuer (AI) per scheme will be authorised to issue the IAS service application on the card, but other AIs may provide other on-card applications. • Implementation of roles may be delegated, but those implementers act as agents of the stakeholder entity; the model shows only the stakeholders.
4 On-card software for performing IAS services is not always needed. Depending from the specifications of the card, a card issuer may create appropriate applicative files onto the card and populates them with data. In that context, IAS handles and protects these data for the purpose of a given electronic service. Softwares are only loaded onto the card whenever the nested IAS functions are not enough to execute the required services. 19 CWA 15264-1:2005 (E)
Card Community processes side • Issuing, identification management • Life cycle management (cards, infrastructure) • Business issues
Card Card Scheme Card Issuer Operator Holder
Access Certif. provider Provider
Content provider Service provider E-Community processes side • Daily use / delivery / interaction • Content management •Creative challenges
Figure 4: Role modelling Some of these roles are “content” oriented and others “issuer” oriented.
The basic roles within a Smart Card Management Framework are exercised by the following stakeholders:
• The card holder (e.g. consumer, user) (CH) is a real person (in the legal sense, i.e. an individual human being, not a company or other legal structure) who has been issued with a smart card by a card issuer. The issued smart card is associated with and issued to the specific card holder and to him/her only. This association enables the card to be used by the card holder for IAS purposes and thus to enable him/her to access services provided by service providers. • The card provider role (CP) is to supply smart cards certified to the security profile required to satisfy the security policy of the card issuer, and to make that supply in a secure manner. • The registration authority (RA) registers card holders: i.e. obtains sufficient proof of the identity of the card holder by traditional means. Additional RA functionality (such as attributes of a real person, as required to implement the advanced electronic signature provision of E-sign) may be provided within the SCC, possibly supplied by other RAs. • The card issuer (CI) roles are to manage personal identities and issue smart cards to card holders according to scheme policies and rules, and manage the issued cards throughout their lives (card population life cycle management).Independently from its issuance policy (which is an implementation level issue), the card issuer in the present model has also the responsibility to: o Define and maintain scheme security policies and rules o At least ensure that the card holder has been registered o Physically issue the smart card (personalise with on-card IAS application, generate security objects (i.e. PIN key pairs) install certificates, enable for use) o Securely deliver the smart card and authentication mechanism (PIN or enrolment of biometrics) to the card holder o Operationally manage card security (including authorising application download/activation in the case of multi-application frameworks, monitoring the scheme for security breaches, administrating cards by authorising post-issuance upload and activation of applications, blocking applications and cards, authorising card unlocking) o Operationally manage the scheme’s card population (including maintaining a database of cards and their contents, providing a single point of contact for the card holder, and arranging for card and card content replacement in cases of lost/stolen/faulty cards) • The roles of the certificate service provider (CSP) or the certificate authority (CA) are to: o Issue certificates under the responsibility of the stakeholder who ordered them: IAS certificates related to the card holder (including certificates containing attributes of the card holder) Any other certificates used for the functioning of the smart card information system (the scheme) Any other certificates required by a service provider for the functioning of its business service.
20 CWA 15264-1:2005 (E)
o Create and maintain a Certificate Revocation List or CRL, including creating and managing a repudiation policy in case of lost or stolen cards or misuse of cards o Provide a service to validate certificates (in the present framework, this must be an on-line service). This service may be delegated to a Validation Authority (VA) • The roles of the card application issuer (AI) are to: o Issue on-card applications o Arrange with the card operator (CO) and card issuer (CI) for on-card applications to be registered and for downloads to the card to be authorised o Provide a mechanism for loading applications onto cards (this mechanism will usually be defined by the card issuer) o Manage security of the applications o Maintain (if required) backup accounts for the contents of the application on the cards, unless this is a function of the card management system o Provide recovery services for data when applications on the cards are replaced • The role of the eService provider (SP) within the model is to provide business services to the card holder using the smart card as an IAS token and/or in conjunction with one or more other specific on- card applications. It must register with the card scheme operator and comply with scheme policies and rules. It concludes all the necessary contractual arrangements with the access provider and it also defines who may have access to the provided services and under which conditions. Beyond that, the content of services is outside the scope of this CWA. Card holders may be required to sign up (register) with service providers in order to use their services. The set of card holders signed up for a service is known as an eService community. The service provider may offer services to more than one smart card community (smart card scheme), and therefore an eService community expects to take advantage of the interoperability between smart card schemes in order to provide seamless services. • The role of the card scheme operator (CSO) is to administer, monitor and support the relationships between the card issuer, the access provider(s) and service provider(s) in order to ensure the integrity of the smart card community. This management and operational responsibility are performed in support of the card issuer and may include: o Definition, maintenance and enforcement of internal smart card community interoperability specifications and rules of access (e.g. interoperability between the card issuer and a service provider, rules for using available space on the card for additional applications). o Registration of the different stakeholders in the smart card community and verification of their compliance to the smart card community specifications and rules of access (e.g. certification of the smart card readers towards the security specifications). o Definition, maintenance and enforcement of external interoperability specifications, and organisation of interoperability with other schemes. o Support of card holders (e.g. Help-Desk), access provider(s) and service provider(s) • The access provider (AP) is the entity in charge of managing the infrastructure to be used by the card holder for accessing the offered services and managing card content. The infrastructure includes: o Terminals directly associated with card handling (e.g. card readers and necessary driver software); o Other terminal functions and equipment (e.g. where PCs are used as clients on the network); o Communication networks; and o Server systems (but note that, in the case of servers hosting service provider applications, only interfacing to those applications is included here, as service content is outside the scope of the framework). • The content provider (CP) is the entity in charge of keeping the content of the service provider up-to- date. This will be in accordance with content service requirements and agreements. Note that the content provider does not play any role in IAS interoperability.
3.2 Processes
Performing the roles is based upon the processes required for the delivery of common and trusted IAS services. These processes are classified as primary (i.e. operational), secondary (i.e. supportive) and tertiary (i.e. business), depending on the relationship that they have with the core IAS functions:
• Primary IAS processes are those which enable interactions between the IAS services and the eServices requiring them (see section 3.2.1). • Secondary (supportive) IAS processes are the pre-requisites which create the Trust required to operate the primary processes (see section 3.2.2).
21 CWA 15264-1:2005 (E)
• Tertiary IAS processes are those which are part of the eService delivery to the card holder. They justify the need for primary and secondary processes. Tertiary processes are not detailed in this CWA.
3.2.1 Primary IAS processes
Five different primary processes are needed for an eService to interact with IAS services. They are identified below and further detailed, in a formal manner, in section 7.
1.0. Card activation
2.0. Connection to e-Service
User 3.0. Interaction with e-Service
4.0. Closing of the e-Service Connection
5.0. Card deactivation
Figure 5: eAuthentication primary process high-level use cases • By the card activation process (primary process 1.0), a smart card communicates with a terminal: o A physical connection between the card and the reader, is established, based on the type of card used (e.g. contact/ contactless) o The reader and/or the terminal accept or reject the connected card. o The terminal initiates a secure communication channel with the card. 5 o Based on the security rules in place, this communication might require a one-side or a two-side authentication between the card and the terminal and the establishment of an encrypted communication between them. When PKI is used in this process, some certificate validation is required. • By the connection to an eService process (primary process 2.0), the terminal initiates a communication to the eService. o Based on the security rules in place, this communication might require a one-side or a mutual authentication between the terminal and the eService and the establishment of an encrypted communication between them. When PKI is used in this process, some certificate validation is required. • During the interaction process with an eService (primary process 3.0), the user initiates a session with the IAS services, for identification, authentication or electronic signature services, according to the security policy rules defined by the card issuer and as required by the business rules applicable to the eService he/she want to interact with. o The identification data required for accessing the eService are provided by the user as loaded in the smart card. The file containing personal data is (optionally) PIN/Biometric protected. o If some assurance of the provided identification data is required, the claimed identity of a person is to be authenticated by one or several of the following elements: A PIN or a Password known only by the user A set of biometric data related to the user A private key under the sole control of the user
5 The private key dedicated to the authentication of the card may be used for a device authentication protocol without necessarily requiring the cardholder to type his PIN code. 22 CWA 15264-1:2005 (E)
The verification by the appropriate relying party of the validity of the certificate the secret key is related to. For providing the highest assurance level, the authentication process includes the following steps: 1. Verification of the link between the card and the user through the verification of a PIN code or biometric data 2. Access to the private key and the IAS application on the card, for generating an authentication cryptogram 3. Transmission of this cryptogram and the appropriate user certificate for their verification 4. Successful verification of the validity, origin and non-revocation of the certificate as well as the validity of the cryptogram using the related public key. o If electronic signature is required, the object (data) is to be signed by passing through the following steps: 1. Hash of the object to be signed 2. Verification of the link between the card and the user through the verification of a PIN code or biometric data 3. Access to the private key and the IAS application stored on the card, for generating a signature cryptogram, based on the hashed data 4. Transmission of this cryptogram and the appropriate user certificate for their verification 5. Successful verification of the validity, origin and non-revocation of the certificate as well as the validity of the cryptogram using the related public key. o When a BioCode is in use, the biometric template that has been generated by the terminal and offered to the card is authenticated. This process includes the “live and wellness” of the source from which the biometric template has been derived. o After the successful running of the identification or authentication service, the eService provider verifies the user access rights and grants the appropriate access to the eService (authorisation process) and may take care of logging activities … This is however out of the scope of this CWA. o After the successful running of the signature process, the eService provider will process the signed object as appropriate and may take care of time stamping, notarisation … This is however out of the scope of this CWA. • By the closing process of the eService connection (primary process 4.0), the user or the eService securely terminate the above processes 4.0 and 3.0. o Terminating the session with the IAS services o Closing of the communication between the terminal and the eService • By the card deactivation process (primary process (5.0), the user or the eService securely terminate the communication between the smart-card and the terminal.
3.2.2 Secondary (supportive) IAS processes
The secondary (supportive) IAS processes are the pre-requisites that must be set up between the entities of the schemes in order to establish the Trust required for operating the primary processes.
• Create a Smart Card Community (Registration and internal certification): This process consists in: o Definition and registration of the smart card scheme (smart card community) o Development of security policies and processes o Verification of the compliance and registration of the SCC stakeholders o PKI certification of the relevant stakeholders o Compliancy and certificates issuance for the technical components of the smart card community which are needed for the mutual device authentication as defined in 0 • Issue and maintain / manage cards that consists in: o Cards personalisation o Certificate issuance o Cards initialisation o Card holder enrolment o Life cycles maintenance • Implement an eService (including ex post registering of users wanting access rights to an eService or acquiring an onboard application added on the card –an applet), that consists in: o Test/Accept IAS and eService interface software o Test/Accept eService on-card application (if used) o Download of eService on-card application (if used)
23 CWA 15264-1:2005 (E)
• Managing community and infrastructure (including the internal invoicing to manage the cash flows), that consists in: o Commercial parameters agreements o Agreements on network infrastructure provision with access providers o Capture and log of session data o Execution, acquirement and settlement of transactions o Security management o Scheme infrastructure management o Providing card holder customer services
3.3 SCMF and generic trust model
The SCMF is defined at conceptual level as a set of stakeholders (persons and organisations), each of which have one or more roles. The figures below demonstrate that a Smart Card Management Framework is well suited for implementing the trust model.
Verifies Verifies Trusted Card Issuer Third Party Grants Grants Issues Issues
Is ID/Authentication Token ID Is IAS Smart Card IAS Invocation Invocation Referenced ID Referenced IAS Answer Answer
Asks for service Asks for service Requester Decider Card Holder Service Provider Grants/denies service Grants/denies service
Figure 6: Generic trust model Figure 7: The trust model in the SCMF
3.4 Smart card communities and eService communities
In order to clearly position the needs of IOP, it is important to introduce the concepts of smart card community and eService Community, and position the IOP requirements when these communities must be put in relationship:
• Smart Card Community (SCC): all holders of smart cards issued and managed by a given card issuer • eService Community : all users of smart card enabled eServices supported by a given service provider
In the below drawing, Case 1 represents the situation where each card has access to one single service, Case 2 where cards are accessing service from several providers and finally Case 3 where services are offered to cards from several card issuers.
Card Communities
e-Service Communities
Case 1 Case 2 Case 3
Figure 8: Interoperability of IAS services
24 CWA 15264-1:2005 (E)
IAS IOP is required when eService communities are typically able to span several distinct card communities. This is the case where groups of service providers agree to mutually recognise each others’ cards independently of the card issuers involved. This can be achieved on a “one to one” basis between service providers or by the definition of a common scheme within a specific industry. More detailed IOP scenarios are provided in chapter 8.1
4 The IAS functional model
For complementing all the above concepts, all functions required in an IAS system needs to be modelled for creating an IAS functional model:
• The IAS nucleus (including the Platform function) • The Crypto (or PKI) function • The Application • The Connectivity function • The Human Interface (as this function is subject to Part 3, no further details will be provided in Part 1)
Additional Applications
A
IAS platform D B Platform Crypto/PKI
Human Interface C
Connectivity
Figure 9: The functional box model All thes functions are connected with an interface.
4.1 The IAS platform function
The IAS platform6 function is card holder oriented. It is the nucleus of the whole IAS system and provides three different sub-functions:
• Identification i.e. determining who the card holder claims to be by using the personal data set available on the card, without verifying it. • Authentication i.e. determining if the card holder really is who he/she professes to be by using keys or key pairs to verify the identity of the card holder, and PIN or BioCode to link the card to the real person using the system. • Electronic signature i.e. has the card holder expressed his/her consent for committing to a particular action
In case the IAS functions nested onto the platform are exposed through public libraries, the additional application loaded/installed on a multi-application card can make use of these IAS functions.
It should be highlighted that the device authentication sub-function is not part of the IAS function but on the crypto one (see below).
6 The term “platform” has been preferred to the term “application”, since the latter should be reserved for other loaded applications and is also used for representing the main card usage (for instance eID application) 25 CWA 15264-1:2005 (E)
4.2 The platform function
This function includes the operating system for each component of the system.
The platform will have no direct interoperability interface to its functional environment other than to the IAS platform that is running on this platform and to the connectivity function.
4.3 The crypto function
The crypto function is in charge of the cryptographic aspects, that can be based either symmetric or assymmetric cryptography. When assymetric cryptography (PKI) is concerned, the following sub-functions are part of the crypto function:
• Device authentication, • Key generation and loading or on-card key generation, • Secure storage of security objects (e.g. Key storage, …), • Digital signature generation, • Calling the PKI directories i.e. to check on policies, • Handling the PKI settings, • Verifying certificate validity.
4.4 The application function
This function applies to the eServices applications, that can be defined in two categories:
• The “On-Card” application(s) is the optional software and data which needs to be present on the card to make the related service operational, • The “Off-Card” application(s) is the software and data which resides in the infrastructure (terminal, front and back-office servers) to make the related service operational.
Note: The downloading of a particular additional application onto a card remains subject to authorisation from the card issuer responsible for the smart card concerned.
4.5 The connectivity function
The connectivity function is in charge of interconnecting each component of the system and includes the following sub-functions:
• Connectivity between the User Access Point and the Card • Connectivity between the User Access Point and the eService Access Point • Connectivity between the eService Access Point and the eService • Connectivity between the User Access Point and the PKI certificates validation • Connectivity between eService Access Point and the PKI certificates validation • This function will also implement additional security measures when communications require mutual authentication or encryption
4.6 The Human Interface function
The user interface function is the interface between the User/Card holder and the User Access Point (i.e. the local terminal and its application(s)) as well as the Smart Card.
By default, the Human Interface features are generic and adapted both to the card profile (depending on the card content) and to the user access point profile (hosted service(s)). The resulting human interface will match the card capabilities with the terminal services.
It includes following sub-functions:
26 CWA 15264-1:2005 (E)
• Smart card community settings (language, accessibility options and tools (if any) to ensure access for all), • Individual settings (if any) (profiles, preferences).
This function is described in more detail in Part 3 of this CWA.
5 IAS system architecture
This chapter defines the different components of a smart card based IAS system used to access on-line eServices:
eService Layer
Infrastructure Layer
eService access point PKI
Verification Authority User access point
Card Layer
Figure 10: Smart card information system architecture The card holder wants to use eServices that can be accessed through the access Infrastructure. The eServices require their users to be authenticated before they are authorized to access the services. The authentication of a card holder is based on the electronic identity (eID) data and the IAS platform on his/her smart card. PKI-based certificate services are needed in the authentication process.
5.1 The Smart Card layer
The Smart Card is a token used to carry the cardholder's eID application laying over the IAS platform. The eID contains private key(s) and corresponding certified public key(s) of the Cardholder, or link(s) to it/them. The card contains an encryption library and supports encryption operations needed by the IAS platform. It also contains the identity files and possible biometric templates for cardholder authentication. The card may be a multi-application card containing other applications, too. Those are, however, relevant from the eAuthentication point of view only in the case they also use the IAS services of the card.
5.2 The Infrastructure layer
The Infrastructure layer consists in the following sub-layers:
• A User Access Point, or the local part of the Infrastructure, including o A terminal device that has a card reader or corresponding facility to communicate with the Smart Card as well as a biometric sensor for supporting the BioCode function if in use in the considered SCC, and o Local application(s) controlling the use of the terminal and providing a human to machine interface to the User / Cardholder. • An eService Access Point, or the remote part of the infrastructure, including o A network site through which one or several eServices can be accessed, o All network security (firewalls etc.) components implemented in front of the eService. o An interface where the IAS functions required by the eService, are implemented; it acts thus as an IAS front-end in front of the eService and remove these aspects from the eServices. 27 CWA 15264-1:2005 (E)
• PKI services (Validation Authority) for supporting the eAuthentication and eSignature procedures. o In this architecture, the User Access Point and the eService Access Point are the components that use PKI services through the Infrastructure, mainly to validate and check the revocation status of the certificates. • NB: A Network sub-layer is also part of the infrastructure: o Allowing the terminal of the User Access Point to communicate with the eService Access Point and PKI services, and o Allowing the eService Access Point to communicate with PKI services.
5.2 The eService layer
An eService is any business service that can be accessed electronically through an ICT system.
In this context, eServices that have the need to limit access to them for authenticated users only, or that need digital signature functionality, are relevant.
One or several eServices may share an eService Access Point that takes care of security and access control for the service applications integrating the IAS front-end functionality. The eService Access Point is interpreted here as an Infrastructure component.
5.4 The layer interfaces
eService Layer
IOP #4 IOP #3 Infrastructure Layer
eService access point PKI
IOP #2 Verification Authority
User access point
IOP #1 Card Layer IOP #5 IAS
Figure 11: eAuthentication system architecture Each of the above layers and sub-layers are interconnected through interfaces. There are 5 interfaces and they are called interoperability interfaces (IOP) because they will be the basis for technically implementing IAS interoperability.
5.4.1 Interoperability interfaces #1 (IOP#1)
IOP#1 is the interface between the Smart Card and the access Infrastructure. It is the interface through which the terminal and the local application(s) implementing the User Access Point as well as the biometric sensor (if any) communicate with the Card and its applications, e.g. the IAS platform.
Compliance with the ISO 7816 standard is assumed for the interface.
28 CWA 15264-1:2005 (E)
5.4.2 Interoperability interface #2 (IOP#2)
IOP#2 is the interface between the User Access Point and the eService Access Point, i.e. between the local terminal application(s) and the remote access point to eService(s).
Most typical cases are a TLS/SSL connection through the Internet, or a WTLS connection through the GSM network.
5.4.3 Interoperability interface #3 (IOP#3)
IOP#3 is the interface between an Infrastructure component and a PKI service used to verify the validity of certificates presented as a credential for a user or a system component.
It is assumed that some standard certificate-check mechanisms are used between a service requester and a PKI service provider. These mechanisms are either based on CRLs retrieval / check or on standard on-line protocols like OCSP5.4.4.
5.4.4 Interoperability interface #4 (IOP#4)
IOP#4 is the interface between an eService Access Point and an eService.
If we consider the eService Access Point as an IAS front-end, this interface propagates, if needed by the eService application:
• The identity of the user authenticated by the IAS front-end layer, • When digital signature is used, it propagates the data, once the signature has been verified by the IAS front-end layer.
When the eService access point acts as an HTTP reversed proxy, the protocols implemented are HTTP/HTTPS.
The detailed definition on this interface is out of scope of this document.
5.4.5 Interoperability interface #5 (IOP#5)
IOP#5 is the interface between the IAS platform and another on-card application wanting to use the IAS/eID functionality.
This interface is represented by the libraries exposed by the IAS platform so that other on-card applications can call the IAS generic functions.
Even though it is an internal interface of the Card, it cannot be used without external interaction of the on-card application with some external application associated with it.
6 The functional model in the IAS system architecture
This chapter aims at illustrating how the functional box model is implemented into the IAS system architecture.
29 CWA 15264-1:2005 (E)
eServiceeService ApplicationApplication eService Layer
Platform
Connectivity
IOP #4
Infrastructure Layer eService Access Point
Crypto function IASIAS platformplatform Crypto function
Platform
IOP #3 ApplicationApplication Connectivity PKI Verification Authority
IOP #2 Platform
TerminalTerminal ApplicationApplication User Access Connectivity Point
IAS platform Crypto function
Platform
Connectivity
IOP #1
On-Card ApplicationApplication IOP #5
Crypto function IASIAS platformplatform Crypto function
Platform
Connectivity Smart card Layer
Figure 12: The functional model in the IAS system architecture More specifically, it identifies which required functions are implemented on each layer of the IAS system architecture.
It also positions the IOP interfaces defined in the previous clause.
6.1 The functional model in the Smart Card Layer
The following functions are implemented in the smart card:
• The platform function, i.e. the smart card operating system. • The IAS platform function, i.e. the set of libraries implemented on the card, and providing the IAS sub- functions (as defined in section 4.1). • The crypto function called by the IAS platform function, i.e. the cryptographic libraries and algorithms implemented on the smart card needed to actually process the cryptograms required by the IAS sub- functions. This function can also implement other algorithms used to secure the communication with the user access point (for mutual authentication, communication encryption). In this case the crypto function is called by the platform function. • The connectivity function, i.e. the set of libraries implementing the protocol stack enabling the communication with the card (it basically consists in the APDU interface). • The application function, i.e. the set of on-card applications making use of the IAS functions. 30 CWA 15264-1:2005 (E)
6.2 The functional model in the User Access Point sub-layer
The following functions are implemented in the User Access Point:
• The platform function, i.e. the operating system of the terminal and the middleware components required to run the applications (e.g. a virtual machine). • IAS platform function on the User Access Point is the set of libraries and applications providing the necessary interfaces on the terminal to the IAS functions on the card(e.g. PKCS#11, MS CAPI) • The crypto function, i.e. the cryptographic libraries locally implemented on the terminal, mainly used for securing the communications with the other components of the system architecture i.e. the card, with the eService Access Point or with the PKI service, when mutual authentication or communication encryption is needed between the terminal and these components (based on the security policies). • The connectivity function, i.e. the set of libraries implementing the protocol stacks enabling the communication with the other components of the system architecture (i.e. the card, the eService Access Point or the PKI service). • The application function, i.e. the set of applications running on the terminal and making use of the IAS functions.
6.3 The functional model in the eService Access Point sub-layer
As defined in section 5.2, the eService Access Point plays two major roles:
• It acts as an IAS front-end, implementing the IAS functions on behalf of the eService, and thus removing these functions from the eService applications layer, • It acts as a protocol gateway that supports different protocols depending on the network used to convey the instructions between the user access point and the eService (e.g. Http for Internet, WTLS for GSM network) and translates them into Http to the eService layer.
In this context, the following functions are implemented in the eService Access Point:
• The platform function, i.e. the operating system and the middleware components on which the eService Access Point is running. • The IAS platform function, i.e. the set of libraries which implements the IAS sub-functions on behalf of the eService layer for the purpose of o Receiving the identification data of the card holder willing to access the eService, o Verifying the authentication data (in cooperation with the PKI service) o Verifying the signature data (also in cooperation with the PKI service) and implementation of the storage, audit and notarisation procedures for non-repudiation if needed. • The crypto function called by the IAS platform function, i.e. the cryptographic libraries and algorithms implemented on eService Access Point to actually verify the cryptograms received by the IAS sub- functions.
The crypto function can also cover other algorithms used to secure the communication with the user access point (for mutual authentication, communication encryption). In this case the crypto function is called by the platform function. • The connectivity function, i.e. the set of libraries implementing the different protocol stacks to be supported as a gateway between different User Access Point and the eService. • There is no application function in this sub-layer.
6.4 The functional model in the eService Layer
The following functions are implemented in the eService Layer:
• The platform function, i.e. the operating system and middleware components on which the eService application is running (e.g. Web Application server, …). • The connectivity function, i.e. the set of libraries implementing the protocol stack enabling the communication with the eService Access Point (e.g. Http)
31 CWA 15264-1:2005 (E)
• The application function, i.e. the eService application made available to the card holder by the service provider.
6.5 The functional model in the PKI service sub-layer
The following functions are implemented in the PKI service sub-layer:
• The platform function, i.e. the operating system and middleware components on which the application function is running. • The connectivity function, i.e. the set of libraries implementing the protocol stack supported by the PKI service sub-layer (e.g. OCSP, …) • The application function i.e. the application in charge of the validation of the revocation status of the PKI certificates.
7 High level description of the primary processes - formal description
While the IOP interfaces have been positioned in section 6, their specifications are to be defined on the basis of the primary (operational) processes. These primary processes are described in the following sections in the form of use cases (UCs), the high-level view of which is presented below.
The drawing below models all primary processes. Each of them is further developed in the below sections.
1.1. Securing 1.2. 1.0. Card extends of terminal- includes Component activation includes card link authentication
N.3. Certificate validation 2.2. 2.0. 2.1. Securing Cardholder Connection to includes includes includes of e-Service authentication e-Service link by PKI
includes User 3.0. 3.2. Interaction Cardholder extends 3.1. Signing of includes with data object authentication e-Service by PIN
includes 4.0. Closing of e-Service Connection Legend of the colour scheme eService PKI 5.0. Card Infrastructure deactivation Card
Figure 13: Primary processes model
7.1 UC 1.0.: Card activation
1.1. Securing 1.2. 1.0. Card extends of terminal- includes Component User activation authentication card link includes
N.3. Certificate validation
Figure 14: The Card Activation use case (UC 1.0.) 32 CWA 15264-1:2005 (E)
Beginning state
Either
• The User decides to start to work at her workstation and wants to activate her smart card for possible further use, or • The User Identification use case (UC 2.2.) prompts the user to activate her card.
End state
• The smart card of the User is ready to be used for IAS purposes.
Description
• The User puts the card into the reader of the User Access Point (terminal) or otherwise starts its activation. • The terminal software recognizes the card in the reader and starts to set up a communications link to the card. (E1) • The terminal-card communication link is set up by the terminal software. Depending on the security policy of the User Access Point, the set-up procedure may imply a secure link to be set up (UC 1.1.) (E2). • The User is informed that the card is ready to be used (E3).
Exceptions
• E1: The terminal does not recognize the card, because either the card or the reader is faulty or the type of the card is not supported • E2: The terminal-link set-up fails, because either the card is incompatible with the terminal software or a secure link cannot be set up (the authentication of some component fails) • E3: The User is informed that the activation of the card failed.
7.2 UC.1.1.: Securing of the terminal-card link
Beginning state
• The Card Activation use case (UC.1.0.) has been started, and the User Access Point security policy requires a secure link to be set up between the terminal and the card.
End state
• The terminal-card link has been successfully activated.
Description
• A handshaking protocol is executed between the terminal and the card. It includes the authentication of the card and possibly also the terminal according to CWA 14890 (UC.1.2.) (E1). • A secure connection between the terminal and the card is ready to be used (E2).
Exceptions
• E1: The authentication of one or both of the parties on the terminal-card link fails. • E2: The set-up of secure connection between the terminal and the card fails, which implies that also the card activation (UC.1.0.) fails.
7.3 UC.1.2.: Component Authentication
Beginning state
• The set-up of a secure link (UC.1.1.) between a terminal and a card has been started. 33 CWA 15264-1:2005 (E)
End state
• One (the card) or both (the card and the terminal) of the communicating components, according to the User Access Point security policy, have been successfully authenticated.
Description
• The authenticity of the card is determined by the terminal software according to CWA 14980. This includes the checking of the validity of the card certificate (UC.N.3.) (E1). • The authenticity of the terminal may be determined by the card software too, according to CWA 14980. This includes the checking of the validity of the terminal certificate (UC.N.3.) (E2). • Link encryption keys are exchanged between the card and the terminal according to CWA 14890. • The set-up of a secure connection is concluded (E3).
Exceptions
• E1: The authentication of the card fails. • E2: The authentication of the terminal fails. • E3: No secure connection can be set up between the terminal and the card.
7.4 UC.N.3.: Certificate validation
Beginning state
• A certificate has been presented as a credential of a subject to be authenticated.
End state
• The validity of the certificate has been successfully verified.
Description
• A query of the validity of the certificate is sent to a directory service according to the Certificate-check protocol (E1). • A response indicating the validity of the certificate is received from the directory service (E2, E3). • The validation is concluded (E3).
Exceptions
• E1: There is no connection to the directory service. • E2: No response is received from the directory service. • E3: The response indicates that the certificate is invalid or has been revoked. • E4: The validation of the certificate fails.
34 CWA 15264-1:2005 (E)
7.5 UC.2.0.: Connection to eService
2.1. Securing of the e- includes Service link
2.0. User Connection to N.3. Certificate e-Service includes validation
2.2. includes Cardholder Authentication by PKI 3.2. includes Cardholder Authentication by PIN
Figure 15: The Connection to eService use case Beginning state
• The User decides to begin to use an eService.
End state
• The User can begin interaction with the eService (UC.3.0.).
Description
• The User starts a User Access Point application, typically a web browser with certain URL, to connect to an eService (E1). • A secure link between the User Access Point and the eService Access Point is established (UC.1.1) according to the employed link protocol (E2). • The User is authenticated (UC.2.2) using the eID on the smart card (E3). • The eService Access Point finalizes an application connection between the User Access Point and the eService (out of the scope of this work). The User is now authorized to use certain set of services of the eService on the connection. • A "connected to service "response from the eService is returned to the User, which thus can begin to use the eService (E4).
Exceptions
• E1: The URL is not accessible because of some reason (network or server failure, or wrong URL). • E2: The set-up of secure link fails. • E3: The user authentication fails. • E4: The use cannot begin to use the eService.
7.6 UC.2.1.: Securing of the eService link
Beginning state
• The User has started a Connection to eService use case (UC.2.0.) and there is no secure link between the User Access Point and the eService Access Point.
35 CWA 15264-1:2005 (E)
End state
• A secure (encrypted) link between the User Access Point and the eService Access Point is ready to be used.
Description
• A handshaking protocol between the User Access Point and the eService Access Point is executed. The handshaking concludes in the exchange of symmetric encryption keys that will be used to encrypt the traffic on the connection (E1). • A secure link has been successfully set up (E2).
Exceptions
• E1: The handshaking fails and the link cannot be secured. • E2: The set-up of a secure link failed.
7.7 UC.2.2.: Cardholder authentication by PKI
Beginning state
• A User has made a request to connect to an eService, and a secure connection between the involved User Access Point and eService Access Point exists.
End state
• The user has been successfully authenticated and granted access to the eService.
Description
• The eService Access Point receives the service request and resolves whether user authentication is needed (E1, E2). • The eService Access Point sends to the User a log-in screen (if needed) that asks the User to identify herself. It is assumed that identification with a smart card based eID is one of the offered identification options • The User authenticates herself with her eID on her Smart Card (UC.3.2.). • The User Access Point returns to the eService Access Point the user credentials (certificate containing the eID of the user) picked out from the card (E3). • The eService Access Point validates the certificate (UC.N.3.) (E4). • The User has been successfully authenticated. User identity information and granted access rights are forwarded to the background eService (E5).
Exceptions
• E1: The service request is invalid, an error response is sent to the User. • E2: The requested service is available for anonymous users, which means that the rest of UC14 doesn't need to be executed. • E3: The eService Access Point is informed that the user authentication failed. • E4: The validation of the certificate fails. • E5: The Connection to eService use case (UC02) is informed that user identification failed.
7.8 UC.3.2.: Cardholder authentication by PIN/BioCode
Beginning state
• The use of one or more private key (PIN and/or BioCode) on the smart card of a User (for user authentication or digital signing operation) has been requested by some component of the eAuthentication system.
36 CWA 15264-1:2005 (E)
End state
• The User has successfully been proved to be the possessor of the private key (the eID on the card).
Description
• If the User's card has not yet been activated, the User starts the activation (UC.1.0.). • When the Card is in activated state, the User Access Point requests the User to give her PIN or biometric data (E1). • The user keys in her PIN and/or uses the biometric sensor of the terminal to feed in biometric data. • The user feed is forwarded to the Smart Card that verifies the PIN or the biometric information. • If the validation succeeded, the Card returns the User's eID to the terminal (E2). • The cardholder authentication ends.
Exceptions
• E1: The activation of the card fails, which means that also the cardholder authentication fails. • E2: The verification of the user feed failed, and the terminal is informed of this.
7.9 UC.3.0.: Interaction with the eService
N.3. Certificate includes validation
3.0. Interaction 3.1. Signing of User extends with the a data object e-Service
includes 3.2. Cardholder Authentication by PIN
Figure 16: The interaction with the eService use case Beginning state
• An application connection between an authenticated User and an eService exists.
End state
• The User decides to stop using the eService, or the eService disconnects for some reason.
Description
• The User and the eService communicate on the application connection according to the application protocol. This may include signing of data object(s) (UC.3.1.).
Exceptions
• None
7.10 UC.3.1.: Signing of a data object
Start state
• The eService presents the User on an active application connection a data object to be signed. 37 CWA 15264-1:2005 (E)
End state
• The data object has been successfully signed by the User.
Description
• The data to be signed are captured by the User Access Point (based on the user’s input or data provided by the eService Access Point) • The User Access Point computes the string to be signed (ensuring its randomness) and requests the Smart Card to do a signing operation for the received data object (E1), (E2) • The signing requires that the cardholder authenticate herself (UC.3.2.) (E3). • The User Access Point returns in a PKCS#7 package to the eService Access Point the signed object plus user credentials (certificate containing the eID of the user) picked out from the card (E4). • The eService Access Point validates the certificate (UC.N.3.) (E5). • The signing operation concludes successfully (E6).
Exceptions
• E1: The User Access Point does not support signing operations, the request is rejected. • E2: The Smart Card cannot handle the request for some reason. • E3: The Cardholder Authentication fails. • E4: The eService Access Point rejects the PKCS#7 package as invalid. • E5: The certificate validation fails. • E6: The signing operation fails.
7.11 UC.4.0.: Closing of the eService Connection
Beginning state
• The User or the eService decides to close the application connection.
End state
• The secure link between the User Access Point and the eService Access Point has been disconnected.
Description
• The application connection and the secure link that carries it are disconnected.
Exceptions
• None
7.12 UC.5.0.: Card deactivation
Beginning state
• The User removes her card from the card reader.
End state
• The eID and the IAS services of the card cannot be used before new Card Activation (UC1.0.). Description
• The logical connection between the terminal (User Access Point) application(s) is disconnected.
38 CWA 15264-1:2005 (E)
Exceptions
• None
8 IAS interoperability
8.1 IAS interoperability scenarios
The issue which is dealt with in this clause is how to create interoperability for using an on-us card is a not-on-us environment, should this be for using a not-on-us access point or for accessing not-on-us eServices.
All different eAuthentication interoperability scenarios are listed below, save the trivial all-on-us case, which does not call for interoperability functions. These scenarios can be classified in three interoperability levels, where level 0 presents the most simple, and level 3 the most hard-to-achieve case.
It should be highlighted that the functional model defined in Figure 12 is applicable to all the IOP scenarios defined here below
Infrastructure layer User access eService Card layer point access point eService layer PKI L1: On-us On-us Not-on-us Not-on-us On-us eService IOP L2: On-us Not-on-us On-us On-us On-us Card IOP #1 L2: On-us Not-on-us Not-on-us Not-on-us On-us Card IOP #2 L2: On-us Not-on-us#1 Not-on-us#2 Not-on-us#2 On-us Card IOP #3 L3: On-us On-us Not-on-us + Not-on-us On-us On-Card IOP #1 Applet
L3: On-us Not-on-us Not-on-us + Not-on-us On-us On-Card IOP #2 Applet
L3: On-us Not-on-us#1 Not-on-us#2 + Not-on-us#2 On-us On-Card IOP #3 Applet
Figure 17: Summary of interoperability scenarios and levels
8.2 IAS Interoperability architecture
8.2.1 IOP Level 0 (L0): Closed eID scheme
This is the trivial case of total "on-us" environment, where the eID can be used only for the services of its issuer (provided the issuer is also a Service Provider). The purpose of eAuthentication specifications is to offer a way out of this kind of closed schemes.
8.2.2 IOP Level 1 (L1): eService interoperability
An example of level 1 interoperability would be a Finnish citizen at his/her home in Finland accessing an EU server to make an application for an EU job using a token with his/her Finnish national eID on it to authenticate him- /herself and to sign the application. 39 CWA 15264-1:2005 (E)
certificate
card IAS user e-Service content application / eID access access
on us IOP #2 not on us IOP #3 card IAS user e-Service content application / eID access access
certificate
Figure 18: eService IOP This is the case where a "not-on-us" eService welcomes users with "on-us" eIDs connected to "on-us" User Access Points. In practice this means that the Service Provider trusts not only on the certificates of its own users' eIDs but also on a number of foreign users' eIDs.
Level 1 interoperability can be achieved, if the following conditions are true:
1) A secure communication link can be established between the "on-us" User Access Point and the "not-on- us" eService Access Point, and the "on-us" User Access Point and the "not-on-us" eService Access Point are able to agree on a common user authentication protocol.
2) There is a trust agreement between the "not-on-us" Service Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Service Provider, and the eService Access Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified.
3) A similar trust agreement must be established between the "not-on-us" Service Provider and the “on-us” Access Provider who manages the User Access Point
Based on these conditions, on this level of interoperability it is totally transparent to the welcoming Service Provider how the eID has been implemented at the user, or what kind of local infrastructure the user is employing to access the eService.
From user point of view, the basic limitation of this level of interoperability is that the eID can only be used with "on- us" type infrastructure, i.e. in an environment that supports the type of smart cards (other tokens) that contain the eID.
8.2.3 IOP Level 2 (L2): Card interoperability
This is the case where a smart card containing the eID can be used in foreign, "not-on-us" environments to access eServices. From the user's point of view, the eServices may be either "on-us" or "not-on-us" services, depending on what the access environment allows. The following three cases are possible at this interoperability level.
Case 1: "On-us" service is accessed through a "not-on-us" User Access Point.
An example of level 2 (case 1) interoperability would be a Finnish MEP at her office in Brussels accessing Finnish government eServices using his/her Finnish citizen card to authenticate him-/herself.
40 CWA 15264-1:2005 (E)
certificate
card IAS user e-Service content application / eID access access
on us
not on us IOP #1 IOP #3 IOP #2 card IAS user e-Service content application / eID access access
certificate
Figure 19: Card IOP - case 1 Interoperability can be achieved, if the following conditions are true:
1) A secure communication link can be established between the "not-on-us" User Access Point and the "on- us" eService Access Point, and the "not-on-us" User Access Point and the "on-us" eService Access Point are able to agree on a common user authentication protocol.
2) The smart card and its IAS/eID application are able to communicate with the User Access Point, i.e. the physical, electrical and logical properties of the terminal-card interface (IOP#1) are commonly agreed with the "on-us" card / eID issuer and the providers of the "not-on-us" User Access Point hardware and software.
3) There is a trust agreement between the "not-on-us" Access Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Access Provider, and, if necessary (e.g. when a secure protocol is needed between the card and the User Access Point), the User Access Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified.
Case 2: A "Not-on-us" service is accessed through a "not-on-us" User Access Point.
An example of level 2 (case 2) interoperability would be a Finnish MEP at his/her office in Brussels accessing EU services using his/her Finnish citizen card to authenticate him-/herself.
Interoperability can be achieved, if the following conditions are true:
1) There is a trust agreement between the Service Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Service Provider, and the eService Access Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified.
2) The smart card and the IAS/eID application on it are able to communicate with the User Access Point, i.e. the physical, electrical and logical properties of the terminal-card interface (IOP#1) must be commonly agreed with the "on-us" card / eID issuer and the providers of the User Access Point hardware and software.
3) There is a trust agreement between the "not-on-us" Access Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Access Provider, and, if necessary (e.g. when a secure protocol is needed between the card and the User Access Point), the User Access Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified.
41 CWA 15264-1:2005 (E)
certificate
card IAS user e-Service content application / eID access access
on us
not on us IOP #1 IOP #3 IOP #3 card IAS user e-Service content application / eID access access
certificate
Figure 20: Card IOP - case 2
Case 3: A "not-on-us" service is accessed through an intermediary "not-on-us" User Access Point.
An example of level 2 (case 3) interoperability would be a Finnish MEP at his/her office in Brussels accessing Spanish eServices using his/her Finnish citizen card to authenticate him-/herself.
This case combines the conditions of the 2 above cases.
certificate
card IAS user e-Service content application / eID access access
on us
not on us IOP #1 IOP #3 2 card IAS user e-Service content application / eID access access
IOP #2 IOP #3 not on us 1 user e-Service content access access
Figure 21: Card IOP - case 3 On this level of interoperability, the technology used in the smart card (token) (e.g. Java Card, Multos, native card) is transparent to the rest of the environment.
From user point of view, the only limitation of this level of interoperability is that he/she can load on his/her card only "on-us" applications, i.e. applications that are compatible with his/her type of card (of course if allowed by the issuer of her card).
8.2.4 IOP Level 3 (L3): Card application interoperability
This is the case where a smart card containing the eID can be used to load "not-on-us" applications, i.e. card applications that have not been specifically designed to work on that card. These foreign card applications are also able to use the services of the on-card IAS application (eID). The following three cases of the scenario are possible.
42 CWA 15264-1:2005 (E)
Case 1: A "not-on-us" applet is interacting with a "not-on-us" service through an "on-us" User Access Point.
An example of level 3 (case 1) interoperability would be a Belgian citizen temporarily working in Finland downloading a Finnish library application on his/her Belgian citizen card, and using it during a vacation back in Belgium.
certificate
card IAS user e-Service content application / eID access access
on us IOP #5IOP #1 IOP #2 not on us IOP #3 card IAS user e-Service content application / eID access access
Figure 22: On-card IOP - case 1 Interoperability can be achieved, if the following conditions are true:
1) A secure communication link can be established between the "on-us" User Access Point and the "not-on- us" eService Access Point, and the "on-us" User Access Point and the "not-on-us" eService Access Point are able to agree on a common user authentication protocol.
2) There is a trust agreement between the "not-on-us" Service Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Service Provider, and the eService Access Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified.
3) The "not-on-us" applet on the card is able to communicate with the "on-us" terminal, i.e. the logical properties of the terminal-card interface (IOP#1) must be commonly agreed with the "not-on-us" card application issuer and the providers of the "on-us" User Access Point hardware and software.
4) The "not-on-us" card applet is able to use the on-card service interface of the "on-us" IAS/eID applet.
Case 2: A "not-on-us" applet is interacting with a "not-on-us" service through a "not-on-us" User Access Point.
An example of level 3 (case 2) interoperability would be a Belgian citizen temporarily working in Finland downloading a Finnish library application on his/her Belgian citizen card, and using the Finnish library service from his/her Finnish workplace.
certificate
card IAS user e-Service content application / eID access access
on us IOP #5 not on us IOP #1IOP #3 IOP #3 card IAS user e-Service content application / eID access access
Figure 23: On-card IOP - case 2 43 CWA 15264-1:2005 (E)
Interoperability can be achieved, if the following conditions are true:
1) There is a trust agreement between the "not-on-us" Service Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Service Provider, and the eService Access Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified.
2) The smart card and the IAS/eID application are able to communicate with the terminal of the "not-on-us" Access Provider, i.e. the physical, electrical and logical properties of the terminal-card interface (IOP#1) must be commonly agreed with the "on-us" card / eID issuer and the providers of the User Access Point hardware and software using the smart card.
3) The "not-on-us" card applet is able to use the on-card service interface of the "on-us" IAS/eID applet.
4) There is a trust agreement between the "not-on-us" Access Provider and the issuer of the "on-us" eIDs, the format and the contents of the "on-us" eID certificate are known and acceptable to the Access Provider, and, if necessary (e.g. when a secure protocol is needed between the card and the User Access Point), the "not-on-us" User Point is able to connect to a PKI service where the validity and revocation status of the eID certificate can be verified. This requirement is only necessary, in case a secure messaging protocol is used between the User Access Point and the Smart Card.
Case 3: A "not-on-us#2" applet is interacting with a "not-on-us#2" service through an intermediate "not- on-us#1" User Access Point.
An example of level 3 (case 3) interoperability would be a Belgian citizen working in Finland downloading a Finnish library application on his/her Belgian citizen card, and using the Finnish library service from a Spanish Internet kiosk during his/her vacation.
This case combines the conditions of the two above cases.
certificate
card IAS application / eID
on us IOP #5 not on us IOP #1 IOP #3 1 user e-Service content access access IOP #1 IOP #2 IOP #3 not on us card IAS e-Service 2 content application / eID access
Figure 24: On-card IOP - case 3 This level of interoperability requires that the smart card as a technical environment is so well standardized that a plug-and-play type of use of card applications on it is possible.
At interoperability level 3 the user has no limitations for using his/her card and the eID within it. He/she can access foreign services with his/her card and his/her eID, use the card in foreign environments to access eServices, and download - from technical point of view - freely applications on his/her card.
44 CWA 15264-1:2005 (E)
8.3 IAS interoperability processes
8.3.1 Interoperability of the primary processes
The interoperability of the primary processes will be achieved by implementing the above architecture, model and technical requirements.
One aspect however deserves some attention from the eService Provider: what minimal level of assurance does it require when authentication is required for interacting with an eService it offers.
As mentioned above under clause 0, several authentication mechanisms are possible7. A user may therefore be able to provide with his/her card a particular set of authentication elements when offering services which is the one required for on-us eService providers, but different from a particular not-on-us eService provider.
This is to be dealt with on a case-by-case basis, depending from the minimum level of assurance the eService Provider requires from the authentication process. It has to be noted that the provided level of assurance will also be depending from the interoperability reached at the level of the secondary (supportive) processes.
8.3.2 Interoperability of the secondary processes
When negotiating interoperability between SCCs, both SCCs should not only be technically interoperable, but should also create mutual Trust, e.g. confidence in the reliability of the registration process of the card holder.
For establishing & maintaining trusted interoperability, it is required to
• Create interoperability specifications by, in particular, o Defining outgoing interoperability requests (e.g. certificate validation request for not-on-us card) o Defining incoming interoperability requests (e.g. certificate validation request for on-us cards used in a not-on-us environment) o Defining pass-through service protocol o Implementing request handlers • Establish interoperability agreements by, in particular, o Comparing security policies and processes for compatibility o Creating rules, where required, defining restrictions for interoperable scenarios, and making them available to eService providers o Defining interoperable services and associated commercial contracts o Agreeing and confirming interoperability agreement under the form of a contract o Creating maintenance mechanisms for these interoperability agreements • Install and maintain rules and policies
9 Securing interoperability
9.1 Introduction
The objective of this clause is to define the interoperability requirements related to the security aspects of the different IOP interfaces defined in section 5.4 should they be in use between components belonging to the same SCC or between architecture components from different SCCs.
9.2 Securing the Card-Terminal interface (IOP#1)
Securing this IOP interface can be accomplished based on two mechanisms, according to CWA 14890:
7 The elements possibly used for verifying a claimed identity may be the following: (1) a PIN or a Password known only by the user, (2) a set of biometric data related to the user, (3) a private key under the sole control of the user, (4) the validation by the appropriate relying party of the validity of the certificate the secret key is related to. 45 CWA 15264-1:2005 (E)
• Mutual authentication between the card and the terminal • Secure messaging between the card and the terminal ensuring the integrity and confidentiality of the data exchanged (like the PIN or the biometric template).
Secure messaging requires device authentication for both parties (the terminal & the card). After a successful mutual authentication, symmetric session keys are available on both parties which can be used for the subsequent encryption operations.
This is only possible (and practical) with secure terminal devices.
Securing this interface is recommended in the context of untrusted environments, where the connection between the card and the User Access Point is not considered as trusted. Mitigation measures are required for the situations where this interface is not secured while the environment is untrusted. Such measures may be of legal or contractual nature (e.g. no or limited liability).
Mutual authentication and session key exchange can be operated based on three different schemes:
• Scheme 1: Key transport protocol (based on PKI mutual authentication) • Scheme 2: Device authentication with privacy protection (using Diffie-Hellman key negotiation). This scheme can be viewed as an extension of scheme 1, in the sense that before launching scheme 1, a key negotiation is processed based on Diffied-Hellman. • Scheme 3: Symmetric authentication scheme, requiring a symmetric key infrastructure available
In order to be interoperable:
• The card and the terminal must support and agree on one common scheme to be used • The card must be able to authenticate the terminal, i.e. either it must be able to verify the terminal certificate (for schemes 1 and 2) or it must belong to the same symmetric key infrastructure (for scheme 3). • The terminal must be able to authenticate the card, i.e. either via the PKI service layer (for schemes 1 and 2) or it must belong to the same symmetric key infrastructure (for scheme 3).
There will be situations where the interface between an on-us card and a not-on-us terminal (or vice versa) could not be secured. For solving these cases, the same type of mitigation measures, as mentioned above, will be required to be included in interoperability agreement between two SCCs (see section 8.3.2).
9.3 Securing the User Access Point - eService Access Point link (IOP#2)
A secure communication link is required between the user access point and the eService Access Point.
The implementation of the secure link is dependent on the type of link: TLS/SSL, WTLS, SSH, VPN, …
Mutual authentication of the communication parties (the User and the eService, or the eService Access Point as a proxy of the eService) is required.
9.4 Securing the access to PKI services (IOP#3)
The link to the PKI service verifying the validity and revocation status of a certificate does not need to be secured
The PKI service, however, has to authenticate itself to the requestor
9.5 Securing the eService Access Point - eService link (IOP#4)
No specific security measures have to be applied to this interface
9.6 Securing the on-card applications – IAS function interface (IOP#5)
There must be a "firewall" on the card preventing unauthorized access to the IAS/services by on-card applications/applet. 46 CWA 15264-1:2005 (E)
In the context of Java cards, the objects belonging to an applet are not made available to another applet unless a specific sharing mechanism is involved between the two applets. This mechanism passes through the firewall according to certain rules determined by the Java Card Run Time Environment (JCRE). The firewall is part of the JCRE specification. Each applet handles its own objects/data within a specific context.
47 CWA 15264-1:2005 (E)
10 Common requirements for IAS interoperability
10.1 Requirements related to the execution of the primary processes
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
Overall System The system shall support different security profile PIN handling requirements compliant with ISO/IEC 7816-4 Requirements If BioCode is in use8, the following applies:
- 1:1 verification compliant to ISO/IEC 7816-11 - a Biometric OID in support of multiple biometric technologies must be present and compliant to ISO/IEC FCD 19785-1 (under development) - Fingerprint minutiae data is the recommended technology. Its implementation shall be compliant to ISO/IEC FCD 19794-2 (under development) - Biometric template storage shall be on the card - Biometric matching on the card is recommended - The PIN is offered as a fall back to the BioCode
The system shall be future proof Secure post issuance update of data as well as application downloading may be supported as an option
Multi-vendor is to be supported
The IAS function shall be executed in a secure Support of Auditability (logging) and controllable way
8 See also related remarks under clause 10.2.4
48 CWA 15264-1:2005 (E)
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
Smart Card The execution of the eID and eAuthentication The smart card shall be compliant with minimum capacity and performance function shall be convenient and fast requirements for IAS execution
The system will be based on international standards (ISO/IEC 7810, 7816 , ISO/IEC 14443 , JavaCard/GP (support of native & Java cards), ISO/IEC 7501-3 (ICAO)
The smart card shall be secure CWA 14169 Secure Signature-creation devices "EAL 4+" The eID-card must contain at least two separate keys and certificates, where one The system shall be trustworthy for the card key pair is used for authentication and a second separate key pair only for the holder. creation of ‘qualified electronic signatures’ (non repudiation).
However, a three key pair eID-card (where the third key pair is used exclusively for encipherment and confidentiality) is recommended.
Card holder ID The system shall support a secure and reliable Personal data of the end-user/cardholder cardholder shall be held in an electronic requirements card holder identification function form
When an eID-card also contains a visual identity document on its surface, the visual identity information and the certificate identity information must not be in conflict with each other.
The biometric reference template is a particular type of personal data in itself as it is used as a PIN in charge of protecting other data. It is therefore stored in the card on an encrypted way and read protected. It is also to be prevented from being used for other purposes.
The Personal data set shall contain, as a minimum interoperable data set, the following data:
- personal identification number awarded by the card issuer or another national organisation from the country of the card issuer (optional)
49 CWA 15264-1:2005 (E)
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
- family name(s) - given name(s) - sex - date of birth - place of birth (optional) - nationality (optional)
This personal data set may optionally be protected by a PIN
The Card related data set shall contain as a minimum for interoperability the following data:
- card issuer name/reference - card number - country name, - date of issuance - expiration date
50 CWA 15264-1:2005 (E)
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
Card holder The system shall support a secure and reliable The certificates used and stored in eID-cards shall contain Authentication card holder authentication function requirements - the name of the Certification Authority issuing the certificate and the country in which it is operating, - the name of the certificate holder, - the unique identifier of the certificate holder, - the period of validity of the certificate, - the serial number of the certificate, - information on the certificate policy used, - the purpose of the certificate and other technical information necessary for the use of the certificates.
A signature key for authentication purposes
- shall be present - shall occur only once and shall be protected so it cannot be derived - shall be protected against unauthorized usage by PIN and optionally by Biometrics
Electronic The system shall support a secure and reliable The PKI system elements shall be in compliance with ETSI QCP 101 456 (under Signature card holder electronic signature function for the revision). The main issues being: requirements purpose of legal validity of the positive consent of the card holder and to guarantee non-repudiation - registration procedures in relation to a signed information object. - information content of a certificate - liability of the certificate authority - responsibility for protecting the eID-card and its content - loading of other applications on the card - renewal of an eID-card - prevention of use of eID-card and its certificates - cancellation of an eID-card - requirements for the supporting PKI (i.e. CWA 14171)b
51 CWA 15264-1:2005 (E)
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
- obtaining and protecting the CA certificate - obtaining certificate status information
For the European Union, the PKI elements of the The PKI system elements shall be in compliance with CWA 14 890 parts 1 and 2. system shall be in compliance with the qualified The main issues being electronic signature as per article 5.1 of the EU directive 1999/93/EC on a Community framework - key pair generation on board the card for electronic signatures. - storage of keys on board card - in compliance with ISO/IEC 7816-15 (PKCS 15) and Crypto Objects - signing function will be PIN and/or Bio protected - data to be signed cannot be altered - user must not be prevented from being presented the data to be signed - the format for electronic signatures and their certificates and for certificate status information (this latter issue is not addressed in 14890) shall be interoperable - secure messaging shall be supported (symmetric crypto) - algorithms as in EU WS eSign algorithm document shall be supported9 - public available certificate status verifying function for relying parties
The PKI system elements shall be implemented in the following way:
- a minimum of 2 certificates (one for a non-repudiation signing function; one for all other functions) - the certificates shall be compliant with X.509 V3 and shall hold at least the following elements: - name of the CA - country where the CA is operating - name of the Certificate holder
9 See also ETSI TS 102 176, indicating the algorithms to be used in electronic signatures
52 CWA 15264-1:2005 (E)
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
- unique identifier of Card Holder /Certificate holder - period of validity of the certificate - serial number of the certificate - information on the CA certificate policy, the purpose of the certificate, the liability.
More details are provided below in Annex 1
User Access Point The system shall be trustworthy for the card Easy sensing of visual PIN code input will be prevented requirements holder. It shall be reliable and shall protect card holder data present on the card Mutual device authentication between a card and the card reading infrastructure shall be supported as a minimal requirements
The system shall ensure a secure and trusted The user access point shall be certified for use in the smart card community by / on communication channel between the card and behalf of the card issuer. the user access point Where secure terminals are required, the FINREAD specification will be used for securing communication between chip, keyboards, and display (when using the screen/display and/or the keyboard of different building block(s), the links must be secured before the interaction starts.)
The system shall be easy to use by the card Human interface requirements defined in Part 3 will be taken into account holder and behave consistently across interoperable SCCs Optionally, eURI for configuration of human interface will be supported
Supporting PKI A certificate validation mechanism needs to be It is the responsibility of the Card Issuer to install and maintain a validation requirements supported for the benefit of the Service Providers mechanism, but it might very well choose to outsource this functionality to the supporting CA.
The validation mechanism may issue complete CRLs or delta CRLs at regular
53 CWA 15264-1:2005 (E)
Smart Card Functional requirements Technical/Organisational system solutions eID- system elements
intervals, or it may provide an OCSP service.
In order for the Service Provider to be able to trust and rely on certificates, two aspects have to be considered:
- It must be able to judge the trustworthiness of the certificate issuer, - It must be able to obtain all the information needed for the validation of the certificate and any information based on the certificate, such as an electronic signature.
Guidance for relying parties for the validation of electronic signatures can be found in CWA 14171: “General guidelines for electronic signature verification”.
The CA must provide a secure channel for distributing its CA and Root certificates to relying parties (Service Provider). It should be possible to verify the hash value of the root certificate at a secure web site of the CA. eService Access The eService layer has to remain independent The eService Access Point act as a front end for the eService layer by ensuring the Point requirements from any particular IAS implementation link the different IAS implementations accepted by the Service Provider.
For interacting with the supporting PKI, the eService Access point must
- be able to read and interpret from the certificate all fields identified in “The data content of certificates” in the CWA eAuthentication (see Annex 1) - have secure storage protecting the integrity of the CA/Root certificates that they hold
54 CWA 15264-1:2005 (E)
10.2 Requirements on secondary processes
10.2.1 Organisation issuing eID-cards
As indicated above, under clause 0, it is the role of the Card Issuer to create and exploit the Smart Card Community, setting the objectives and the limits of the SCC, defining the architecture specifications, the terms of references for its relationships with each type of stakeholders (i.e. the Card Holders, eService Providers, Access providers, …), the cost sharing policy, the ownership of the cards and the data, the limits of their usage, the card appliance policy, the user interface policy …
Ultimately, because it is in charge of identity management, the Card Issuer is responsible for the trustability of the SCC towards all the stakeholders.
As stated above, eID-card consists of a smart card provided by the Card Issuer (CI), and containing private keys and certificates issued by a Certificate Authority (CA) on the basis of the card holder data collected or verified by a Registration Authority (RA). Although these roles may be taken care of by different organisations, the Workshop expects that, in the particular case of an eID-card, it will always be a central administration (i.e. central Government) that would take the ultimate responsibility for these different roles.
The liabilities of and between different parties should therefore be defined according to the national legislation of the Member State of the Card Issuer.
10.2.2 Card holder’s registration procedures
The Registration Authority (RA) is responsible for face-to-face identifying the candidate card holder before starting the issuing of the card and certificates.
The RA verifies by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued.
Evidence of the identity shall be checked directly against a physical person and if available against a national population register. The same requirement applies to biometric enrolment.
10.2.3 PIN code policy
Separate PIN code will be used for authentication and electronic signature purpose.
A global PIN code will be provided for data access (e.g. authentication) and another one for electronic signature.
The global PIN will also be used for allowing access to personal data in the SCC where the access to personal data is protected by a PIN code. It will also be used for post issuance downloading of applications (in case this possibility is offered) and may also be used as far as authentication or access to personal data is required by these applications.
The user interface however will ensure that the request for providing PIN code will always be made clear to the card holder.
The card holder will however be offered the possibility to change all PIN codes, under his/her sole responsibility.
55 CWA 15264-1:2005 (E)
10.2.4 Remarks on biometrics
Within the IAS scheme, the functionality of the BioCode is on the same level as the normal PIN: In the absence of managed biometric databases it does not play any role in identifying a person but contributes solely to the Authentication process10
Nevertheless there are some important differences by its nature:
• A PIN can be changed, a BioCode not;11 • A BioCode is not an exact comparison, because the “life” template can differ (to a certain extent) from the reference template and still establish a match; • A biometric characteristic can be spoofed, if the biometric sensor is not able to detect the difference; • A normal PIN can be stored in a safe place (e.g. in a persons memory). A biometric characteristic is being carried openly.
Several security measures have to be implemented in order to maintain the integrity of the BioCode:
• Protection of the reference template: o The matching takes place on the card o The reference template cannot be used for other purposes than for the functionalities supported by the IAS scheme o The reference template cannot be retrieved by third parties without the consent of the card holder o The reference template is encrypted • Protection of the “life” biometric template (and its creation) o The “life” biometric template should only be retrieved from authorized sensors and being transported to the card through a high secure link o The result of the “live and wellness” check will be communicated to the IAS so it can decide whether or not to accept the “life” biometric template as a valid input for the BioCode. • Protection of the biometric matching process o The matching process takes place on the card o The biometric matching application can not operate outside of the card • Interoperability is achieved by: o Using a standard biometric file format (e.g. CBEFF part 1, data element specification) o Using a standardized interface between the biometric sensor and the card (e.g. FCD 19784-1, BioAPI) o The standards mentioned above have not been finalised yet. As soon this will be the case, it has to be assessed if those standards meet the IAS requirements.
10.2.5 Other applications on an eID-card
Upon the request of the card holder, applications or information relating to different purposes of use may be stored in the vacant memory space of the card, if it is allowed by the Card Issuer.
10 The link between the PIN or the BioCode and the identity data of the person concerned is therefore required to be highly secure.
11 Nevertheless, it must be highlighted that biometric data of a certain feature can be refreshed from time to time and that all 10 fingers, and 2 eyes may be enrolled.
56 CWA 15264-1:2005 (E)
Installing additional application or information can be done at issuance time or, if legally allowed by the Card Issuer, after issuance of the card.
Post issuance can be done over an insecure network, with all appropriate security and trustability measures agreed by the Card Issuer, or in a secure environment, under the control of the Card Issuer.
Post issuance downloading and storage of additional applications should be protected by a PIN (and/or biometrics) code. It is recommended to use different, separate PIN codes for different applications.
Placing of additional applications on an eID-card and the termination of the use of the applications should in general be agreed between the card holder and the Service Provider.
10.2.6 Responsibility for protecting the eID-card
Before delivery to the card holder, the eID-card and the PIN codes relating to it shall be stored by the card issuer in accordance with applicable national legislation.
The card holder has to take care of his eID-card in accordance with the Terms of Use stipulated in his/her contract with the card issuer. The card holder should keep his/her eID- card and the PIN codes relating to it so that they are not disclosed to outsiders. The personal PIN codes should not be kept in the same place as the eID-card.
The eID-card has to be protected so that it does not fall into the hands of outsiders, and is not altered or used without permission.
It has to be noted that a BioCode cannot be protected by the cardholder. It is based on some own specific physical characteristics (e.g finger), which he/she carry with him/her openly. In principle these characteristics remain unchanged for life. If the BioCode has been compromised, it has to be unabled.
The security policy of the card issuer should therefore allow a fall back (i.e. PIN or another biometric) but one should realize that the different types of biometric technologies have all different security profiles which make them not inter-exchangeable at forehand both from the card issuer or the service provider viewpoint.
10.2.7 Renewal of an eID-card
The eID-card and the certificates it contains must have a validity period defined by the Card Issuer. It is strongly recommended that the validity period of the card and its certificates are the same.
Renewal of the certificates is accomplished in accordance with national legislation. The certificates in the card will never have their keys changed. If a key is to be revoked, a new card has to be issued.
The eID-card shall be renewed through a proper and secure procedure.
If there are other applications on an eID-card, the card holder is responsible for the transfer of these other applications onto the renewed card.
10.2.8 Prevention of the use of an eID-card and its certificates
Primarily the card holder himself will decide why and when he wants to prevent the use of the card, e.g. if the card is lost, or prior to the termination of its validity.
57 CWA 15264-1:2005 (E)
The use of an eID-card and its certificates has to be prevented upon notification by the card holder to the card issuer.
The certificates on the eID-card have to be entered in the revocation list or other certificate validity check system so that the use of certificates relating to electronic communication and granted by the issuer is prevented.
In any case the reference template should not be able to be derived from the card by the service provider, in order to perform other kind of operations with the biometric information.
In any circumstance, the card holder is to be able to choose not to use the BioCode and prefer a standard PIN. It is up to the service provider whether or not to deliver the requested service.
10.2.9 Cancellation of an eID-card
Cancellation of an eID-card shall result in revocation of all known certificates.
The card itself is not necessarily cancelled.
10.2.10 Liability of the Certificate Authority
The CA has to ensure that the certificates have been created by using the procedures required by regulatory authority (Directive 1999/93/EC on a Community framework for electronic signatures). The applied procedure is to be defined in the certificate policy and presented in its certification practice statement.
The Card Issuer has to ensure that the eID-card has been prepared and personalized according to agreed specifications.
The CA is liable for damage caused to any legal entity or natural person who reasonably relies on the certificate. Liabilities concerning the optional visual identity document on the eID- card shall be set according to the national legislations.
58 CWA 15264-1:2005 (E)
Annex A
Mandatory field in certificates
The below minimum data content for the signature certificate (non repudiation) will ensure interoperability between SCCs.
Mandatory fields in the signature certificate
Field Criticality Type/Value Description Certificate* signatureAlgorithm OID** This field contains the identifier for the algorithmIdentifier (1.2.840.113549.1.1.5) cryptographic algorithm used by the CA to sign the certificate. This field MUST contain the same algorithm identifier as the signature field. signatureValue BIT STRING This field contains a digital signature computed upon the tbsCertificate. The tbsCertificate is used as the input to the signature function. tbsCertificate SEQUENCE TBSCertificate version INTEGER Only version 3 certificates shall be used, integer value is “2”. serialNumber INTEGER All certificates issued by one CA must have a unique serial number. signature OID Contains the algorithm identifier for the algorithm (1.2.840.113549.1.1.5) used by the CA to sign the certificate. issuer Name The issuer field identifies the entity who has signed (RDNSequences) and issued the certificate. RDNSequence consists of attribute type (OID) and value (String). countryName OID (2.5.4.6)*** Country where the CA is operating. Printable String organizationName OID (2.5.4.10) An informative unique name of the issuing UTF8String**** organization. commonName OID (2.5.4.3) An informative unique (inside organization) name of UTF8String the CA. Useful if the CA issues certificates for different purposes (citizens, employees etc.). Validity The field is represented as a sequence of two dates: notBefore YYMMDDhhmmssZ - the date on which the certificate validity period (UTCTime) begins (notBefore) notAfter - the date on which the certificate validity period ends (notAfter). Both notBefore and notAfter may be encoded as UTCTime or GeneralizedTime. CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. subject Name The subject field identifies the entity associated with (RDNSequences) the public key stored in the subject public key field. countryName OID (2.5.4.6) This field specifies a general context in which other PrintableString attributes are to be understood. The country does not necessarily indicate the subject's country of citizenship or country of residence, nor does it have
59 CWA 15264-1:2005 (E)
Field Criticality Type/Value Description to indicate the country of issuance. serialNumber OID (2.5.4.5) The serialNumber field is used to differentiate UTF8String between names where the subject field would otherwise be identical. It may contain a number or code assigned by the CA or an identifier assigned by a government or civil authority. It is the CA's responsibility to ensure that the serialNumber is sufficient to resolve any subject name collisions. Additionally, the subject field SHALL include at least the commonName field and/or the givenName one commonName OID (2.5.4.3) A common name is a (possibly ambiguous) name UTF8String by which an object is commonly known in some limited scope and conforms to the naming conventions or the country or the culture within which it is associated. givenName OID (2.5.4.42) Contains the registered given name of the subject, UTF8String in accordance with the laws under which the CA prepares the certificate. Other attributes may be present in the subject field subjectPublicKeyInfo Contains the public key and identifies the algorithm algorithm OID with which the key is used. subjectPublicKey BIT STRING Extensions: keyUsage C BIT STRING This extension defines the purpose (e.g. (nonRepudiation) authentication) of the key contained in the certificate. certificatePolicies NC BIT STRING This field lists certificate policies, recognized by the policyIdentifier OID issuing CA which applies to the certificate, together policyQualifiers URL with mandary qualifier information containing a URL to the CPS. authorityKeyIdentifier NC BIT STRING This extension contains the Key Identifier of the issuing CA. subjectKeyIdentifier NC BIT STRING This extension contains the Key Identifier, whichprovides a means for identifying certificates containing the particular public key used in an application Additionally, the extensions field SHALL include cRLDistributionPoints extension and/or authorityinfoAccess extension cRLDistributionPoints NC BIT STRING This extension identifies how CRL information is distributionPoint URI obtained. Contains a uniform resource identifier (URI) pointing to the appropriate CRL for this certificate. authorityinfoAccess NC This extension indicates how to access CA accessMethod OID information and services for the issuee of the accessLocation GeneralName certificate in which the extension appears. Information and servicers may include on-line services and CA policy data (the location of CRLs is not specified in this extension; that information is provided by the cRLDistribuionPoints extension). Optionally, the extensions field MAY include qcStatements extension, and it is RECOMMENDED to use it, if applicable to the issuing CA.
60 CWA 15264-1:2005 (E)
Field Criticality Type/Value Description qcStatements NC This field defines an extension for inclusion of statementid OID defined statements related to Qualified Certificates. A typical statement suitable for inclusion in this extension MAY be a statement by the issuer that the certificate is issued as a Qualified Certificate in accordance with a particular legal system.
* For further details about certificate data content read RFC 3280, RFC 3039, ETSI TS 102 280 and ETSI TS 101 862.
** Further information about algorithm identifiers: http://www.alvestrand.no/objectid/1.2.840.113549.1.1.html
*** Further information about X.500 attributes types: http://www.alvestrand.no/objectid/2.5.4.html
**** According to RFC 3280 the UTF8String encoding is the preferred encoding, and all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString.
Mandatory fields in other certificates
The data content of other end user certificates is otherwise the same excluding these exceptions:
• The keyUsage MUST NOT be nonRepudiation • The qcStatements extension MUST NOT be used.
It is also recommended to include the commonName attribute in the subject field, at least in the authentication certificate, because many client implementations presuppose the presence of the commonName attribute value in the subject field and use this value to display the subject's name regardless of present givenName or surname attribute values.
61