Názory k článku Nebojte se elektronického podpisu: Praxe
-
Ad a) jak uz jsem psal v predchozi odpovedi, hlavicky se nepodepisuji. A s prilohami je to tak, ze se vygeneruje cela zprava ve formatu MIME vcetne vsech priloh, sakumprask se podepise a ten podpis se ulozi na konec se jako dalsi priloha. Takze pak je struktura treba takova:
Part.1 (puvodni MIME zprava)
Part.1.1 (text)
Part.1.2 (obrazek)
Part.2 (podpis)
Takoveto zprave se rika S/MIME a ma MIME hlavicku:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"
Ad b) OpenPGP pouziva uplne jiny druh certifikatu - duveryhodnost neni "strom" s korenem v Certifikacni Autorite ktere kdyz verite, tak implicitne verite i vsem ji podepsanym certifikatum. U OpenPGP (GnuPG, PGP, ...) si lide kteri si duveruji certifikaty podepisuji vzajemne a teoreticky by mel fungovat tranzitivni vztah: pokud Jarda podepsal Pepuv certifikat a Pepa podepsal Karluv certifikat, tak by Jarda mel verit i Karlovu certifikatu, protoze je podepsan nekym komu on sam veri.
Technicky je mozne PGP podpis resit dvema zpusoby - bud "inline", kdy je podepsan jen text e-mailu a ne prilohy. V tom pripade se text ohranici znackami "BEGIN PGP SIGNED MESSAGE" / "BEGIN PGP SIGNATURE" / "END PGP SIGNATURE" a mezi BEGIN/END signature je vlastni podpis. V mailovem klientovi ktery PGP neumi tyto znacky uvidite vlozene primo v textu zpravy.
Druha moznost je PGP/MIME, kdy je format zpravy prakticky stejny jako jsem popsal u S/MIME v bodu (a), az na to, ze zprava je typu "multipart/signed; protocol="application/pgp-signature". -
petr andrs (neregistrovaný)U toho PGP je právě ten problém, Pepa v tomto příkladě vystupuje v roli certifikační autority. To že Jarda podepsal Pepův veřejný klíč a tím vytvořil svým způsobem cetifikát, říká pouze to, že Jarda tvrdí, že osoba prokazující se jím podepsaným klíčem je Pepa, Pepa ale může podepsat komukoliv cokoliv, to že Jarda ověřil Pepovu totožnost rozhodně neznamená, že budé také věřit všemu co ověří Pepa.
Čili tvrzení by mělo spíše znít: "pokud Jarda podepsal Pepuv certifikat, Pepa podepsal Karluv certifikat a Jarda fakt věří Pepovi, že je to opravdu dobrej kluk a nikdy by nevystavil certifikát nikomu koho nezná, tak pak by Jarda mel verit i Karlovu certifikatu, protoze je podepsan nekym komu on sam veri."
Dále bych chtěl trochu upřesnit použití pojmu certifikát, který je použit způsobem, který může být matoucí. Tedy certifikát je veřejný klíč subjektu ke kterému jsou definovaným způsobem připojena identifikační data subjektu a tento celek je podepsaný certifikační autoritou. Čili pokud si koupím od Certifikační autority certifikát, znamená to, že certifikační autorita vezme můj veřejný klíč a má identifikační data a připojí k nim svůj podpis vytvořený za pomoci svého privátníjo klíče. Tím prohlašuje, že subjekt dostatečným způsobem prokázal svojí totožnost, což certifikační autorita svým podpisem stvrzuje. A spousta různých předpisů od technických norem až po zákony by měla zajistit, že toto tvrzení CA je důvěryhodné. U PGP je nutno důkladně prověřit důvěryhodnost všech článků řetězu. -
zviratko (neregistrovaný)Nevim jestli je to oficialni rozdeleni, ale jsou ruzne tridy certifikatu.
Class 1 potvrzuje pouze emailovou adresu - pokud Vam prijde podepsana zprava z bill.gates@microsoft.com tak je overene, ze odesilatel zpravy kontroluje tento email.
Class 2 potvrzuje take identitu ktera se k emailu vaze, v certifikatu je jmeno a prijmeni, jde dohledat adresu a nejaky unikatni identifikator (social security number, cislo OP, rodne cislo)...
Class 3 a vys se pouzivaji v kombinaci s hw klici (smartcard), jestli je tam jiny rozdil nevim...
No a je to prave o tom, ze Thawte vydava Class 2, takze potrebuje nejaky identifikator...
Btw, jestli neverite CA (Verisign, Thawte) tak radsi nechodte na internet :) -
To rodne cislo ci cislo obcanky potrebujete ve chvili, kdyz chcete u tzv. notare overit svoji identitu a ziskat tak moznost uvadet sve jmeno v certifikatu. Pokud tohle nechcete, muzete si teoreticky rodne cislo vymyslet. Ale jak uz nekdo poznamenal, pokud neverite Thawte, tak komu? Nehlede na to, ze me (a asi i vase) rodne cislo ma tolik ruznych instituci, ze jednu navic uz preziju... -
Jan Schermer (neregistrovaný)Omyl - thawte novemu uzivateli NEDA jmeno do certifikatu, proto je uplne jedno co tam je za identifikaci u uzivatelee, overuje se JEN emailova adresa (a ta musi byt platna protoze se overuje).
S neplatnym rodnym cislem vas neoveri notar a proto se nemuze (nemelo by) stat, ze tam nekdo bude mit jmeno a k nemu vazanou spatnou identifikaci.
Your argument is flawed, fix it :) -
a) na webu nic nevystavujete, to cislo zustane u Thawte
b) ano, certifikat s podpisem "Thawte freemail member" je presne to, co rikate. Pokud ale uvedu nejake "oficialni" cislo, muzu se nechat proverit a pak mam u certifikatu podpis Tomas Krause. Jak hodne tomu druha strana veri, je samozrejme na ni, ale pro 99 % komunikace to IMHO staci a rozhodne je to lepsi varianta, nez posilat choulostiva data "jen tak" (mluvim o sifrovani). -
zviratko (neregistrovaný)Co by jeste meli uzivatele vedet
1) certifikat zustava na webu thawte ke stazeni dokud ho nezrevokujete (nezneplatnite), to ale _neznamena_ ze si ho muzete kdykoliv (napriklad po reinstalaci) stahnout znovu! stahnout jde jen do prohlizece ve kterem byl vytvoren. Takze zalohuje pres export certifikatu a pouzivejte silne heslo
2) pokud budete posilat podepsanou/zasifrovanou zpravu nekomu, kdo ma nainstalovany aplikace I.CA (pokud Vam posle jen jednu podepsanou zpravu tak mate jeho public klic e muzete sifrovat, dokonce se to myslim samo nastavi) tak uzivatel nejen ze sifrovanou zpravu neotevre, on dokonce neotevre ani podepsanou. Zrejme aby se zvysil zajem o ceskou certifikacni autoritu... -
petr andrs (neregistrovaný)ad 1) na to jsem také narazili, vygenerovali jsem certifikát na jednom PC a pak se děsně divili, že na jiném ho nelze stáhnot. Pak nám došlo, že klíče generuje prohlížeč a ten privátní nedá z ruky, pouze předá Thawte k podpisu ten veřejný a pak stáhne certifikát. Tj. je nutné stáhnout certifikát stáhnout v prohlížeči, kde probíhalo generování a kde je tedy i privátní klíč a pár tvořený privátním klíčem a certifikátem pro použití jinde exportovat do formátu PKCS12. Pokud se snažím stáhnot certifikát jinde, kde není privátní klíč, nic se neprovede.
-
Frn (neregistrovaný)A jak se ten formulář vyplňuje ?
Zkoušel jsem (na systému Fedora3, UTF) nastavit "Kódování pro vložený text" na hodnoty :
* Use the default for my language
* ISO-8859-2 (Latin 2)
* UTF-8 (best for UniCode)
* UTF-16 (UniCode)
.. ale vždycky se mi háčkovaná souhláska změní v otazník. To bych pak asi těžko dokazoval že jsem to já, když by jméno nesouhlasilo. Stejně jako kdybych se zadal bez diakritiky. Takže co s tím ? -
Myslim ze to muzete vyplnit bez diakritiky. Ja uz jsem jakozto Thawte notar par lidem jmeno bez hackocarek uznal, pokud jim sedelo rodne cislo v udajich u Thawte. Navic hacky by stejne mohly v certifikatu delat neplechu - standard sice unicode pokud vim povoluje, ale kdo vi jak jsou na tom vsechny implementace, co si budem namlouvat.
-
James_Bond (neregistrovaný)Dobrý den,
už jsem se u Thawte zaregistroval, ale pokud si požádám o vydání certifikátu, tak se mě to zeptá na typ softwaru, co používám. Je tam na výběr Netscape, Opera, MSIE, Outlook Express, atd. Ale já používám kombinaci Firefox a Evolutio. Zadal jsem Netscape. Všechno proběhlo v pohodě, certifikát jsem si nainstaloval dle návodu (i do Evolution), ale podepsat s ním nemůžu. Pokud píšu novou zprávu a zvolím podepsat PGP nebo podepsat S/MIME (nevím, jaký je rozdíl, a tak jsem vyzkoušel obě možnosti), tak mi to napíše:
Nemohu vytvořit zprávu.
Protože "Nemohu podepsat odchozí zprávu: Pro tento účet nebyl nastaven podpisový certifikát", možná budete muset zvolit jiná nastavení pošty.
A tak nevím, jestli je ten certifikát špatný nebo je chyba v mém SW, případně něco jiného. V dialogu vytvoření certifikátu u Thawte jsou i nějaké pokročilé možnosti, nicméně jim vůbec nerozumím, a tak jsem tuto možnost nepoužil.
Děkuji
Richard
student -
James_Bond (neregistrovaný)Ten certifikát nestačí pouze naimportovat, ale musí se ještě nastavit pro každý účet zvlášť.
Akorát by mě pořád zajímalo, proč se ten certifikát importuje i do prohlížeče. Je to kvůli identifikaci na nějakých stránkách? Nikdy jsem se s tím nesetkal, vždy se musel vygenerovat certifikát na stránkách např. banky...
Richard -
James_Bond (neregistrovaný)Ten certifikát nestačí pouze naimportovat, ale musí se ještě nastavit pro každý účet zvlášť.
Akorát by mě pořád zajímalo, proč se ten certifikát importuje i do prohlížeče. Je to kvůli identifikaci na nějakých stránkách? Nikdy jsem se s tím nesetkal, vždy se musel vygenerovat certifikát na stránkách např. banky...
Richard -
anonymníCA Thawte nemuze vydat kvaliffikovany certifikat pokud neni registrovana jako kvalifikovana CA a *hlavne pokud 100% a osobne neoveri Vasi totoznost*. Tak ze certifikat vystaveny jen prostrednictvim weu nemuze byt za zadnych okolnosti povazovan za kvalifikovany. Ten ma pravo v nasi republice vydavat zatim pouze ICA (vim ze Ceska posta mela nejake umysly v tomto smeru, ale jak to dopadlo, nevm). Myslim si ze v dohledne dobe nebude nikdo na svete vydavat kvalifikovane certifikaty zcela zdarma :-)
-
Zviratko (neregistrovaný)Ceska Posta ma vlastni autoritu (ale doted jsem nepochopil proc nebo k cemu by to nekdo pouzival :))
A abych to uvedl na pravou miru - Thawte _VYDAVA_ kvalifikovany certifikat... ve smyslu vsech RFC a dalsich standardu a interoperability ve svete.
Cesky "kvalifikovany certifikat" je jen ten samy termin pouzity pro jiny vyznam, znamena to "kvalifikovany certifikat vydany certifikacni autoritou akreditovanou pro vydavani certifikatu pro komunikaci s ceskou statni spravou"... bohuzel bez one interoperability se zbytkem internetu :P
certifikat od ICA vypada asi takto:
Object Identifier (2 5 4 5 ) = ICA - 10009xxx (cislo)
Object Identifier (2 5 4 4 ) = Novak
Object Identifier (2 5 4 41 ) = Ing. Pavel Novak
Object Identifier (2 5 4 42 ) = Novak
E = pavel@novak.cz
L = Praha 1, Prvni ulice 111/22
CN = Ing. Pavel Novak
C = CZ
v beznem certifikatu tyto veci nejsou pokud se nejedna o podpis organizace (napriklad v pripade SSL certifikatu pro webovy server nejakeho eshopu), ICA tam ma navic identifikacni cislo
do ceskych certifikatu zas tolik nevidim, pokud ma nekdo lepsi informace tak me doplnte :) -
Vondruska (neregistrovaný)Abych to uvedl na pravou miru zase ja :-)
--
Thawte _NEVYDAVA_ kvalifikovany certifikat... ve smyslu vsech RFC a dalsich standardu a interoperability ve svete :-)
--
Pojem kvalifikovany certifikat vznikl v souvislosti s "Directive 1999/93/EC", kde je definován. Požadavky na kvalifikovaný certifikát jsou uvedeny v Příloze I.
--
Kvalifikovany certifikat a jeho vydavani je vzdy spjato s narodni legislativou a vzřdy v něm musí být uvedeno, že byl vydan jako kvalifikovany certifikat !!!! (to prave u Thawte nenajdete...)
--
Takto je používán tento pojem ve všech standardech ETSI, CEN a je tak chápán i v RFC, které se touto problematikou zabývají.
--
Pokud jde např. o RFC 3039 Qualified Certificates Profil - pak se zde přímo počítá s položkou: " .. a statement by the issuer that the certificate is issued as a Qualified Certificate in accordance with a particular legal system (...) "
---
Dále doporučuji se podívat do odstavce 2.2 a ujistite se , PROČ
Thawte nwní vydavtel kvalifikovaných certifikátů...
--
Pokud jde o interoperabilitu - je potreba, aby kvalifikovane certifikaty pouzivaly stejnou strukturu, co je a co neni povoleno viz. prave zminene RFC. Z tohoto hlediska vami uvadeny priklad se tam vejde ...
Co je bezeny certifikat to nevim :-). Takovy pojem zadny standard ani RFC nedefinuje. -
Vondruska (neregistrovaný)Abych to uvedl na pravou miru zase ja :-)
--
Thawte _NEVYDAVA_ kvalifikovany certifikat... ve smyslu vsech RFC a dalsich standardu a interoperability ve svete :-)
--
Pojem kvalifikovany certifikat vznikl v souvislosti s "Directive 1999/93/EC", kde je definován. Požadavky na kvalifikovaný certifikát jsou uvedeny v Příloze I.
--
Kvalifikovany certifikat a jeho vydavani je vzdy spjato s narodni legislativou a vzřdy v něm musí být uvedeno, že byl vydan jako kvalifikovany certifikat !!!! (to prave u Thawte nenajdete...)
--
Takto je používán tento pojem ve všech standardech ETSI, CEN a je tak chápán i v RFC, které se touto problematikou zabývají.
--
Pokud jde např. o RFC 3039 Qualified Certificates Profil - pak se zde přímo počítá s položkou: " .. a statement by the issuer that the certificate is issued as a Qualified Certificate in accordance with a particular legal system (...) "
---
Dále doporučuji se podívat do odstavce 2.2 a ujistite se , PROČ
Thawte nwní vydavtel kvalifikovaných certifikátů...
--
Pokud jde o interoperabilitu - je potreba, aby kvalifikovane certifikaty pouzivaly stejnou strukturu, co je a co neni povoleno viz. prave zminene RFC. Z tohoto hlediska vami uvadeny priklad se tam vejde ...
Co je bezeny certifikat to nevim :-). Takovy pojem zadny standard ani RFC nedefinuje. -
Zdravim
Vie mi niekto poradit ako to rozbehat pre Kmail? Postupoval som podla:
http://jdurand.home.cern.ch/jdurand/cern_ca_and_mail/
http://kmail.kde.org/kmail-pgpmime-howto.html
http://kmail.kde.org/kmail-pgpmime-howto.html#gnupg
No bez uspechu. Mama p12 aj pem subory.
gpgsm --import som importovat
pgp-agent --daemon mi bezi
gpgsm --list-secret-keys vypise key
gpg --list-secret-keys nevypise nic
v Kleopatre certifikaty vidim, v KGpgp nie, Kmail najde S/MIME Signing aj Encryption certificate.
Ked dam podpisat spravu v kmaili, tak mi hodi error:
Signing failed: General error
Prosim poradte ako postupovat dalej
PS: rozbehat to v Thunderbirde bolo hrackou ... -
luvan (neregistrovaný)Zdravím,
mám problém s el.podpisem, naše webová aplikace prostřednictvím qmailu resp. PHP funkce odesílá podepsaný mail ve formátu multipart/signed. A někdy se zřejmě stane že se obsah změní. Zřejmě jde o změny v ukončování řádků.
Zdá se mi že pokud použiju LF, někdy se po cestě změní na CRLF a tím se obsah fakticky poruší. Na druhou stranu použiju-li CRLF (což je myslím standard), nastal případ že některý klient (nebo pošťák?) opět konvertuje a vkládá jeden prázdný řádek navíc, čímž naprosto obsah rozhodí.
Pokud bych mail formátoval jako application/pkcs7-mime, pak mu zase nerozumí někteří freemailoví klienti.
Vypadá to že se prostě nelze nikomu zavděčit :-(
Nevíte jak tento problém ošetřit, nebo alespoň co je standard abych mohl aspoň říct že chyba není na naší straně?
Dík -
Josef (neregistrovaný)Dle toho, co jsem zjistil, myslím, že certifikát (podpis) od CA Thawte nemá adresát zprávy nijak možnost ověřit. Zneplatním-li svůj certifikát (byl ukraden), mohu se o zneplatnění dovědět pouze já sám, ale nikdo jiný nepozná, zda je doručený podpis platný nebo zneplatněný - to nabourává celý smysl odvolávání certifikátů, to vše ztrácí smysl a dosti to narušuje bezpečnost celého systému. Thawte zcela chybí jakýsi seznam zneplatněných certifikátů (stáhnutelný), či např. ověření certifikátu on-line, jež by mohl provádět kdokoli. Mýlím se snad?
-
Ano, buhuzel se mylite. Seznamy zneplatnenych certifikatu (tzv. Certificate Revocation List, CRL) jsou na adrese http://www.thawte.com/roots/crldatabase.html
Pro FreeMail certifikaty od Thawte jde konkretne o tento CRL:
http://crl.thawte.com/ThawtePersonalFreemailIssuingCA.crl -
Josef (neregistrovaný)Ano, mýlil jsem se. Jenom mne napadá, kde se k adrese pro stažení CRL dostane někdo, kdo dostane podepsanou zprávu? Z úvodní stránky CA Thawte jsem se k CRL probojovat nedokázal, ani ve vlastním podpise jsem nikde nenašel adresu pro stažení seznamu či ověření (mimochodem, jak často je aktualizován jsem též nezjistil).
-
Aktualizován je asi každou chvíli, protože je v něm i záznam z "Aug 6 01:36:57 2005 GMT", čili certifikát odvolaný před pár hodinami.
Jak se k němu dostat ... já do vyhledávacího políčka na stránce Thwate napsal CRL a hned první odkaz byl ten správný. Jinak v certifikátu "Thawte Personal Freemail Issuing CA" je položka "CRL distribution points" - sice to není plain text, ale možná se zrovna tam ukrývá adresa odkud lze CRL stáhnout. -
Josef (neregistrovaný)V "CRL distribution points" se konkrétně u mně ukrývá toto:
Nekritické
30 3a 30 38 a0 36 a0 34 86 32 68 74 74 70 3a 2f
2f 63 72 6c 2e 74 68 61 77 74 65 2e 63 6f 6d 2f
54 68 61 77 74 65 50 65 72 73 6f 6e 61 6c 46 72
65 65 6d 61 69 6c 43 41 2e 63 72 6c
Alespoň já osobně z toho žádnou adresu získat nedokážu. Mozilla mi navíc při zobrazení certifikátu píše, že jej z neznámých důvodů nebylo možno ověřit (mám něco špatně nastaveno?) - myslím, že by bylo ideální, kdyby v okně zobrazení certifikátu bylo rovnou např. tlačítko, jež by on-line platnost prověřilo (tak je tomu např. při ověřování platnosti certifikátů vydaných Komerční bankou).
Navíc mne napadá, kdyby někdo teoreticky vytvořil falešný certifikát na mé jméno a dokázal do něj vložit i název vydavatele CA Thawte (nevím, zda je to prakticky možné), jak někdo zjistí, že je neplatný? - v CRL jeho číslo nebude. Připadlo by mi mnohem logičtější uveřejňovat seznam platných certifikátů (i když potom by ve výše uvedeném případě padělatel vložil i falešné seriové číslo), nebo nejlépe, kdyby bylo možno přímo on-line "zaslat" obdržený podpis a CA by odpověděla zda certifikát vydala a zda je platný. -
qube (neregistrovaný)Nechal jsem si vygenerovat certifikat od Thawte a prekvapilo me, ze soukromy klic nema heslo. Tudiz podepsat email muze kdokoli, kdo pouzije muj otevreny Thunderbird. Nejspis jsem neco pri procesu generovani klice prehledl. Podarilo se nekomu vygenerovat soukromy klic s heslem?
Take me prekvapilo, ze pokud certifikat exportuju do souboru (exportuje se vse - muj soukromy i verejny klic a verejny klic CA Thawte), jde tento soubor (.p12) importovat napriklad do PGP a muzu ho normalne pouzivat. Asi to vsichni vite, ale ja jsem si o certifikatech zacal shanet informace teprve nedavno a netusil jsem, ze je to az tolik kompatibilni s PGP. -
Jenda (neregistrovaný)
No, já jsem z toho byl jelen a tak jsem našel stránku: http://www.digitalni-podpis.cz, kde mi s tím pomohli a podpis byl pak zařízený raz dva.
-
- Administrátor poštovních serverů
- Angular Developer (Fin&Energy, Health or Digital)
- Výzkumník strojového učení pro relevanci
- prodejce na prodejně T-Mobile v Třebíči
- Vývojář/Analytik JAVA
- Office management Intern
-
- Zkratky v online komunikaci
- Barevná osobnostní typologie pro obchodníky
- Používáme Mac efektivně
- Google Workspace - bezpečnost v cloudu, hesla a Chrome
- Start Speaking Czech Now! - The Essentials
- Firemní vzdělávání: efektivní rozvoj zaměstnanců
-
- Administrátor poštovních serverů
- PLC programátor Jihlava
- Projekt "Mladí - Mladým" Specialista prodeje služeb T-Mobile
- prodejce na prodejně T-Mobile v Třebíči
- Vývojář/Analytik JAVA
- Fullstack developer
-
- Zkratky v online komunikaci
- Barevná osobnostní typologie pro obchodníky
- Používáme Mac efektivně
- Google Workspace - bezpečnost v cloudu, hesla a Chrome
- Cool fráze a obraty pro každou situaci
- Vzdělávání jako součást života
ČLÁNKY DO MAILU