European Federated Validation Service Study. Solution Profile MOA Signature Verification software

Transcription

1 Eurpean Federated Validatin Service Study Slutin Prfile MOA Signature Verificatin sftware

2 This reprt / paper was prepared fr the IDABC prgramme by: Authr s name: Indicated in the slutin prfile belw, under cntact infrmatin Crdinated by: Hans Graux (time.lex), Christian Staffe (Siemens), Eric Meyvis (Siemens) Cntract N. 1, Framewrk cntract ENTR/05/58-SECURITY, Specific cntract N 14 Disclaimer The views expressed in this dcument are purely thse f the writer and may nt, in any circumstances, be interpreted as stating an fficial psitin f the Eurpean Cmmissin. The Eurpean Cmmissin des nt guarantee the accuracy f the infrmatin included in this study, nr des it accept any respnsibility fr any use theref. Reference herein t any specific prducts, specificatins, prcess, r service by trade name, trademark, manufacturer, r therwise, des nt necessarily cnstitute r imply its endrsement, recmmendatin, r favuring by the Eurpean Cmmissin. All care has been taken by the authr t ensure that s/he has btained, where necessary, permissin t use any parts f manuscripts including illustratins, maps, and graphs, n which intellectual prperty rights already exist frm the titular hlder(s) f such rights r frm her/his r their legal representative. This paper can be dwnladed frm the IDABC website: Eurpean Cmmunities, 2009 Reprductin is authrised, except fr cmmercial purpses, prvided the surce is acknwledged. 2

3 Executive summary The Eurpean Federated Validatin Service (EFVS) Study was initiated by IDABC in rder t assess the feasibility f specific measures t ensure the availability f a Eurpean scale federated electrnic signature verificatin functinality. As a first step in the EFVS Study, infrmatin has been cllected n twenty existing slutins that already prvide all r sme f the functinalities assciated with Eurpean signature verificatin functinality, r that culd prvide valuable insights n hw such an EFVS culd be rganised. This has been dne by drafting standardised prfiles f the identified slutins, fcusing specifically n hw each f these slutins (a) determine the validity f signature certificates; (b) verify electrnic signatures created using these certificates; and (c) prvide specific guarantees t their custmers n the utcmes f these prcesses. The present dcument cntains the slutin prfile fr: MOA Signature Verificatin sftware. 3

4 Table f Cntents EXECUTIVE SUMMARY 3 1 DOCUMENTS APPLICABLE DOCUMENTS REFERENCE DOCUMENTS 5 2 GLOSSARY DEFINITIONS ACRONYMS 8 3 SOLUTION PROFILE MOA SIGNATURE VERIFICATION SOFTWARE 9 4

5 1 Dcuments 1.1 Applicable Dcuments [AD1] Framewrk Cntract ENTR/05/58-SECURITY 1.2 Reference Dcuments [RD1] [RD2] [RD3] Prject Management and Quality Plan (EFVS SC14 PMQP) DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL f 13 December 1999 n a Cmmunity framewrk fr electrnic signatures n.pdf Preliminary Study n Mutual Recgnitin f esignatures fr egvernment applicatins 5

6 2 Glssary 2.1 Definitins In the curse f this reprt, a number f key ntins are frequently referred t. T avid any ambiguity, the fllwing definitins apply t these ntins and shuld als be used by the crrespndents. Entity: anyne r anything that is characterised thrugh the measurement f its attributes in an eidm system. This includes natural persns, legal persns and assciatins withut legal persnality; it includes bth natinals and nn-natinals f any given cuntry. eidm system: the rganisatinal and technical infrastructure used fr the definitin, designatin and administratin f identity attributes f entities. This Prfile will nly elabrate n eidm systems that are cnsidered a key part f the natinal eidm strategy. Decentralised slutins (state/regin/prvince/cmmune ) can be included in the scpe f this Prfile if they are cnsidered a key part f the natinal eidm strategy. eidm tken (r tken ): any hardware r sftware r cmbinatin theref that cntains credentials, i.e. infrmatin attesting t the integrity f identity attributes. Examples include smart cards/usb sticks/cell phnes cntaining PKI certificates, Authenticatin 1 : the crrbratin f the claimed identity f an entity and a set f its bserved attributes. (i.e. the ntin is used as a synnym f entity authenticatin ). Authrisatin: the prcess f determining, by evaluatin f applicable permissins, whether an authenticated entity is allwed t have access t a particular resurce. Unique identifiers: an attribute r a set f attributes f an entity which uniquely identifies the entity within a certain cntext. Examples may include natinal numbers, certificate numbers, etc. Official registers: data cllectins held and maintained by public authrities, in which the identity attributes f a clearly defined subset f entities is managed, and t which a particular legal f factual trust is attached (i.e. which are generally assumed t be crrect). This includes Natinal Registers, tax registers, cmpany registers, etc. egvernment applicatin: any interactive public service using electrnic means which is ffered entirely r partially by r n the authrity f a public administratin, fr the mutual 1 Fr the purpses f this Prfile, the ntin f authenticatin is cnsidered t be synnymus with entity authenticatin, as ppsed t data authenticatin. The ntin f identificatin shuld be avided t avid cnfusin. 6

7 benefit f the end user (which may include citizens, legal persns and/r ther administratins) and the public administratin. Any frm f electrnic service (including stand-alne sftware, web applicatins, and prprietary interfaces ffered lcally (e.g. at a lcal ffice cunter using an electrnic device)) can be cnsidered an egvernment applicatin, prvided that a certain degree f interactivity is included. Interactivity requires that a transactin between the parties must be invlved; ne-way cmmunicatin by a public administratin (such as the publicatin f standardised frms n a website) des nt suffice. esignature: data in electrnic frm which are attached t r lgically assciated with ther electrnic data and which serve as a methd f authenticatin with regard t this data. Nte that this als includes nn-pki slutins. Advanced electrnic signature: an electrnic signature which meets the fllwing requirements: (a) it is uniquely linked t the signatry; (b) it is capable f identifying the signatry; (c) it is created using means that the signatry can maintain under his sle cntrl; and (d) it is linked t the data t which it relates in such a manner that any subsequent change f the data is detectable; Again, this definitin may cver nn-pki slutins. Qualified electrnic signature: advanced electrnic signatures which are based n a qualified certificate and which are created by a secure-signature-creatin device, as defined in the esignatures Directive 2. Validatin: the crrbratin f whether an esignature was valid at the time f signing. 2 See 7

8 2.2 Acrnyms A2A... Administratin t Administratin A2B... Administratin t Businesses A2C... Administratin t Citizens CA... Certificatin Authrity CRL... Certificate Revcatin Lists CSP... Certificate Service Prvider eid... Electrnic Identity eidm... Electrnic Identity Management IAM... Identity and Authenticatin Management IDM... Identity Management OCSP... Online Certificate Status Prtcl OTP... One-Time Passwrd PKCS... Public-Key Cryptgraphy Standards PKI... Public Key Infrastructure SA... Supervisin Authrity SOAP... Simple Object Access Prtcl SCVP... Server-based Certificate Validatin Prtcl SSCD... Secure Signature Creatin Device USB... Universal Serial Bus TTP... Trusted Third Party XAdES... XML Advanced Electrnic Signature XML... extensible Markup Language XML-DSIG... XML Digital Signature 8

9 3 Slutin Prfile MOA Signature Verificatin sftware General identificatin infrmatin Name and rganisatin The "Mdule fr Online Applicatin (MOA) Signature Verificatin (German: Signatur-Prüfung), referred t as "MOA-SP" is issued by: Federal Chancellery - Bundeskanzleramt Reference (n-line surce) Federal Chancellery: Prject website (mstly German): Cntact infrmatin Federal Chancellery Bundeskanzleramt Ballhausplatz Vienna Austria Tel.: +43/1/ pst@bka.gv.at Send questins related t this questinnaire t: Herbert.Leitld@egiz.gv.at 9

10 Scpe f the slutin Services ffered (What services des the slutin ffer t a relying party? This shuld include mst ntably the three basic services abve validatin f certificates, verificatin f the signature, and ensuring trustwrthiness and legal liability but may als cver additinal services e.g. semantic services, archiving f dcuments/signatures, maintenance, time stamping, security/reliability metrics fr the security level f the signature and the certificate, Services that are nt currently available but which are planned fr the future may als be indicated. ) MOA-SP is an pen surce framewrk that prvides the means fr signature verificatin including certificate validatin f XML r CMS based signatures. MOA-SP has been launched in 2002 and is part f a mre cmprehensive framewrk cnsisting f multiple mdules fr signature creatin as well as fr identificatin. MOA-SP aims at facilitating autmated prcesses by cmpletely taking ver the signature verificatin tasks. Thus, SOAP webservice and JAVA API interfaces are prvided. Basic Services: The basic service that MOA-SP prvides is Signature Verificatin. The framewrk may be used by API as well as via SOAP web service interface. Currently the fllwing signatures are supprted: XAdES BES based XML-DSig CMS Signatures Apart frm a cryptgraphic verificatin the signature verificatin als invlves the validatin f the underlying certificate chain (cryptgraphic integrity as well as trust including revcatin checking). Existing Additinal services: Apart frm the basic services mentined abve MOA-SP prvides the fllwing additinal services: Examinatin f the signing certificate fr QC statements in rder t determine qualified signatures. Examinatin f the signing certificate fr private extensins cntaining special bject identifiers indicating fficial signatures frm public authrities. Histrical verificatin f signatures (certificates are validated accrding t the signing 10

11 time retrieved frm the signed dcument) Optinal archival f signature revcatin infrmatin. Future additinal services: The fllwing extensins are planned in the medium term: Integratin f Trusted Lists (TSL as defined related t the Service Directive) Applicatin dmain (e.g. sectr r applicatin types) (Is the slutin usable in any sectr r applicatin field (i.e. is it generic in scpe), r is it currently limited t a specific sectr, applicatin r dmain? If it is currently restricted, wuld it be pssible t extend the slutin t ther sectrs, applicatins r dmains? What wuld need t be changed?) Basically the slutin may perate in any sectr r applicatin field as far as the signatures that have t be verified are either XAdES BES XML-DSig- r CMS-based and the underlying certificates are X.509 certificates. Since MOA-SP ffers a SOAP interface the slutin may be used by arbitrary applicatins. Since MOA-SP is pen surce sftware supprt fr signatures ther than the abve mentined may be added anytime. CAs cvered by the slutin (Hw many CAs are presently cvered by the slutin, and which nes? D they include CAs established in multiple cuntries r states?) The default cnfiguratin cmes with Austrian CAs: A-TRUST ( Main Assciatin f Scial Security Institutins (http;// Technically new CAs may be immediately installed, registering specific trust anchrs. The mst cmmn hash/signature algrithms (including RSA and ECDSA based algrithms, SHA-1, SHA- 2 and RIPEMD160, respectively) are supprted. Extensibility f the slutin (Can additinal CAs be integrated int the slutin? If s, are there restrictins? Have such 11

12 extensins been dne in the past yet, r are any extensins currently planned?) Additinal CAs can be quickly registered. The nly restrictin may be impsed by the underlying signature algrithms. But since the mst cmmn algrithms have been implemented n prblems shuld ccur in case f CAs fllwing cmmn standards. Business mdel/cst mdel f the slutin (Hw is the slutin funded? Is it envisaged as a fr-prfit mdel? Wh pays cntributins, and fr what type f services? What prfits (if any) are made with the services prvided by the slutin? Upn request f the crrespndent, any cmmunicated price infrmatin r ther cmmercially sensitive infrmatin will nt be disclsed.) The framewrk is pen surce under the Apache 2.0 licence and may be used free f charge. It is funded by the Federal Chancellery in rder t equip small and medium-sized businesses with a secure and easy tl t handle signature verificatin/creatin slutins. 12

13 Technical apprach Validatin apprach (Des the slutin validate signature certificates, electrnic signatures based n a hash value f the signed dcument(s), r signed dcuments with embedded signatures (attached signatures - envelping r envelped signatures detached signatures)? What is the maturity f the slutin i.e. can it be classified as a knwn technical apprach, such as a trusted list, bridge, r validatin platfrm?) Upn signature verificatin the underlying signing certificate (including each certificate f the cmplete chain up t a trusted rt certificate) is als validated. The service supprts envelping, envelped and detached signatures. MOA-SP can be used by API r by SOAP interface based n HTTP/HTTPS Using the SOAP interface, requests and respnses are defined as XML structures with defined cntent. The user builds up a request (either by using the API r by creating an XML based request) and sends it t MOA-SP. The respnse f MOA-SP has t be evaluated (API) r interpreted (XML based respnse received via SOAP) respectively by the invking applicatin. Requests and respnses cnsist f sme mandatry and sme ptinal elements. The specificatin f the XML structures (request and respnse) may be retrieved frm the pen surce web site (refer t the title page f this questinnaire). With regard t certificates (Hw des the validatin f certificates wrk based n OCSP, CRLs, r bth? What certificate prfiles are supprted by the slutin?) Certificates are being validated in cntext f signature verificatin. Bth appraches OCSP and CRLs are being supprted. Which type revcatin infrmatin service is used depends n the certificate. The preferred rder (in case f certificates with multiple revcatin infrmatin) depends n the cnfiguratin f the verificatin service. The service distinguishes between qualified and nn-qualified certificates/signatures. 13

14 Independent frm the quality f the underlying certificate the service indicates fficial signatures (special signatures frm authrities indicated by a certain private extensin). The verall status f a certificate validatin is either "trusted": if there is a certificate chain frm the signing certificate up t a trusted rt certificate and if each certificate f this chain was valid at the given time. r nt "trusted": if the service was nt able t build a valid certificate chain up t a trusted rt certificate r althugh the service was able t build up a certificate chain up t a trusted rt certificate at least ne f the certificates f the chain was either revked, nhld, the validity perid did nt match the time given r the revcatin status culd nt be determined. With regard t signatures (What signature frmats are supprted by the slutin - PKCS #7, CMS, XML signatures, PDF signatures, XAdES, CAdES, r thers?) MOA-SP supprts CMS and XAdES BES based XML-Signatures. Multi-signatures (Is the slutin capable f validating multiple signatures n a dcument? Des it supprt independent signatures (c-signatures) and/r verall cuntersignatures?) MOA-SP des nt supprt multiple signatures, but can be/is used fr it. The service has t be invked multiple times fr the verificatin f multiple signatures (each time referencing anther signature). Lgging and auditing (Is the use f the slutin lgged, and if s, t what extent? D users f the slutin have the pssibility t perfrm audits r t gain access t independent auditing reprts?) Depending n the cnfigured lg level all steps are being lgged, including parsing f XML based requests and dwnlad f certificate revcatin infrmatin (LDAP), OCSP r CRLs. Auditing depends n the practice f the service prvider perating MOA-SP. Custmers d nt have access t lgs. Restrictins impsed n CAs 14

15 (What technical requirements are impsed n CAs, e.g. with regard t standards, frmats r certificate prfiles that they need t adpt? This includes e.g. the inclusin f certain infrmatin in signature certificates that is necessary in specific sectrs.) MOA-SP exclusively supprts X.509 certificates. CRL distributin pints and authrity infrmatin are taken frm the certificate. QC statements and key usages are evaluated and included in the signature verificatin respnse. Usage f the slutin by relying parties (Hw d relying parties use the slutin? Are there sftware cmpnents which they need t integrate int their wn systems, is it a web service, etc.) MOA-SP prvides the verificatin service either as a SOAP web service r as a Java API. While the API apprach requires a J2SE (minimum versin 1.4.x) and the integratin f the crrespnding Java libraries int the specific applicatin the SOAP interface may be used frm any type f applicatin n any platfrm. The SOAP interface which is naturally based n HTTP can be secured by SSL, allwing the server t authenticate against the clients. Technical flexibility (Given the technical characteristics utlined abve, culd the technical requirements f the slutin be changed t increase its flexibility (e.g. by supprting ther signature standards, validatin methds, certificate prfiles, etc...))? The slutin has been implemented in a very generic and mdular way, s that future enhancements can be easily cnducted. Status f the prject/actual usage f the slutin (What is the status f the prject (e.g. in develpment, prttyped, in prductin, etc.). What is the actual usage f the slutin (e.g. in terms f relying parties adpting the slutin t validate electrnic signatures) and what are the impacts f its use? Hw many transactins, hw many certificates des it handle?) MOA-SP which is fully peratinal is used by a large number f applicatins, many f them in the dmain f e-gvernment, and sme f them in private sectrs. Usually cmpanies r public authrities use their wn instance f MOA-SP t prvide signature verificatin fr the applicatins they are perating. 15

16 16

17 Legal apprach Relatinship with the CAs 3 (What requirements des a CA need t meet befre being able t accede t the slutin? Specifically, which prcesses and prcedures have been freseen t vet CAs? What kind f agreements are put in place with the CAs, and what are the main issues addressed in these agreements?) Since cmpanies and public authrities use MOA-SP fr their wn applicatins and services they usually run their wn instances. That allws them t individually cnfigure trust anchrs and individually include CAs. Therefre the requirements fr CAs are up t the specific cmpany r authrity. Relatinship with the relying parties (Hw des a relying party get the right t use the slutin? What kind f agreements are put in place in relatin with the relying parties, and which services can be ffered t the relying parties via these agreements?) The framewrk is released under the Apache 2.0 licence. Relying parties that want t use the slutin d nt have t meet any agreements in excess t the licence terms. Reliability f the signature certificates (What prcedures des the slutin put in place t determine the reliability f signature certificates? Are certificate plicies checked? Are supervisin/accreditatin schemes cnsidered? Have specific security criteria been defined, and des the slutin supprt multiple levels f reliability? If s, can the slutin distinguish between qualified and nnqualified signature certificates?) Certificate plicies are nt explicitly checked. The slutin is able t determine and distinguish between qualified and nn-qualified signature certificates (by evaluating QC statements). Finally the specific certificate is being evaluated with regard t fficial signatures. Official signatures are based n advanced r qualified certificates cntaining a special bject identifier as a private extensin. Official signatures are used t sign fficial dcuments issued by authrities. 3 Within the EU, the term CA shuld be taken t mean a certificatin service prvider as defined in article 2.11 f the esignatures Directive (Directive 1999/93/EC) and utside the EU, this means a Certificatin Authrity in the technical sense, i.e. an entity issuing signature certificates t third parties. 17

18 Legal value f the signatures (Can the slutin make a statement n the legal value f signatures? If s, what factrs are taken int accunt? If multiple degrees f validity are supprted by the system (i.e. a statement n the reliability f the signature as a whle is prvided), then hw are these reliability levels defined and cmmunicated t the relying party? Can the slutin identify if a signature can be cnsidered a qualified signature (i.e. if it is an advanced electrnic signature based n a qualified certificate created by using a secure signature creatin device, as defined in the esignatures Directive)? Finally, if the certificate plicies cntain restrictins n the use f the signatures (e.g. limitatin t transactins f a certain amunt r exclusin f certain sectrs), then are these restrictins taken int accunt when cmmunicating the legal value f the signature?) As nted abve the slutin is able t distinguish between qualified and nn-qualified certificates. There are tw degrees f validity prvided by the system: trusted and nt trusted. Since certificate plicies are nt explicitly evaluated pssible restrictins are nt taken int accunt. Liability f the slutin prvider (What liability (if any) des the slutin prvider accept with regard t its services? Specifically, if the signatures rely n qualified certificates as defined under the Eurpean esignatures Directive (if this is applicable t the slutin), then hw des the slutin address its liability fr prviding guarantees t the public in relatin t such certificates?) N specific liability rules in excess t the law (e.g. Signature Law r Civil Cde). Quality f service and availability (Des the slutin prvide any guarantees with regard t the quality f its service (i.e. the reliability f the infrmatin it prvides) and its availability t relying parties, ther than already mentined abve?) As nted abve MOA-SP is usually perated by cmpanies r authrities by themselves fr serving their wn applicatins. Any guarantees in terms f quality f service is up t the specific cmpany r authrity. Independence f the slutin (Is the slutin fully unaffiliated (legally unrelated) with all f the CAs that are integrated int the slutin? If nt, then hw is trust created twards the relying party fr affiliated CAs?) 18

19 As mentined abve MOA-SP is usually perated by cmpanies r authrities by themselves. The MOA-SP default cnfiguratin nly invlves the integratin f A-TRUST CA, which can be remved r cmplemented by the perating party if needed. Cmpliance with the prvisins f the esignatures Directive (Des the slutin supprt signatures frm CAs established in cuntries that are nt subjected t the prvisins f the esignatures Directive (Directive1999/93/EC)? If s, hw are they integrated and hw des the slutin address their legal value?) The default cnfiguratin nly invlves Austrian CAs. Which further CAs are t be integrated is up t the perating service prvider. 19

20 Suitability f the slutin at the Eurpean level Assessment f the slutin wner (Des the slutin wner feel that the slutin culd be adapted t perate at the Eurpean level nt applicable if the slutin already functins at the Eurpean level?) The slutin can be easily adapted t perate at the Eurpean level. Issues t be addressed (Which issues des the slutin wner feel wuld still need t be addressed befre the slutin culd be made t perate at the Eurpean level?) Additinal CAs shuld be integrated in rder t perate at the Eurpean level. If XML-DSig signatures ther than XAdES BES based nes are t be verified, these type f signatures has t be integrated. Integratin with ther validatin slutins (Is there any strategy t allw the slutin t interperate with ther validatin slutins, i.e. can the slutin cnnect t ther islands f trust?) The interperatin with ther validatin slutins is cnceivable but currently nt planned. Market Impacts (Hw culd the slutin impact r influence the Eurpean market?) The slutin is aimed at cmpanies and authrities. Since the dcument frmats being supprted (XML-DSig, CMS) are based n cmmn standards a crss-brder peratin is cnceivable. A free f charge signature verificatin slutin fr cmpanies and authrities may be helpful in terms f disseminatin. Any ther cmments? 20

21 (The slutin wner can prvide any ther cmments that (s)he feels were nt adequately cvered elsewhere) N further cmments. 21