8             PKI

PKI je soustavou technických a především organizačních opatření spojených s vydáváním, správou, používáním a odvoláváním platnosti kryptografických klíčů a certifikátů. Jednu z možných norem PKI definuje sada internetových standardů RFC popisujících základní využití asymetrické kryptografie na Internetu. Navazujícími normami popsanými v dalších kapitolách jsou pak normy pro bezpečnou elektronickou poštu (S/MIME) a norma pro bezpečnou komunikaci nejen s webovým servem (TLS).

 

8.1                 Certifikát

Certifikát je struktura obsahující identifikační údaje klienta, veřejný klíč klienta, identifikaci vydavatele, číslo certifikátu, platnost certifikátu a další údaje týkající se zejména vymezení způsobu použití certifikátu. Tato struktura je digitálně podepsána certifikační autoritou (vydavatelem certifikátu).

 

K čemu slouží tato poměrně komplikovaná konstrukce? Na obr.8-1 je znázorněn případ, kdy uživatel A chce uživateli B zaslat zprávu, kterou chce zabezpečit šifrováním asymetrickou šifrou. V takovém případě je nutné, aby příjemce B nejprve vygeneroval dvojici klíčů: veřejný klíč (VK-B) a soukromý klíč (SK-B). Soukromý klíč si uloží jako své tajemství např. na disk či čipovou kartu. Veřejný klíč (VK-B) nějakým kanálem distribuuje uživateli A.  

 

Obr. 8-1 Distribuce veřejného klíče bez certifikátu

Uživatel A pak použije veřejný klíč uživatele B (na obrázku označený VK-B) k zašifrování odesílané zprávy. Uživatel B pak takto šifrovanou zprávu dešifruje svým soukromý klíčem (SK-B) a získá tak původní zprávu.

 

U asymetrické kryptografie nespočívá nebezpečí ve vyzrazení veřejného klíče. Avšak i u asymetrické kryptografie je nebezpečím podvržení klíče.

 

Na obr. 8-2 nám vstupuje do hry útočník X, který si vygeneruje svou dvojici klíčů: veřejný klíč (VK-X) a soukromý klíč (SK-X). Útočník svůj veřejný klíč VK-X podvrhne za klíč uživatele B. Tj. uživatel A si myslí, že VK-X je veřejným klíčem uživatele B a provede tímto klíčem šifrování odesílané zprávy. Zprávu odchytne útočník X a dešifruje si ji svým soukromým klíčem SK-X.  Útočník tak získá zprávu. Avšak aby uživatel B si neztěžoval, že nedostane zprávu, tak mu ji útočník zašifruje a odešle šifrovanou jeho klíčem (VK-B).  

 

 

Obr. 8-2 Podvržení veřejného klíče

Proti podvržení veřejného klíče se bráníme certifikací veřejného klíče – tj. pomocí certifikátu (obr. 8-3). Uživatel B vygeneruje dvojici veřejný a soukromý klíč (1), přičemž soukromý klíč si jako tajemství pečlivě uloží. Avšak veřejný klíč neodesílá uživateli B samotný, ale jako součást certifikátu.

 

Po vygenerování dvojice klíčů uživatel sestaví strukturu „žádost o certifikát“. Tato struktura obsahuje identifikační údaje uživatele, veřejný klíč uživatele a případně další data, která jsou popisována dále. Tuto strukturu digitálně podepíše svým právě vygenerovaným soukromým klíčem a předá certifikační autoritě (2). Certifikační autorita může ověřit totožnost uživatele a v každém případě verifikuje elektronický podpis na žádosti o certifikát. Pokud je žádost certifikační autoritou shledána v pořádku, pak certifikační autorita vystaví certifikát.

 

Certifikát obsahuje mj.: informace o tom, kdo jej vydal, sériové číslo certifikátu, identifikační údaje uživatele, platnost certifikátu a pochopitelně veřejný klíč uživatele. Certifikát je digitálně podepsán za využití soukromého klíče certifikační autority.

 

Certifikační autorita má svou dvojici klíčů: veřejný klíč CA (VK-CA) a soukromý klíč (SK-CA). Na bezpečnost uložení soukromého klíče CA jsou kladeny extrémní nároky. Veřejný klíč CA se distribuuje jako součást certifikátu CA. Certifikát CA může být podepsán soukromým klíčem CA samotné nebo i soukromým klíčem jiné CA.

 

Uživateli je certifikační autoritou vrácen vystavený certifikát (3). S vystaveným certifikátem by měl uživatel obdržet též jeden nebo více certifikátů certifikačních autorit. Pomocí certifikátů certifikačních autorit může být ověřován vystavený certifikát. Dále se dozvíme, že uživatel může od certifikační autority obdržet též seznam zneplatněných certifikátů.

 

Nyní již může uživatel B svůj certifikát odeslat (4) uživateli A, který jej ověří a v případě, že je vystaven pro uživatele A důvěryhodnou certifikační autoritou a elektronický podpis na certifikátu je v pořádku, pak může z tohoto certifikátu použít veřejný klíč k šifrování zprávy, kterou chce odeslat uživateli B. Šifrovanou zprávu odešle uživateli B (5). Uživatel B pak pomocí svého soukromého klíče dešifruje zprávu (6) a získá tak původní zprávu.

Obr. 8-3 Činnost certifikátu

Pokud namítnete, že ne každý certifikát je určen k elektronickému podpisu, pak i tento případ je dále detailně rozebrán u protokolů CMP a CMC.

 

Certifikát se často přirovnává k občanskému průkazu. Zatímco občanský průkaz se vydává v tištěné podobě, tak certifikát se popisuje jako struktura v jazyce ASN.1 a mezi počítači se přenáší v kódování DER (podmnožina BER). Certifikát je možné vypsat i v textovém tvaru, ale s tímto případem se setkáváme zřídka - např.  certifikát samotné certifikační autority  může být vytištěn v textovém tvaru a ověřen (neelektronickým) notářem a  podepsán rukou psaným podpisem. Zásadní rozdíl mezi občanským průkazem a certifikátem je, že občanský průkaz neobsahuje šifrovací klíč.

 

V Internetu je certifikát popsán normou RFC-2459. Tato norma je odvozena od doporučení ITU (dříve CCITT) X.509. Původní verze číslo 1 certifikátu podle normy X.509 z roku 1988 byla postupně rozšířena až do dnes nejběžnější verze 3. 

 

Kromě certifikátů podle RFC-2459 (resp. doporučení X.509) se v praxi můžeme setkat i s certifikáty jiných formátů - např. EDI. Forma takový certifikátu je sice jiná, ale princip zůstává stejný. 

 

Porovnání položek občanského průkazu a položek certifikátu: 

 

Položka struktury certifikátu

Přirovnání k položce občanského průkazu

Verze 

0 ... X.509 verze 1 (1988)

1 ... X.509 verze 2

2 ... X.509 verze 3

Verze (federální, červený český, karta, ...)

Sériové číslo

Číslo a série občanského průkazu

Algoritmus použitý pro podpis

Razítko či samolepka přes fotografii

Vydal (identifikace certifikační autority podle X.500)

Vydal

Platnost od-do

Platnost

Jméno a adresa (identifikace vlastníka)

Jméno a adresa

Veřejný klíč

-

Rozšíření certifikátu

Další údaje

Elektronický podpis certifikátu

Vlastní razítko či samolepka přes fotografii

 

Strukturu certifikátu podle RFC-2459 zapisujeme v jazyce ASN.1:

 

Certificate  ::=  SEQUENCE  {

        tbsCertificate       TBSCertificate,

        signatureAlgorithm   AlgorithmIdentifier,

        signatureValue       BIT STRING  }

 

Což je pouze trik vyjadřující, že certifikát je podepsaná struktura (SEQUENCE).  Tj. certifikát je sekvencí vlastních dat certifikátu (tbsCertificate), algoritmu použitého certifikační autoritou pro elektronický podpis certifikátu (AlgorithmIdentifier) a vlastního elektronického podpisu.

 

Položka AlgorithmIdentifier je pak sama sekvencí skládající se z identifikátoru objektu použitého algoritmu a jeho parametrů:

 

AlgorithmIdentifier  ::=  SEQUENCE  {

        algorithm               OBJECT IDENTIFIER,

        parameters              ANY DEFINED BY algorithm OPTIONAL  }

 

Identifikátor objektu použitého pro elektronický podpis vždy identifikuje dvojici: asymetrický algoritmus a algoritmus pro výpočet kontrolního součtu (např. sha1WithRSAEncryption mající identifikátor objektu { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 5 }).

 

Příklad (elektronický podpis certifikátu):

  SEQUENCE         

     30 0d

   OBJECT            :md5WithRSAEncryption

      06 09 2a 86 48 86 f7 0d 01 01 04

   NULL             

      05 00

  BIT STRING       

     03 81 81 00 28 0a ca d3 33 e1 91 d4 bb 98 f5 d1 fb aa 59 18

     75 fd 47 a6 94 e4 c4 f5 df 4b f6 01 27 e7 68 bf d9 1a a9 2f

     75 da 58 d8 fd 7a db 26 56 ba 0c e9 b3 5c b7 6e c7 13 5f 08

     7c bc fb 3b 7c cd c8 5b 6a 5d a8 cb eb ef dc 4b 04 68 06 21

     cb 02 fc 35 5b 7c a2 18 0d 91 8d 2c a5 78 2c b3 34 37 f0 86

     e2 d2 f9 c4 5f 9e 0e 27 0f 40 43 aa 01 41 de 46 ec e4 78 0c

     b9 14 aa 9f 7f 38 2a 8d 4e 1c 3c eb

 

 

Nás však zajímá vnitřek certifikátu, tj. to co podepisujeme:

 

   TBSCertificate  ::=  SEQUENCE  {

        version         [0]  EXPLICIT Version DEFAULT v1,

        serialNumber         CertificateSerialNumber,

        signature            AlgorithmIdentifier,

        issuer               Name,

        validity             Validity,

        subject              Name,

        subjectPublicKeyInfo SubjectPublicKeyInfo,

        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,

                             -- If present, version shall be v2 or v3

        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,

                             -- If present, version shall be v2 or v3

        extensions      [3]  EXPLICIT Extensions OPTIONAL

                             -- If present, version shall be v3

        }

 

8.1.1                      Verze certifikátu

Verze certifikátu  souvisí s tím, zda-li je certifikát odvozen od normy X.509 verze 1, 2 nebo 3.  Položka Version má v případě verze jedna hodnotu nula, v případě verze 2 hodnotu 1 a v případě verze 3 hodnou 2.

 

8.1.2                      Sériové číslo certifátu

Sériové číslo certifikátu je definováno jako celé číslo.

 

8.1.3                      Algoritmus

Položka signature obsahuje algoritmus použitý CA pro vytvoření elektronického podpisu certifikátu. Toto pole musí obsahovat stejný identifikátor jako je použit v položce signatureAlgorithm.

 

8.1.4                      Platnost certifikátu

Ppoložka platnost certifikátu obsahuje dva časy, od kdy certifikát platí a do kdy certifikát platí.

 

8.1.5                      Jedinečná jména

Jedinečná jména se používají pro popis vystavitele certifikátu i pro popis předmětu certifikátu. Jedinečné jméno (Distinguished name) je typu Name zavedeného normou X.501.

 

Cílem norem řady X.500 je vytvořit celosvětovou adresářovou strukturou. Adresářem se přitom nerozumí adresář souborů, ale adresář jako seznam adres. Cílem je vytvořit obdobu celosvětových bílých stránek telefonních seznamů. Jeden záznam v takovém seznamu odpovídá pak jedinečnému jménu. Záznam v takové bílé knize by pak byl hypoteticky tvořen informacemi o státu, telefonní společnosti, telefonním obvodě, jméně, adrese, telefonním čísle.

 

Obdobně i jedinečné jméno bude tvořeno relativními jedinečnými jmény. Jednotlivá relativní jedinečná jména budou popisovat např.: stát, kraj, organizaci, jméno, adresu elektronické pošty atd.

 

Jedinečné jméno (někdy též absolutní jedinečné jméno či RDNSequence)  je vždy posloupností relativních jedinečných jmen (Relative Distinguished Name). Přitom v jedinečném jméně se mohou i relativní jedinečná jména opakovat.

 

Relativní jedinečné jméno je množina dvojic tvořených identifikátorem objektu (např. Country, Organization, CommonName apod.) a řetězcem (např. CZ). Textově pak často relativní jedinečné jméno zapisujeme např.

 

Country=CZ

 

Jedinečné jméno popisující jedince je pak sekvencí relativních jedinečných jmen. Např.:

 

Country=CZ, Organization=PVT, CommonName=Libor Dostalek

 

Tento zápis se často zkracuje pomocí zkratek pro identifikátory objektů relativních jedinečných jmen:

 

C=CZ, O=PVT, CN=Libor Dostalek

 

I když relativní jedinečné jméno je množinou dvojic identifikátor objektu + hodnota, tak v praxi bývá tato množina jednoprvková, tj. obsahuje dvojici jen jednu. Jedinečná jména jsou tvořena vždy větví ve stromu relativních jedinečných jmen (obr. 8-4).

Obr. 8-4 Hierarchická struktura relativních jedinečných jmen

Zajímavé je, že Libor Dostalek může být ve struktuře uveden mnoha způsoby. Např.

 

Použil jsem jméno Dostalek, tj. bez české diakritiky, ale nic nebrání používat diakritiku, protože PKI ve všech řetězcích, u kterých přichází v úvahu použití diakritiky, připouští kódování UTF-8.

 

Vrátíme-li se zpět k definici jedinečného jména jako RDNSequence v jazyce ASN.1, pak tato definice je graficky znázorněna na obr. 8-5.

 

Obr. 8-5 Jedinečné jméno (RDNSequence) je posloupností relativních jedinečných jmen

 

Přehled atributů relativních jedinečných jmen používaných PKI:

 

Identifikátor / zkratka

Atribut

OID

Význam

Common Name

CN

commonName

{id-at 3}

Název objektu, pod kterým je místně znám. Např. u osob to může být jméno a příjmení. U serverů pak jejich DNS-jméno.

Surname

surname

{id-at 4}

Příjmení

Serial Numbe

serialNumber

{id-at 5}

Slouží k rozlišení různých certifikovaných objektů, kterým by jinak vyšlo stejné jedinečné jméno.  Je doporučen používat  u kvalifikovaných certifikátů.

Country

C

countryName

{id-at 6}

Stát podle ISO 3166, tj. podle stejné normy, jaká se používá pro top level domény DNS (CZ=Česká republika, SK=Slovensko, FJ=Fidži...)

Locality

L

localityName

{id-at 7}

Místo (např. město)

State or Province

SP

stateOrProvinceName

{id-at 8}

Nižší organizační jednotka státu. Např. spolková země.

Organization

O

organizationName

{id-at 10}

Název firmy

Organization Unit

OU

organizationUnitName

{id-at 11}

Název části firmy

Title

title

{id-at 12}

Titul

Postal Adres

postalAdress

{id-at 16}

Poštovní adresa

Name

name

{id-at 41}

Jméno

Given Name

givenName

{id-at 42}

Rodné jméno

Initilas

initials

{id-at 43}

Iniciály

Generation Qualifier

generationQualifier

{id-at 44}

Např. „Jr.“ či „IV“ pro Karel IV

DNQualifier

dnQualifier

{id-at 46}

Slouží k rozlišení různých certifikovaných objektů, kterým by jinak vycházel stejný předmět.

E-mail Address

E

emailAddress či

pkcs9mail

{pkcs-9 1}

Adresa elektronické pošty (dle RFC-822).

Domain Component

DC

domainComponent

{0 9 2342 19200300 100 1 25}

Jednotlivé řetězce z DNS jména. Např. info.pvt.net je

DC=info, DC=pvt, DC=net

 

 

Rozdíl mezi DNQualifier a SerialNuber já spatřuji v tom, že atributem DNQualifier rozlišujeme osoby, které by měly shodou okolností jinak stejný předmět. Kdežto atributem SerialNumber můžeme rozlišit dva certifikáty téže osoby. Např. má-li osoba vydány dva podepisovací certifikáty  jiné bezpečnostní úrovně: jeden má soukromý klíč např. na disku a druhý na čipové kartě.

 

Norma X.509v3 však definuje podstatně více atributů – např.: Street Address, House Address, Postal Code, Telephone Number, Teletex Number, Teletex Terminal Identifier, Facsimile Telephone Number, X.121 Address, Internation ISDN Number, Registered Address, Destination Indicator, Prefferd Delivery Method, Description, Sear Guide, Enhanced Search Guide, OSI Application Attrribute, Distinguished Name, Member, Unique Member, Owner, Role Occupant atd. 

8.1.6                      Identifikační údaje CA (vystavitel certifikátu) - Issuer

Položka issuer, česky vystavitel či vydavatel certifikátu, obsahuje jedinečné jméno certifikační autority, které je jako celek též identifikací certifikační autority jako takové. Je třeba, aby certifikační autorita měla jednoznačnou identifikaci (jedinečné jméno) v rámci všech certifikačních autorit

 

Položka issuer – jedinečné jméno certifikační autority – je tvořena kombinací atributů relativních jedinečných jmen. Musí být podporovány následující atributy: country, organization, organizationUnit, dnQualifier,  stateOrProvinceName, commonName a podpora domainComponent. Programy by měly být dále podporovány atributy: locality, title, surname, givenName, initials, a generationQualifier.

8.1.7                      Identifikační údaje uživatele (předmět certifikátu) - subject

Položka subject certifikátu se do češtiny překládá jako předmět certifikátu. Tato položka obsahuje jedinečné jméno objektu, kterému je certifikát vydán.

 

Předmět certifikátu musí být jedinečný v rámci všech objektů certifikovaných danou certifikační autoritou. V případě, že pro dva různé objekty by vycházel stejný předmět, pak se pro rozlišení objektů použije atribut DNQualifier (v případě kvalifikovaných certifikátů použijeme atribut serialNumber).

 

Důležité je, že pro stejný objekt může tatáž certifikační autorita vydat i několik různých certifikátů, které mají stejný předmět (stejné jedinečné jméno). Tj. Václav Vopička může mít více různých certifikátů se stejným předmětem, protože se jedná o stejného Václava Vopičku. Ale jeho jmenovec, který se jen shodou okolností také jmenuje Václav Vopička, musí mít jiný předmět. Může mít např. jinou  lokalitu (město), ale kdyby i všechny ostatní údaje byly stejné, pak CA použije k rozlišení jedinečné jméno dnQualifier či jedinečné jméno serialNumber u kvalifikovaných certifikátů (nezaměňovat s číslem certifikátu – to musí být v každém případě různé).

 

V předmětu certifikátu zpravidla využíváme širší paletu atributů jedinečných jmen než u jedinečného jména vystavitele, kde bychom měli být střídmí, i když software má podporovat nejrůznější atributy.

 

8.1.8                      Veřejný klíč

Ztráta soukromého klíče k šifrovacímu certifikátu způsobí, že zašifrované zprávy se stanou nedostupné. Proto soukromý klíč k šifrovacím certifikátům si uživatelé často nechávají archivovat na CA (může být poslán jako součást žádosti o certifikát – viz protokoly CRMF, CMP a CMC). Za absurdní považuji používat soukromý klíč šifrovacích certifikátů na čipových kartách, u kterých soukromý klíč nikdy neopouští kartu. V případě ztráty karty se pak dostaneme do nemilé situace.

 

Mnozí ovšem považují za rizko předávat soukromý šifrovací klíč certifikační autoritě. Je to vždy na zvážení rizik. Já si ale dovedu představit, že bych si skladovat např. dvacet let dozadu čipové karty se starými klíči. V případě, že je pro nás rizikové ukládat soukromé šifrovací klíče na certifikační autoritě, pak je asi výhodnější ukládat dokumenty do šifrovaného archivu, který používá šifrovací klíč archivu.

 

Zásadně je třeba ale upozornit, že soukromý klíč podepisovacích certifikátů naopak nikdy (opakuji nikdy) nedáváme z ruky či si jej nenecháváme generovat cizím zařízením (např. na registrační autoritě).

 

Ztráta (nikoliv zcizení) podepisovacího soukromého klíče není nic katastrofického – stačí vygenerovat novou dvojici veřejný/soukromý klíč a nechat si vydat nový certifikát.

 

Je naprosto absurdní si nechat generovat podepisovací dvojici veřejný/soukromý klíč v cizím zařízení. Elektronický podpis stojí a padá s tím, že se jiné osobně nedostane do ruky váš soukromý klíč. Pokud někdo argumentuje, že se nemusíte bát, že u něj si klidně můžete vygenerovat dvojici klíčů pro elektronický podpis, protože on má zařízení splňující maximální bezpečností kriteria (např. FIPS 140-3), pak tato kriteria splňuje pouze jeho zařízení – nikoliv on jako člověk. A kdo ví, jestli by vám generoval dvojici opravdu na deklarovaném zařízení nebo v krabici, která pouze vypadá jako deklarované zařízení a při generaci zcizí váš soukromý klíč… .

 

8.1.9                      Rozšíření certifikátu

To, co se nevešlo do předchozích položek certifikátu, se snažíme uložit do některého z rozšíření.

 

Nejčastěji používaná rozšíření:

Rozšíření

Označení

OID (extnID)

Identifikátor klíče certifikační autority

id-ce-AuthorityKeyIdentifier

{id-ce 35}

Identifikátor klíče předmětu

id-ce-SubjectKeyIdentifier

{id-ce 14}

Doba platnosti soukromého klíče

id-ce-PrivateKeyUsagePeriod

{id-ce 16}

Použití klíče

id-ce-keyUsage

{id-ce 15}

Rozšířené použití klíče

id-ce-extKeyUsage

{id-ce 37}

Alternativní jméno předmětu

id-ce-subjectAltName

{id-ce 17}

Alternativní jméno vydavatele

id-ce-issuerAltName

{id-ce 18}

Certifikační politiky

id-ce-certificatePolicies

{id-ce 32}

 

id-ce-policyMappings

{id-ce 33}

 

id-ce-policyConstraints

{id-ce 36}

Základní omezení

id-ce-basicConstraints

{id-ce 19}

Omezení jména

id-ce-nameConstraints

{id-ce 30}

Distribuční místa odvolaných certifikátů

id-ce-cRLDistributionPoints

{id-ce 31 }

 

id-ce-subjectDirectoryAttributes

{id-ce 9 }

 

 

Identifikátor klíče certifikační autority – Authority Key Identifier

Toto rozšíření slouží k identifikaci klíče certifikační autority, kterým byl certifikát podepsán. To je důležité zejména v případě, že certifikační autorita má více dvojic veřejný/soukromý klíč. Pokud vám připadá zbytečné, aby certifikační autorita měla více dvojic klíčů, tak jste si jen neuvědomili, že i certifikát certifikační autority má  svou dobu platnosti. Tj. i certifikáty certifikačních autorit je třeba obnovovat. Navíc certifikační autorita musí vydat svůj nový certifikát nejméně tak dlouho před vypršením svého starého certifikátu, na jak dlouho vydává certifikáty svým uživatelům (resp. podřízeným CA). CA nemůže totiž vydat uživateli certifikát podepsaný klíčem CA, který by v době platnosti vydaného certifikátu vypršel. Tj. nastala by situace, že uživatel má sice platný certifikát, který je však podepsán neplatným (expirovaným) certifikátem.

 

Obr. 8-6 Otazníkem je vyznačená doba, po kterou platí dva certifikáty CA. Pro ověření 2. certifikátu uživatele je nutný veřejný klíč ze starého certifikátu CA a pro ověření 3. certifikátu uživatele je třeba veřejný klíč z nového certifikátu CA. Jelikož položka issuer ve všech certifikátech uživatele může být stejná, tak právě identifikátor klíče certifikační autority určuje, který z certifikátů CA je nutný pro ověření certifikátu uživatele.

 

CA tak poměrně dlouhou dobu má dva certifikáty, které se překrývají. Někteří uživatelé mají svůj certifikát podepsán „starým“ certifikátem CA a jiní „novým“ certifikátem CA. Oba certifikáty CA budou mít stejný předmět. Budou se lišit sériovým číslem a veřejným klíčem. V certifikátu uživatele je však v položce vydavatel (issuer) uveden pouze předmět z certifikátu CA, kterým je certifikát uživatele podepsán. Jenže jak sestavit řetězec certifikátu, když máme dva certifikáty certifikační autority se stejným polem předmět? Pro identifikaci je možné použít sériové číslo či samotný veřejný klíč z certifikátu, ale použití rozšíření „Identifikátor rozšíření veřejného klíče CA“ je podstatně jednodušší.

 

Příkladem je situace na obr. 8-6. Certifikační autorita vystavuje svým uživatelům certifikáty platné nejvýše 1,5 roku. Sama CA si vydává certifikáty CA platné 4 roky. Proto 1,5 roku před vypršením svého certifikátu si musí vydat nový certifikát. Pokud by např. 1 rok před vypršením certifikátu CA vydala uživateli certifikát podepsaný soukromým klíčem příslušejícím ke starému certifikátu, pak by v posledním 0,5 roce platnosti takto vydaného uživatelského certifikátu byla potíž s ověřováním certifikátu: certifikát uživatele by byl platný, ale při ověřování tohoto certifikátu by se narazilo na to, že již není platný příslušný certifikát CA.

 

V době označené na obr. 8-6 otazníkem jsou platné dva certifikáty CA. 2. uživatelův certifikát je podepsán starým certifikátem CA a 3. uživatelův certifikát novým certifikátem CA. Přitom ve 2. i 3. certifikátu je uvedena stejná CA. Jak má tedy software poznat, kterým certifikátem CA má ověřovat 2. a kterým 3. uživatelův certifikát?

 

Tj. pro ověření certifikátu je třeba vytvořit řetězec certifikátů až ke kořenovému certifikátu. Pro usnadnění tvorby tohoto řetězce certifikátů slouží rozšíření identifikátor klíče certifikační autority.

 

Identifikátor klíče certifikační autority, která certifikát vydala, je ve své podstatě rozšířením pole vystavitel certifikátu (issuer) o identifikaci klíče. Zatímco v poli vystavitel certifikátu je pouze předmět certifikátu, jehož příslušným soukromým klíčem byl certifikát vydán, tak v rozšíření „identifikátor klíče CA“ může být navíc i sériové číslo certifikátu, jehož příslušným soukromým klíčem byl certifikát  podepsán. Tj. snadno lze pak vytvářet řetězce certifikátů pro ověření cerifikátu.

 

 

Identifikátor klíče předmětu – Subject Key Identifier

Jedná se o identifikátor veřejného klíče uživatele. Uživatel si může vygenerovat dvojici veřejný/soukromý klíč a veřejný klíč pak vložit do žádosti o certifikát. Žádost o certifikát může uplatnit i u více CA, tj. z jedné dvojice veřejný/soukromý klíč si uživatel nechá vydat více certifikátů.

 

Rozšíření „identifikátor klíče předmětu“ identifikuje veřejný klíč uživatele. V případě, že se jedná o certifikát CA, pak identifikátor klíče předmětu musí být shodný s položkou keyIdentifier rozšíření „identifikátor klíče CA“.

 

 

Použití klíče – Key Usage

Pomocí tohoto rozšíření lze omezit způsob použití veřejného klíče obsaženého v certifikátu (resp. jemu příslušejícího soukromého klíče). Toto rozšíření obsahuje bitový řetězec. Každý bit z řetězce pak odpovídá konkrétnímu způsobu použití certifikátu. Je-li příslušný bit nastaven na jedničku, pak je certifikát k danému použití možné používat.  Rozšíření se označí jako kritické, čímž se zamezí použití certifikátu k jiným účelům než k účelům vyznačeným v certifikátu.

 

Význam jednotlivých bitů:

 

Rozšířené použití klíče

Je obecnějším řešením pro určení účelů, k jakým je certifikát určen. Toto rozšíření může obsahovat sekvenci identifikátorů objektů. Tyto identifikátory objektů pak specifikují způsoby použití klíče.

 

Alternativní jméno předmětu - Subject Alternative Name

Toto rozšíření umožňuje vložit do certifikátu další identifikační údaje, které se nevešly do předmětu. Při vydávání certifikátu nesmí být opomenuta kontrola i údajů uvedených v tomto rozšíření.

 

Uvedeno zde mj. může být:

 

 

 

Certifikační politiky - Certificate Policies

Certifikační politika je skupina dokumentů vydaných certifikační autoritou. V těchto dokumentech jsou popsány postupy, praktiky a cíle CA. Tj. pravidla, za kterých CA vydává certifikáty, a zejména jak za vydané certifikáty ručí.  Na rozdíl o některých jiných dokumentů CA  je certifikační politika veřejným dokumentem.

 

MS Explorer používá místo „Certifikační politika“ název „Certifikační zásady“.

 

Provozovatel CA si zpravidla zaregistruje identifikátor objektu pro své dokumenty. Identifikátory objektu certifikační politiky se pak uvádí v rozšíření certifikátu nazývaném „Certifikační politika“.  Jestliže je toto rozšíření označeno jako kritické, pak software ověřující certifikát může certifikát akceptovat jedině v případě, že je schopen interpretovat toto rozšíření včetně jeho parametrů. Jinými slovy: musí pro něj být akceptovatelná uvedená certifikační politika.

 

 

 

Základní omezení  - Basic Constraints  

Obr. 8-7 Uživatel 3 se prohlásil za certifikační autoritu

Jádrem činnosti CA je to, že svým podpisem ručí za údaje uvedené ve vydaných certifikátech. Na obr. 8-7 je znázorněno nebezpečí pro CA spočívající v tom, že CA vydává certifikáty svým uživatelům a najednou uživatel 3 se svévolně prohlásí za CA a vydá certifikáty uživatelům X a Y. Problém je v tom, že CA ručí za takto vydané certifikáty uživatelů X a Y díky tomu, že např. uživatel X dostane řetězec certifikátů obsahující: certifikát uživatele X, certifikát uživatele 3 a certifikát CA. Čili není problém ověřit platnost takového certifikátu (tj. zodpovědnost CA za takto vydaný certifikát).

 

Jeden mechanismus, jak takovémuto počínání uživatele zamezit, jsme již popsali – pomocí rozšíření „Použití klíče“, kterým v certifikátech vydávaných uživatelům jejich klíč neoznačíme, že je jej možné používat k verifikaci certifikátů.

 

Rozšíření „Základní omezení“ umožňuje označit certifikát, aby bylo zřejmé, zdali se jedná o certifikát CA nebo koncového uživatele, nastavením položky cA (je-li nastavena na TRUE, pak se jedná o certifikát CA).  Pomocí položky pathLenConstraint pak sdělíme, kolik může v certifikační cestě následovat certifikátů certifikačních autorit pod tímto certifikátem. Např. je-li tato položka nastavena na nulu, pak se pod tímto certifikátem certifikační autority může v certifikační cestě vyskytovat pouze certifikát koncového uživatele (nikoliv certifikát CA).

 

Omezení jména – Name Constrains

Toto rozšíření může být též použito pouze v certifikátech CA. Certifikát CA  se tímto omezením omezuje jen pro certifikáty uživatelů splňující v certifikátu uvedené podmínky pro jedinečná jména či alternativní jména uvedená v tomto rozšíření.

 

Omezovat lze např. na DNS jména patřící do domény .firma.cz. Či lze omezovat jména poštovních schránek na poštovní adresy patřící určité doméně. Lze omezovat i IP-adresy apod.

 

 

Distribuční místa odvolaných certifikátů – CRL Distribution points

Toto rozšíření obsahuje sekvenci URI, na kterých je vystaven seznam odvolaných certifikátů (CRL).

 

8.2                 Kvalifikované certifikáty

Kvalifikovaný certifikát je zvláštní typ certifikátu, které používá Evropská unie ve své legislativě. Zvláštní není ani svou syntaxí (ta je ve své podstatě podmnožinou certifikátu popsaného v předchozí kapitole, tj. certifikátu dle RFC-2459). Zvláštnost je v právní oblasti. Cílem kvalifikovaného certifikátu je i po právní stránce nahradit rukou psaný podpis elektronickým podpisem. Jádro myšlenek ohledně kvalifikovaných  certifikátů je uvedeno v RFC-3039. Je to snad jediné RFC, které vychází z Evropských zkušeností a pokouší se je celosvětově zobecnit. V Česku je použití kvalifikovaných certifikátů vymezeno zákonem o elektronickém podpisu. 

 

Kvalifikovaný certifikát se vydává konkrétnímu člověku (nikoliv např. serveru). Kvalifikovaný certifikát obsahuje identifikaci držitele certifikátu založenou na oficiální identifikaci člověka nebo na jeho pseudonymu. Certifikační autorita vždy zná konkrétní osobu, které certifikát vydala.

 

Předmět certifikátu musí být jednoznačný pro konkrétní osobu, tj. dvě různé osoby nemohou mít vydán certifikát se shodným předmětem. Tato podmínka musí být splněna po celou dobu existence konkrétní CA. Pro docílení této podmínky je možné použít atribut serialNumer (nezaměňovat s položkou sériové číslo certifikátu). Kdyby dvě osoby mely mít stejné předměty, pak se odliší hodnotou v položce serialNumer.

 

U kvalifikovaných certifikátů nestačí, aby byl pouze předmět jednoznačný pro konkrétní osobu, ale certifikační autorita nesmí vydat dvěma různým osobám certifikát, který by měl stejný veřejný klíč. Tj. certifikační autorita musí po dobu své existence archivovat i veřejné klíče, které uživatelům podepsala. U veřejných klíčů musí mít i informaci pro jaké algoritmy se budou používat, aby mohla porovnávat klíče, zdali již nejsou použité. Otázkou je, co udělat, když CA obdrží žádost o certifikát s veřejným klíčem tč. platného certifikátu. Asi by měl být  platný certifikát odvolán z iniciativy CA a žádost zamítnuta.

 

Podle zákona o elektronickém  podpisu je nutné, aby byly kvalifikované certifikáty používané pro styk se státní správou vydávány státem akreditovaným certifikačními autoritami. 

 

RFC-3039 určujeatributy položek vydavatele certifikátu, předmět certifikátu a jaká rozšíření mohou být použita v kvalifikovaném certifikátu.

8.2.1                      Identifikační údaje CA – issuer

Položka identifikační údaje CA (issuer) může být libovolnou kombinací atributů:

§         countryName,

§         stateOrProvinceName,

§         organizationName,

§         localityName,

§         serialNumber – slouží pro rozlišení dvou CA, které by jinak měly identické identifikační údaje. Nesmí se zaměňovat se sériovým číslem certifikátu.

§         domainComponent – jednotlivé řetězce z DNS jména. Tento atribut je jako identifikační údaj CA asi málo paktický.

 

Atribut serialNumber není uveden v RFC-2459. Tam se pro podobný účel používá atribut DNQualifier.

8.2.2                      Identifikační údaje uživatele (předmět certifikátu)

Předmět certifikátu (subject) může být kombinací následujících atributů:

§         countryName – váže se na občanství či místo pobytu držitele certifikátu

§         commonName

§         surname

§         givenName

§         pseudonym

§         serialNumber

§         organizationName

§         organizationalUnitName;

§         stateOrProvinceName

§         localityName

§         postalAddress.

 

V příloze k normě RFC-3039 jsou pak ještě zmíněny atributy: pkcs9mail a dnQualifier.

 

Kvalifikovaný certifikát musí obsahovat vždy alespoň jeden z atributů: commonName, givenName nebo pseudonym.

 

Atribut serialNumber není uveden v RFC-2459. V RFC-2459 se pro podobný účel používá atribut DNQualifier, který je rovněž uveden v dodatku k RFC-3039. Tj. pravděpodobně by se u kvalifikovaných certifikátů měl pro jednoznačnou identifikaci předmětu certifikátu používat atribut serialNuber a u ostatních certifikátu by se měla dát přednost atributu DNQualifier.

 

 

8.2.3                      Požadavky na standardní rozšíření certifikátu

Standardními rozšířeními certifikátu rozumíme rozšíření zavedená v RFC-2459.

 

Subject directory attributes

Pro kvalifikované certifikáty se zavádí atributy pro rozšíření „Subject directory attributes“. Jedná se o další osobní údaje o držiteli certifikátu“.

 

Identifikátor / zkratka

Atribut

OID

Význam

Title

title

{id-at 12}

Titul

Date of Birth

dateOfBirth

{id-pda 1}

Datum narození

Place of Birth

PlaceOfBirth

{id-pda 2}

Místo narození

Gender

Gender

{id-pda 3}

Pohlaví (M=muž, F=žena)

Country of Citizenship

contryOfCitizenship

{id-pda 4}

Občanství

Country of Residence

countryOfResidence

{id-pda 5}

Zemně pobytu

 

 

 

 

 

 

 

 

 

 

Použití klíče

Toto rozšíření musí být u kvalifikovaných certifikátů označeno jako kritické a mělo by být v certifikátu vždy přítomno.

 

Jestliže je v tomto rozšíření nastaven bit nonRepudation, pak nesmí být nastaven žádný jiný bit. Tj. je snaha, aby jiným použitím páru veřejný/soukromý klíč nemohlo dojít k poškození uživatele.

 

Já si to vysvětluji následovně. Na obr. 4-4 jsme si vysvětlili, jak se používá elektronický podpis k autentizaci klienta. Kdyby byl policista falešný, pak by mohl místo náhodného čísla vygenerovat např. platební příkaz klienta ve svůj prospěch (obr 8-9).

 

Obr 8-9 Použitím soukromého klíče pro autentizaci by mohlo dojít k nechtěnému podpisu v neprospěch uživatele.

Jinými slovy je předepsáno: pokud se vystavuje certifikát pro ověřování podpisu, pak je třeba zamezit tomu, aby tento certifikát bylo možné použít k něčemu jinému, přičemž by uživatel digitálně podepsal něco, co např. vůbec nevidí.

Prakticky to znamená, že by měl mít člověk tři certifikáty: podepisovací, identifikační a šifrovací. Přitom podepisovací by měl být v každém případě kvalifikovaným certifikátem. Proč nesloučit identifikační a šifrovací certifikát? To je čistě z praktických důvodů. Soukromý klíč od šifrovacího certifikátu je praktické zálohovat na CA, kdežto u identifikačního certifikátu to zase není dobré. Identifikační certifikát může také používat úplně jiný algoritmus, než šifrovací certifikát. Např. algoritmus DSA je použitelný pro podepisování i identifikaci, ale nikoli pro šifrování.

 

Pokud budeme používat čipové karty, které generují samy dvojicí klíčů, pak je asi praktické mít jednu podepisovací kartu a druhou identifikační. Soukromý klíč k šifrovacímu certifikátu pak můžeme uložit zašifrován v souborovém systému identifikační karty. Prostě identifikační kartu použijeme jen jako nosič (při nošení v kapse je odolnější než disketa).

8.2.4                      Nově zavedená rozšíření

Norma RFC-3039 zavádí dvě rozšíření, která mají podle mne praktický význam jen pro kvalifikované certifikáty. Jedná se o rozšíření „Biometrické informace“ a o rozšíření „Příznaky kvalifikace certifikátu“.

 

Rozšíření

Označení

OID (extnID)

Biometrické informace

id-pe-biometricInfo

{id-pe 2}

Příznaky kvalifikace certifikátu

id-pe-qcStatements

{id-pe 3}

 

 

Biometrické informace

V certifikátu nejsou uloženy samotné biometrické vlastnosti držitele certifikátu, ale pouze kontrolní součty z příslušných biometrických vlastností. U příslušného kontrolního součtu může být uvedeno URI, na kterém je celá biometrická vlastnost kompletně k dispozici.

 

Toto rozšíření  obsahuje sekvenci kontrolních součtů jednotlivých biometrických vlastností držitele certifikátu. 

 

Tč. jsou definovány dvě biometrické vlastnosti:

-         Obrázek držitele certifikátu

-         Nasnímaný obrázek rukou psaného podpisu držitele certifikátu.

 

Příznaky kvalifikace certifikátu

Toto rozšíření by mělo vyjadřovat, že se jedná o kvalifikovaný certifikát. Rozšíření obsahuje sekvenci příznaků kvalifikace certifikátu.

 

Každý příznak se skládá z identifikátoru objektu a parametrů definovaných při zavedení tohoto identifikátoru objektů. RFC-3039 zavádí pouze jeden příznak, a to příznak pro identifikaci registrační autority. Další příznaky by měl zavést zákon (resp. související vyhlášky) země, ve které se kvalifikované certifikáty vydávají.

 

8.3                 Žádost o odvolání certifikátu

Představte si situaci, kdy přijdete o soukromý klíč nebo se vám podaří soukromý klíč vyzradit. Pak je třeba příslušný certifikát odvolat.

 

Při odvolávání certifikátu nejde o to, postupovat podle nějakých norem, ale jde především o rychlost. Pokud soukromý klíč máte, pak pošlete žádost o odvolání certifikátu na CA např. elektronickou poštou. Zprávu elektronické pošty podepíšete soukromým klíčem příslušejícím odvolávanému certifikátu. Jenže to stejně nejde, pokud není certifikát k takovémuto podpisu určen.

 

Pokud o soukromý klíč přijdete nebo certifikát není určen pro ověřování elektronického podpisu, pak elektronické cesty selhávají.

 

Některé CA při vydání certifikátu pro takové případy vystaví jednorázové heslo pro odvolání certifikátu. Pokud toto heslo znáte, pak lze odvolat certifikát telefonicky, faxem nebo nepodepsanou elektronickou poštou s uvedením zmíněného jednorázového hesla.

 

Pokud neznáte ani jednorázové heslo, pak nezbývá, než se s doklady totožnosti a smlouvou o vydání certifikátu vydat na registrační autoritu. Pokud přijdete úplně o vše, pak máte problém. V takovém případě to ale asi není ten největší problém který máte.

8.4                 Seznam odvolaných certifikátů - CRL

Certifikát může ztratit svou platnost tak, že vyprší, tj. uplyne čas notAfter uvedený v certifikátu. Druhou možností, jak může pozbýt certifikát své platnosti, je na základě žádosti držitele certifikátu či jeho zaměstnavatele (např. při rozvázání pracovního poměru) o odvolání certifikátu podané na certifikační autoritu. Třetí možností je odvolání certifikátu z iniciativy samotné CA (např. dorazí-li na CA žádost o certifikát se stejným veřejným klíčem jako má existující vydaný certifikát).

 

CA odvolaný certifikát zveřejní na seznamu odvolaných certifikátů (Certificate Revocation List - neboli CRL).

 

Mechanizmus žádosti o odvolání certifikátu zveřejňuje CA v dokumentu „Certifikační politika CA“. Žádost o odvolání certifikátu nemusí být prováděna ani elektronickou formou, ale CA může vyžadovat např. osobní účast uživatele. Pokud se provádí elektronickou cestou, pak žádost musí být elektronicky podepsána soukromým klíčem odvolávaného certifikátu (v případě, že by takou žádost provedl hacker neoprávněně, tj. uměl ji elektronicky podepsat, tj. znal soukromý klíč, pak je pro uživatele jen dobře, že ji podal). Nebo může být použito jednorázové heslo pro odvolání certifikátu.

 

CRL obsahuje sériová čísla odvolaných certifikátů (CRL může být i prázný). Odvolané certifikáty se zveřejňují v CRL až do vypršení jejich původní doby platnosti (notAfter).

 

Způsob zveřejňování CRL je opět uveden v dokumentu „Certifikační politika CA“. Může jej např. vystavovat na webovém serveru atp. V rozšíření certifikátu  „Distribuční místa odvolaných certifikátů“ jsou uvedená URI, na kterých CA dává k dispozici CRL.

 

Mechanismus CRL spočívá v tom, že CA vydává CRL zpravidla v pravidelných intervalech. V intervalu mezi vydáváním CRL schraňuje jednotlivé žádosti o odvolání certifikátu, které pak shrne do následujícího CRL. Tj. účinnost odvolání CRL není okamžitá, ale až s vydáním následujícího CRL.

 

8.4.1                      Rozšíření CRL

Rozšíření CRL jsou obdobou rozšíření certifikátu. Tato rozšíření mohou být opět označena jako kritická, pak při jejich zpracování si zpracovávající software musí být vědom, co takové kritické rozšíření znamená.

 

RFC-2459 explicitně popisuje pět rozšíření. Přitom dvě rozšíření „Identifikátor klíče certifikační autority“ a „Alternativní jméno vydavatele“ jsou shodné se stejnými rozšířeními certifikátů. Dále pak definuje rozšíření: „Číslo CRL“,  „Přírůstkové CRL“ a „Distribuční místo CRL“.

 

Rozšíření

Označení

OID (extnID)

Číslo CRL

id-ce-cRLNumber

{id-ce 20}

Přírůstkové CRL

id-ce-deltaCRLIndicator

{id-ce 27}

Identifikátor klíče certifikační autority

id-ce-AuthorityKeyIdentifier

{id-ce 35}

Alternativní jméno vydavatele

id-ce-issuerAltName

{id-ce 18}

Distribuční místo CRL

id-ce-issuingDistributionPoint

{id-ce 28}

 

Číslo CRL

Certifikační autorita pomocí tohoto rozšíření čísluje vydávané CRL. Číslování musí vzrůstat vždy právě po jedné, aby uživatel mohl zjistit, že mu nějaké CRL neschází.

 

Toto rozšíření se neoznačuje jako kritické.

 

8.4.2                      Rozšíření položky CRL

Kromě samotného odvolání certifikátu mohou být zajímavé i další informace související s tímto odvoláním. Tyto informace mohou obsahovat rozšíření položky CRL. Tato rozšíření by neměla být označována jako kritická.

 

Rozšíření

Označení

OID (extnID)

Důvod odvolání certifikátu

id-ce-cRLReason

{id-ce 21}

Instrukce pro případ odvolání certifikátu

id-ce-holdInstructionCode

{id-ce 23}

Datum a čas kompromitace soukromého klíče

id-ce-invalidityDate

{id-ce 24}

Vydavatel certifikátu

id-ce-certificateIssuer

{id-ce 19}

 

Datum a čas kompromitace soukromého klíče

Toto rozšíření obsahuje datum a čas, kdy byla zjištěna ztráta či prozrazení soukromého klíče, jež je důvodem odvolání certifikátu.

 

Vydavatel certifikátu

Toto rozšíření se používá u nepřímých CRL. V nepřímém CRL mohou být odvolávány i certifikáty vydané jinými CA. V takovém případě je nutné pro identifikaci certifikátu znát nejenom sériové číslo certifikátu, ale i jméno vydavatele certifikátu (issuer). Právě tato informace je obsažena v rozšíření „Vydavatel certifikátu“.

 

Při obnovování certifikátu certifikační autority, která používá certifikát podepsaný vlastním veřejným klíčem, by měl být nejenom předmět a vystavitel identický, ale obojí by mělo být identické i v řadě následných certifikátů. Tj. následný certifikát má stejný předmět jako starý certifikát. Někdy to není možné z právních důvodů zajistit (následný certifikát CA má odlišný předmět od starého certifikátu CA). V takovém případě se může drobně lišit vydavatel odvolávaného certifikátu (tj. jméno vydavatele ve starém certifikátu CA) a vydavatel certifikátů, kterým je podepsáno CRL (tj. nové jméno vydavatele), protože CRL je společné pro všechny certifikáty CA. Tato situace je příležitostí právě pro rozšíření „Vydavatel certifikátu“.

 

8.5                 On Line zjišťování platnosti certifikátu - OCSP

V případě, že držitel certifikátu zjistí, že jeho soukromý klíč byl ztracen nebo odcizen, pak mechanismus CRL mu nebude příliš vyhovovat, protože do vydání dalšího CRL může být jeho soukromý klíč zneužit.

 

Pokud uživatel používá certifikát primárně pouze v jedné aplikaci (např. při styku s bankou), pak nejspíše okamžitě kontaktuje provozovatele této aplikace a certifikát si nechá zablokovat v této aplikaci. V tomto případě snad ani CRL nepotřebuje.

 

Jenže pokud uživatel používá certifikát k více účelům, pak takovou službu vyžaduje od CA. Tuto problematiku řeší protokol OCSP (Online Certificate Status Protocol).

 

Protokol OCSP je protokol typu klient/server. Klient pošle na OCSP server dotaz obsahující identifikaci certifikátu a OCSP server vrátí informaci o tom, zda-li je certifikát odvolán či nikoliv, nebo vrátí odpověď, že mu tato informace není známa či nějakou chybovou hlášku. V případě, že byl odvolán certifikát CA, pak OCSP server odpovídá na všechny dotazy na platnost certifikátů touto CA vydaných informací, že jsou neplatné.

 

Ve své podstatě protokol OCSP může být užitečný i v případě, že CRL obsahují příliš velké množství odvolaných certifikátů. Pak při každé manipulaci s certifikátem by procházení tak rozsáhlého CRL zabralo příliš mnoho času – kdežto protokol OCSP na jednoduchý dotaz vrátí jednoduchý výsledek. Problém vyhledání certifikátu v CRL se tak přesouvá na server, který ho může umět řešit mnohem efektivněji.

 

OCSP server může provozovat samotná CA, pak odpovědi OCSP serveru jsou podepsány klíčem samotné CA. CA však může delegovat svou pravomoc na jiný server. Pak vydá tomuto serveru certifikát s rozšířením „Rozšířené použití klíče“ obsahující objekt id-kp-OCSPSigning.

 

Poslední možností je, že certifikát OCSP serveru není ani certifikát CA, jež dotazovaný certifikát vydala, ani neobsahuje zmíněné rozšíření, pak v lokální konfiguraci OCSP klienta musí být tento certifikát explicitně uveden. Tuto možnost lze použít i v intranetu, odkud není přímé spojení na oficiální OCSP servery.

 

Naopak uživatelský certifikát může obsahovat privátní rozšíření „Přístupové informace CA“ s objektem id-ad-ocsp specifikující např. URI, na kterém běží OCSP server.

8.6                 Žádost o certifikát tvaru PKCS#10

Uživatel žádá CA o vydání certifikátu pomocí žádosti o certifikát. V Internetu máme tři normy specifikující žádost o certifikát:

 

V této kapitole se budeme zabývat druhým případem, tj. žádostí podle normy PKCS#10, která byla převzata jako RFC-2314. Formát této žádosti o certifikát je ve své podstatě jakoby certifikátem vydaný samotným žadatelem, tj. podepsán soukromým klíčem žadatele. Pochopitelně některé položky certifikátu v této žádosti být nemohou (serialNumber, signature, issuer apod.), protože je určuje až CA. 

 

Žádost je podepsána soukromým klíčem, který přísluší k veřejnému klíči uvedenému v žádosti. Jedná se tedy o důkaz, že žadatel vlastní příslušný soukromý klíč. Tj. pokud žádáme o následný certifikát a chtěli bychom použít elektronický podpis starým klíčem jako identifikaci žadatele, pak je nutné žádost PKCS#10 vložit např. do zprávy CMS obsahující tento druhý elektronický podpis. Pokud bychom přímo v žádosti PKCS#10 vytvořili podpis starým klíčem, pak bychom přišli o důkaz vlastnictví nového soukromého klíče.

 

Elektronický podpis žádosti je bohužel ale také důvod, proč se tento formát žádost nehodí pro žádosti o certifikáty, které nebudou určeny pro certifikáty určené k ověřování elektronického podpisu. Asi si říkáte, proč takové komplikace s šifrovacími certifikáty. Ať to prostě uživatel podepíše a hotovo, a pak ať si ten certifikát používá jen pro šifrování. Jenže u CRMF žádostí o certifikát se dozvíme, že pokud žádáme o Diffie-Hellmanův certifikát, tak prostě ze soukromého DH čísla elektronický podpis neuděláme, ať se budeme sebevíc snažit. Navíc pomocí CRMF žádostí se bude žádat i o certifikát, jehož dvojici soukromý/veřejný klíč bude generovat CA až po obdržení žádosti o certifikát (pro šifrovací certifikáty). Takže sama žádost veřejný klíč ani neobsahuje a uživatel při tvorbě žádosti žádný soukromý klíč k dispozici nemá, takže elektronický podpis vyrobit nemůže. Ale nepředbíhejme, vraťme se k žádostem PKCS#10.

 

Žádosti nepodepsané soukromým klíčem žadatele RA zpravidla neakceptuje.

 

RA přijme žádost a verifikuje její obsah pomocí veřejného klíče uvedeného v žádosti, tím ověří, nebyly-li údaje v žádosti cestou změněny. Verifikovanou žádost o certifikát předá RA certifikační autoritě ke zpracování. RFC-2314 nespecifikuje formát, v jakém RA předává ověřenou  žádost CA. Touto problematikou se zabývají až protokoly CMP a CMC.

 

8.7                 Žádost o certifikát tvaru CRMF

Žádost o certifikát tvaru CRMF  (Certificate Request Message Format)  je podstatně bohatší než žádost PKCS#10. Řeší totiž některé problémy, se kterými žádost PKCS#10 nedokáže vyrovnat. Žádost PKCS#10 je digitálně podepsána soukromým klíčem příslušejícím veřejnému klíči v žádosti. Jenže co si počít v případě, že certifikát nemá být používán pro elektronický podpis? V takovém případě je nekorektní použít elektronický podpis, byť jen v žádosti o certifikát.

 

Žádost tvaru CRMF umožňuje jako součást žádosti zaslat i účtovací informace.

 

 

8.8                 Protokol CMP

Protokol CMP (Certificate Management Protocol) je protokolem určeným pro vydávání a správu certifikátů. Není však jediným protokolem tohoto druhu v PKI. Později se zmíníme i o novějším protokolu CMC.

 

Asi si řeknete: k čemu vlastně je ten protokol CMP třeba? Popsali jsme si dokonce dva tvary žádosti o certifikát. Na obr. 8-10 je však vidět, že např. takové vydání certifikátu je docela složitá komunikace. Klient nejprve odešle žádost o certifikát na RA. Pokud klient s RA komunikuje elektronicky, pak RA může zpětným dotazem prověřit, zda-li klient opravdu vlastní příslušný soukromý klíč (resp. RA autentizuje uživatele). V případě, že prověření vlastnictví soukromého klíče i autentizace proběhnou dobře, pak teprve RA předá žádost o certifikát CA, která vydá příslušný certifikát (nebo také nevydá a vrátí chybovou hlášku). CA zašle RA vydaný certifikát. RA potvrdí přijetí certifikátu a zašle vydaný certifikát uživateli, který příjem potvrdí RA.

 

Takže vlastní žádost o vydání certifikátu a certifikát jsou z hlediska protokolu CMP jen černé skříňky, jejichž přenos protokol CMP zajišťuje. Kromě vydání certifikátu protokol CMP zajišťuje i odvolání certifikátu, obnovení certifikátu, předání CRL, křížovou certifikaci mezi CA atd.

  

 

Obr. 8-10 Protokol CMP: vydání certifikátu

Paket protokolu CMP (obr. 8-11) se skládá ze záhlaví, těla zprávy, ochrany a případných dalších certifikátů, které mohou být užitečné příjemci (např. certifikáty CA, které slouží pro verifikaci vydaného certifikátu).

 

Obr.  8-11 Paket protokolu CMP

8.9                 PKCS#7 a CMS

Už jsme si ukázali, jak se certifikát vydá, jak se odvolá atd. Nyní přistoupíme k tomu nejdůležitějšímu, a to jak certifikát použít. V Internetu se nejspíše setkáme se čtyřmi způsoby:

 

Jelikož tato kapitola pojednává o PKI, tak se budeme věnovat PKCS#7 a CMS. Protokolům SSL a TLS je věnována samostatná kapitola; rovněž problematice IPsec je také věnována samostatná kapitola.

 

Takže nyní k zabezpečeným zprávám PKCS#7 a CMS. Pojmem je protokol PKCS#7, který zavedla firma RSA. Je to podobný pojem jako Lux pro vysavače či IBM PC pro osobní počítače.

 

Protokol PKCS#7 byl přejat jako RFC pod označením RFC-2315. Avšak postupně i v této oblasti došlo k některým úpravám, a tak vyšla norma RFC-2630: Cryptographic Message Standard – CMS. Takže postupně přecházíme na protokol CMS, ale stále často mluvíme o PKCS#7, a přitom bychom měli mluvit o CMS.

 

Protokol CMS se snaží být maximálně zpětně kompatibilní s protokolem PKCS#7.

 

Obr. 8-15 PKCS#7 může data zpracovávat cyklem – např. je nejprve elektronicky podepsat a výsledek pak šifrovat

Protokoly PKCS#7 a CMS jsou určeny k zabezpečení dat. Jenže pod slovem zabezpečení rozumíme jak elektronický podpis, tak elektronickou obálku či autentizaci dat.

 

Zpracovávaná i zabezpečená (výsledná) data jsou vždy určena dvojicí: identifikátor objektu typu dat a vlastní data. Jak je znázorněno na obr. 8-15, tak do zpracování  PKCS#7 (resp. CMS) vstupuje jedna dvojice (např. identifikátor nezabezpečených dat, tj. „data“ + nezabezpečená data). PKCS#7 (resp. CMS) provede elektronický podpis, tj. výsledkem je dvojice identifikátor objektu pro podepsaná data + podepsaná data. Tato dvojice opět vstoupí do procesu PKCS#7 (resp. CMS) a výsledkem je dvojice identifikátor objektu pro data v elektronické obálce + elektronicky zaobálkovaná data (uvnitř elektronické obálky jsou podepsaná data).

 

Obr. 8-16 Formát zprávy PKCS#7 (resp. CMS)

Jak je znázorněno na obr. 8-16, zpráva PKCS#7 (resp. CMS) se skládá z identifikátoru objektu typu dat (contentType) a vlastních přenášených dat (content). Vlastní data jsou nepovinná. Nepovinných dat se používá zejména u elektronicky podepisovaných zpráv, a to jednak pro tzv. externí elektronický podpis a jednak pro distribuci certifikátů samotných.

 

8.9.1                      Typy dat

PKCS#7 specifikujíce následující typy obsahu zpráv:

CMS přináší následující úpravy:

 

8.9.2                      Typ zprávy „Data“

Jedná se o nejjednodušší typ, o data nešifrovaná ani nepodepisovaná – prostě řetězec bajtů. Asi si myslite: "K čemu to muže být?". Už v následující kapitole Typ zprávy „SignedData“ uvidíte, že tímto typem se specifikují původní data, která vstupují do procesu elektronického podepisování či šifrování.

8.9.3                      Typ zprávy „Signed Data“

Tento typ se používá u elektronicky podepsané zprávy. Jedna zpráva může obsahovat i více elektronických podpisů. Zajímavostí je, že tento typ zprávy může být i degenerován na případ, kdy zpráva neobsahuje žádný elektronický podpis. Tento degenerovaný případ se používá pro distribuci certifikátů a CRL, kdy nezáleží na obsahu zprávy.

 

Uvnitř podepsané zprávy je vnořena zpráva, která se podepisuje (vstupní data). Vstupní data se opět skládají z identifikátoru typu dat a vlastních dat. Další zajímavostí je, že položka vstupních dat může být prázdná. To může mít dva důvody:

1.        Může se jednat o již uvedenou degenerovanou zprávu sloužící pro distribuci certifikátů.

2.        Může se jednat o tzv. externí elektronický podpis, kdy podepisovaná data jsou přepravována mimo vlastní strukturu pro elektronický podpis. To je časté např. u elektronické pošty. U elektronické pošty pak zprávu rozdělíme na data a elektronický podpis. Příjemce, který nemá software pro zpracování elektronického podpisu, pak může alespoň první část zprávy přečíst, což je mnohdy velice praktické.

Obr. 8-17 Struktura elektronicky podepsané zprávy (Signed Data)

 

Formát elektronický podepsané zprávy je znázorněn na obr. 8-17. Význam jednotlivých položek je následující:

          eContentType ContentType,

          eContent [0] EXPLICIT OCTET STRING OPTIONAL }

 

Obecně může zpráva obsahovat více elektronických podpisů. To je běžné i u rukou psaného podpisu. Např. pro platební příkazy v bance nad stanovený limit mohou být požadovány také dva podpisy. Ještě běžnější je podepisování smluv. Smlouva je vztah minimálně mezi dvěma stranami, takže na smlouvě budou také minimálně dva podpisy atd.

Poslední položka SignerInfos obsahuje množinu elektronických podpisů. Nyní se podíváme na elektronický podpis podrobněji. Elektronický podpis (struktura signerInfo) je sama strukturou zobrazenou na obr. 8-18.

Obr. 8-18 Struktura elektronický podis

Tato struktura obsahuje následující položky:

         issuerAndSerialNumber IssuerAndSerialNumber,

   subjectKeyIdentifier [0] SubjectKeyIdentifier }
Identifikací může být buď sekvence (jedinečné jméno CA, číslo certifikátu) nebo identifikátor klíče předmětu.

        attrType OBJECT IDENTIFIER,

        attrValues SET OF AttributeValue }

1.        Zpráva neobsahuje žádný podepisovaný atribut. V tomto případě se kontrolní součet spočte ze vstupních dat, tj. z položky eContent.

2.        Zpráva obsahuje podepisované atributy. V tomto případě musí být jako podepisované atributy uvedeny: „Kontrolní součet zprávy“ a „Typ podepisovaných dat“. Pro výpočet kontrolního součtu pro vlastní elektronický podpis se pak vezmou všechny podpisované atributy. Kontrolní součet podepisované zprávy je tak obsažen nepřímo v kontrolním součtu, ze kterého se vytváří elektronický podpis.

Pokud chcete programovat výpočet příslušných kontrolních součtů, pak doporučuji si přímo přečíst RFC-2630, kde jsou uvedena jistá upřesnění.

 

 

Důležité podepisované atributy:

 

 

 

  id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)

          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

  id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)

          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

  id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)

          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

 

      SigningTime ::= Time

 

      Time ::= CHOICE {

        utcTime          UTCTime,

        generalizedTime  GeneralizedTime }

 

Důležité nepodepisované atributy

 

 

      id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)

           us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

 

         Countersignature ::= SignerInfo

 

Sice jsme se snažili na místo suché definice nakreslit obrázek, ale i obrázek je podle našich zkušeností kritizován za odtažitost. Jelikož z pohádek jste už vyrostli, tak jsme pro Vás připravili detektivní příběh (česky triler).

8.9.4                      Příklad exportu certifikátu

Jak jsem již uvedl, degenerovaným případem elektronicky podepsané zprávy protokolu CMS je zpráva obsahující pouze certifikáty. Na obr. 8-22 je ukázka menu MS Exploreru pro export certifikátu do tvaru této degenerované elektronicky podepsané zprávy CMS (resp. PKCS#7 nebo jak je na obrázku přímo napsáno „PKCS č. 7“).

 

V MS Exploreru jsem nezvolil volbu „Zahrnout všechny certifikáty na cestě …“ jen z toho důvodu, aby výpis pro potřeby této publikace byl kratší. V praxi bude častější zahrnout všechny certifikáty. Výhodou tohoto formátu exportu certifikátu naopak je, že v něm může být zahrnuto více certifikátů (včetně certifikátů CA). U ostatních formátů exportu certifikátu by se většinou musel exportovat každý certifikát do samostatného souboru. A navíc export certifikátů CA nebývá vždy programy klienta podporován.

 

Obr. 8-22 Export certifikátu z MS Exploreru ve formátu „PKCS#7“ do souboru s příponou .p7b

Zajímavé je prohlédnout si rozbor takového certifikátu:

 

SEQUENCE         

    30 82 03 f1

  OBJECT            :pkcs7-signedData

     06 09 2a 86 48 86 f7 0d 01 07 02

  cont [ 0 ]       

     a0 82 03 e2

   SEQUENCE         

      30 82 03 de

    INTEGER           :01

       02 01 01

    SET              

       31 00

    SEQUENCE         

       30 0b

     OBJECT            :pkcs7-data

        06 09 2a 86 48 86 f7 0d 01 07 01

    cont [ 0 ]       

       a0 82 03 c6

     SEQUENCE         

        30 82 03 c2

      SEQUENCE         

         30 82 02 aa

       cont [ 0 ]       

          a0 03

        INTEGER           :02

           02 01 02

       INTEGER           :01F24B

          02 03 01 f2 4b

       SEQUENCE         

          30 0d

        OBJECT            :sha1WithRSAEncryption

           06 09 2a 86 48 86 f7 0d 01 01 05

        NULL             

           05 00

       SEQUENCE         

          30 4e

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 2c

         SEQUENCE         

            30 2a

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :I.CA - Standard root certificate 01

             13 23 49 2e 43 41 20 2d 20 53 74 61 6e 64 61 72 64 20 72 6f

             6f 74 20 63 65 72 74 69 66 69 63 61 74 65 20 30 31

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

       SEQUENCE         

          30 1e

        UTCTIME           :010302075739Z

           17 0d 30 31 30 33 30 32 30 37 35 37 33 39 5a

        UTCTIME           :010901075739Z

           17 0d 30 31 30 39 30 31 30 37 35 37 33 39 5a

       SEQUENCE         

          30 81 ae

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 1d

         SEQUENCE         

            30 1b

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :RNDr. Libor Dostalek

             13 14 52 4e 44 72 2e 20 4c 69 62 6f 72 20 44 6f 73 74 61 6c

             65 6b

        SET              

           31 14

         SEQUENCE         

            30 12

          OBJECT            :stateOrProvinceName

             06 03 55 04 08

          PRINTABLESTRING   :Netolicka 9

             13 0b 4e 65 74 6f 6c 69 63 6b 61 20 39

        SET              

           31 19

         SEQUENCE         

            30 17

          OBJECT            :localityName

             06 03 55 04 07

          PRINTABLESTRING   :Ceske Budejovice

             13 10 43 65 73 6b 65 20 42 75 64 65 6a 6f 76 69 63 65

        SET              

           31 2f

         SEQUENCE         

            30 2d

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :IPB Homebanking Pristup 19991008125931

             13 26 49 50 42 20 48 6f 6d 65 62 61 6e 6b 69 6e 67 20 50 72

             69 73 74 75 70 20 31 39 39 39 31 30 30 38 31 32 35 39 33 31

        SET              

           31 1e

         SEQUENCE         

            30 1c

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :dostalek@pvt.cz

             16 0f 64 6f 73 74 61 6c 65 6b 40 70 76 74 2e 63 7a

       SEQUENCE         

          30 5c

        SEQUENCE         

           30 0d

         OBJECT            :rsaEncryption

            06 09 2a 86 48 86 f7 0d 01 01 01

         NULL             

            05 00

        BIT STRING       

           03 4b 00 30 48 02 41 00 c8 72 d0 b0 d0 c5 46 25 77 d1 c6 af

           2e 53 fa fc 0a 0e 19 91 37 c9 6f 57 95 91 23 96 ef 3b ac 66

           bd e9 5c 1d e0 70 c1 03 44 2b 24 50 94 c6 c6 74 48 e0 b0 20

           2c 9b 16 30 44 6f c4 10 4c d4 54 8f 02 03 01 00 01

       cont [ 3 ]       

          a3 82 01 0e

        SEQUENCE         

           30 82 01 0a

         SEQUENCE         

            30 0b

          OBJECT            :X509v3 Key Usage

             06 03 55 1d 0f

          OCTET STRING     

             04 04 03 02 04 f0

         SEQUENCE         

            30 1f

          OBJECT            :X509v3 Authority Key Identifier

             06 03 55 1d 23

          OCTET STRING     

             04 18 30 16 80 14 31 df 5d 34 67 56 16 ed f5 18 b7 54 e0 47

             51 c0 67 44 2e 1e

         SEQUENCE         

            30 1d

          OBJECT            :X509v3 Subject Key Identifier

             06 03 55 1d 0e

          OCTET STRING     

             04 16 04 14 a3 d8 94 fe 06 43 f6 6d 1a d7 0c af df 30 85 0a

             0f 76 88 7c

         SEQUENCE         

            30 49

          OBJECT            :X509v3 CRL Distribution Points

             06 03 55 1d 1f

          OCTET STRING      

             04 42 30 40 30 1e a0 1c a0 1a 86 18 68 74 74 70 3a 2f 2f 63

             61 2e 69 63 61 2e 63 7a 2f 63 72 6c 2e 63 67 69 30 1e a0 1c

             a0 1a 86 18 68 74 74 70 3a 2f 2f 70 73 2e 69 70 62 2e 63 7a

             2f 63 72 6c 2e 63 67 69

         SEQUENCE         

            30 70

          OBJECT            :X509v3 Certificate Policies

             06 03 55 1d 20

          OCTET STRING     

             04 69 30 67 30 65 06 0a 2b 06 01 04 01 b3 61 01 01 02 30 57

             30 2d 06 08 2b 06 01 05 05 07 02 01 16 21 68 74 74 70 3a 2f

             2f 77 77 77 2e 69 63 61 2e 63 7a 2f 62 65 7a 70 65 63 6e 6f

             73 74 2e 68 74 6d 6c 30 26 06 08 2b 06 01 05 05 07 02 01 16

             1a 68 74 74 70 3a 2f 2f 77 77 77 2e 69 63 61 2e 63 7a 2f 72

             61 64 2e 68 74 6d 6c

      SEQUENCE         

         30 0d

       OBJECT            :sha1WithRSAEncryption

          06 09 2a 86 48 86 f7 0d 01 01 05

       NULL             

          05 00

      BIT STRING       

         03 82 01 01 00 58 a7 4c 23 ce 2b 2c 24 ac a3 66 7e 1f cb 6d

         b7 75 dd 0c f9 3a fb 71 57 f6 40 06 c7 fe ba 9f bd 16 e7 47

         64 77 04 93 16 f5 3c dc d4 77 d2 8c cf d0 1d ce ba a1 e3 2c

         de ea 3c 60 65 04 4a 22 c2 5c 69 dd c5 8a 5e 34 ef e9 7a ca

         3e 7f 00 26 4c af 0e 5c 70 ca ba ff 79 dc 37 84 3b 3e 58 fd

         bf 69 a3 84 fa 2f 73 38 c2 85 cd bf 19 da 7a 17 70 fd 8c eb

         58 ea fa 92 cd a2 f2 c5 3b d0 52 cd 5b 53 fa 1d 39 44 62 6c

         ac fe 1b 2e 87 d8 ac c7 ff b7 62 7c bd 99 0a e0 87 20 24 d6

         0b 7e 40 a8 10 fc 8a 8d 31 5c 9f b5 25 c2 e8 0f 63 df 1e 6f

         c6 0f 22 59 44 ff 12 3f 23 58 7c 59 f3 9b 8f b1 96 93 98 8f

         50 e6 0b 0c 9d 64 e0 82 11 dd af 77 8d a7 db 03 b1 13 7e 28

         3a 0a 92 06 09 d2 8c d7 84 79 85 1e 8b 1e 89 a3 71 4d 00 59

         b2 4f a7 59 f6 04 f6 8c db 44 aa 28 a5 13 91 70 36 85 b6 f8

         ad

    SET              

       31 00

 

 

8.9.5                      Typ zprávy „Enveloped Data“

Tato zpráva obsahuje data v elektronické obálce. Pro vytvoření elektronické obálky zprávy jsou nutné certifikáty všech příjemců (adresátů). Princip elektronické obálky spočívá v tom, že zpráva (vstupní data) se šifruje náhodně generovaným symetrickým klíčem. Každý adresát zprávy má pak ve zprávě jeden výskyt položky „Informace pro adresáta“. Struktura „Informace pro adresáta“ v sobě obsahuje tento náhodně generovaný symetrický klíč. Jenže jej neobsahuje jen tak, ale zašifrován veřejným klíčem z certifikátu adresáta.

 

Takto to perfektně pracuje v případě, že adresátův certifikát obsahuje asymetrický šifrovací klíč adresáta – např. pro algoritmus RSA. Asi proto, že norma PKCS#7 je podnikovou normou RSA, tak se její tvůrci nezabývali jinými možnostmi. Norma CMS popisuje celkem tři možnosti:

1.        Symetrický šifrovací klíč obsahu zprávy je zašifrován veřejným klíčem adresáta (již zmíněná metoda PKCS#7).

2.        Z veřejného klíče adresáta a soukromého klíče odesilatele se spočte symetrický šifrovací klíč, kterým odesilatel šifruje obsah zprávy (Diffie-Hellman). Adresát pak z veřejného klíče odesilatele a svého soukromého zjistí symetrický šifrovací klíč zprávy. Adresát tak potřebuje veřejný klíč odesilatele. Proto struktura Enveloped Data musela být rozšířena o položku recipientInfos obsahující certifikáty odesilatele a případně CRL.

3.        Symetrický šifrovací klíč obsahu zprávy je šifrován symetrickým šifrovacím klíčem předchozí zprávy. Zpráva proto musí obsahovat identifikaci klíče, kterým je symetrický šifrovací klíč šifrován. Tento případ v podstatě nevyžaduje žádnou asymetrickou šifrovací metodu (poprvé může být klíč distribuován jinou cestou).

 

Vytvoření elektronické obálky zprávy lze shrnout do následujících bodů (obr. 8-23):

Obr. 8-23 Zpráva v elektronické obálce (případ 1,  kdy symetrický šifrovací klíč obsahu zprávy je zašifrován veřejným klíčem adresáta)

Zpráva EnvelopedData má následující strukturu:

 

      EnvelopedData ::= SEQUENCE {

        version CMSVersion,

        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,

        recipientInfos RecipientInfos,

        encryptedContentInfo EncryptedContentInfo,

        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

 

Význam jednotlivých položek je:

      OriginatorInfo ::= SEQUENCE {

        certs [0] IMPLICIT CertificateSet OPTIONAL,

        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }

      RecipientInfos ::= SET OF RecipientInfo

      EncryptedContentInfo ::= SEQUENCE {

        contentType ContentType,

        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,

        encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

      EncryptedContent ::= OCTET STRING

      UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

Struktura RecipientInfo obsahuje zašifrovaný klíč, kterým se šifrují data přenášené zprávy. Tento klíč je šifrován jednou ze tří výše uvedených metod. Syntaxe struktury RecipientInfo závisí na použité metodě zabezpečení šifrovacího klíče zprávy (vstupních dat). Ta specifikuje i použitou metodu. Struktura  RecipientInfo je tak jednou z možností:

      RecipientInfo ::= CHOICE {

        ktri KeyTransRecipientInfo,

        kari [1] KeyAgreeRecipientInfo,

        kekri [2] KEKRecipientInfo }

První položkou struktury  RecipientInfo je vždy verze; její hodnotou se rozlišuje příslušná možnost:

·         V případě, že se verze rovná nule, pak se jedná o zprávu PKCS#7. Struktura recipientInfo se pak skládá z verze (=0), identifikace certifikátu příjemce issuerAndSerialNumber (jedinečné jméno CA + sériové číslo certifikátu), identifikátoru objektu šifrovacího algoritmu, kterým je klíč šifrován, a pochopitelně i šifrovacího klíče zprávy zašifrovaného veřejným klíčem z certifikátu příjemce identifikovaného právě položkou issuerAndSerialNumber:

      KeyTransRecipientInfo ::= SEQUENCE {

        version CMSVersion,

        issuerAndSerialNumber IssuerAndSerialNumber,

        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,

        encryptedKey EncryptedKey }

·         Identifikace certifikátu adresáta pomocí položky issuerAndSerialNumber je nepříjemná v tom, že tato položka není pevné délky a může být i značně dlouhá, proto protokol CMS přináší i možnost identifikovat certifikát příjemce pomocí rozšířené položky certifikátu „Identifikace klíče předmětu“ (verze = 2):

      KeyTransRecipientInfo ::= SEQUENCE {

        version CMSVersion,

        rid RecipientIdentifier,

        subjectKeyIdentifier [0] SubjectKeyIdentifier }

        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,

        encryptedKey EncryptedKey }

·         Verze 3 struktury RecipientInfo je pro případ algoritmů založených na výměně klíčů (Diffie-Hellman). Její syntaxe je popsána v RFC-2630. V praxi jsem se s touto možností nesetkal.

·         Verze 4 struktury RecipientInfo je pro případ, kdy symetrický šifrovací klíč obsahu zprávy je šifrován symetrickým šifrovacím klíčem předchozí zprávy. Jak jsem se již zmínil, tak v tomto případě struktura RecipientInfo obsahuje identifikaci dříve použitého šifrovacího klíče zprávy (KEKIdentifier):

       KEKRecipientInfo ::= SEQUENCE {

        version CMSVersion,

        kekid KEKIdentifier,

        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,

        encryptedKey EncryptedKey }

 

      KEKIdentifier ::= SEQUENCE {

        keyIdentifier OCTET STRING,

        date GeneralizedTime OPTIONAL,

        other OtherKeyAttribute OPTIONAL }

 

8.9.6                      Typ zprávy „Digest Data“

Tato zpráva obsahuje data s kontrolním součtem:

 

      DigestedData ::= SEQUENCE {

        version CMSVersion,

        digestAlgorithm DigestAlgorithmIdentifier,

        encapContentInfo EncapsulatedContentInfo,

        digest Digest }

 

      Digest ::= OCTET STRING

Položka version obsahuje verzi syntaxe zprávy. Nabývá hodnoty nula v případě, že je počítán kontrolní součet ze zprávy s identifikátorem objektu id-data. V opačném případě je verze 2 (tj. zpráva obsahuje jiná data než obecná data s identifikátorem id-data). Význam ostatních položek jsem již zmínil v předchozích kapitolách.

8.9.7                      Typ zprávy „Encrypted Data“

Data šifrovaná jiným způsobem. Používá se např. pro ochranu dat ukládaných na lokální disk (např. pro ochranu soukromého šifrovacího klíče PINem apod.). Tento typ neobsahuje žádné informace o šifrovacím klíči, předpokládá se, že správa šifrovacích klíčů bude prováděna jiným způsobem.

 

      EncryptedData ::= SEQUENCE {

        version CMSVersion,

        encryptedContentInfo EncryptedContentInfo,

        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

 

Položka version je opět stejná záležitost. Norma PKCS#7 neobsahovala poslední položku nezabezpečené atributy (unprotectedAttrs) a používala verzi 0. Takže v případě, že zpráva tuto položku neobsahuje, pak se může použít verze 0, jinak se musí použít verze 2.

 

8.9.8                      Typ zprávy „Authenticated Data“

Jedná se o typ zprávy zavedený až normou CMS (nebyla v PKCS#7), proto i příslušné pole version bude moci obsahovat nulu. Tento typ zprávy nese autorizovaná data. Autorizace není tak silný prostředek jako elektronický podpis, ale důvodů, proč nepoužít elektronický podpis a použít „pouze“ autetnizaci, může být několik. Např. používáme asymetrický algoritmus neumožňující elektronický podpis (např. Diffie-Hellman) nebo používáme algoritmus sice podporující elektronický podpis, ale máme certifikát „pouze pro šifrování“ či máme právní důvody, proč se chceme podpisu vyhnout.

 

O autorizaci dat jsme se zmínili v kap. 4.2.5. I zde je podporována např. v kap. 4.2.5 zmíněná metoda HMAC (RFC-2104).

 

Autorizace dat se provádí pomocí sdíleného tajemství, které mezi sebou sdílí tvůrce (odesilatel) zprávy a adresát. Pro autorizaci dat se spočte kontrolní součet z dat zřetězených se sdíleným tajemstvím. Sdílené tajemství má z hlediska přenosu mezi odesilatelem podobné vlastnosti jako symetrický šifrovací klíč zprávy. Přenáší se proto ve struktuře recipientInfo definované u elektronické obálky. Odesilatel provádí následující postup vytvoření autorizované zprávy:

  1. Vygeneruje generátorem náhodných čísel sdílené tajemství.
  2. Pro každého příjemce zašifruje sdílené tajemství za využití veřejného klíče příjemce.
  3. Pro každého příjemce vytvoří strukturu recipientInfo obsahující šifrované sdílené tajemství.
  4. Pomocí sdíleného tajemství spočte autorizační kontrolní součet z přenášené zprávy.

 

Autorizovaná data mají následující strukturu:

 

      AuthenticatedData ::= SEQUENCE {

        version CMSVersion,

        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,

        recipientInfos RecipientInfos,

        macAlgorithm MessageAuthenticationCodeAlgorithm,

        digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,

        encapContentInfo EncapsulatedContentInfo,

        authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,

        mac MessageAuthenticationCode,

        unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }

 

      AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

 

      UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

 

      MessageAuthenticationCode ::= OCTET STRING

 

Kde jednotlivé položky mají následující význam:

 

8.10           Protokol CMC

Protokol CMC (Certificate Management Messages over CMS) je příkladem protokolu využívajícího zabezpečení zpráv protokolem CMS. Aplikačně slouží protokol CMC ke stejným účelům jako protokol CMP, tj. pro komunikaci uživatele s CA či RA. Nejdůležitější funkcí protokolu CMC je tak komunikace uživatele s CA/RA za účelem vydání/obnovení certifikátu, dále pak komunikace za účelem odvolání certifikátů. U šifrovacích certifikátů si uživatel může protokolem CMC v případě ztráty svého soukromého klíče požádat CA o zaslání svého soukromého klíče z archivu CA (uložil-li si jej do archivu CA při vydání šifrovacího certifikátu).

 

Na vytvoření protokolu CMC se podílely mj. firmy CISCO a Microsoft. Očekávané verze systémů Windows proto budou protokol CMC podporovat, což podle mého názoru, věští protokolu CMC velkou budoucnost.

 

Protokol CMC honosně popisuje zprávu, kterou zasílá uživatel CA, jako strukturu  „PKIData“. Zabezpečení struktury PKIData je pak zajištěno protokolem CMS (obr. 8-24). Tj. výstupem protokolu CMC je struktura PKIData, která se zabezpečuje protokolem CMS. Nejprve se struktura PKIData elektronicky podepíše a pak se (v případě, že je to nutné) uloží do elektronické obálky. Jelikož mezi uživatelem a CA může být ještě RA, tak „stroj PKCS#7“ může být zavolán ještě navíc na RA a obálky zabezpečující zprávu protokolem CMS mohou být ještě složitější. Jedna zpráva PKIData odesílaná RA na CA tak v sobě může obsahovat více dílčích zpráv PKIData.

 

Obr. 8-24 Zabezpečení struktury PKIData

Zcela obdobně vytváří svou odpověď v protokolu CMC i CA. Jediný rozdíl je v tom, že odpověď neobsahuje strukturu PKIData, ale strukturu ResponseBody.

8.10.1                  Formát CMC zpráv

Protokol CMC používá dva typy zpráv: krátké nebo úplné zprávy. Pro zpětnou kompatibilitu protokol CMC připouští krátké zprávy (obr. 8-25), které nezavádí žádný nový typ zprávy. Tj. krátké zprávy nejsou tvořeny zprávami PKIData a ResponseBody.

 

V případě krátkých zpráv klient žádá o vydání certifikátu pomocí klasické zprávy PKCS#10 a server (tj. CA) mu vrací vydaný certifikát včetně certifikátů CA degenerovanou zprávou CMS „Signed Data“, která obsahuje pouze certifikáty a případně CRL (viz kapitola 8.9.5).

 

 

Obr. 8-25 Krátké zprávy protokolu CMC

Degenerovaná zpráva CMS „Signed Data“ neobsahuje elektronický podpis celé zprávy (proto je degenerovaná). Podpis celé zprávy ale není nutný, protože jednotlivé certifikáty (i případná CRL) jsou samy podepsány CA.

 

Pomocí krátké zprávy nemůže CA vrátit ani informaci, že příslušný certifikát vydat nemůže. Takže se dostáváme k úplným zprávám (obr. 8-26). V  případě, že CA není schopna odpovědět krátkou zprávou, pak jí nezbývá, než na krátkou zprávu odpovědět úplnou zprávou. Nelze si proto představovat, že bychom mohli provozovat nějaký „zjednodušený CMC server“, který by komunikoval pouze krátkými zprávami.

 

Úplná zpráva je vložena do zprávy CMS. Tj. úplná zpráva  nemusí ani obsahovat elektronický podpis. Veškeré zabezpečení zprávy např. pomocí šifrování přenechává protokol CMC obálce své zprávy, která je tvořena protokolem CMS. Zpráva CMC je tvořena tělem zprávy popisovaným v této kapitole a obálkou popsanou v kapitole 8.9 o PKCS#7 a CMS. Pokud CMC zpráva elektronický podpis obsahuje, pak jej obsahuje jako důkaz o vlastnictví soukromého klíče.

Obr. 8-26 Úplné zprávy protokolu CMC

 

8.11           Přenosové protokoly pro certifikáty a CRL

Pokud chceme získat nějaký vydaný certifikát či CRL, tak máme několik cest. Již jsme si popsali, že je můžeme získat protokolem CMP či protokolem CMC. Jenže klienta ani jednoho z těchto protokolů nebudete mít pravděpodobně vůbec po ruce. Jinou možností je použít protokolu LDAP, který si později také popíšeme. Klienta LDAP asi po ruce máte, protože to je aplikace Adresář, jež je součástí jak aplikace MS Outlook, tak i konkurenčního Netscape. Ale asi vůbec nevíte, že to je mj. LDAP klient. A hlavně jeho použití není pro běžného uživatele triviální. Umístění certifikátů ve stromu X.500 jmen totiž není jednotné, proto by používání obecného LDAP klienta vyžadovalo manuální zásah zdatného a informovaného uživatele.

 

Nejschůdnější cestou je stáhnout si certifikát či CRL pomocí webového prohlížeče, tj. z FTP nebo HTTP  serveru, prostě tím, že kliknete na hypertextový odkaz. Takže mnozí si na své vizitky vytisknou URI se svým aktuálním certifikátem. A také URI v rozšíření certifikátu „Distribuční místa odvolaných certifikátů“.

 

Jak to udělat, aby kliknutí na hypertextový odkaz s certifikátem nezobrazilo rozsypaný čaj na obrazovku, ale aby nastartovalo aplikaci správce úložiště certifikátů, je na bílední. Pro aplikace využívající MIME nebo které jsou odvozeny od MIME (např. protokol HTTP) stačí definovat příslušný typ do hlavičky Content-Type. Dále norma RFC-2585 též zavádí rozšíření jména souboru obsahujícího certifikát (na .cer)  a souboru obsahujícího CRL na .crl. Např. pokud ve Windows 2000 kliknete na soubor obsahující CRL (tj. s příponou .crl), nastartuje se příslušný program, jehož okno je zobrazeno na obr. 8-28.

 

 

 

 

 

Obr. 8-28 CRL

 

 

Content-type:

rozšíření

Certifikát

application/pkix-cert

.cer

CRL

application/pkix-crl

.crl

 

 

8.12           Protokol DVCSP

Obdržím-li elektronicky podepsaná data, pak zpravidla budu chtít ověřit elektronický podpis těchto dat. Pro ověření elektronického podpisu dokumentu musím:

1.        Nalézt certifikát obsahující příslušný veřejný klíč pro ověření tohoto dokumentu.

2.        Ověřit platnost tohoto certifikátu. Což je často potíž, protože:

·         Musím zjistit, zda-li certifikát není na CRL. Přesněji: musím zjistit, zda-li certifikát nebyl na CRL v době vytvoření elektronického podpisu. Tj. musím zjistit, zdali byl certifikát v době podpisu platný.

·         Pokud se jedná o čerstvý dokument (např. právě došlou elektronickou poštu), pak bych se měl dotázat OCSP serveru, zda-li certifikát není odvolán a na aktuálním CRL není pouze proto, že od odvolání certifikátu prostě nové CRL ještě nevyšlo.

3.        Musím ověřit elektronický podpis certifikátu. Tj. musím nalézt certifikát certifikační autority, jež certifikát vydala, a ověřit jeho platnost. Také musím ověřit elektronický podpis certifikátu certifikační autority tzn., že musím nalézt řetězec certifikátů až k certifikátu, který považuji za platný díky nějaké předchozí relaci, a u všech mezilehlých certifikátů ověřit jejich platnost a jejich elektronický podpis.

4.        U konečného certifikátu musím zjistit, zdali se shoduje s certifikátem, který mám lokálně uložen a kterému důvěřuji díky nějaké předchozí relaci. V mnoha případech bývá tímto certifikátem kořenový certifikát CA.

5.        Nakonec, když je příslušný certifikát platný, mohu jeho veřejným klíčem verifikovat dokument.

 

Jenže ono je to ještě složitější v případě, že  na certifikáty aplikujeme certifikační politiku. Tj. používáme rozšíření „certifikační politika“ a rozšíření omezující jména či certifikační politiku apod. V tomto případě máme v ruce ověřený certifikát z hlediska platnosti certifikátu i ověřen elektronický podpis na něm, ale nevíme, zdali jej může použít pro konkrétní aplikaci. Musíme se vnořit do těchto „nepříjemných“ rozšíření a opět ověřit celý řetězec certifikátů.

 

Je to složité, ale v případě, že potřebujeme ověřit dokument několik let starý, pak získání CRL platných v době podpisu dokumentu i získání všech „starých“ certifikátů do řetězce certifikátů je značně obtížné. Řešením je protokol DVCSP.

 

Protokol DVCSP (Data Validation and Certification Server Protocols) je specifikován v RFC-3029. Tento protokol v žádném případě nenahrazuje CRL či protokol OCSP.  Potřebujeme-li ověřit nějaký elektronicky podepsaný dokument, pak jej protokolem DVCSP zašleme na DVCS server, který nám vrátí buď chybové hlášení nebo nám ověří pravost (tj. platnost) zaslaného dokumentu. Pravost ověřuje vystavením ověřovacího certifikátu (Data Validation Certificate - DVC).

 

DVCS server je určen pro důvěryhodné třetí strany, které mohou vystavovat ověřovací certifikáty o:

 

Je zjevné, že ověřování platnosti certifikátů a elektronických podpisů dokumentů je netriviální záležitostí, pro kterou je navíc třeba i značné množství informací (např. stará CRL či staré certifikáty certifikačních autorit). Je proto výhodné např. na vnitropodnikové síti zřídit DVCS server, který tyto záležitosti bude vyřizovat centrálně. Tím se zamezí nutnosti všechna uvedená krkolomná ověřování provádět v každé aplikaci.

 

Ve veřejném sektoru je zase pro uživatele praktické, když služby DVCS serveru nabídne veřejná certifikační autorita.

 

DVCS server může být kombinován s „Evidenční a záznamovou autoritou“, tj. s aplikací udržující logy a ukládající ověřená data pro případ odmítnutí zodpovědnosti za tato data.

8.12.1                  Příklad žádosti o DVC certifikát

Příklad je převzat přímo z RFC-3029:

 

3082024606092a864886f70d010702a082023730820233020103310b300906052b0e03021a050030

8199060b2a864886f70d0109100107a0818904818630818330600a0104a04da44b3049310b300906

0355040613024652310e300c0603550407130550617269733110300e060355040a13074564656c57

6562311830160603550403130f50657465722053796c766573746572a10c060a2b06010401a93d01

0201301f300706052b0e03021a041475b685af6f89467de80715251e45978fcd1fa5663182018330

82017f020101307c3070310b300906035504061302465231153013060355040a130c4564656c5765

6220532e412e31283026060355040b131f436c657073796472652044656d6f6e7374726174696f6e

20536572766963653120301e0603550403131754696d65205374616d70696e6720417574686f7269

747902080094881721343776300906052b0e03021a0500a05f301a06092a864886f70d010903310d

060b2a864886f70d0109100107301c06092a864886f70d010905310f170d30303034313731373134

35375a302306092a864886f70d010904311604144da8c2d2ce7c0d04412f44133375db2f5b2df9dc

300d06092a864886f70d01010105000481806e7b0e36f5085f163c317b28bb0bc2c61767a6b554f1

98e26f89960e0c99e6cb40c19b8dd8d78ed32b41f716265bb708bfe695b2d9016cfeb12c52c15ad2

31f38ecadd11a1720529416add2840aa5c77c69d1d8053db6f9c4ca5a38f928b183fd53aad018769

c3fdd3d8c3d0ca6be60d4e536e5020997c94c244251b06c09996

 

SEQUENCE         

    30 82 02 46

  OBJECT            :pkcs7-signedData

     06 09 2a 86 48 86 f7 0d 01 07 02

  cont [ 0 ]       

     a0 82 02 37

   SEQUENCE         

      30 82 02 33

    INTEGER           :03

       02 01 03

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :sha1

         06 05 2b 0e 03 02 1a

      NULL             

         05 00

    SEQUENCE         

       30 81 99

     OBJECT            :1.2.840.113549.1.9.16.1.7 (id-ct-DVCSRequestData)

        06 0b 2a 86 48 86 f7 0d 01 09 10 01 07

     cont [ 0 ]       

        a0 81 89

      OCTET STRING     

         04 81 86 30 81 83 30 60 0a 01 04 a0 4d a4 4b 30 49 31 0b 30

         09 06 03 55 04 06 13 02 46 52 31 0e 30 0c 06 03 55 04 07 13

         05 50 61 72 69 73 31 10 30 0e 06 03 55 04 0a 13 07 45 64 65

         6c 57 65 62 31 18 30 16 06 03 55 04 03 13 0f 50 65 74 65 72

         20 53 79 6c 76 65 73 74 65 72 a1 0c 06 0a 2b 06 01 04 01 a9

         3d 01 02 01 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 75 b6 85

         af 6f 89 46 7d e8 07 15 25 1e 45 97 8f cd 1f a5 66

                Tj. vlastní žádost od DVC certifikát:

              SEQUENCE         

    30 81 83

  SEQUENCE         

     30 60

   ENUMERATED        :04 (žádost o časové razítko)

      0a 01 04

   cont [ 0 ]       

      a0 4d

    cont [ 4 ]       

       a4 4b

     SEQUENCE         

        30 49

      SET              

         31 0b

       SEQUENCE         

          30 09

        OBJECT            :countryName

           06 03 55 04 06

        PRINTABLESTRING   :FR

           13 02 46 52

      SET               

         31 0e

       SEQUENCE         

          30 0c

        OBJECT            :localityName

           06 03 55 04 07

        PRINTABLESTRING   :Paris

           13 05 50 61 72 69 73

      SET              

         31 10

       SEQUENCE         

          30 0e

        OBJECT            :organizationName

           06 03 55 04 0a

        PRINTABLESTRING   :EdelWeb

           13 07 45 64 65 6c 57 65 62

      SET              

         31 18

       SEQUENCE         

          30 16

        OBJECT            :commonName

           06 03 55 04 03

        PRINTABLESTRING   :Peter Sylvester

           13 0f 50 65 74 65 72 20 53 79 6c 76 65 73 74 65 72

   cont [ 1 ]       

      a1 0c

    OBJECT            :1.3.6.1.4.1.5309.1.2.1

       06 0a 2b 06 01 04 01 a9 3d 01 02 01

  SEQUENCE         

     30 1f

   SEQUENCE         

      30 07

    OBJECT            :sha1

       06 05 2b 0e 03 02 1a

   OCTET STRING     

      04 14 75 b6 85 af 6f 89 46 7d e8 07 15 25 1e 45 97 8f cd 1f

      a5 66

 

    SET         (signerInfos)     

       31 82 01 83

     SEQUENCE         

        30 82 01 7f

      INTEGER           :01

         02 01 01

      SEQUENCE         

         30 7c

       SEQUENCE         

          30 70

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :FR

             13 02 46 52

        SET              

           31 15

         SEQUENCE          

            30 13

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :EdelWeb S.A.

             13 0c 45 64 65 6c 57 65 62 20 53 2e 41 2e

        SET              

           31 28

         SEQUENCE          

            30 26

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :Clepsydre Demonstration Service

             13 1f 43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72

             61 74 69 6f 6e 20 53 65 72 76 69 63 65

        SET              

           31 20

         SEQUENCE         

            30 1e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Time Stamping Authority

             13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

             6f 72 69 74 79

       INTEGER           :94881721343776

          02 08 00 94 88 17 21 34 37 76

      SEQUENCE         

         30 09

       OBJECT            :sha1

          06 05 2b 0e 03 02 1a

       NULL             

          05 00

      cont [ 0 ]        (podepisované parametry)

         a0 5f

       SEQUENCE         

          30 1a

        OBJECT            :contentType

           06 09 2a 86 48 86 f7 0d 01 09 03

        SET              

           31 0d

         OBJECT            :1.2.840.113549.1.9.16.1.7

            06 0b 2a 86 48 86 f7 0d 01 09 10 01 07

       SEQUENCE         

          30 1c

        OBJECT            :signingTime

           06 09 2a 86 48 86 f7 0d 01 09 05

        SET              

           31 0f

         UTCTIME           :000417171457Z

            17 0d 30 30 30 34 31 37 31 37 31 34 35 37 5a

       SEQUENCE         

          30 23

        OBJECT            :messageDigest

           06 09 2a 86 48 86 f7 0d 01 09 04

        SET              

           31 16

         OCTET STRING     

            04 14 4d a8 c2 d2 ce 7c 0d 04 41 2f 44 13 33 75 db 2f 5b 2d

            f9 dc

      SEQUENCE         

         30 0d

       OBJECT            :rsaEncryption

          06 09 2a 86 48 86 f7 0d 01 01 01

       NULL             

          05 00

      OCTET STRING      (elektronický podpis)

         04 81 80 6e 7b 0e 36 f5 08 5f 16 3c 31 7b 28 bb 0b c2 c6 17

         67 a6 b5 54 f1 98 e2 6f 89 96 0e 0c 99 e6 cb 40 c1 9b 8d d8

         d7 8e d3 2b 41 f7 16 26 5b b7 08 bf e6 95 b2 d9 01 6c fe b1

         2c 52 c1 5a d2 31 f3 8e ca dd 11 a1 72 05 29 41 6a dd 28 40

         aa 5c 77 c6 9d 1d 80 53 db 6f 9c 4c a5 a3 8f 92 8b 18 3f d5

         3a ad 01 87 69 c3 fd d3 d8 c3 d0 ca 6b e6 0d 4e 53 6e 50 20

         99 7c 94 c2 44 25 1b 06 c0 99 96

 

8.12.2                  Příklad DVC certifikátu

Příklad je opět převzat z RFC-3029:

 

308207f706092a864886f70d010702a08207e8308207e4020103310b300906052b0e03021a050030

82012d060b2a864886f70d0109100108a082011c04820118308201143081d60a0104a04da44b3049

310b3009060355040613024652310e300c0603550407130550617269733110300e060355040a1307

4564656c576562311830160603550403130f50657465722053796c766573746572a10c060a2b0601

0401a93d010201a274a4723070310b300906035504061302465231153013060355040a130c456465

6c57656220532e412e31283026060355040b131f436c657073796472652044656d6f6e7374726174

696f6e20536572766963653120301e0603550403131754696d65205374616d70696e672041757468

6f72697479301f300706052b0e03021a041475b685af6f89467de80715251e45978fcd1fa5660207

01780a1eca8823180f32303030303431373137313631375aa08203e0308203dc308202c4a0030201

…

ae2a3b4684bf4d8c9fee1fefc535a363be38c0037c3a5eb8cf3b181088dbbb4f78f6fbe41c8dd4f8

fbeb50

 

 

SEQUENCE         

    30 82 07 f7

  OBJECT            :pkcs7-signedData

     06 09 2a 86 48 86 f7 0d 01 07 02

  cont [ 0 ]       

     a0 82 07 e8

   SEQUENCE         

      30 82 07 e4

    INTEGER           :03

       02 01 03

    SET              

       31 0b

     SEQUENCE          

        30 09

      OBJECT            :sha1

         06 05 2b 0e 03 02 1a

      NULL             

         05 00

    SEQUENCE         

       30 82 01 2d

     OBJECT            :1.2.840.113549.1.9.16.1.8    (id-ct-DVCSResponseData)

        06 0b 2a 86 48 86 f7 0d 01 09 10 01 08

     cont [ 0 ]       

        a0 82 01 1c

      OCTET STRING     

         04 82 01 18 30 82 01 14 30 81 d6 0a 01 04 a0 4d a4 4b 30 49

         31 0b 30 09 06 03 55 04 06 13 02 46 52 31 0e 30 0c 06 03 55

         04 07 13 05 50 61 72 69 73 31 10 30 0e 06 03 55 04 0a 13 07

         45 64 65 6c 57 65 62 31 18 30 16 06 03 55 04 03 13 0f 50 65

         74 65 72 20 53 79 6c 76 65 73 74 65 72 a1 0c 06 0a 2b 06 01

         04 01 a9 3d 01 02 01 a2 74 a4 72 30 70 31 0b 30 09 06 03 55

         04 06 13 02 46 52 31 15 30 13 06 03 55 04 0a 13 0c 45 64 65

         6c 57 65 62 20 53 2e 41 2e 31 28 30 26 06 03 55 04 0b 13 1f

         43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72 61 74

         69 6f 6e 20 53 65 72 76 69 63 65 31 20 30 1e 06 03 55 04 03

         13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

         6f 72 69 74 79 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 75 b6

         85 af 6f 89 46 7d e8 07 15 25 1e 45 97 8f cd 1f a5 66 02 07

         01 78 0a 1e ca 88 23 18 0f 32 30 30 30 30 34 31 37 31 37 31

         36 31 37 5a

                 Tj. vlastní DVC certifikát:

SEQUENCE         

    30 82 01 14

  SEQUENCE         

     30 81 d6

   ENUMERATED        :04

      0a 01 04

   cont [ 0 ]       

      a0 4d

    cont [ 4 ]       

       a4 4b

     SEQUENCE         

        30 49

      SET              

         31 0b

       SEQUENCE         

          30 09

        OBJECT            :countryName

           06 03 55 04 06

        PRINTABLESTRING   :FR

           13 02 46 52

      SET              

         31 0e

       SEQUENCE         

          30 0c

        OBJECT            :localityName

           06 03 55 04 07

        PRINTABLESTRING   :Paris

           13 05 50 61 72 69 73

      SET              

         31 10

                             SEQUENCE         

          30 0e

        OBJECT            :organizationName

           06 03 55 04 0a

        PRINTABLESTRING   :EdelWeb

           13 07 45 64 65 6c 57 65 62

      SET              

         31 18

       SEQUENCE         

          30 16

        OBJECT            :commonName

           06 03 55 04 03

        PRINTABLESTRING   :Peter Sylvester

           13 0f 50 65 74 65 72 20 53 79 6c 76 65 73 74 65 72

   cont [ 1 ]       

      a1 0c

    OBJECT            :1.3.6.1.4.1.5309.1.2.1

       06 0a 2b 06 01 04 01 a9 3d 01 02 01

   cont [ 2 ]       

      a2 74

    cont [ 4 ]       

       a4 72

     SEQUENCE         

        30 70

      SET              

         31 0b

       SEQUENCE         

          30 09

        OBJECT            :countryName

           06 03 55 04 06

        PRINTABLESTRING   :FR

           13 02 46 52

      SET              

         31 15

       SEQUENCE         

          30 13

        OBJECT            :organizationName

           06 03 55 04 0a

        PRINTABLESTRING   :EdelWeb S.A.

           13 0c 45 64 65 6c 57 65 62 20 53 2e 41 2e

      SET              

         31 28

       SEQUENCE         

          30 26

        OBJECT            :organizationalUnitName

           06 03 55 04 0b

        PRINTABLESTRING   :Clepsydre Demonstration Service

           13 1f 43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72

           61 74 69 6f 6e 20 53 65 72 76 69 63 65

      SET              

         31 20

       SEQUENCE         

          30 1e

        OBJECT            :commonName

           06 03 55 04 03

        PRINTABLESTRING   :Time Stamping Authority

           13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

           6f 72 69 74 79

  SEQUENCE          

     30 1f

   SEQUENCE         

      30 07

    OBJECT            :sha1

       06 05 2b 0e 03 02 1a

   OCTET STRING     

      04 14 75 b6 85 af 6f 89 46 7d e8 07 15 25 1e 45 97 8f cd 1f

      a5 66

  INTEGER           :01780A1ECA8823

     02 07 01 78 0a 1e ca 88 23

  GENERALIZEDTIME   :20000417171617Z

     18 0f 32 30 30 30 30 34 31 37 31 37 31 36 31 37 5a

 

    cont [ 0 ]          (certifikáty) 

       a0 82 03 e0

     SEQUENCE         

        30 82 03 dc

      SEQUENCE          (Certtfikát DVCS serveru)  

         30 82 02 c4

       cont [ 0 ]       

          a0 03

        INTEGER           :02

           02 01 02

       INTEGER           :94881717643732

          02 08 00 94 88 17 17 64 37 32

       SEQUENCE         

          30 0d

        OBJECT            :md5WithRSAEncryption

           06 09 2a 86 48 86 f7 0d 01 01 04

        NULL             

           05 00

       SEQUENCE         

          30 70

        SET              

           31 0b

         SEQUENCE          

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :FR

             13 02 46 52

        SET              

           31 15

         SEQUENCE         

            30 13

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :EdelWeb S.A.

             13 0c 45 64 65 6c 57 65 62 20 53 2e 41 2e

        SET              

           31 28

         SEQUENCE         

            30 26

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :Clepsydre Demonstration Service

             13 1f 43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72

             61 74 69 6f 6e 20 53 65 72 76 69 63 65

        SET              

           31 20

         SEQUENCE         

            30 1e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Time Stamping Authority

             13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

             6f 72 69 74 79

       SEQUENCE         

          30 1e

        UTCTIME           :000125161938Z

           17 0d 30 30 30 31 32 35 31 36 31 39 33 38 5a

        UTCTIME           :200120161938Z

           17 0d 32 30 30 31 32 30 31 36 31 39 33 38 5a

       SEQUENCE         

          30 70

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :FR

             13 02 46 52

        SET              

           31 15

         SEQUENCE         

            30 13

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :EdelWeb S.A.

             13 0c 45 64 65 6c 57 65 62 20 53 2e 41 2e

        SET              

           31 28

         SEQUENCE         

            30 26

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :Clepsydre Demonstration Service

             13 1f 43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72

             61 74 69 6f 6e 20 53 65 72 76 69 63 65

        SET              

           31 20

         SEQUENCE         

            30 1e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Time Stamping Authority

             13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

             6f 72 69 74 79

       SEQUENCE         

          30 82 01 22

        SEQUENCE         

           30 0d

         OBJECT            :rsaEncryption

            06 09 2a 86 48 86 f7 0d 01 01 01

         NULL             

            05 00

        BIT STRING       

           03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 fa c3 17 ae eb b7

           9d eb ab bd 05 7e 39 43 6d 04 45 58 74 05 a5 cc f3 6c 2f 8c

           8e 77 7e c2 9f 12 11 5c 7d db be 23 28 9a 90 d2 ab c6 a2 ba

           bd a3 7e 99 a6 99 21 a5 d8 90 b9 cf a7 23 4e a0 56 a0 c1 0a

           46 89 8e 3c 91 67 37 fd 9b ab 49 17 fc 4a a5 f2 e4 4c 6e e3

           6a 1c 92 97 04 6f 7f 0c 5c fb 74 cb 95 7e 4c c3 58 12 e8 a9

           d6 f0 dd 12 44 15 e7 8b 2e af 51 c0 0c 5f a8 65 fc 47 a1 c9

           98 1f d4 e1 ea bc 1c 1a 27 bb 8b 56 f1 12 55 10 f4 8e d8 9f

           19 9c 1e 81 f7 db 63 dd 88 37 3f 71 79 5b 96 e2 5f 82 d5 12

           19 05 0d e1 3d a5 6d 66 e4 2c 1e ed c7 4c b8 df aa 38 c8 15

           6a ae 25 7d 46 2a 07 f9 83 77 c4 51 ee 90 dc 05 d0 c3 f0 f1

           5f e8 d4 ed 5d 34 70 91 9d 9f 08 55 7d 5b e5 8d 5f 35 59 83

           4e 72 19 bb 9c 88 d1 7a fc 23 a5 84 99 b4 17 8a 4d 6c 9d d0

           a6 35 80 5f ca fb 24 8b 54 1d 02 03 01 00 01

       cont [ 3 ]        (Rozšíření certifikátu DVCS serveru)

          a3 7a

        SEQUENCE         

           30 78

         SEQUENCE         

            30 0f

          OBJECT            :X509v3 Basic Constraints

             06 03 55 1d 13

          OCTET STRING      (CA:TRUE, pathlen:0)

             04 08 30 06 01 01 ff 02 01 00

         SEQUENCE         

            30 16

          OBJECT            :X509v3 Extended Key Usage

             06 03 55 1d 25

          BOOLEAN           :255

             01 01 ff

          OCTET STRING     

             04 0c 30 0a 06 08 2b 06 01 05 05 07 03 0a

             Tj.

SEQUENCE         

   30 0a

                        OBJECT            :1.3.6.1.5.5.7.3.10 (id-kp-dvcs)

      06 08 2b 06 01 05 05 07  03 0a

 

         SEQUENCE         

            30 4d

          OBJECT            :1.3.6.1.5.5.7.1.1   (id-pe-authorityInfoAccess - „privátní rozšíření“)

             06 08 2b 06 01 05 05 07 01 01

          BOOLEAN           :255

             01 01 ff

          OCTET STRING     

             04 3e 30 3c 30 3a 06 08 2b 06 01 05 05 07 30 04 86 2e 68 74

             74 70 73 3a 2f 2f 63 6c 65 70 73 79 64 72 65 2e 65 64 65 6c

             77 65 62 2e 66 72 2f 64 76 63 73 2f 73 65 72 76 69 63 65 2d

             63 63 70 64

     Tj.

                      SEQUENCE         

    30 3c

  SEQUENCE         

     30 3a

   OBJECT            :1.3.6.1.5.5.7.48.4   (id-ad-dvcs)

      06 08 2b 06 01 05 05 07 30 04

   cont [ 6 ]        :https://clepsydre.edelweb.fr/dvcs/service-ccpd

      86 2e 68 74 74 70 73 3a 2f 2f 63 6c 65 70 73 79 64 72 65 2e

      65 64 65 6c 77 65 62 2e 66 72 2f 64 76 63 73 2f 73 65 72 76

      69 63 65 2d 63 63 70 64

 

      SEQUENCE         

         30 0d

       OBJECT            :md5WithRSAEncryption

          06 09 2a 86 48 86 f7 0d 01 01 04

       NULL             

          05 00

      BIT STRING       

         03 82 01 01 00 08 da af 5b 09 39 66 d3 be 80 1d d7 72 b5 2c

         a3 04 fb 46 f8 05 f5 bf 83 f3 6d 6d 32 28 1c 46 ee 0f ea 30

         61 8a 1e 8a 03 4e 98 81 60 1f 97 17 53 d1 54 73 3f 72 98 45

         d3 10 9a d3 77 b8 74 0e 9a 90 29 8e ac a4 eb d2 24 6d f6 21

         1d 3f 52 8b 2c e6 92 e7 52 c6 54 93 91 bc 57 74 21 38 39 75

         cd 30 49 54 13 94 6c fe f1 64 38 1f 5f 7d bb e0 3e a8 f1 28

         1c f1 d9 28 fa 32 1e 3b 48 bf 5c 70 21 29 ef be 72 24 da 0d

         f9 51 7a fe d7 f5 ff e8 c2 ea c6 4c 45 14 51 53 fd 00 d5 5b

         cc 67 2a 23 94 31 9e c2 90 38 9b b0 df f9 de 67 0c 57 5c d7

         b0 fc f2 72 96 c4 d1 7a 9d a0 e6 51 24 99 9e 89 c6 39 f9 72

         7a 44 fd 2d 3f bc df c7 25 27 94 a1 b5 7d ba 06 75 67 1c 95

         6c bd 2c 74 41 3e cd cd 39 5c 2e 9c c3 c3 09 e3 79 d5 eb 85

         e8 f1 72 29 80 f6 c6 6e 61 1b 58 fc 87 3e d9 e1 53 10 e0 b1

         05

    SET             (podpisy)             

       31 82 02 bb

     SEQUENCE         

        30 82 02 b7

      INTEGER           :01

         02 01 01

      SEQUENCE         

         30 7c

       SEQUENCE         

          30 70

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :FR

             13 02 46 52

        SET              

           31 15

         SEQUENCE         

            30 13

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :EdelWeb S.A.

             13 0c 45 64 65 6c 57 65 62 20 53 2e 41 2e

        SET              

           31 28

         SEQUENCE         

            30 26

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :Clepsydre Demonstration Service

             13 1f 43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72

             61 74 69 6f 6e 20 53 65 72 76 69 63 65

        SET              

           31 20

         SEQUENCE         

            30 1e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Time Stamping Authority

             13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

             6f 72 69 74 79

       INTEGER           :94882572352750

          02 08 00 94 88 25 72 35 27 50

      SEQUENCE         

         30 09

       OBJECT            :sha1

          06 05 2b 0e 03 02 1a

       NULL             

          05 00

      cont [ 0 ]      (Podepisované atributy) 

         a0 82 01 14

       SEQUENCE         

          30 1a

        OBJECT            :contentType

           06 09 2a 86 48 86 f7 0d 01 09 03

        SET              

           31 0d

         OBJECT            :1.2.840.113549.1.9.16.1.8    (id-ct-DVCSResponseData)

            06 0b 2a 86 48 86 f7 0d 01 09 10 01 08

       SEQUENCE         

          30 1c

        OBJECT            :signingTime

           06 09 2a 86 48 86 f7 0d 01 09 05

        SET               

           31 0f

         UTCTIME           :000417171619Z

            17 0d 30 30 30 34 31 37 31 37 31 36 31 39 5a

       SEQUENCE         

          30 23

        OBJECT            :messageDigest

           06 09 2a 86 48 86 f7 0d 01 09 04

        SET              

           31 16

         OCTET STRING     

            04 14 68 50 dc 90 20 2e c2 f0 55 15 7f 77 a9 a6 0c 34 cc 13

            06 fa

       SEQUENCE         

          30 81 b2

        OBJECT            :1.2.840.113549.1.9.16.2.12      (id-aa-signingCertificate – kap. 10.7.5)

           06 0b 2a 86 48 86 f7 0d 01 09 10 02 0c

        SET              

           31 81 a2

         SEQUENCE         

            30 81 9f

          SEQUENCE         

             30 81 9c

           SEQUENCE         

              30 81 99

            OCTET STRING     

               04 14 5c f1 18 f3 4a ca b4 67 d6 d8 e7 f8 3b 4a d9 7a 32 a5

               43 a5

            SEQUENCE         

               30 81 80

             SEQUENCE         

                30 74

              cont [ 4 ]       

                 a4 72

               SEQUENCE         

                  30 70

                SET              

                   31 0b

                 SEQUENCE         

                    30 09

                  OBJECT            :countryName

                     06 03 55 04 06

                  PRINTABLESTRING   :FR

                     13 02 46 52

                SET              

                   31 15

                 SEQUENCE         

                    30 13

                  OBJECT            :organizationName

                     06 03 55 04 0a

                  PRINTABLESTRING   :EdelWeb S.A.

                     13 0c 45 64 65 6c 57 65 62 20 53 2e 41 2e

                SET              

                   31 28

                 SEQUENCE         

                    30 26

                  OBJECT            :organizationalUnitName

                     06 03 55 04 0b

                  PRINTABLESTRING   :Clepsydre Demonstration Service

                     13 1f 43 6c 65 70 73 79 64 72 65 20 44 65 6d 6f 6e 73 74 72

                     61 74 69 6f 6e 20 53 65 72 76 69 63 65

                SET              

                   31 20

                 SEQUENCE         

                    30 1e

                  OBJECT            :commonName

                     06 03 55 04 03

                  PRINTABLESTRING   :Time Stamping Authority

                     13 17 54 69 6d 65 20 53 74 61 6d 70 69 6e 67 20 41 75 74 68

                     6f 72 69 74 79

             INTEGER           :94882572352750

                02 08 00 94 88 25 72 35 27 50

      SEQUENCE         

         30 0d

       OBJECT            :rsaEncryption

          06 09 2a 86 48 86 f7 0d 01 01 01

       NULL             

          05 00

      OCTET STRING     

         04 82 01 00 2e 70 9f 56 5e 01 56 a9 e1 47 81 12 35 21 29 09

         16 7a ed 45 f9 5a a2 ed e4 fe 9d 2c e4 da 12 66 62 14 59 61

         8b 50 7b 01 82 3d bd 7e e6 38 d0 a8 a0 37 98 79 13 26 39 29

         c6 72 20 a9 95 71 e7 53 7f 79 77 98 ef 23 02 4e b9 bd 90 9b

         ac 05 a2 70 8f 3a 42 36 9c 2c b0 94 b1 2b 0b 36 94 0e 78 0e

         b0 d1 09 20 63 bc ff cd 32 f1 5a d3 ab 9f 93 9c 5a a3 58 99

         a0 28 11 e0 80 4d 4d 1e 77 04 f4 50 07 d5 8b 54 a0 23 32 ff

         a6 9c e2 ba b8 db 55 47 c9 c8 ba 07 ef 90 14 48 a8 b6 c5 7c

         d5 a9 20 74 1c 56 ef 8f 1b b3 fc 87 6d 81 f1 d4 6f 1a 87 30

         92 47 69 e0 79 e0 bc 10 99 cf 4d 36 4c 36 03 51 72 d1 5b a6

         1e 2d 86 f1 1f 0a e8 bf eb 38 f9 ce 1a ec b0 8f 51 ae 2a 3b

         46 84 bf 4d 8c 9f ee 1f ef c5 35 a3 63 be 38 c0 03 7c 3a 5e

         b8 cf 3b 18 10 88 db bb 4f 78 f6 fb e4 1c 8d d4 f8 fb eb 50

 

8.13           Time Stamp Protocol (TSP)

Tč. se jedná pouze o návrh protokolu (RFC draft). Zatímco protokol DVCSP je poměrně komplikovaným protokolem, u nějž se předpokládá, že např. pro ověřování elektronického podpisu dokumentu budou aplikace zpočátku implementovat jen část protokolu, tak protokol TSP je jednoduchým protokolem pro vydávání časových razítek.

 

Protokol TSP je určen pro server označovaný jako „autorita pro vydávání časových razítek (Time Stamping Authority –TSA)“. Předpokládá se, že TSA bude provozovat nějaká důvěryhodná nezávislá organizace.

 

Jak jsme popsali již v případě protokolu DVCSP, tak časové razítko elektronického dokumentu uživatel získá tak, že na TSA zašle kontrolní součet z tohoto dokumentu a TSA mu vrátí časové razítko, což je elektronicky podepsaný zaslaný kontrolní součet.

 

Jelikož je časové razítko elektronicky podepsaný dokument, tak si hypoteticky  můžeme časová razítka nechat ověřit DVCS serverem.

 

 TSA je povinna:

         id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)

               identified-organization(3) dod(6)  internet(1) security(5)

               mechanisms(5) pkix(7)  kp (3) timestamping (8)}

8.13.1                  Transportní protokoly

Jako transportní protokoly je možné použít např. elektronickou poštu či protokol HTTP. Žádost o časové razítko používá MIME hlavičku (resp. hlavičku protokolu HTTP):

 

Content-Type: application/timestamp-query

 

A časové razítko používá hlavičku:

 

Content-Type: application/timestamp-replay

 

V případě elektronické pošty je třeba DER kódovanou zprávu (tj. jak žádost tak i časové razítko) kódovat Base64, tj. přidá se ještě hlavička:

 

Content-Transfer-Encoding: Base64

 

Pro jména souborů jsou následující konvence: