Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban a hitelesítésszolgáltatók

Átírás

1 Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban a hitelesítésszolgáltatók által végzett viszontazonosítás protokolljának műszaki specifikációjára december 6.

2 TARTALOMJEGYZÉK 1. Bevezetés A dokumentum célja Alapfogalmak A dokumentum hatóköre Figyelembe vett mértékadó dokumentumok Alkalmazási terület, olvasóközönség A dokumentum felépítése Alkalmazott jelölések A viszontazonosítás folyamata A viszontazonosítási szolgáltatás logikai működése Viszontazonosítás interfész leírása A viszontazonosítás üzeneteinek elektronikus aláírása

3 1. Bevezetés A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló évi CXL. törvény (a továbbiakban Ket.) 160. (2) bekezdése kimondja, hogy ha az ügyfél elektronikus aláírással ellátott kérelmet nyújt be a központi rendszeren keresztül vagy közvetlenül hatósághoz, akkor a hatóság az érintett hitelesítés szolgáltatónál viszontazonosítás jelleggel az aláíró természetes azonosítóit ellenőrizheti. A közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről szóló 194/2005. (IX. 22.) Korm. rendelet 6. (1) bekezdése szerint a közigazgatási hatósági eljárás során az ügyfél csak olyan, legalább fokozott biztonságú elektronikus aláírási tanúsítványt használhat, amelyhez tartozó hitelesítési rendben a hitelesítésszolgáltató vállalja a viszontazonosítási kötelezettség teljesítését. Magáról a viszontazonosításról, amely az ügyfél természetes személyazonosító adatainak ellenőrzésére szolgál, az elektronikus ügyintézés részletes szabályairól szóló 193/2005. (IX. 22.) Korm. rendelet rendelkezik részleteiben az alábbiak szerint: 5. - a regisztráció általános szabályai ügyfélkapu igénybevétele esetén 8. - az azonosítás egyes sajátos módjai ügyfélkapu igénybevétele esetén elektronikus aláírás útján történő azonosítás szabályai a viszontazonosítás módjai a viszontazonosítás elvégzése 1.1 A dokumentum célja Ezt a dokumentumot az Informatikai és Hírközlési Minisztérium (IHM) az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságának, együttműködési képességének és egységes használatának támogatása érdekében teszi közzé Az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról szóló 195/2005. (IX. 22.) Korm. rendelet 3. (1) bekezdésében foglaltak alapján. A viszontazonosítási szolgáltatást az egyes hitelesítésszolgáltatók rendszereiben az azt igénybe vevő szervezetek információs rendszerei (célrendszerek) számára technikailag egységes specifikáció alapján, egységes kommunikációs protokollal célszerű kialakítani, annak érdekében, hogy a célrendszerben a folyamat kezelése független legyen az ügyfél tanúsítványát kibocsátó hitelesítésszolgáltatótól. A jelen dokumentum elsődleges célja tehát a közigazgatási hatósági eljárásokban az ügyfél által használt elektronikus aláírásokhoz kapcsolódó viszontazonosításra ajánlott egységes specifikáció meghatározása. A jogszabályi előírásoknak megfelelően a hitelesítésszolgáltatók felé a viszontazonosítás-kérés akár a központi rendszertől, akár közvetlenül a hatóság célrendszerétől érkezhet. Mindkét esetben a jelen ajánlásban meghatározott módon történik a viszontazonosítás-kérés összeállítása a központi rendszer, illetve az arra jogosult hatóság által; és a viszontazonosítást végző szervezet (hitelesítésszolgáltató) az itt leírt módon ad a jogszabályok által meghatározott tartalmú választ. Az egységesség érdekében a jelen dokumentum célja volt az is, hogy az ajánlott protokoll a Kormányzati Portál Ügyfélkapujához kialakított, és a Kormányzati Informatikai Egyeztető 3

4 Tárcaközi Bizottság (KIETB) 21. számú ajánlásában 1 szereplő viszontazonosítás specifikációjával a lehető legnagyobb mértékben megegyezzen, ezért jelentős részben annak alapján készült. A specifikáció kidolgozása során az érintett hitelesítésszolgáltatók, ill. a Magyar Elektronikus Aláírás Szövetség (MELASZ) bevonása azt a célt szolgálta, hogy a specifikáció a lehető legszélesebb szakmai konszenzust tükrözze. 1.2 Alapfogalmak Jelen dokumentumban használt alapfogalmakat az elektronikus aláírásról szóló évi XXXV. törvény (a továbbiakban Eat.), a Ket., valamint a 193/2005. (IX. 22.) és 194/2005. (IX. 22.) Korm. rendeletek definiálják. A dokumentum felhasználja a 21. számú KIETB ajánlás terminológiáját is, az ott is alkalmazott XML, XSD és SOAP szabványok fogalmi rendszerét, valamint az IHM által a Magyar E-Közigazgatási Interoperabilitási Keretrendszer (MEKIK) alapjainak lerakása céljából lefolytatott projekt 2 (MEKIK projekt) eredményeit. A tanúsítványokra vonatkozóan használt fogalmakat az 1.4 pontban felsorolt szabványok definiálják. 1.3 A dokumentum hatóköre Ez a dokumentum meghatározza a közigazgatási hatósági ügyek elektronikus úton történő intézése során az elektronikus aláíráshoz kapcsolódó viszontazonosítás protokollját. 1.4 Figyelembe vett mértékadó dokumentumok Ez az ajánlás az alábbi nemzetközi mértékadó dokumentumokon alapul: Extensible Markup Language (XML) W3C Recommendation [1] W3C XML Schema Specification [2] W3C SOAP Recommendation [3] SOAP Security Extensions: Digital Signature [4] Web Services Security: SOAP Message Security OASIS Standard [5] RFC 3280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile [6] RFC 3739 Internet X.509 Public Key Infrastructure Qualified Certificates Profile [7] ETSI TS X.509 Certificate Profile for Certificates Issued to Natural Persons [8] ETSI TS Qualified Certificate Profile [9] Felhasználjuk továbbá az alábbi hazai dokumentumokat: MEKIK projekt eredményei 21. számú KIETB ajánlás [10] Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható hosszú távú és archív elektronikus aláírás formátumok műszaki specifikációjára [11] Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható elektronikus aláírási szabályzatok készítésére [12]

5 1.5 Alkalmazási terület, olvasóközönség Ez az ajánlás elsősorban a közigazgatási szektor számára készült, mivel a személyes adatok kezelésével járó viszontazonosítás alkalmazására jelenleg az elektronikus hatósági ügyintézés esetén van törvényi felhatalmazás. A viszontazonosítás jogszerű alkalmazása esetén azonban az ajánlást használhatják a közszféra más területein, sőt a magánszférában is. A jogszerűség a mindenkori hatályos jogszabályok rendelkezései alapján dönthető el. Az első fejezet minden (elektronikus aláírás iránt) érdeklődő olvasónak szól, köztük az elektronikus aláírásokat felhasználóknak és a különböző elektronikus szolgáltatások rendszerfejlesztőinek is. A dokumentum további részei (a viszontazonosításra vonatkozó részletes műszaki specifikáció, illetve a magyarázó és szemléltető részek) elsősorban az alábbi szereplők műszaki szakemberei számára készültek: viszontazonosítást használó alkalmazásokat fejlesztők, viszontazonosítást használó alkalmazásokat értékelők és tanúsítók. 1.6 A dokumentum felépítése A dokumentum további része az alábbi szerkezetet követi: A 2. fejezet a viszontazonosítás folyamatát írja le A 3. fejezet a viszontazonosítás szolgáltatás logikai működését írja le. A 4. fejezet a viszontazonosítás interfész leírását tartalmazza. Az 5. fejezet a kérés és válasz elektronikus aláírásának specifikációját tartalmazza. 1.7 Alkalmazott jelölések Az adatstruktúra leírásokban az XML leíró nyelvet alkalmazzuk. 5

6 2. A viszontazonosítás folyamata A 193/2005. (IX. 22.) Korm. rendelet értelmében a közigazgatási hatósági ügyek elektronikus úton történő intézése során az ügyfél előzetes viszontazonosítása szükséges abban az esetben, ha az ügyfél személyes adathoz, illetve adó-, bank-, biztosítási-, vagy értékpapírtitokhoz kíván hozzáférni. A viszontazonosítás során a hatóság az ügyfélről jogszerűen rendelkezésére álló és a viszontazonosítást végző szervezet által az éppen használt tanúsítvány kibocsátásakor ténylegesen rögzített személyazonosító adatok egyezőségét ellenőrzi. A folyamat lépései: 1. Célrendszeri azonosító adat(ok) megadása: Az ügyfél elektronikus aláírásával hitelesített kérelmében megadja a célrendszerben használt törvényben meghatározott egyedi azonosítót, vagy a célrendszerben jogszabály alapján kezelhető, az azonosításához szükséges személyes adatokat. 2. Ügyfél természetes azonosítóinak összeállítása: A célrendszer a megkapott azonosító adat(ok) alapján saját rendszerében előkeresi vagy összeállítja a személy természetes azonosító adatait (viselt név, születési név, anyja neve, születési helye, születési ideje, állampolgársága) vagy ezek egy részhalmazát. 3. Viszontazonosítás kérés: Az összeállított természetes személyazonosító adatok és az aláírásra használt digitális tanúsítvány alapján a célrendszer elküldi kérelmét viszontazonosítás céljából a hitelesítésszolgáltató felé. A viszontazonosítási kérést a hatóság elektronikus aláírással látja el. 4. Kérés fogadása: A hitelesítésszolgáltató fogadja a célrendszer által összeállított kérést viszontazonosítás elvégzésére. Ellenőrzi a kérés elektronikus aláírását és a kérő fél jogosultságát. 5. Ellenőrzés: A meghatározott tolerancia (lásd később) alapján az összehasonlítás elvégzése. 6. Viszontazonosítás válasz: A hitelesítésszolgáltató a viszontazonosítás eredményét IGEN / NEM formájú válasz üzenetben küldi vissza a kezdeményező célrendszer felé. A válasz üzenetet a hitelesítésszolgáltató saját elektronikus aláírásával látja el. Amennyiben nincs szükség viszontazonosításra, a folyamat az 1. pont után véget ér. Az ügyfél viszontazonosítását nemcsak a hatóság önálló célrendszere kérheti, hanem a központi rendszer is. Ennek folyamata teljesen hasonló a fent leírtakhoz, de a célrendszer helyét a központi rendszer veszi fel (a továbbiakban is értelemszerűen a célrendszer felcserélhető a központi rendszerrel). 6

7 Természetesen a viszontazonosítástól függetlenül történik az elektronikusan aláírt dokumentumok kezelése során az aláírás kezdeti és utólagos ellenőrzése, időbélyegzése (a közigazgatásban alkalmazható elektronikus aláírási szabályzatok készítéséről szóló IHM ajánlásnak [12] megfelelően). 3. A viszontazonosítási szolgáltatás logikai működése A viszontazonosítási szolgáltatást a hitelesítésszolgáltató automatikusan hajtja végre. A kérelem az OASIS Web Service Security: SOAP Message Security 1.0 (WS-Security 2004) szabványnak [5] megfelelő formátumú elektronikusan aláírt XML üzenet formájában az arra jogosult célrendszer felől érkezik. A kérelem tartalma a SOAP borítékba ágyazva kerül aláírásra. A kérés fogadása után a hitelesítésszolgáltató: - ellenőrzi a kérő fél jogosultságát, és a kérés elektronikus aláírását, - elvégzi az XML szintaktikai ellenőrzését, - ellenőrzi, hogy az ügyfél tanúsítványához tartozó hitelesítési rend szerepel-e az NHH által a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről szóló 194/2005. (IX. 22.) Korm. rendelet előírásai szerint vezetett nyilvántartásban, - hiba (kérő nem jogosult, nem értelmezhető kérés vagy nem megfelelő hitelesítési rend) esetén visszaküldi a kapott üzenetet, - amennyiben az elektronikus aláírás ellenőrzése sikertelen, az [5] szabványnak megfelelő hibaválaszt küld, - szintaktikailag elfogadható, arra jogosult szakrendszertől érkező, hiteles aláírással rendelkező kérés esetében elvégzi az összehasonlítandó elemek átalakítását a tolerancia szabályoknak megfelelően, elvégzi saját adatbázisában a keresést, összeállítja a választ, ellátja elektronikus aláírásával, és az összeállított SOAP válasz üzenetet küldi vissza a célrendszernek. A hitelesítésszolgáltató IGEN választ ad, ha a megadott természetes személyazonosító adatok és az ellenőrző által kezelt (a tanúsítvány alapján beazonosított) természetes személyazonosító adatok az alkalmazott tolerancia szabályok alapján megegyeznek. Egyéb esetben a hitelesítésszolgáltató NEM választ ad. Eltérés esetén vagy a célrendszerbeli azonosító adatot/adatait adta meg hibásan az ügyfél, vagy a célrendszerbeli nyilvántartás és a hitelesítésszolgáltató nyilvántartása tér el. Ezen esetekben (illetve hiba válasz esetén) a kért szolgáltatás nem vehető igénybe, amennyiben az viszontazonosításhoz kötött. A szolgáltatást kérő célrendszer a viszontazonosítást az alábbi adatok megadásával kérheti: - viselt név (családi név, első utónév, további utónevek) - születési név (családi név, első utónév, további utónevek) - anyja születési neve (családi név, első utónév, további utónevek) - születési helye (születés ország neve, születés település neve) - születési ideje (év, hó, nap) 7

8 - neme (férfi/nő) - állampolgársága (elsődleges állampolgársága) - tanúsítvány adatok A felsorolt adatok közül az alábbiak megadása kötelező: - viselt név vagy születési név (családi név, első utónév) - anyja születési neve (családi név, első utónév) - születési helye (születés település neve) - születési ideje - tanúsítvány adatok A viszontazonosítást kérő célrendszer a viselt név helyett amennyiben az rendelkezésére áll a születési nevet is megadhatja a viszontazonosítás során. Az ellenőrzés algoritmusában az alább felsorolt tolerancia elemeket kell alkalmazni az összehasonlítás előtt a kérésben és a nyilvántartásban lévő adatokra. Nevek (viselt név, születési név, anyja neve) összehasonlításakor: - szóközök és egyéb speciális karakterek kivágása, - nagybetűkké konvertálás, - a doktorjelzők szűrése a családnevekből (dr, dr., Dr, Dr., DR, DR.), - az ékezetes betűk teljes körű helyettesítése ékezetmentes betűpárjaikkal (á-a, ä-a, é-e, í-i, ó-o, ö-o, ő-o, ú-u, ü-u, ű-u, Á-A, Ä-A, É-E, Í-I, Ó-O, Ö-O, Ő-O, Ú-U, Ü-U, Ű-U). A születés településnevének összehasonlításakor: - nagybetűkké konvertálás, - településnevek levágása balról az első szóköznél. Az alkalmazott toleranciaszint így megegyezik az ügyfélkapun keresztül azonosított felhasználók viszontazonosításánál alkalmazott megoldással. 4. Viszontazonosítás interfész leírása Ebben a fejezetben találhatók a szabványos csatlakozási felület XML mintái és séma definíciói, melyek elektronikus változatban az ajánlás részét képezik. A séma definíciók a SOAP üzenet tartalmának felépítését határozzák meg ("Body" elem tartalma). A SOAP üzenet elektronikus aláírását a következő fejezet írja le. Viszontazonosítás példa: <?xml version="1.0" encoding="utf-8"?> <!--Sample XML file generated by XMLSPY v2004 rel. 3 U ( <soap-env:envelope xmlns:soap-env=" xmlns:xsd=" xmlns:ds=" xmlns=" xmlns:hszva=" <soap-env:header/> <soap-env:body soap-env:encodingstyle=" 8

9 <Kerdes> <KerdesFejlec> <Felhasznalo>RendszerAzonosító</Felhasznalo> <UzenetIdopont> T09:30:47-05:00</UzenetIdopont> </KerdesFejlec> <Session> <Property Source="HivatalAzonosító" Name="TranzakcioKod" Value=" "/> </Session> <Form FormID="AlairasViszontazonositas" JogCim="String"> <hszva:termeszetesszemelyazonositok EID="1"> <ViseltNev EID="2" NevKod="0" DrJelzo="0"> <DrCimJelzes>Text</DrCimJelzes> <CsaladiNev EID="3">String</CsaladiNev> <UtoNev1 EID="4">String</UtoNev1> <UtoNev2 EID="5">String</UtoNev2> </ViseltNev> <SzuletesiNev EID="6"> <DrCimJelzes>Text</DrCimJelzes> <CsaladiNev EID="7">String</CsaladiNev> <UtoNev1 EID="8">String</UtoNev1> <UtoNev2 EID="9">String</UtoNev2> </SzuletesiNev> <TermeszetesSzemelyNeme EID="10" KodCsoport="8" KodErtek="1">1</TermeszetesSzemelyNeme> <SzuletesiHely EID="11"> <Orszag>Text</Orszag> <Telepules>Text</Telepules> <TelepulesMagyarNeve>Text</TelepulesMagyarNeve> <KozigazgatasiEgyseg>Text</KozigazgatasiEgyseg> </SzuletesiHely> <SzuletesiIdo EID="12"> <SzuletesDatum>Text</SzuletesDatum> </SzuletesiIdo> <AnyjaNeve EID="13" DrJelzo="0"> <DrCimJelzes>Text</DrCimJelzes> <CsaladiNev EID="14">String</CsaladiNev> <UtoNev1 EID="15">String</UtoNev1> <UtoNev2 EID="16">String</UtoNev2> </AnyjaNeve> </hszva:termeszetesszemelyazonositok> <hszva:x509tanusitvanyazonosito URI="#1111"> <hszva:certdigest> <ds:digestmethod Algorithm=" <ds:digestvalue>r0lgodlhcggsalmaaaqcaemmcztumfqxds8b</ds:digestvalue> </hszva:certdigest> <hszva:issuerserial> <ds:x509issuername>string</ds:x509issuername> <ds:x509serialnumber>0</ds:x509serialnumber> </hszva:issuerserial> </hszva:x509tanusitvanyazonosito> </Form> <Parancs PID="String"> <Rendszer>String</Rendszer> <Szolgaltatas Module="String" FormID="AlairasViszontazonositas" Muvelet="String">String</Szolgaltatas> <Cimke>String</Cimke> </Parancs> </Kerdes> 9

10 </soap-env:body> </soap-env:envelope> Válasz üzenet sikeres viszontazonosítás esetén: <?xml version="1.0" encoding="utf-8"?> <soap-env:envelope xmlns:soap-env=" xmlns:xsd=" xmlns=" xmlns:hszva=" <soap-env:header/> <soap-env:body soap-env:encodingstyle=" <Valasz> <ValaszFejlec> <Felhasznalo>RendszerAzonosító</Felhasznalo> <UzenetIdopont> T09:30:47-05:00</UzenetIdopont> </ValaszFejlec> <Session> <Property Source="HivatalAzonosító" Name="TranzakciosKod" Value=" "/> </Session> <Form> <hszva:azonositott EID="1">1</hszva:Azonositott> </Form> <Parancs PID="String"> <Rendszer>String</Rendszer> <Szolgaltatas Module="String" FormID="String" Muvelet="String">String</Szolgaltatas> <Cimke>String</Cimke> </Parancs> </Valasz> </soap-env:body> </soap-env:envelope> Válasz üzenet sikertelen viszontazonosítás esetén: <?xml version="1.0" encoding="utf-8"?> <soap-env:envelope xmlns:soap-env=" xmlns:xsd=" xmlns=" xmlns:hszva=" <soap-env:header/> <soap-env:body soap-env:encodingstyle=" <Valasz> <ValaszFejlec> <Felhasznalo>RendszerAzonosító</Felhasznalo> <UzenetIdopont> T09:30:47-05:00</UzenetIdopont> </ValaszFejlec> <Session> <Property Source="HivatalAzonosító" Name="TranzakciosKod" Value=" "/> </Session> <Form> <hszva:azonositott EID="1">0</hszva:Azonositott> <HibaLista> <Hiba EIDRef="1" Kod="n">HibaLeírás</Hiba> </HibaLista> </Form> <Parancs PID="String"> 10

11 <Rendszer>String</Rendszer> <Szolgaltatas Module="String" FormID="String" Muvelet="String">String</Szolgaltatas> <Cimke>String</Cimke> </Parancs> </Valasz> </soap-env:body> </soap-env:envelope> Az alkalmazott XML struktúra leírása részletesen az alábbi hierarchiájú állományokban található meg: kerdes.xsd valasz.xsd tranzakciotypes.xsd va_kerdes.xsd va_valasz.xsd HSZTSZATypes.xsd IOP_ExtTypes.xsd 11

12 A struktúra magas szintű elemeit mutatják be az alábbi ábrák: 12

13 13

14 Elektronikusan aláírt adat viszontazonosításhoz szükséges tanúsítvány információk definíciója: <xs:element name="x509tanusitvanyazonosito" type="hszva:certidtype"/> <xs:complextype name="certidtype"> <xs:sequence> <xs:element name="certdigest" type="hszva:digestalgandvaluetype"/> <xs:element name="issuerserial" type="ds:x509issuerserialtype"/> </xs:sequence> <xs:attribute name="uri" type="xs:anyuri" use="optional"/> </xs:complextype> <xs:complextype name="digestalgandvaluetype"> <xs:sequence> <xs:element ref="ds:digestmethod"/> <xs:element ref="ds:digestvalue"/> </xs:sequence> </xs:complextype> 14

15 Az X509 Tanúsítvány azonosító struktúra XSD dokumentum definíció felépítése a következő: 15

16 Természetes személy IOP szerinti szabványos azonosító adatai: 5. A viszontazonosítás üzeneteinek elektronikus aláírása A viszontazonosítás során küldött kérést és választ elektronikus aláírással kell ellátni. A SOAP üzenetek elektronikus aláírásánál alapvetően két lényeges szabványt, ill. ajánlást kell figyelembe venni: i. Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható hosszú távú és archív elektronikus aláírás formátumok műszaki specifikációjára [11] ii. OASIS Web Service Security: SOAP Message Security 1.0 (WS-Security 2004) [5] 16

17 Jelen fejezetnek nem célja ezen szabványok részletes ismertetése, de taglalja a lényegesebb pontokat, valamint az esetleges pontosításokat, ill. eltéréseket. Az aláírás formátumára, ill. a SOAP (XML) dokumentumban az aláírással kapcsolatos szabályokat az (i) ajánlás tartalmazza. A viszontazonosítás során közlekedő elektronikusan aláírt üzenetnek meg kell felelnie ezen ajánlás előírásainak. (Signature elem, ill. tartalomhivatkozások URI) A (ii) szabvány 8. fejezete foglalkozik részletesen a SOAP üzenetbe helyezett aláírással. A viszontazonosítás során közlekedő elektronikusan aláírt üzenetnek meg kell felelnie ezen szabvány előírásainak, az alábbi pontosításokkal, kivételekkel: 1. A SOAP fejléc Security elemének mustunderstand attribútumát true értékre kell állítani, amikor a 193/2005. (IX. 22.) Korm. rendelet 15. előírásainak megfelelően a viszontazonosítás kérést kötelező aláírni. 2. A SecurityTokenReference elem használata nem megengedett. 3. A fejléc Security elemben definiált gyermek elemek közül csak a UserNameToken és a Signature elem kezelése kötelező. (A többi elem használata opcionális, de nem várható el sem a viszontazonosítás kérőtől sem a hitelesítésszolgáltatótól, hogy értelmezze azokat.) 4. A Signature elem formátumának az (i) ajánlásban foglaltakat kell követni, így kötelező az xmldsig névtér mellett a XAdES névtér használata is. 5. A SOAP Body elemének kötelezően tartalmaznia kell egy Id attribútumot, mely a Signature elem SignedInfo elemében a referencia alapja. 6. Az aláírást a SOAP üzenet Body eleme "fölött" kell végrehajtani. 7. A (ii) szabványban ajánlottól eltérően a SignedInfo referenciában az aláírandó adatra alkalmazandó Transform algoritmus az Exclusive XML Canonicalization ( ) helyett az i. ajánlásban engedélyezett Canonical XML ( transzformáció. További előírások az aláírás kezeléssel kapcsolatban: A viszontazonosítás üzeneteket fokozott biztonságú szervezeti aláíró tanúsítvánnyal kell aláírni. A viszontazonosítási üzenetek aláírására vonatkozó elektronikus aláírási szabályzatot a hitelesítés-szolgáltatónak publikálnia kell. Az aláírási szabályzatnak kötelezően elő kell írnia az időbélyeg használatát. Az aláírási szabályzatban rögzíteni kell, hogy a "kivárási idő" 0 hosszúságú. Az üzenet fogadó oldalán amennyiben az elektronikus aláírás ellenőrzése sikertelen, vagy valamilyen okból nem lehet végrehajtani az aláírás ellenőrzést az üzenetet vissza kell utasítani. (A hibajelzést a (ii) szabvány 12. fejezetének megfelelően kell végrehajtani.) Az aláírás ellenőrzését az (i) ajánlásban megfogalmazott követelményeknek megfelelően kell végezni, azzal a megkötéssel, hogy a kivárási idő 0 hosszúságú. 17

18 (Az alábbi példákban szereplő mezőértékek nem valósak, az olvashatóság érdekében az aláírásban szereplő base64 kódolt mezők jelzésként szerepelnek.) Elektronikusan aláírt viszontazonosítási kérés minta: <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v2004 rel. 3 U ( by aaa (aaa) --> <S11:Envelope xmlns:s11=" xmlns:s12=" xmlns:wsse=" wsswssecuritysecext-1.0.xsd" xmlns:wsu=" xmlns:ds=" xmlns:xades=" xmlns:xsd=" xmlns:iop=" xmlns:hszva=" xmlns=" xmlns:xxx=" <S11:Header> <wsse:security S11:mustUnderstand="true"> <ds:signature Id="Signature0"> <ds:signedinfo Id="SignedInfo0"> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference Id="Reference0" URI="#SignedObject0"> <ds:transforms> <ds:transform Algorithm=" </ds:transforms> <ds:digestvalue>dyab+5mrhi0adf0bbsqvu+fxsb4=</ds:digestvalue> </ds:reference> <ds:reference Id="Reference1" URI="#SignedProperties0" Type=" #SignedProperties"> <ds:transforms> <ds:transform Algorithm=" </ds:transforms> <ds:digestvalue>bmiwca6q06soq396+lbiolz5qui=</ds:digestvalue> </ds:reference> <ds:reference Id="Reference2" URI="#XXXObject0"> <ds:transforms> <ds:transform Algorithm=" </ds:transforms> <ds:digestvalue>li7lgz4n1hfhf07haaal7ha7+kk=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue Id="SignatureValue0"> D/lbynn0uAxIDWU56YtGb11R0MgCFEl7TN2esJZqjQ+ThHfB5ktpIWftPjp70b39M/rL+M1wFLVt 8gFbYMv7aXP5raUayk31BGNwAHJuXsjb+uyqeoWcmOaNN91IbGFoxwyFM3NZkcydT8djEN3yu/yC bbhthw7xo3gshlgxoj8=</ds:signaturevalue> <ds:keyinfo Id="KeyInfo0"> <ds:x509data> <ds:x509issuerserial> <ds:x509issuername>serialnumber=3, CN=E-Group Certification Authority enon- Repudiation CA, OU=PKI Services, O=E-Group Hungary Plc., C=HU</ds:X509IssuerName> <ds:x509serialnumber>61</ds:x509serialnumber> </ds:x509issuerserial> 18

19 <ds:x509certificate>miieetcca2ggawibagibptanbgkqhkig9w0baqufadcbjtelmakga1ue</ds:x509certif icate> </ds:x509data> </ds:keyinfo> <ds:object Id="SignatureObject0"> <QualifyingProperties Id="QualifyingProperties0" Target="#Signature0"> <SignedProperties Id="SignedProperties0"> <SignedSignatureProperties> <SigningTime> T10:45:07Z</SigningTime> <SigningCertificate> <Cert URI="#KeyInfo0"> <CertDigest> <ds:digestvalue>v8dhtlikq1lhjmhnoibmvpdubzs=</ds:digestvalue> </CertDigest> <IssuerSerial> <ds:x509issuername>serialnumber=3, CN=E-Group Certification Authority enon- Repudiation CA, OU=PKI Services, O=E-Group Hungary Plc., C=HU</ds:X509IssuerName> <ds:x509serialnumber>61</ds:x509serialnumber> </IssuerSerial> </Cert> </SigningCertificate> <SignaturePolicyIdentifier> <SignaturePolicyId> <SigPolicyId> <Identifier> </SigPolicyId> <SigPolicyHash> <ds:digestvalue>lnrudishokxh0lfzvexkz04r3jg=</ds:digestvalue> </SigPolicyHash> <SigPolicyQualifiers> <SigPolicyQualifier> <SPURI> <SPUserNotice> <ExplicitText>Jelen dokumentum...</explicittext> </SPUserNotice> </SigPolicyQualifier> </SigPolicyQualifiers> </SignaturePolicyId> </SignaturePolicyIdentifier> </SignedSignatureProperties> <SignedDataObjectProperties> <DataObjectFormat ObjectReference="#Reference0"> <MimeType>text/xml</MimeType> </DataObjectFormat> </SignedDataObjectProperties> </SignedProperties> <UnsignedProperties Id="UnsignedProperties0"> <UnsignedSignatureProperties> <SignatureTimeStamp Id="SignatureTimeStamp0"> <Include URI="#SignatureValue0"/> <ds:canonicalizationmethod Algorithm=" "/> <EncapsulatedTimeStamp Id="EncapsulatedTimeStamp0">MIIFNDADAgEAMIIFKwYJKoZIhvcNAQcCoIIFHDCCBRgCAQMx</EncapsulatedTim estamp> </SignatureTimeStamp> 19

20 <CompleteCertificateRefs Id="CompleteCertificateRefs0"> <CertRefs> <Cert URI="#EncapsulatedX509Certificate0"> <CertDigest> <ds:digestmethod Algorithm=" <ds:digestvalue>ylu+fxi+7glevtcbckkklfbr3m8=</ds:digestvalue> </CertDigest> <IssuerSerial> <ds:x509issuername>cn=e-group Certification Authority eprimary CA, OU=PKI Services, O=E-Group Hungary Plc., C=HU</ds:X509IssuerName> <ds:x509serialnumber>3</ds:x509serialnumber> </IssuerSerial> </Cert> <Cert URI="#EncapsulatedX509Certificate1"> <CertDigest> <ds:digestmethod Algorithm=" <ds:digestvalue>jbirejty215zj7o7mkpnmu/ie7k=</ds:digestvalue> </CertDigest> <IssuerSerial> <ds:x509issuername>cn=e-group Certification Authority eprimary CA, OU=PKI Services, O=E-Group Hungary Plc., C=HU</ds:X509IssuerName> <ds:x509serialnumber>0</ds:x509serialnumber> </IssuerSerial> </Cert> <Cert URI="#EncapsulatedX509Certificate2"> <CertDigest> <ds:digestmethod Algorithm=" <ds:digestvalue>h59l7gxfmfg742dwm+cnp/6yca8=</ds:digestvalue> </CertDigest> <IssuerSerial> <ds:x509issuername>cn=netlock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU</ds:X509IssuerName> <ds:x509serialnumber>105</ds:x509serialnumber> </IssuerSerial> </Cert> </CertRefs> </CompleteCertificateRefs> <CertificateValues Id="CertificateValues0"> <EncapsulatedX509Certificate Id="EncapsulatedX509Certificate0">MIIFejCCBGKgAwIBAgIBAzANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQ</E ncapsulatedx509certificate> <EncapsulatedX509Certificate Id="EncapsulatedX509Certificate1">MIIFgTCCBGmgAwIBAgIBADANBgkqhkiG9w0BAQUFADB5MQswCQYD</Enca psulatedx509certificate> <EncapsulatedX509Certificate Id="EncapsulatedX509Certificate2">MIIFSzCCBLSgAwIBAgIBaTANBgkqhkstE3Kfq51hdcR0/jHTjrn9V7lagonhVK0dH QKwCXoOK</EncapsulatedX509Certificate> </CertificateValues> </UnsignedSignatureProperties> </UnsignedProperties> </QualifyingProperties> </ds:object> <xxx:object Id="XXXObject0"> <xxx:valami>aaaaaaa</xxx:valami> </xxx:object> 20

21 </ds:signature> </wsse:security> </S11:Header> <S11:Body S11:encodingStyle=" wsu:id="signedobject0"> <iop:kerdes> <iop:kerdesfejlec> <iop:felhasznalo>rendszerazonosító</iop:felhasznalo> <iop:uzenetidopont> t09:30:47-05:00</iop:uzenetidopont> </iop:kerdesfejlec> <iop:session> <iop:property Source="HivatalAzonosító" Name="TranzakciosKod" Value=" "/> </iop:session> <iop:form FormID="AlairasViszontazonositas" JogCim="String"> <hszva:termeszetesszemelyazonositok EID="1"> <iop:viseltnev EID="2" NevKod="0" DrJelzo="0"> <iop:drcimjelzes>text</iop:drcimjelzes> <iop:csaladinev EID="3">String</iop:CsaladiNev> <iop:utonev1 EID="4">String</iop:UtoNev1> <iop:utonev2 EID="5">String</iop:UtoNev2> </iop:viseltnev> <iop:szuletesinev EID="6"> <iop:drcimjelzes>text</iop:drcimjelzes> <iop:csaladinev EID="7">String</iop:CsaladiNev> <iop:utonev1 EID="8">String</iop:UtoNev1> <iop:utonev2 EID="9">String</iop:UtoNev2> </iop:szuletesinev> <iop:termeszetesszemelyneme EID="10" KodCsoport="8" KodErtek="1">1</iop:TermeszetesSzemelyNeme> <iop:szuletesihely EID="11"> <iop:orszag>text</iop:orszag> <iop:telepules>text</iop:telepules> <iop:telepulesmagyarneve>text</iop:telepulesmagyarneve> <iop:kozigazgatasiegyseg>text</iop:kozigazgatasiegyseg> </iop:szuletesihely> <iop:szuletesiido EID="12"> <iop:szuletesdatum>text</iop:szuletesdatum> </iop:szuletesiido> <iop:anyjaneve EID="13" DrJelzo="0"> <iop:drcimjelzes>text</iop:drcimjelzes> <iop:csaladinev EID="14">String</iop:CsaladiNev> <iop:utonev1 EID="15">String</iop:UtoNev1> <iop:utonev2 EID="16">String</iop:UtoNev2> </iop:anyjaneve> </hszva:termeszetesszemelyazonositok> <hszva:x509tanusitvanyazonosito> <hszva:certdigest> <ds:digestmethod Algorithm=" <ds:digestvalue>r0lgodlhcggsalmaaaqcaemmcztumfqxds8b</ds:digestvalue> </hszva:certdigest> <hszva:issuerserial> <ds:x509issuername>string</ds:x509issuername> <ds:x509serialnumber>0</ds:x509serialnumber> </hszva:issuerserial> </hszva:x509tanusitvanyazonosito> </iop:form> <iop:parancs PID="String"> <iop:rendszer>string</iop:rendszer> 21