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.

 

Oficiální definice jedinečného jména je:

  Name ::= CHOICE {

     RDNSequence }

 

(opravdu to není chyba, že se tč. jedná o výběr z jediné možnosti)

 

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

 

   RelativeDistinguishedName ::=

     SET OF AttributeTypeAndValue

 

   AttributeTypeAndValue ::= SEQUENCE {

     type     AttributeType,

     value    AttributeValue }

 

   AttributeType ::= OBJECT IDENTIFIER

 

   AttributeValue ::= ANY DEFINED BY AttributeType

 

   DirectoryString ::= CHOICE {

         teletexString           TeletexString (SIZE (1..MAX)),

         printableString         PrintableString (SIZE (1..MAX)),

         universalString         UniversalString (SIZE (1..MAX)),

         utf8String              UTF8String (SIZE (1.. MAX)),

         bmpString               BMPString (SIZE (1..MAX)) }

 

Všimněte si, že řetězec může pro naše zeměpisné šířky být v kódu UTF-8 (utf8String) nebo UCS-2 (bmpString). Dokonce podle RFC-2459 musí všechny certifikáty vydané po 31. prosinci 2003 používat výhradně (kromě specifikovaných výjimek) pouze kódování UTF-8. To se týká jak předmětu certifikátu, tak i jména vydavatele (jména CA) i některých rozšíření certifikátu.

 

UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING

BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 

 

Nyní lidsky. 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 Number*)

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 Adress*)

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

 

Kde

id-at   OBJECT IDENTIFIER  ::=  {joint-iso-ccitt(2) ds(5) 4}

pkcs-9  OBJECT IDENTIFIER  ::=  {iso(1) member-body(2) us(840)

rsadsi(113549) pkcs(1) 9}.

 

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.

 

Příklad:

   SEQUENCE         

      30 5d

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :countryName

         06 03 55 04 06

      PRINTABLESTRING   :CZ

         13 02 43 5a

    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

    SET              

       31 11

     SEQUENCE         

        30 0f

      OBJECT            :organizationalUnitName

         06 03 55 04 0b

      PRINTABLESTRING   :20000901

         13 08 32 30 30 30 30 39 30 31

    SET              

       31 28

     SEQUENCE         

        30 26

      OBJECT            :commonName

         06 03 55 04 03

      PRINTABLESTRING   :Certifikacni autorita I.CA 0009

         13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

         69 74 61 20 49 2e 43 41 20 30 30 30 39

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.

 

U certifikátů kořenových certifikačních autorit obsahuje předmět i vystavitel stejné údaje. Kořenová certifikační autorita si podepisuje certifikáty sama sobě – vydává tzv. „self-signed“ certifikáty.

 

Mnohé údaje, které se „nevejdou“ do předmětu certifikátu, je možné uložit do rozšíření certifikátu.

 

Příklad:

   SEQUENCE         

      30 74

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :countryName

         06 03 55 04 06

      PRINTABLESTRING   :CZ

         13 02 43 5a

    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

    SET              

       31 19

     SEQUENCE         

        30 17

      OBJECT            :organizationalUnitName

         06 03 55 04 0b

      PRINTABLESTRING   :Ceske Budejovice

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

    SET              

       31 17

     SEQUENCE         

        30 15

      OBJECT            :commonName

         06 03 55 04 03

      PRINTABLESTRING   :Libor Dostalek

         13 0e 4c 69 62 6f 72 20 44 6f 73 74 61 6c 65 6b

    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

8.1.8                      Veřejný klíč

   SubjectPublicKeyInfo  ::=  SEQUENCE  {

        algorithm            AlgorithmIdentifier,

        subjectPublicKey     BIT STRING  }

 

Položka SubjectPublicKeyInfo je sekvencí dvou informací: identifikátorem algoritmu, pro který je veřejný klíč určen, a samotným veřejným klíčem.

 

Na rozdíl od položek signatureAlgorithm a signature neobsahuje položka algorithm identifikátor algoritmu, kterým je certifikát podepsán, ale obsahuje identifikátor šifrovacího algoritmu, pro který je určen veřejný klíč, který je  v certifikátu.

 

Příklad:

   SEQUENCE         

      30 81 9f

    SEQUENCE         

       30 0d

     OBJECT            :rsaEncryption

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

     NULL             

        05 00

    BIT STRING       

       03 81 8d 00 30 81 89 02 81 81 00 ad e7 93 2d 2b 10 78 0c 17

       e2 88 d7 bd c4 b4 f4 39 bf 32 39 24 60 f1 61 7f b1 fe 59 96

       c1 3a 5d 0d e2 e3 79 8d 6e ee c3 74 1d fa 17 1c 02 c1 6e 3f

       0e 17 e5 a1 d4 95 a5 35 34 80 5c b4 97 17 a1 c1 94 16 2a 32

       11 8e 3e 58 dd e8 a2 10 03 1c 0b ec fe 83 9d 47 06 ac 9f a7

       51 80 68 07 ad 1a da f2 4d ee 1e ff 58 fb 88 5d 54 85 23 d5

       78 29 90 db 5f ac db ad 2b 02 90 7f 07 17 d0 40 70 e6 2b 02

       03 01 00 01

 

Soukromý a 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íč… .

 

Co se týká čipových karet, které generují dvojici klíčů samy. Tak tady číhá  nebezpečí v případě, že má karta obě funkce, tj. umí si dvojici vygenerovat sama i umí načíst soukromý klíč vygenerovaný mimo kartu. Pak kartu vložíte do krabice v domnění, že karta sama bude generovat dvojici klíčů. Podvržená krabice však vygeneruje dvojici sama (poznamená si soukromý klíč) a soukromý klíč vloží do karty. Pokud generujete dvojici na kartě s oběma funkcemi, pak dvojici můžete generovat pouze na důvěryhodném zařízení (např. na vašem osobním PC – pokud je opravdu osobní).

 

8.1.9                      Jednoznačné identifikátory

Norma X.509 verze 2 přinesla dvě další položky certifikátu:

 

PKI striktně doporučuje tyto položky nepoužívat.

8.1.10                  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í. Položka rozšíření (nebo někdy též přípona certifikátu) je sekvencí obsahující jednotlivá rozšíření:

 

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

 

Jednotlivé rozšíření je samo sekvencí skládající se z identifikátoru rozšíření, závažnosti rozšíření a hodnoty prozšíření:

 

   Extension  ::=  SEQUENCE  {

        extnID      OBJECT IDENTIFIER,

        critical    BOOLEAN DEFAULT FALSE,

        extnValue   OCTET STRING  }

 

I když rozšíření je definováno zcela obecně, tak je i u rozšíření potíž podobně jako u atributů předmětu certifikátu spočívající v tom, že aplikace s některým rozšířením nebude počítat – nebude znát, k čemu nějaké konkrétní rozšíření slouží. Tento problém řeší položka závažnost rozšíření (critical). Tato položka sděluje, jestli je rozšíření kritické či nikoliv. V případě, že je tato položka nastavena na TRUE, pak je rozšíření označeno jako kritické.

 

Jelikož je certifikát kódován v DER, které přikazuje, aby se volitelné položky nekódovaly v případě, že nabývají implicitních hodnot, tak ve výpisu certifikátu nesmíme být překvapeni, že pokud není rozšíření kritické, tak položka critical chybí.

 

Samotná hodnota rozšíření (extentValue) je řetězec bajtů (OCTET STRING). Dále uvidíme, že hodnota rozšíření certifikátu je často komplikovaně strukturovaná; tak proč se rozšíření jako celek strčí do jednoho pytle OCTET STRING? Důvod je prostý. V certifikátu muže být rozšíření, které je zpracovávajícímu programu neznámé. Pak je podstatně snazší přeskočit celý pytel neznámého obsahu, než  procházet neznámou strukturu.

 

Software pracující s certifikátem musí znát všechna kritická rozšíření – musí si být vědom závažnosti informací v nich uvedených. V případě, že některé z rozšíření v certifikátu je označeno jako kritické a software neví, k čemu toto rozšíření slouží, pak musí celý certifikát odmítnout.

 

Této vlastnosti využívá např. protokol SET určený k platbám na Internetu. V tomto protokolu se používají rovněž certifikáty dle X.509, ve kterých je řada rozšíření specifických pro protokol SET. Mnohá z nich jsou označena jako kritická. To zamezí použití těchto certifikátů v jiných aplikacích (např. ve webovém prohlížeči pro protokol HTTPS).

 

Pro rozšíření certifikátů se často používá objekt:

   id-ce   OBJECT IDENTIFIER ::=  {joint-iso-ccitt(2) ds(5) 29}

 

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.

 

 

   AuthorityKeyIdentifier ::= SEQUENCE {

      keyIdentifier             [0] KeyIdentifier           OPTIONAL,

      authorityCertIssuer       [1] GeneralNames            OPTIONAL,

      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

 

Kde

KeyIdentifier ::= OCTET STRING

 

Toto rozšíření je tak sekvencí tří údajů:

Prakticky se do uživatelského certifikátu do rozšíření „Identifikátor klíče certifikační autority“ uvede buď keyIdentifier nebo authorityCertSerialNumber, který se převezme z rozšíření „Identifikátor klíče předmětu“ certifikátu CA, jemuž příslušným soukromým klíčem se vystavovaný certifikát podepíše.

 

V  případě kořenové CA se toto rozšíření  nemusí používat,  je však doporučeno toto rozšíření použít ve všech uživatelských certifikátech.

 

Toto rozšíření nesmí být označeno jako kritické.

 

Cvičení:

Pokud používáte MS Explorer, pak si zobrazte certifikáty „zprostředkujících certifikačních úřadů“, tj. certifikáty certifikačních autorit, jež nejsou kořenové. V detailním pohledu na rozšíření certifikátu pak nalezněte rozšíření „identifikace klíče úřadu“, tj. rozšíření popisované v této kapitole.

 

 

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“.

 

Rozšíření identifikátor klíče předmětu se definuje:

 

SubjectKeyIdentifier ::= KeyIdentifier

 

Kde

KeyIdentifier ::= OCTET STRING

 

Toto rozšíření umožňuje identifikovat veřejný klíč. K identifikaci je možné použít např. číslování jednotlivých vygenerovaných klíčů. RFC-2459 navrhuje používat jako identifikátor např. kontrolní součet veřejného klíče vytvořený algoritmem SHA-1. Důvod je opět prostý: kontrolní součet z veřejného klíče může provést sama CA, kdežto číslování vydaných certifikátů by bylo sporné v tom, jestli si jej má dělat uživatel, nebo snad CA jej má generovat ze své evidence, což je podstatně komplikovanější.

 

Hodnota uvedená v rozšíření „Identifikátor klíče předmětu“ z certifikátů certifikační autority se často vkládá do uživatelského certifikátu do rozšíření  „Identifikátor klíče certifikační autority“.

 

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

 

Příklad:

     SEQUENCE         

        30 1d

      OBJECT            :X509v3 Subject Key Identifier

         06 03 55 1d 0e

      OCTET STRING     

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

         67 44 2e 1e

Tento příklad jsem převzal z certifikátu CA. Plynou z něj následující ponaučení pro analýzu rozšíření certifikátů:

 

OCTET STRING     

    04 14 31 df 5d 34 67 56 16 ed f5 18 b7 54 e0 47 51 c0 67 44

    2e 1e

 

Ten opět můžeme rozebrat:

 

OCTET STRING     

    31 df 5d 34 67 56 16 ed f5 18 b7 54 e0 47 51 c0 67 44 2e 1e

 

No a nyní si v MS Exploreru vypíšeme pro tento certifikát rozšíření „Identifikator klíče předmětu a obdržíme:

 

31DF 5D34 6756 16ED F518 B754 E047 51C0 6744 2E1E

 

Doba platnosti soukromého klíče - Private Key Usage Period

Jedná se o rozšíření zmíněné v kapitole „Platnost certifikátu“. RFC-2459 nepovoluje toto rozšíření používat.

 

   PrivateKeyUsagePeriod ::= SEQUENCE {

        notBefore       [0]     GeneralizedTime OPTIONAL,

        notAfter        [1]     GeneralizedTime OPTIONAL }

 

 

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.

 

      KeyUsage ::= BIT STRING {

           digitalSignature        (0),

           nonRepudiation          (1),

           keyEncipherment         (2),

           dataEncipherment        (3),

           keyAgreement            (4),

           keyCertSign             (5),

           cRLSign                 (6),

           encipherOnly            (7),

           decipherOnly            (8) }

 

 

Význam jednotlivých bitů:

 

Pokud bychom chtěli vydat certifikát se všemi nastavenými bity, pak jej vydáme bez tohoto rozšíření.

 

Příklad:

     SEQUENCE         

        30 0e

      OBJECT            :X509v3 Key Usage

         06 03 55 1d 0f

      BOOLEAN           :255

         01 01 ff

      OCTET STRING     

         04 04 03 02 01 06

 

Rozšíření je označeno jako kritické. Opět rozebereme řetězec bajtů obsahující vlastní rozšíření, tj. uřízneme 04 (= typ OCTET STRING) a 04 (= délka řetězce) a zbude nám 03 02 01 06. Jedná o se o bitový řetězec (03) dlouhý 2 bajty. Přičemž první bajt je délka výplně (01), tj. bitový řetězec byl zprava doplněn jedním bitem.

 

Takže abychom získali výsledný  bitový řetězec musí převést poslední bajt 06 do dvojkové soustavy a získáme 00000110. Poslední nula je jen výplň, takže bitový řetězec je 0000011. Tj. jsou nastaveny pouze bity 5 a 6 (počítá se od nuly), tj. bit keyCertSign a bit cRLSign. MS Exporer u tohoto rozšíření vypíše:

 

Podepisování certifikátu , Podepisování CRL v režimu offline , Podepisování CRL(06)

 

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.

 

   ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

 

Kde je

KeyPurposeId ::= OBJECT IDENTIFIER

 

Jestliže je rozšíření označeno jako kritické, pak certifikát musí být použit pouze k uvedeným účelům. Rozšíření „Použití klíče“ a rozšíření „Rozšířené použití klíče“ musí být zpracovávány samostatně. Tj. obě rozšíření musí být konzistentní, nemůže jedno rozšíření něco zakázat a druhé totéž povolit.

 

RFC-2459 zavádí následující objekty:

   id-kp-serverAuth              OBJECT IDENTIFIER ::=   {id-kp 1}

   id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}

   id-kp-codeSigning             OBJECT IDENTIFIER ::=   {id-kp 3}

   id-kp-emailProtection         OBJECT IDENTIFIER ::=   {id-kp 4}

   id-kp-ipsecEndSystem          OBJECT IDENTIFIER ::=   {id-kp 5}

   id-kp-ipsecTunnel             OBJECT IDENTIFIER ::=   {id-kp 6}

   id-kp-ipsecUser               OBJECT IDENTIFIER ::=   {id-kp 7}

   id-kp-timeStamping            OBJECT IDENTIFIER ::=   {id-kp 8}

   id-kp-OCSPSigning             OBJECT IDENTIFIER ::=   {id-kp 9}

Kde

id-kp OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6)

                       internet(1) security(5) mechanisms(5) pkix(7) 3}

 

Význam jednotlivých objektů:

 

Při vydávání certifikátů je třeba zajistit, aby údaje v rozšířeních „Použití klíče“ a „Rozšířené použití klíče“ byly vzájemně konzistentní.

 

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:

 

 

      SubjectAltName ::= GeneralNames

 

      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

 

      GeneralName ::= CHOICE {

           otherName                       [0]     OtherName,

           rfc822Name                      [1]     IA5String,

           dNSName                         [2]     IA5String,

           x400Address                     [3]     ORAddress,

           directoryName                   [4]     Name,

           ediPartyName                    [5]     EDIPartyName,

           uniformResourceIdentifier       [6]     IA5String,

           iPAddress                       [7]     OCTET STRING,

           registeredID                    [8]     OBJECT IDENTIFIER}

 

      OtherName ::= SEQUENCE {

           type-id    OBJECT IDENTIFIER,

           value      [0] EXPLICIT ANY DEFINED BY type-id }

 

      EDIPartyName ::= SEQUENCE  {

           nameAssigner            [0]     DirectoryString OPTIONAL,

           partyName               [1]     DirectoryString }

 

Příklad:

     SEQUENCE         

        30 29

      OBJECT            :X509v3 Subject Alternative Name

         06 03 55 1d 11

      OCTET STRING     

         04 22 30 20 81 0b 6f 70 65 72 40 69 63 61 2e 63 7a 86 11 68

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

 

Po rozbalení řetězce „30 20 81 0b 6f 70 65 72 40 69 63 61 2e 63 7a 86 11 68 74 74 70 3a 2f 2f 77 77 77 2e 69 63 61 2e 63 7a“ dostaneme:

 

SEQUENCE         

    30 20

  cont [ 1 ]        :oper@ica.cz

     81 0b 6f 70 65 72 40 69 63 61 2e 63 7a

  cont [ 6 ]        :http://www.ica.cz

     86 11 68 74 74 70 3a 2f 2f 77 77 77 2e 69 63 61 2e 63 7a

(Ty řetězce za dvojtečkou jsem doplnil ručně, jelikož se jedná o typy platné pouze v rámci struktury, tak žádný konvertor nepozná o jaký typ se jedná).

 

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.

 

Rozšíření „Certifikační politika“ obsahuje sekvenci, kde každý její prvek identifikuje jeden dokument (PolicyInformation):

 

  certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

 

Každý dokument (PolicyInformation) je sekvencí skládající se z identifikátoru objektu certifikační politiky (policyIdentifier) a parametrů  této certifikační politiky (policyQualifiersInfo):

 

   PolicyInformation ::= SEQUENCE {

        policyIdentifier   CertPolicyId,

        policyQualifiers   SEQUENCE SIZE (1..MAX) OF

                                PolicyQualifierInfo OPTIONAL }

 

   CertPolicyId ::= OBJECT IDENTIFIER

 

RFC-2459 doporučuje používat pouze identifikátory objektů (bez parametrů).

Každý parametr je pak sekvencí skládající se z identifikátoru objektu parametru (policyQualifierId) a kvalifikátoru (qualifier):

 

   PolicyQualifierInfo ::= SEQUENCE {

        policyQualifierId  PolicyQualifierId,

        qualifier          ANY DEFINED BY policyQualifierId }

 

V opodstatněných případech RFC-2459 připouští pouze dva parametry pro certifikační politiku:

        noticeRef        NoticeReference OPTIONAL,
        explicitText     DisplayText OPTIONAL}

 

-         Položka noticeRef  identifikuje text připravený organizací a uložený např. na disku.  Dále může obsahovat číslo blíže určující zobrazovaný text:

NoticeReference ::= SEQUENCE {

organization     DisplayText,
noticeNumbers    SEQUENCE OF INTEGER }

-         Položka  explicitText pak obsahuje maximálně 200 znaků dlouhý text přímo obsažený v certifikátu.
      
DisplayText ::= CHOICE {

                        visibleString    VisibleString  (SIZE (1..200)),

                        bmpString        BMPString      (SIZE (1..200)),
                        utf8String       UTF8String     (SIZE (1..200)) }

  

Příklad:

     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

 

 Rozborem řetězce obdržíme:

SEQUENCE         

    30 67

  SEQUENCE         

     30 65

   OBJECT            :1.3.6.1.4.1.6625.1.1.2

      06 0a 2b 06 01 04 01 b3 61 01 01 02

   SEQUENCE         

      30 57

    SEQUENCE         

       30 2d

     OBJECT            :Policy Qualifier CPS

        06 08 2b 06 01 05 05 07 02 01

    //www.ica.cz/bezpecnost.html

        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

    SEQUENCE         

       30 26

     OBJECT            :Policy Qualifier CPS

        06 08 2b 06 01 05 05 07 02 01

    //www.ica.cz/rad.html

        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

 

 

 

Policy Mappings

Toto rozšíření se používá pouze v certifikátech certifikačních autorit. Má význam v případě, že certifikát certifikační autority je podepsán jinou CA. V takovém případě je pravděpodobné, že nadřízená certifikační autorita si vydá jinou certifikační politiku než podřízená certifikační autorita. Při ověřování řetězce certifikátů je pak důležité, aby certifikační politiky jednotlivých certifikátů v řetězci byly konzistentní. Jelikož každá CA má pro své certifikační politiky své identifikátory objektu, tak  úkolem rozšíření Policy Mappings je sdělit, že ta a ta certifikační politika vydavatele (nadřízené CA - issuerDomainPolicy) je srovnatelná s tou a tou certifikační politikou předmětu (podřízené CA - subjectDomainPolicy).

 

Rozšíření „Policy Mappings“  pak obsahuje sekvenci dvojic:

 

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

        issuerDomainPolicy      CertPolicyId,

        subjectDomainPolicy     CertPolicyId }

 

 

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).

 

BasicConstraints ::= SEQUENCE {

        cA                      BOOLEAN DEFAULT FALSE,

        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

 

 

Toto rozšíření se označuje jako kritické a používá se pouze u certifikátů CA.

 

Příklad:

    SEQUENCE         

       30 82 01 08

     SEQUENCE         

        30 0f

      OBJECT            :X509v3 Basic Constraints

         06 03 55 1d 13

      BOOLEAN           :255

         01 01 ff

      OCTET STRING     

         04 05 30 03 01 01 ff

Po rozboru řetězce zjistíme, že řetězec obsahuje pouze položku cA a neobsahuje položku pathLenConstraint:

SEQUENCE          

    30 03

  BOOLEAN           :255

     01 01 ff

 

 

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):

 

 cRLDistributionPoints ::= {

        CRLDistPointsSyntax }

 

   CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

 

Každé distribuční místo je specifikováno sekvencí:

 

   DistributionPoint ::= SEQUENCE {

        distributionPoint       [0]     DistributionPointName OPTIONAL,

        reasons                 [1]     ReasonFlags OPTIONAL,

        cRLIssuer               [2]     GeneralNames OPTIONAL }

 

Kde DistributionPointName obsahuje konkrétní URI:

 

   DistributionPointName ::= CHOICE {

        fullName                [0]     GeneralNames,

        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

 

Volitelná položka  ReasonsFlags může obsahovat důvody odvolání certifikátu, pro které se tento seznam odvolaných certifikátů vystavuje:

 

   ReasonFlags ::= BIT STRING {

        unused                  (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6) }

 

Není-li položka ReasonsFlags uvedena, pak se jedná o kompletní CRL. Poslední volitelnou položkou je jméno vydavatele (jméno CA), pro kterou je CRL vystaven (cRLIssuer), není-li tato položka uvedena, pak CRL je vydáno pro CA, která vydala tento certifikát.

 

Příklad:

     SEQUENCE         

        30 29

      OBJECT            :X509v3 CRL Distribution Points

         06 03 55 1d 1f

      OCTET STRING     

         04 22 30 20 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

 

Po rozboru řetězce obdržíme:  

SEQUENCE         

    30 20

  SEQUENCE         

     30 1e

   cont [ 0 ]       

      a0 1c

    cont [ 0 ]       

       a0 1a

     cont [ 6 ]            :http://ca.ica.cz/crl.cgi

        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

 

 

Subject directory attributes

Jedná se o rozšíření obsahující další atributy, které se nevešly do předmětu certifikátu. Rozšíření obsahuje sekvenci těchto atributů.

 

Toto rozšíření není normou RFC-2459 doporučeno k všeobecnému použití. Norma RFC-3039 pro kvalifikované certifikáty však zavádí některé atributy pro toto rozšíření.

 

8.1.11                  Privátní rozšíření certifikátu

Tato rozšíření jsou zavedena pro PKI. Používají následující objekty:

 

id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

 

id-pe    OBJECT IDENTIFIER  ::= { id-pkix 1 }

id-ad    OBJECT IDENTIFIER  ::= { id-pkix 48 }

 

Rozšíření

Označení

OID (extnID)

Přístupové informace CA

id-pe-authorityInfoAccess

{id-pe 1}

 

Přístupové informace CA

Toto rozšíření obsahuje informace o tom, jak OnLine zjišťovat platnost certifikátu nebo politiku CA. Toto rozšíření obsahuje sekvenci jednotlivých přístupovových informací:

 

  AuthorityInfoAccessSyntax  ::=

           SEQUENCE SIZE (1..MAX) OF AccessDescription

 

Konkrétní přístupová informace je pak sekvencí identifikátoru objektu specifikujícího konkrétní přístupové informace a vlastních informací (accessLocation):

 

   AccessDescription  ::=  SEQUENCE {

           accessMethod          OBJECT IDENTIFIER,

           accessLocation        GeneralName  }

 

Jsou definovány následující identifikátory objektů (následující typy přístupových informací):

id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

id-ad-ocsp      OBJECT IDENTIFIER ::= { id-ad 1 }

 

Kde

 

8.1.12                  Příklad certifikátu

Rozebereme si nějaký kratší certifikát a pro ušetření papíru jej vypíši ve dvou sloupcích:

 

SEQUENCE         

    30 82 02 96

  SEQUENCE         

     30 82 01 ff

   cont [ 0 ]       

      a0 03

    INTEGER           :02

       02 01 02

   INTEGER           :01E012

      02 03 01 e0 12

   SEQUENCE         

      30 0d

    OBJECT            :md5WithRSAEncryption

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

    NULL             

       05 00

   SEQUENCE         

      30 5d

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :countryName

         06 03 55 04 06

      PRINTABLESTRING   :CZ

         13 02 43 5a

    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

    SET              

       31 11

     SEQUENCE         

        30 0f

      OBJECT            :organizationalUnitName

         06 03 55 04 0b

      PRINTABLESTRING   :20000901

         13 08 32 30 30 30 30 39 30 31

    SET              

       31 28

     SEQUENCE         

        30 26

      OBJECT            :commonName

         06 03 55 04 03

      PRINTABLESTRING   :Certifikacni autorita I.CA 0009

         13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

         69 74 61 20 49 2e 43 41 20 30 30 30 39

   SEQUENCE         

      30 1e

    UTCTIME           :010212104051Z

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

    UTCTIME           :010814104051Z

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

   SEQUENCE         

      30 74

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :countryName

         06 03 55 04 06

      PRINTABLESTRING   :CZ

         13 02 43 5a

    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

 

    SET              

       31 19

     SEQUENCE         

        30 17

      OBJECT            :organizationalUnitName

         06 03 55 04 0b

      PRINTABLESTRING   :Ceske Budejovice

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

    SET              

       31 17

     SEQUENCE         

        30 15

      OBJECT            :commonName

         06 03 55 04 03

      PRINTABLESTRING   :Libor Dostalek

         13 0e 4c 69 62 6f 72 20 44 6f 73 74 61 6c 65 6b

    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 81 9f

    SEQUENCE         

       30 0d

     OBJECT            :rsaEncryption

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

     NULL             

        05 00

    BIT STRING       

       03 81 8d 00 30 81 89 02 81 81 00 ad e7 93 2d 2b 10 78 0c 17

       e2 88 d7 bd c4 b4 f4 39 bf 32 39 24 60 f1 61 7f b1 fe 59 96

       c1 3a 5d 0d e2 e3 79 8d 6e ee c3 74 1d fa 17 1c 02 c1 6e 3f

       0e 17 e5 a1 d4 95 a5 35 34 80 5c b4 97 17 a1 c1 94 16 2a 32

       11 8e 3e 58 dd e8 a2 10 03 1c 0b ec fe 83 9d 47 06 ac 9f a7

       51 80 68 07 ad 1a da f2 4d ee 1e ff 58 fb 88 5d 54 85 23 d5

       78 29 90 db 5f ac db ad 2b 02 90 7f 07 17 d0 40 70 e6 2b 02

       03 01 00 01

   cont [ 3 ]       

      a3 4d

    SEQUENCE         

       30 4b

     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 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

 

 

DER-kódovaný certifikát mohu vypsat šestnáctkově (což není nic jiného než předchozí výpis po vypuštění textových komentářů):

 

30820296308201ffa003020102020301e012300d06092a864886f70d0101040500305d310b300906

035504061302435a3111300f060355040a130850565420612e732e3111300f060355040b13083230

303030393031312830260603550403131f436572746966696b61636e69206175746f726974612049

2e43412030303039301e170d3031303231323130343035315a170d3031303831343130343035315a

3074310b300906035504061302435a3111300f060355040a130850565420612e732e311930170603

55040b13104365736b6520427564656a6f76696365311730150603550403130e4c69626f7220446f

7374616c656b311e301c06092a864886f70d010901160f646f7374616c656b407076742e637a3081

9f300d06092a864886f70d010101050003818d0030818902818100ade7932d2b10780c17e288d7bd

c4b4f439bf32392460f1617fb1fe5996c13a5d0de2e3798d6eeec3741dfa171c02c16e3f0e17e5a1

d495a53534805cb49717a1c194162a32118e3e58dde8a210031c0becfe839d4706ac9fa751806807

ad1adaf24dee1eff58fb885d548523d5782990db5facdbad2b02907f0717d04070e62b0203010001

a34d304b30490603551d1f04423040301ea01ca01a8618687474703a2f2f63612e6963612e637a2f

63726c2e636769301ea01ca01a8618687474703a2f2f70732e6970622e637a2f63726c2e63676930

0d06092a864886f70d010104050003818100280acad333e191d4bb98f5d1fbaa591875fd47a694e4

c4f5df4bf60127e768bfd91aa92f75da58d8fd7adb2656ba0ce9b35cb76ec7135f087cbcfb3b7ccd

c85b6a5da8cbebefdc4b04680621cb02fc355b7ca2180d918d2ca5782cb33437f086e2d2f9c45f9e

0e270f4043aa0141de46ece4780cb914aa9f7f382a8d4e1c3ceb

 

Jenže běžnější je, že se certifikát nevypisuje šestnáctkově, ale DER-kódovaný certifikát se kóduje Base64.

A po doplnění úvodního a koncového řádku obdržíme certifikát ve tvaru PEM (někdy označovaném též jako CER):

 

-----BEGIN CERTIFICATE-----

MIICljCCAf+gAwIBAgIDAeASMA0GCSqGSIb3DQEBBAUAMF0xCzAJBgNVBAYTAkNa

MREwDwYDVQQKEwhQVlQgYS5zLjERMA8GA1UECxMIMjAwMDA5MDExKDAmBgNVBAMT

H0NlcnRpZmlrYWNuaSBhdXRvcml0YSBJLkNBIDAwMDkwHhcNMDEwMjEyMTA0MDUx

WhcNMDEwODE0MTA0MDUxWjB0MQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZUIGEu

cy4xGTAXBgNVBAsTEENlc2tlIEJ1ZGVqb3ZpY2UxFzAVBgNVBAMTDkxpYm9yIERv

c3RhbGVrMR4wHAYJKoZIhvcNAQkBFg9kb3N0YWxla0BwdnQuY3owgZ8wDQYJKoZI

hvcNAQEBBQADgY0AMIGJAoGBAK3nky0rEHgMF+KI173EtPQ5vzI5JGDxYX+x/lmW

wTpdDeLjeY1u7sN0HfoXHALBbj8OF+Wh1JWlNTSAXLSXF6HBlBYqMhGOPljd6KIQ

AxwL7P6DnUcGrJ+nUYBoB60a2vJN7h7/WPuIXVSFI9V4KZDbX6zbrSsCkH8HF9BA

cOYrAgMBAAGjTTBLMEkGA1UdHwRCMEAwHqAcoBqGGGh0dHA6Ly9jYS5pY2EuY3ov

Y3JsLmNnaTAeoBygGoYYaHR0cDovL3BzLmlwYi5jei9jcmwuY2dpMA0GCSqGSIb3

DQEBBAUAA4GBACgKytMz4ZHUu5j10fuqWRh1/UemlOTE9d9L9gEn52i/2RqpL3Xa

WNj9etsmVroM6bNct27HE18IfLz7O3zNyFtqXajL6+/cSwRoBiHLAvw1W3yiGA2R

jSyleCyzNDfwhuLS+cRfng4nD0BDqgFB3kbs5HgMuRSqn384Ko1OHDzr

-----END CERTIFICATE-----

 

Abych byl úplně upřímný, tak abych vám tento certifikát takto zobrazil, tak jsem si jej vyexportoval z MS Exploreru právě jako certifikát typu „X.509, kódování Base-64 (CER)“. S tím exportem je svázaná ještě další věc. Jelikož se jedná o můj osobní certifikát, tak v úložišti Windows 2000 je k tomuto certifikátu i soukromý klíč, takže jsem dotazován, zda-li si přeji export pouze certifikátu (výše uvedený případ) nebo chci exportovat jak certifikát, tak i soukromý klíč.  Exportem dvojice certifikát + soukromý klíč se zabývá norma PKCS#12.

 

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

 

Kde

 

id-pda  OBJECT IDENTIFIER  ::=  {iso(1) identified-organization(3) dod(6)

      internet(1) security(5) mechanisms(5) pkix(7) 9}

 

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}

 

Kde

id-pe  OBJECT IDENTIFIER  ::=  {iso(1) identified-organization(3) dod(6)

      internet(1) security(5) mechanisms(5) pkix(7) 1}

 

 

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.

 

      BiometricData ::= SEQUENCE {

          typeOfBiometricData  TypeOfBiometricData,

          hashAlgorithm        AlgorithmIdentifier,

          biometricDataHash    OCTET STRING,

          sourceDataUri        IA5String OPTIONAL }

 

      TypeOfBiometricData ::= CHOICE {

          predefinedBiometricType    PredefinedBiometricType,

          biometricDataID            OBJECT IDENTIFIER }

 

      PredefinedBiometricType ::= INTEGER { picture(0),

          handwritten-signature(1)} (picture|handwritten-signature,...)

 

Jednotlivá biometrická vlastnost držitele (Biometricdata) obsahuje:

 

Rozšíření nesmí být označeno jako kritické.

 

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.

 

Tvar CRL specifikovala norma X.509. Avšak v Internetu používáme CRL, které sice vycházejí ze specifikace CRL podle normy X.509 verze 2, ale opět je tato struktura pro Internet popsána v RFC-2459. Podle RFC-2459 musí CRL obsahovat: pravděpodobné datum a čas vydání následujícího CRL, číslo CRL uvedené v příslušném rozšíření CRL a rozšíření „Identifikátor klíče certifikační autority“.

 

   CertificateList  ::=  SEQUENCE  {

        tbsCertList          TBSCertList,

        signatureAlgorithm   AlgorithmIdentifier,

        signatureValue       BIT STRING  }

 

   TBSCertList  ::=  SEQUENCE  {

        version                 Version OPTIONAL,

        signature               AlgorithmIdentifier,

        issuer                  Name,

        thisUpdate              Time,

        nextUpdate              Time OPTIONAL,

        revokedCertificates     SEQUENCE OF SEQUENCE  {

             userCertificate         CertificateSerialNumber,

             revocationDate          Time,

             crlEntryExtensions      Extensions OPTIONAL

                                  }  OPTIONAL,

        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL

                                  }

 

Definice CRL je obdobná definici certifikátu. Nejprve se definuje sekvence CertificateList, která vyjadřuje, že CRL je digitálně podepsaná sekvence. Nás bude nejvíce zajímat, jaké položky CRL obsahuje, tj. položka TBSCertList, která je sama sekvencí obsahující:

·         První položka version je sice podle X.509 volitelná, ale RFC-2459 předepisuje, že musí v CRL být použita a musí mít celočíselnou hodnotu 1 (tj. CRL dle X.509 verze 2).

·         Položka signature obsahuje identifikátor algoritmů použitých pro elektronický podpis CRL.

·         Položka issuer identifikuje, kdo toto CRL vydal.

·         Položka tihsUpdate specifikuje čas vydání CRL.

·         Položka nextUpdate určuje pravděpodobné datum a čas vydání následujícího CRL. Následující CRL může být vydáno dříve nebo v čas uvedený v této položce. Následující CRL nesmí být vydáno později než je datum a čas uvedené v položce nextUpdate předchozího CRL.

·         Položka revokedCertificates obsahuje vlastní seznam odvolávaných certifikátu. Pro každý odvolávaný certifikát obsahuje sekvenci údajů:

o        Sériové číslo odvolávaného certifikátu (userCertificate), které společně s položkou issuer jednoznačně identifikuje odvolávaný certifikát.

o        Datum a čas, kdy držitel podal žádost o revokaci certifikátu (revocationDate).

o        Volitelnou položku rozšíření odvolávaného certifikátu (crlEntryExtension).

·         Položka crlExtension obsahuje rozšíření CRL.

 

Všimněte si, že v CRL jsou dva typy rozšíření: rozšíření jednotlivé položky CRL (rozšíření odvolávaného certifikátu) a pak rozšíření CRL jako takového, které je společné pro celé 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é.

 

Přírůstkové CRL (Delta CRL)

Doposud jsme předpokládali, že CRL obsahuje seznam všech odvolaných certifikátů, které by byly platné v době vydání CRL. CRL se ale vydává v poměrně dlouhých intervalech, pokud čas měříme pohledem držitele odvolávaného certifikátu.

 

V intervalu mezi vydáním dvou kompletních CRL mohou být vydávány přírůstkové CRL obsahující pouze čísla odvolaných certifikátů od posledního kompletního CRL. Skutečnost, že se jedná o přírůstkové CRL (a nikoliv o kompletní CRL), musí být vyznačena kritickým rozšířením „Přírůstkové CRL“. Toto rozšíření pak obsahuje celé číslo, ve kterém je uloženo číslo kompletního CRL, od kterého obsahuje přírůstkové CRL přírůstek odvolaných certifikátů.

 

Distribuční místo CRL

Rozšíření „Distribuční místa CRL“ (Issuing Distribution Point) je kritickým rozšířením, které indikuje, že se nejedná o kompletní CRL vydavatele. Toto rozšíření obsahuje následující sekvenci:

 

IssuingDistributionPoint ::= SEQUENCE {

     distributionPoint       [0] DistributionPointName OPTIONAL,

     onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,

     onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,

     onlySomeReasons         [3] ReasonFlags OPTIONAL,

     indirectCRL             [4] BOOLEAN DEFAULT FALSE }

 

Kde:

 

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}

 

Důvod odvolání certifikátu

Rozšíření důvod odvolání certifikátu (CRLReason) je definováno jako výčet důvodů:

 

   CRLReason ::= ENUMERATED {

        unspecified             (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6),

        removeFromCRL           (8) }

 

CRL by mělo obsahovat vždy konkrétní důvod odvolání certifikátu. Je však možné v odůvodněných případech toto rozšíření neuvést, což je stejné jako by byl uveden nespecifikovaný důvod (unspecified).

 

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

Rozšíření „Instrukce pro případ odvolání certifikátu“  (holdInstruction) obsahuje identifikátor objektu, který specifikuje co máme dělat, když zjistíme, že je certifikát na CRL.

 

Jsou definovány následující objekty:

 

   id-holdinstruction-none       OBJECT IDENTIFIER ::= {holdInstruction 1}

   id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2}

   id-holdinstruction-reject     OBJECT IDENTIFIER ::= {holdInstruction 3}

 

Kde:

holdInstruction    OBJECT IDENTIFIER ::=

                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }

 

Objekt id-holdinstruction-none je ekvivalentní s případem, kdy by toto rozšíření nebylo vůbec uvedeno. Je nedoporučeno tuto eventualitu používat.

 

Objekt id-holdinstruction-callissuer sděluje, že máme zavolat vydavateli certifikátu nebo certifikát odmítnout.

 

Objekt id-holdinstruction-reject sděluje, že se má certifikát odmítnout.

 

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.4.3                      Příklad CRL

 

-----BEGIN X509 CRL-----
MIIEWTCCA0EwDQYJKoZIhvcNAQEEBQAwTjELMAkGA1UEBhMCQ1oxLDAqBgNVBAMT
I0kuQ0EgLSBTdGFuZGFyZCByb290IGNlcnRpZmljYXRlIDAxMREwDwYDVQQKEwhQ
VlQgYS5zLhcNMDEwMzA1MTYxNTI1WhcNMDEwMzEwMTYxNTI1WjCCAsAwFAIDAU+r
Fw0wMDA5MTgxMzI2MzdaMBQCAwFSHxcNMDAxMDAzMTEyOTA2WjAUAgMBVAMXDTAw
MDkyMTA5MTUxM1owFAIDAVQIFw0wMDA5MjEwOTE1MzZaMBQCAwFVqRcNMDAwOTI1
MDgwMTU1WjAUAgMBVrAXDTAwMDkyNjEyNDIwNVowFAIDAWB1Fw0wMDEwMDgwODU2
NDhaMBQCAwFjZhcNMDAxMDExMDczMTQyWjAUAgMBZRoXDTAwMTAxMjEyMDQwMVow
FAIDAWViFw0wMDEwMjMwNDU1NTNaMBQCAwFmJBcNMDEwMTE5MDgxNjUzWjAUAgMB
Z20XDTAxMDExNzE3MDQzNVowFAIDAWh0Fw0wMDEwMTcxNDAwMTNaMBQCAwFowBcN
MDAxMTI0MDgzMDM4WjAUAgMBaXMXDTAwMTAyNTEzNTQ1MlowFAIDAWrZFw0wMDEw
MjQxMDI1MDVaMBQCAwFrBxcNMDAxMTA5MTQxNzU5WjAUAgMBc+MXDTAwMTIwMTA5
MDY1MlowFAIDAXf2Fw0wMDExMDIxMTEzNTlaMBQCAwF6GRcNMDAxMTA2MTMwMjI0
WjAUAgMBe8AXDTAwMTEwMzExNTc0OFowFAIDAXvBFw0wMDEyMDQxNzQyMzFaMBQC
AwF9nBcNMDEwMjAxMTExNDQ2WjAUAgMBfeYXDTAwMTEwNzA3MTM1M1owFAIDAX8Z
Fw0wMDEyMjEwNzA1MTBaMBQCAwGAphcNMDAxMjI5MTcxMjExWjAUAgMBhSIXDTAx
MDExNzE3MDMxOVowFAIDAZZPFw0wMDExMjgxMzA0MjBaMBQCAwGZLhcNMDAxMTMw
MTMzODMwWjAUAgMBojsXDTAwMTIwNzA3NTMwMFowFAIDAcYNFw0wMTAxMTYxNTE5
MDlaMBQCAwHPxBcNMDEwMTI0MTAwODE1WjANBgkqhkiG9w0BAQQFAAOCAQEAFg2h
N+dtcOdZoAd/7B1w9BLBxM9nbwD/zmgjItcYZi19kMH2dV6gNbLMgockepUvntkC
ZUncpAl78VpKjavGSGff4Xgy8qlBEYAMAbNsJWpm4Eim4nYQVEYVRrSplgbZgiEn
Sa1E9YV9WQ9bixQTiCIu18R+zGqXD87GT02f11sBnWodvccRjcZJpAAxsbwFqKm/
BGl4B3utX5cjn7HlS4921C0Bkv5MqFwyh5x3QqQdxIMB4iLswSqYxeql9U2LOVVZ
Vwovh9GHGWvjqNCNTqMAN8a948N+yAMxpQHqEOxom27H+MtDFKmVAxqRbCjhFSwH
252fnqw3P7iy/L4fBw==
-----END X509 CRL-----

 

SEQUENCE         

    30 82 04 59

  SEQUENCE         

     30 82 03 41

   SEQUENCE         

      30 0d

    OBJECT            :md5WithRSAEncryption

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

    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

   UTCTIME           :010305161525Z

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

   UTCTIME           :010310161525Z

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

   SEQUENCE         

      30 82 02 c0

    SEQUENCE         

       30 14

     INTEGER           :014FAB

        02 03 01 4f ab

     UTCTIME           :000918132637Z

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

 

    SEQUENCE         

       30 14

     INTEGER           :01521F

        02 03 01 52 1f

     UTCTIME           :001003112906Z

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

    SEQUENCE         

       30 14

     INTEGER           :015403

        02 03 01 54 03

     UTCTIME           :000921091513Z

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

    SEQUENCE         

       30 14

     INTEGER           :015408

        02 03 01 54 08

     UTCTIME           :000921091536Z

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

…

…

    SEQUENCE         

       30 14

     INTEGER           :01CFC4

        02 03 01 cf c4

     UTCTIME           :010124100815Z

        17 0d 30 31 30 31 32 34 31 30 30 38 31 35 5a

  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 16 0d a1 37 e7 6d 70 e7 59 a0 07 7f ec 1d 70

     f4 12 c1 c4 cf 67 6f 00 ff ce 68 23 22 d7 18 66 2d 7d 90 c1

     f6 75 5e a0 35 b2 cc 82 87 24 7a 95 2f 9e d9 02 65 49 dc a4

     09 7b f1 5a 4a 8d ab c6 48 67 df e1 78 32 f2 a9 41 11 80 0c

     01 b3 6c 25 6a 66 e0 48 a6 e2 76 10 54 46 15 46 b4 a9 96 06

     d9 82 21 27 49 ad 44 f5 85 7d 59 0f 5b 8b 14 13 88 22 2e d7

     c4 7e cc 6a 97 0f ce c6 4f 4d 9f d7 5b 01 9d 6a 1d bd c7 11

     8d c6 49 a4 00 31 b1 bc 05 a8 a9 bf 04 69 78 07 7b ad 5f 97

     23 9f b1 e5 4b 8f 76 d4 2d 01 92 fe 4c a8 5c 32 87 9c 77 42

     a4 1d c4 83 01 e2 22 ec c1 2a 98 c5 ea a5 f5 4d 8b 39 55 59

     57 0a 2f 87 d1 87 19 6b e3 a8 d0 8d 4e a3 00 37 c6 bd e3 c3

     7e c8 03 31 a5 01 ea 10 ec 68 9b 6e c7 f8 cb 43 14 a9 95 03

     1a 91 6c 28 e1 15 2c 07 db 9d 9f 9e ac 37 3f b8 b2 fc be 1f

     07

 

 

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.5.1                      OCSP dotaz

OCSP dotaz může být digitálně podepsaný, avšak elektronický podpis není povinný. OCSP server však může nepodepsané dotazy odmítnout.

 

   OCSPRequest     ::=     SEQUENCE {

       tbsRequest                  TBSRequest,

       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

  

   Signature       ::=     SEQUENCE {

       signatureAlgorithm      AlgorithmIdentifier,

       signature               BIT STRING,

       certs               [0] EXPLICIT SEQUENCE OF Certificate

   OPTIONAL}

 

Vnitřek OCSP dotazu je sekvence:

 

   TBSRequest      ::=     SEQUENCE {

       version             [0]     EXPLICIT Version DEFAULT v1,

       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,

       requestList                 SEQUENCE OF Request,

       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

 

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

 Request         ::=     SEQUENCE {

    reqCert                     CertID,

    singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

Kde položka reqCert identifikuje příslušný certifikát:

 CertID          ::=     SEQUENCE {

    hashAlgorithm       AlgorithmIdentifier,

    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN

    issuerKeyHash       OCTET STRING, -- Hash of Issuers public key

    serialNumber        CertificateSerialNumber }

Identifikace certifikátu se tak skládá z čísla certifikátu (serialNumber) a kontrolního součtu, ze jména z identifikace CA (issuer) a kontrolního součtu z veřejného klíče CA (issuerKeyHash).

8.5.2                      OCSP odpověď

OCSP odpověď (OCSPResponse) se skládá z obálky a těla odpovědi (responseBytes).

 

OCSP obálka

OCSP obálka je jakousi minimální odpovědí OCSP serveru, protože zejména v případě chyby může být tělo odpovědi prázdné.

 

   OCSPResponse ::= SEQUENCE {

      responseStatus         OCSPResponseStatus,

      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

 

OCSP obálka obsahuje status odpovědi (OCSPResponseStatus):

 

   OCSPResponseStatus ::= ENUMERATED {

       successful            (0),  --Response has valid confirmations

       malformedRequest      (1),  --Illegal confirmation request

       internalError         (2),  --Internal error in issuer

       tryLater              (3),  --Try again later

       sigRequired           (5),  --Must sign the request

       unauthorized          (6)   --Request unauthorized

   }

Stavový kód může být:

 

Tělo OCSP odpovědi

OCSP server může používat několik druhů odpovědí. Tělo OCSP odpovědi se proto skládá ze sekvence obsahující identifikátor objektu druhu odpovědi (responseType)  a vlastní odpovědi (response):

 

   ResponseBytes ::=       SEQUENCE {

       responseType        OBJECT IDENTIFIER,

       response            OCTET STRING }

 

Tč. je definován identifikátor druhu odpovědi pouze pro tzv. základní odpověď, mající identifikátor objektu id-pkix-ocsp-basic:

   id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }

   id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

 

Základní odpověď

Základní odpověď (BasicOCSPResponse) je digitálně podepsána což vyjadřuje následující sekvence:

 

   BasicOCSPResponse       ::= SEQUENCE {

      tbsResponseData      ResponseData,

      signatureAlgorithm   AlgorithmIdentifier,

      signature            BIT STRING,

      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

 

Vnitřek digitálně podepsané odpovědi (ResponseData)  má tvar:

 

   ResponseData ::= SEQUENCE {

      version              [0] EXPLICIT Version DEFAULT v1,

      responderID              ResponderID,

      producedAt               GeneralizedTime,

      responses                SEQUENCE OF SingleResponse,

      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

 

   ResponderID ::= CHOICE {

      byName               [1] Name,

      byKey                [2] KeyHash }

   SingleResponse ::= SEQUENCE {

      certID                       CertID,

      certStatus                   CertStatus,

      thisUpdate                   GeneralizedTime,

      nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,

      singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

 

kde:

o        Položka certID odpovídá identifikaci certifikátu udané v dotazu klienta.

o        Položka  certStatus sděluje informaci, zdali je dotazovaný certifikát platný (good), odvolaný (revoked) či zda OCSP server nemá příslušnou informaci k dispozici.

   CertStatus ::= CHOICE {

       good        [0]     IMPLICIT NULL,

       revoked     [1]     IMPLICIT RevokedInfo,

       unknown     [2]     IMPLICIT UnknownInfo }

 

V případě odvolaného certifikátu je v sekvenci RevokedInfo uveden čas odvolání (revocationTime) a případně důvod odvolání (revocationReason):

  RevokedInfo ::= SEQUENCE {

    revocationTime              GeneralizedTime,

    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

 

o        Položka thisUpdate obsahuje čas, od kterého je indikován stav odpovědi. Tj. v případě odvolaného certifikátu tento čas odpovídá položce thisUdate v CRL.

o        Položka nextUdate obsahuje čas, do kterého bude dostupná novější informace o dotazovaném certifikátu. Pokud je čas lokálního systému OCSP klienta pozdější, než hodnota v položce nextUpdate, pak se odpověď považuje za nevěrohodnou.

8.5.3                      Transportní protokol

Jako transportní protokol pro protokol OCSP lze použít např. protokol HTTP. V takovém případě je pro dotazy menší než 255 bajtů možné použít metodu GET, pro větší dotazy je nutné použít metodu POST.

Jelikož dotaz OCSP protokolu je kódován DER, tj. v binární podobě, tak při použití metody GET kódujeme dotaz Base64. Dotaz má tvar:

 

GET URI/Base64 kódovaný dotaz

 

Kde URI klient vezme buď ze své lokální konfigurace nebo z rozšíření „Rozšířené použití klíče“ dotazovaného certifikátu.

 

V hlavičce Content-Type uvádíme typ/podtyp:

 

Komunikace mezi klientem a serverem může být zabezpečena např. protokoly SSL či TLS. Při této komunikaci může být použita i autentizace klienta za využití certifikátu.

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.6.1                      Formát žádosti o certifikát

Skutečnost, že žádost o certifikát je podepsaná sekvence, se obdobně jako při popisu certifikátu vyjádří následující sekvencí:

 

   CertificationRequest ::= SEQUENCE {

     certificationRequestInfo CertificationRequestInfo,

     signatureAlgorithm SignatureAlgorithmIdentifier,

     signature Signature }

 

Nás zajímá vnitřek této struktury, tj. položka certificationRequestInfo:

 

   CertificationRequestInfo ::= SEQUENCE {

     version Version,

     subject Name,

     subjectPublicKeyInfo      SEQUENCE {

        algorithm                 AlgorithmIdentifier,

        subjectPublicKey          BIT STRING },

     attributes [0] IMPLICIT Attributes }

 

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

 

pkcs-9-at-challengePassword      OBJECT IDENTIFIER ::= { pkcs-9 7 }

 

kde

pkcs-9     OBJECT IDENTIFIER ::=  { iso(1) member-body(2) us(840)
                                   rsadsi(113549) pkcs(1) pkcs-9(9) }

 

I když formát žádosti podle PKCS#10 není kompatibilní s žádostí PEM, tak se v praxi ujalo označení „žádost PKCS#10 ve formátu PEM“. Taková žádost ve své podstatě má společné s formátem PEM pouze to, že je kódována Base64 a před žádost je vložen řetězec:

-----BEGIN CERTIFICATE REQUEST-----

A za žádost je vložen řetězec:

-----END CERTIFICATE REQUEST-----

8.6.2                      Příklad žádosti

-----BEGIN CERTIFICATE REQUEST-----
MIIC3TCCAkYCAQAwRjEXMBUGA1UEAxMOTGlib3IgRG9zdGFsZWsxCzAJBgNVBAYT
AkNaMR4wHAYJKoZIhvcNAQkBFg9kb3N0YWxla0BwdnQuY3owgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBANR4NfMMFOpGsm6PNTro0o2G5BqvyeP9T7TPlsGiMnJN
nbmkAJ2MXYMsZS5zBTKRrOy03SUnehfTKARhUVSPLDPrzm/BopsoD73B/kCcpV0+
3IYjIO7PC76ke+dCNR3OXgoRPDIkJpRg5MwQjC5Lqxk+qnsqn47na1TFtkBodUt5
AgMBAAGgggFVMBoGCisGAQQBgjcNAgMxDBYKNS4wLjIxOTUuMjA1BgorBgEEAYI3
AgEOMScwJTAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwgf8G
CisGAQQBgjcNAgIxgfAwge0CAQEeXABNAGkAYwByAG8AcwBvAGYAdAAgAEUAbgBo
AGEAbgBjAGUAZAAgAEMAcgB5AHAAdABvAGcAcgBhAHAAaABpAGMAIABQAHIAbwB2
AGkAZABlAHIAIAB2ADEALgAwA4GJACB3C0g9psK0+V+N/Me1JsG39vonCPQBdOwN
p6zHJSPCU3FwQ0SgFpEQNy6HEn79I0CMrU93q9Hh1TQtd2YU6lWHQunXrIcytmAF
VjhibNX6Dp1e41Wjc2N4ilJyy1GFss686cdZt2GP6y04I74/OvkW2Wf9nezUrMrE
SM2PP4B1AAAAAAAAAAAwDQYJKoZIhvcNAQEEBQADgYEAdVxY32/RSrKbq4qAzd43
4bSKjqDp24C2qkmD3+7GNcTQnxdiCtIjZwAKMn2XFaBwJcbg8sazlnMrStjY63xP
WjQKPTKTQh3nH1pw86/gIn9W0iu+xz/9P2P7woaJcp7FZNS2ZdPgIbF4zRd4GK2I
pN/0owIDJxUVELiHb1nUs9U=
-----END CERTIFICATE REQUEST-----

 

SEQUENCE         

    30 82 02 dd

  SEQUENCE         

     30 82 02 46

   INTEGER           :00

      02 01 00

   SEQUENCE         

      30 46

    SET              

       31 17

     SEQUENCE         

        30 15

      OBJECT            :commonName

         06 03 55 04 03

      PRINTABLESTRING   :Libor Dostalek

         13 0e 4c 69 62 6f 72 20 44 6f 73 74 61 6c 65 6b

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :countryName

         06 03 55 04 06

      PRINTABLESTRING   :CZ

         13 02 43 5a

    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 81 9f

    SEQUENCE         

       30 0d

     OBJECT            :rsaEncryption

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

     NULL             

        05 00

    BIT STRING       

       03 81 8d 00 30 81 89 02 81 81 00 d4 78 35 f3 0c 14 ea 46 b2

       6e 8f 35 3a e8 d2 8d 86 e4 1a af c9 e3 fd 4f b4 cf 96 c1 a2

       32 72 4d 9d b9 a4 00 9d 8c 5d 83 2c 65 2e 73 05 32 91 ac ec

       b4 dd 25 27 7a 17 d3 28 04 61 51 54 8f 2c 33 eb ce 6f c1 a2

       9b 28 0f bd c1 fe 40 9c a5 5d 3e dc 86 23 20 ee cf 0b be a4

       7b e7 42 35 1d ce 5e 0a 11 3c 32 24 26 94 60 e4 cc 10 8c 2e

       4b ab 19 3e aa 7b 2a 9f 8e e7 6b 54 c5 b6 40 68 75 4b 79 02

       03 01 00 01

   cont [ 0 ]       

      a0 82 01 55

    SEQUENCE         

       30 1a

     OBJECT            :1.3.6.1.4.1.311.13.2.3

        06 0a 2b 06 01 04 01 82 37 0d 02 03

     SET              

        31 0c

      IA5STRING         :5.0.2195.2

         16 0a 35 2e 30 2e 32 31 39 35 2e 32

    SEQUENCE         

       30 35

     OBJECT            :1.3.6.1.4.1.311.2.1.14

        06 0a 2b 06 01 04 01 82 37 02 01 0e

     SET              

 

        31 27

      SEQUENCE         

         30 25

       SEQUENCE         

          30 0e

        OBJECT            :X509v3 Key Usage

           06 03 55 1d 0f

        BOOLEAN           :255

           01 01 ff

        OCTET STRING     

           04 04 03 02 04 f0

       SEQUENCE         

          30 13

        OBJECT            :X509v3 Extended Key Usage

           06 03 55 1d 25

        OCTET STRING     

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

    SEQUENCE         

       30 81 ff

     OBJECT            :1.3.6.1.4.1.311.13.2.2

        06 0a 2b 06 01 04 01 82 37 0d 02 02

     SET              

        31 81 f0

      SEQUENCE         

         30 81 ed

       INTEGER           :01

          02 01 01

       BMPSTRING        

          1e 5c 00 4d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74

          00 20 00 45 00 6e 00 68 00 61 00 6e 00 63 00 65 00 64 00 20

          00 43 00 72 00 79 00 70 00 74 00 6f 00 67 00 72 00 61 00 70

          00 68 00 69 00 63 00 20 00 50 00 72 00 6f 00 76 00 69 00 64

          00 65 00 72 00 20 00 76 00 31 00 2e 00 30

       BIT STRING       

          03 81 89 00 20 77 0b 48 3d a6 c2 b4 f9 5f 8d fc c7 b5 26 c1

          b7 f6 fa 27 08 f4 01 74 ec 0d a7 ac c7 25 23 c2 53 71 70 43

          44 a0 16 91 10 37 2e 87 12 7e fd 23 40 8c ad 4f 77 ab d1 e1

          d5 34 2d 77 66 14 ea 55 87 42 e9 d7 ac 87 32 b6 60 05 56 38

          62 6c d5 fa 0e 9d 5e e3 55 a3 73 63 78 8a 52 72 cb 51 85 b2

          ce bc e9 c7 59 b7 61 8f eb 2d 38 23 be 3f 3a f9 16 d9 67 fd

          9d ec d4 ac ca c4 48 cd 8f 3f 80 75 00 00 00 00 00 00 00 00

  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 75 5c 58 df 6f d1 4a b2 9b ab 8a 80 cd de 37 e1

     b4 8a 8e a0 e9 db 80 b6 aa 49 83 df ee c6 35 c4 d0 9f 17 62

     0a d2 23 67 00 0a 32 7d 97 15 a0 70 25 c6 e0 f2 c6 b3 96 73

     2b 4a d8 d8 eb 7c 4f 5a 34 0a 3d 32 93 42 1d e7 1f 5a 70 f3

     af e0 22 7f 56 d2 2b be c7 3f fd 3f 63 fb c2 86 89 72 9e c5

     64 d4 b6 65 d3 e0 21 b1 78 cd 17 78 18 ad 88 a4 df f4 a3 02

     03 27 15 15 10 b8 87 6f 59 d4 b3 d5

 

 

 

 

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.

 

Žádost o certifikát tvaru CRMF je následující sekvence

 

CertReqMsg ::= SEQUENCE {

    certReq   CertRequest,

    pop       ProofOfPossession  OPTIONAL,

    regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }

 

Kde:

 

8.7.1                      Důkaz vlastnictví soukromého klíče

Tento důkaz je třeba dělat na jiném principu pro klíče určené k elektronickému podepisování, pro klíče určené k šifrování a pro klíče určené pro výměnu klíčů.

 

V případě, že žádost obsahuje veřejný klíč určený pro ověření elektronického podpisu, pak se vytvoří elektronický podpis z žádosti jako důkaz (obdoba PKCS#10). V případě, že se jedná o šifrovací klíč, pak je důkaz nutné provést na základě šifrování – např. tak, že vydaný klíč CA zašifruje veřejným klíčem žadatele. Nikdo jiný jej nemůže dešifrovat a dát k dispozici než vlastník soukromého klíče … .

 

Položka pop obsahující důkaz vlastnictví klíče je výběrem z následujících možností:

 

   ProofOfPossession ::= CHOICE {

       raVerified        [0] NULL,

       signature         [1] POPOSigningKey,

       keyEncipherment   [2] POPOPrivKey,

       keyAgreement      [3] POPOPrivKey }

 

Verifikaci provedla RA (raVerified)

Tato možnost říká, že příslušné ověření provedla registrační autorita (RA), tj. zpráva neobsahuje žádný důkaz.

 

Verifikace elektronickým podpisem (signature)

Pro tento případ se definuje struktura POPOSigningKey, která obsahuje příslušný důkaz pomocí elektronického podpisu:

 

   POPOSigningKey ::= SEQUENCE {

       poposkInput         [0] POPOSigningKeyInput OPTIONAL,

       algorithmIdentifier     AlgorithmIdentifier,

       signature               BIT STRING }

 

V případě, že žádost obsahuje jedinečné jméno žadatele a veřejný klíč, pak se položka poposkInput neuvede.  Elektronický podpis (signature) se spočte ze struktury certReq. V opačném případě se uvede položka poposkInput a elektronický podpis se počítá z ní.

 

Položka POPPrivKey

 

   POPOPrivKey ::= CHOICE {

       thisMessage       [0] BIT STRING,

       subsequentMessage [1] SubsequentMessage,

       dhMAC             [2] BIT STRING }

 

Slouží pro zbylé důkazy:

·         První možnost (thisMessage) obsahuje celý soukromý klíč uživatele šifrovaný klíčem CA. Předání soukromého klíče CA je u certifikátů určených pro elektronický podpis nepředstavitelné, ale u certifikátů určených pro šifrování to není až tak nezvyklé. Ač se to může zdát podivné, tak některé CA generují dvojici veřejný klíč/soukromý klíč pro uživatele samy. Je to možné výhradně pro šifrovací certifikáty. Dokonce tento postup považuji za přednost (?). Výhoda je v tom, že CA mají prostředky na archivaci klíčů. V případě ztráty klíče uživatelem je pak možné dešifrovat zprávu klíčem z archivu CA.

·         Druhou možností je právě důkaz tím, že CA odešle v následující zprávě vydaný certifikát. Uživatel jej dešifruje a dešifrovaný vrátí CA.

·         Třetí možnost je určena pro DH klíče.

8.7.2                      Vlastní žádost o certifikát

 

CertRequest ::= SEQUENCE {

    certReqId     INTEGER,          -- ID for matching request and reply

    certTemplate  CertTemplate,  -- Selected fields of cert to be issued

    controls      Controls OPTIONAL }   -- Attributes affecting issuance

 

CertTemplate ::= SEQUENCE {

    version      [0] Version               OPTIONAL,

    serialNumber [1] INTEGER               OPTIONAL,

    signingAlg   [2] AlgorithmIdentifier   OPTIONAL,

    issuer       [3] Name                  OPTIONAL,

    validity     [4] OptionalValidity      OPTIONAL,

    subject      [5] Name                  OPTIONAL,

    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,

    issuerUID    [7] UniqueIdentifier      OPTIONAL,

    subjectUID   [8] UniqueIdentifier      OPTIONAL,

    extensions   [9] Extensions            OPTIONAL }

 

  OptionalValidity ::= SEQUENCE {

      notBefore  [0] Time OPTIONAL,

      notAfter   [1] Time OPTIONAL } --at least one must be present

 

  Time ::= CHOICE {

      utcTime        UTCTime,

      generalTime    GeneralizedTime }

 

Vlastní žádost o certifikát (CertRequest) se skládá ze tří částí:

 

 

   id-regCtrl-regToken            OBJECT IDENTIFIER ::= { id-regCtrl 1 }

   id-regCtrl-authenticator       OBJECT IDENTIFIER ::= { id-regCtrl 2 }

   id-regCtrl-pkiPublicationInfo  OBJECT IDENTIFIER ::= { id-regCtrl 3 }

   id-regCtrl-pkiArchiveOptions   OBJECT IDENTIFIER ::= { id-regCtrl 4 }

   id-regCtrl-oldCertID           OBJECT IDENTIFIER ::= { id-regCtrl 5 }

   id-regCtrl-protocolEncrKey     OBJECT IDENTIFIER ::= { id-regCtrl 6 }

 

Kde:

   id-regCtrl  OBJECT IDENTIFIER ::= { iso(1)

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

           security(5) mechanisms(5) pkix(7) pkip(5) regCtrl(1) }

 

 

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.8.1                      Záhlaví CMP zprávy

Záhlaví zprávy je zobrazeno na obr. 8-12.  Skládá se z celé řady položek, z nichž je povinná pouze první položka – verze protokolu. Ostatní položky mají následující význam:

 

 

Obr. 8-12 Záhlaví protokolu CMP

8.8.2                      Tělo CMP zprávy

Tělo zprávy (PKIBody) je pro protokol CMP v podstatě černá skříňka. Tělo zprávy  obsahuje vždy jednu z následujících možností: 

 

ASN.1 definice

Význam položek

PKIBody ::= CHOICE {

 

  ir      [0]  CertReqMessages,       

CRMF: žádost o certifikát (inicializační požadavek)

  ip      [1]  CertRepMessage,

Odpověď na žádost o certifikát (inicializační požadavek)

  cr      [2]  CertReqMessages,

CRMF žádost o certifikát (další požadavek)

  cp      [3]  CertRepMessage,

Odpověď na žádost o certifikát (další požadavek)

  p10cr   [4]  CertificationRequest,

PKCS#10 žádost o certifikát

  popdecc [5]  POPODecKeyChallContent,

POP dotaz (dotaz na vlastnictví soukromého klíče)

  popdecr [6]  POPODecKeyRespContent,

POP odpověď

  kur     [7]  CertReqMessages,

Žádost o obnovení certifikátu

  kup     [8]  CertRepMessage,

Odpověď na žádost o obnovení certifikátu

  krr     [9]  CertReqMessages,

Žádost o obnovení klíčů

  krp     [10] KeyRecRepContent,

Odpověď na žádost o obnovení klíčů

  rr      [11] RevReqContent,

Žádost o odvolání certifikátů

  rp      [12] RevRepContent,

Odpověď na žádost o odvolání certifikátů

  ccr     [13] CertReqMessages,

Žádost o křížovou certifikaci

  ccp     [14] CertRepMessage,

Odpověď na žádost o křížovou certifikaci

  ckuann  [15] CAKeyUpdAnnContent,

Vydání nového certifikátu CA

  cann    [16] CertAnnContent,

Nabídka certifikátu

  rann    [17] RevAnnContent,

Nabídka CRL

  crlann  [18] CRLAnnContent,

Nabídka odvolání certifikátu CA

  conf    [19] PKIConfirmContent,

Potvrzení

  nested  [20] NestedMessageContent

Vložená zpráva

  genm    [21] GenMsgContent

Obecná zpráva

  genp    [22] GenRepContent

Odpověď na obecnou zprávu

  error   [23]

Chybová zpráva

}

 

 

Každá z uvedených možností („každá černá skříňka“) je identifikována  typem DER-kódovaných dat (tj. typem [0] až [23]). Většina požadavků (dotazů) se vytváří  podle protokolů CRMF (resp. PKCS#10). Jiná je situace u odpovědí, tj. protokoly CRMF (resp. PKCS#10) nespecifikují. Tuto mezeru si protokol CMP vyplňuje sám a definuje příslušné odpovědi.

 

V případě odpovědí je důležité, jak požadavek dopadl, tj. status odpovědi (typ PKIStatusInfo):

 

ASN.1 definice

Význam položek

PKIStatusInfo ::= SEQUENCE {

 

  status        PKIStatus,

Status odpovědi (OK nebo chybová hláška)

  statusString  PKIFreeText    OPTIONAL,

Čitelný text komentující odpověď (viz záhlaví)

  failInfo      PKIFailureInfo OPTIONAL

Specifikace chyby

}

 

    

Status odpovědi se skládá ze stavové informace o tom, jak požadavek dopadl (PKIStatus), a případně specifikace chyby (PKIFailureInfo).

 

Typ PKIStatus je jednou hodnotou z následujícího výčtu:

 

ASN.1 definice

Význam položek

PKIStatus ::= INTEGER {

 

  granted                (0),

Odpověď přináší požadovaný výsledek

  grantedWithMods        (1),

Odpověď přináší podobný výsledek, jaký byl požadován.

  rejection              (2),

Zamítnutí požadavku

  waiting                (3),

Požadavek nemohl být okamžitě zpracován

  revocationWarning      (4),

Zpráva obsahuje informaci, že hrozí odvolání (certifikátu)

  revocationNotification (5),

Zpráva obsahuje informaci o odvolání (certifikátu)

  keyUpdateWarning       (6)

Bylo provedeno obnovení klíče

}

 

 

Specifikace chyby PKIFailureInfo je pak bitovým řetězcem, kde nastavení konkrétních bitů indikuje příčinu chyby:

 

ASN.1 definice

Význam položek

PKIFailureInfo ::= BIT STRING {

 

  badAlg                 (0),

Chybný identifikátor algoritmu (nebo neznámý algoritmus)

  badRequest             (2),

Chybný požadavek (např. chyba integrity)

  badTime                (3),

Nesprávný čas

  badCertId              (4),

Nenašel se požadovaný certifikát.

  badDataFormat          (5),

Chybný formát dat

  wrongAuthority         (6),

Požadavek byl uplatněn u jiné CA nebo byla chybně identifikována CA

  incorrectData          (7),

Chybná data

  missingTimeStamp       (8),

V požadavku chybí časové razítko, které  však bylo požadováno.

  badPOP                 (9)

Selhal důkaz vlastnictví soukromého klíče

}

 

 

8.8.3                      Pole ochrana

Typ PKIProtection tvořící položku ochrana (protection) je bitový řetězec, kterým se zajišťuje integrita zprávy.  Toto pole nemusí být použito, je-li např. použita externí ochrana zprávy, tj. když je např. zpráva zajištěna (vložena) do PKCS#7 zprávy.

 

V případě, že se pole ochrana použije a zajištění se provede pomocí kontrolního součtu ze zprávy, pak do výpočtu kontrolního součtu vstupuje DER-kódované záhlaví a tělo zprávy. Tj. kontrolní součet se nepočítá z pole ochrana a pole další certifikáty.

 

Ochrana se zajišťuje několika způsoby:

·         Na bázi sdíleného tajemství, které si vymění uživatel s CA/RA jinou cestou. Kontrolní součet se pak počítá ze sdíleného tajemství a zprávy (a pochopitelně i soli – celý postup je podrobně popsán v RFC-2510).

·         V žádosti o Diffie-Hellmanův certifikát se vygeneruje symetrický klíč na základě privátního DH čísla. Ochrana pak obsahuje kontrolní součet šifrovaný tímto symetrickým klíčem.

·         Ochrana na bázi elektronického podpisu. Tato ochrana je opět možná pouze v případě žádostí o certifikát umožňující ověřování elektronického podpisu.

 

Jak je vidět z obr. 8-10, tak uživatel žádost odesílá na RA, která žádost zkontroluje a předá na CA. První ochranu provede uživatel a další ochranu pak RA, protože CA bude chtít akceptovat pouze požadavky prověřené RA. Ale pole ochrana je ve zprávě pouze jedno. V tomto případě se postupuje tak, že RA přijme žádost, prověří ji, a celou žádost včetně záhlaví vloží jako tělo do nově vytvářené zprávy. Vznikne tak zpráva typu NestedMessageContent.

 

Obr. 8-13 RA odesílá ve zprávě NestedMessageContent vnořenou zprávu CertReqMessage

Při vytváření ověření pro zprávu RA již nenastávají komplikace s volbou ochrany zprávy. Pracovník RA má vydán podepisovací certifikát a tak může ochranu vytvořit jednoduše pomocí elektronického podpisu (ať uživatel žádá o DH certifikát či šifrovací certifikát).

 

8.8.4                      Žádost o certifikát

RFC-2510 rozlišuje tři typy žádostí o certifikát:

 

Žádost  je vždy formátu CRMF; alternativně se připouští i formát PKCS#10. Jednotlivé typy požadavků jsou v protokolu CMP rozlišeny tágem v typu požadavku (viz tělo CMP zprávy).

 

8.8.5                      Odpověď na žádosti o certifikát

Odpověď (CertRepMessage) může obsahovat sekvenci odpovědí na několik žádostí o certifikát:

 

  CertRepMessage ::= SEQUENCE {

      caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,

      response            SEQUENCE OF CertResponse

  }

Odpověď může volitelně obsahovat v položce caPubs certifikáty CA. V položce response je pak jádro vlastní odpovědi, které je typu CertResponse:

 

  CertResponse ::= SEQUENCE {

      certReqId           INTEGER,

      status              PKIStatusInfo,

      certifiedKeyPair    CertifiedKeyPair    OPTIONAL,

      rspInfo             OCTET STRING        OPTIONAL

      -- analogous to the id-regInfo-asciiPairs OCTET STRING defined

      -- for regInfo in CertReqMsg [CRMF]

  }

Struktura CertResponse se skládá z položek:

 

  CertifiedKeyPair ::= SEQUENCE {

      certOrEncCert       CertOrEncCert,

      privateKey      [0] EncryptedValue      OPTIONAL,

      publicationInfo [1] PKIPublicationInfo  OPTIONAL

  }

 

  CertOrEncCert ::= CHOICE {

      certificate     [0] Certificate,

      encryptedCert   [1] EncryptedValue

  }

 

Položka CertOrEncCert může obsahovat buď certifikát nebo šifrovaný certifikát. Šifrovaný certifikát je užitečné zaslat uživateli v případě, že žádal o vydání šifrovacího certifikátu. Uživatel certifikát dešifruje a dešifrovaný vrátí CA. Tím uživatel prokáže, že vlastní příslušný soukromý klíč.

V případě, že uživatel požadoval vygenerování dvojice veřejný/soukromý klíč na CA, pak v položce privateKey vrací CA zašifrovaný soukromý klíč uživatele.

 

 

8.8.6                      Obnovení klíčů

V případě, že CA generovala pro uživatele dvojici veřejný/soukromý klíč a archivovala ji, pak uživatel v případě ztráty klíče může žádat o obnovení.

 

Žádost je formátu CRMF a odpověď má následující strukturu:

 

KeyRecRepContent ::= SEQUENCE {

  status          PKIStatusInfo,

  newSigCert  [0] Certificate                OPTIONAL,

  caCerts     [1] SEQUENCE SIZE (1..MAX) OF  Certificate      OPTIONAL,

  keyPairHist [2] SEQUENCE SIZE (1..MAX) OF  CertifiedKeyPair OPTIONAL

}

 

8.8.7                      Odvolání certifikátu

Pokud je uživatel schopen podat elektronicky žádost o odvolání certifikátu, pak použije zprávu RevReqContent, která je sekvencí požadavků na odvolání jednotlivých certifikátů.

 

RevReqContent ::= SEQUENCE OF RevDetails

 

Typ RevDetails obsahující požadavky na odvolání konkrétního certifikátu má strukturu:

 

RevDetails ::= SEQUENCE {

         certDetails         CertTemplate,

         revocationReason    ReasonFlags      OPTIONAL,

         badSinceDate        GeneralizedTime  OPTIONAL,

         crlEntryDetails     Extensions       OPTIONAL

     }

Význam jednotlivých položek:

 

CA odpoví zprávou Revocation Response Content:

 

RevRepContent ::= SEQUENCE {

  status        SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,

  revCerts  [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,

  crls      [1] SEQUENCE SIZE (1..MAX) OF CertificateList  OPTIONAL

}

 

Význam jednotlivých položek:

 

8.8.8                      Vydání nového certifikátu kořenové CA

V případě, že dojde k vydání nového certifikátu kořenové CA, pak CA zprávou CA Key Update Announcement content nabízí trojici certifikátů:

CAKeyUpdAnnContent ::= SEQUENCE {

  oldWithNew          Certificate,

  newWithOld          Certificate,

  newWithNew          Certificate

  }

 

Druhý z trojice certifikátů newWithOld slouží k tomu, aby příjemce si podle starého certifikátu mohl ověřit, že nový certifikát (newWithNew) není žádný podvrh, a mohl si nový certifikát bez obav nahrát do svého software. No a první certifikát oldWithNew zase slouží klientům majícím podepsaný certifikát novým certifikátem, aby věřili klientům a serverům s certifikátem podepsaným starým klíčem.

 

8.8.9                      Potvrzení

Mnohé komunikace se skládají ze tří kroků. Např. u žádosti o certifikát uživatel podá žádost a CA/RA v odpovědi vrátí vydaný certifikát. Potvrzení přijetí vydaného certifikátu se provádí zprávou „Potvrzení“ (PKI Confirmation Content). Tato zpráva má zpravidla prázdný obsah, protože veškeré informace jsou neseny v záhlaví.

8.8.10                  Další zprávy

Nabídka certifikátu a CRL

Zpráva nabídka certifikátu (Certificate Announcement) slouží k distribuci certifikátu (nejsou-li např. k dispozici adresářové služby). Obdobnou zprávou je i nabídka CRL (CRL Announcement).

 

Nabídka odvolání certifikátu CA

Zpráva nabídka odvolání certifikátu (Revocation Announcement) je opět zprávou CA pro případ, že by došlo k odvolání certifikátu samotné CA.

 

Chybová zpráva

Obecná chybová zpráva protokolu CMP má tvar:

 

 ErrorMsgContent ::= SEQUENCE {

   pKIStatusInfo          PKIStatusInfo,

   errorCode              INTEGER           OPTIONAL,

   errorDetails           PKIFreeText       OPTIONAL

}

 

Kde položky errorCode a errorDetails jsou ponechány na implementaci aplikace.

 

Obecná zpráva a odpověď na ní

Tvůrcům aplikace je v těchto zprávách ponechán prostor pro případy, které nepokryjí předchozí zprávy.

 

8.8.11                  Přenos protokoly TCP/IP a rozšíření souborů

Zprávy protokolu CMP mohou být přenášeny On Line komunikací přímo protokolem TCP, elektronickou poštou nebo protokolem HTTP. 

 

 TCP On Line komunikace

CMP protokol je možné použít  jako aplikační protokol běžící nad protokolem TCP. Server CMP zpravidla běží na portu 829/tcp. Zprávy CMP jsou baleny do transportních paketů, které jsou blíže popsány v RFC-2510.

 

Komunikace elektronickou poštou

CMP zprávy, které jsou DER-kódovány, se musí převést do sedmibitového tvaru pomocí kódování Base64. MIME-typ přenášených dat je application/pkixcmp. Takže záhlaví zprávy elektronické pošty bývá pro přenos zpráv protokolu CMP doplněno hlavičkami:

 

Content-Type: application/pkixcmp

Content-Transfer-Encoding: base64 

 

Komunikace protokolem HTTP

Zde se opět použije typ přenášených dat application/pkixcmp, tj. hlavička

 

Content-Type: application/pkixcmp

 

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:

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 4 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)

    ct(1) 2 }

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)

    ct(1) 6 }

1.2.840.113549.1.9.15

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 podepsané zprávy

Jedna věc je popis struktury elektronicky podepsané zprávy a druhá je konkrétní příklad. Nejlépe je studovat tvar elektronicky podepsané zprávy na externím elektronickém podpisu. Jako příklad použijeme elektronickou zprávu odeslanou programem MS Outlook 2000. Abychom příliš nemrhali papírem, tak nejprve nastavíme MS Outlook tak, aby nám do elektronicky podepsané zprávy nevkládal certifikáty odesilatele (obr. 8-19), což v praxi není příliš praktické, protože tím zamezíme jinak žádoucí distribuci certifikátů.

 

Obr. 8-19 Zrušením volby „S podepsanými zprávami posílat tato osvědčení“ zrušíme vkládání certifikátu do elektronicky podepsané zprávy (osvědčení = certifikát)

Rovněž jsem v MS Outlooku nastavil, aby se zprávy zasílaly pouze v textovém tvaru. (Nástroje -> Možnosti -> Formát pošty -> Odeslat v tomto formátu -> Prostý text).

Nyní již můžeme odeslat elektronicky podepsanou zprávu elektronické pošty (obr. 8-20).

 

Obr. 8-20 Odesílaná zpráva

.

Nyní si počíháme na uživatele, který bude tuto zprávu stahovat protokolem POP3. Spustíme si na jeho LAN MS-Network Monitor (obr. 8-21) a začneme sledovat provoz na LAN.

 

Obr. 8-21 Network Monitorem zachycený první paket poštovní zprávy

Nyní z Network Monitoru postupně okopírujeme obsah všech paketů spojení a získáme celou komunikaci uživatele s POP3 serverem. Rozborem následujícího dialogu si zopakujete i kapitolu o aplikačních protokolech i kapitolu o MIME: 

 

POP3 S: +OK QPOP ( version.2.1.4-R4-b5a  starting …

POP3 C: USER uživatel

POP3 S: +OK Password required for uživatel

POP3 C: PASS heslo

POP3 S: +OK test has 1 message(s) (4908 octets)

…

POP3 C: RETR 1

POP3 S: +OK 2232 octets

 

SMTP: X-UIDL: b817b080eaf955473464e6923d987cbc

SMTP: Received: from.smtp.nextra.cz (dns.nextra.cz.[195.70.130.1])

SMTP:   by.t1.pvt.cz (8.9.3/8.9.3) with ESMTP id.LAA30018

SMTP:   for.<test@t1. pvt.cz>;.Wed,.7. Mar.2001.11:35:19 +0100 (MET)

SMTP: Received: from libor ([195.47.37.200])

SMTP:   by smtp.nextra.cz (8.11.1/8.11.1) with SMTP id.f27AZLU12227

SMTP:   for <test@t1.pvt.cz>; Wed, 7 Mar 2001 11:35:21 +0100 (CET)

SMTP:   (envelope-from.dostalek@pvt.cz)

SMTP: From: "Libor Dostalek" dostalek@pvt.cz

SMTP: To: test@t1.pvt.cz

SMTP: Subject: Banka

SMTP: Date: Wed, 7 Mar 2001.11:32:58 +0100

SMTP: MIME-Version:.1.0

SMTP: Message-ID: 000c01c0a6f1$fb6c6cd0$c8252fc3@libor

SMTP: Content-Type: multipart/signed;

SMTP:   protocol="application/x-pkcs7-signature";

SMTP:   micalg=SHA1;

SMTP:   boundary="----=_NextPart_000_0027_01C0A6FA.5C17C3B0"

SMTP: X-Priority: (Normal)

SMTP: X-MSMail-Priority: Normal

SMTP: X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)

SMTP: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

SMTP: Importance: Normal

SMTP:

SMTP: Toto je zpráva ve formátu MIME obsahující více částí

SMTP:

SMTP: ------=_NextPart_000_0027_01C0A6FA.5C17C3B0

SMTP: Content-Type: text/plain;

SMTP:    charset="iso-8859-2"

SMTP: Content-Transfer-Encoding: 7bit

SMTP:

SMTP: Banka na namesti v 11:00

SMTP:

SMTP: Sef

SMTP:

SMTP: ------=_NextPart_000_0027_01C0A6FA.5C17C3B0

SMTP: Content-Type: application/x-pkcs7-signature;

SMTP:    name="smime.p7s"

SMTP: Content-Transfer-Encoding: base64

SMTP: Content-Disposition: attachment;

SMTP:    filename="smime.p7s"

SMTP:

SMTP: MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYICOjCCAjYC

SMTP: AQEwZDBdMQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZUIGEucy4xETAPBgNVBAsTCDIwMDAwOTAx

SMTP: MSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0b3JpdGEgSS5DQSAwMDA5AgMB4BIwCQYFKw4DAhoF

SMTP: AKCCASwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMzA3MTAz

SMTP: MjU4WjAjBgkqhkiG9w0BCQQxFgQUiTyLOzG09qg6S71Ob5OHiiSyYUgwWAYJKoZIhvcNAQkPMUsw

SMTP: STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF

SMTP: Kw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQswCQYDVQQGEwJDWjERMA8GA1UE

SMTP: ChMIUFZUIGEucy4xETAPBgNVBAsTCDIwMDAwOTAxMSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0

SMTP: b3JpdGEgSS5DQSAwMDA5AgMB4BIwDQYJKoZIhvcNAQEBBQAEgYBjQe3gKqprZNG20K3O9bBEPWPx

SMTP: MiHfiupGBw799nMPFuJThITq8aR/JnPusFw9HJMFF+TrAxxk4f9jlYFaVDm9HdrdjODAGh1tP91x

SMTP: jZ+1By37iibmNV2C23Px1Vq+aoZON0ZDEIqjqnm0D2ruqqrdCa9rpx/j8Pb4nayRi0d2HQAAAAAA

SMTP: AA==

SMTP:

SMTP: ------=_NextPart_000_0027_01C0A6FA.5C17C3B0--

 

POP3 C: DELE 1

POP3 S: +OK.Message 1 has.been.deleted        

POP3 C: QUIT

POP3 S: +OK Pop server at signing off

 

Odchytili jsme poštovní zprávu ve formátu MIME skládající se ze dvou částí (multipart/signed). První část obsahuje zprávu a druhá část obsahuje elektronický podpis kódovaný Base64 (tvar PEM):

 

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYICOjCCAjYC

AQEwZDBdMQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZUIGEucy4xETAPBgNVBAsTCDIwMDAwOTAx

MSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0b3JpdGEgSS5DQSAwMDA5AgMB4BIwCQYFKw4DAhoF

AKCCASwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMzA3MTAz

MjU4WjAjBgkqhkiG9w0BCQQxFgQUiTyLOzG09qg6S71Ob5OHiiSyYUgwWAYJKoZIhvcNAQkPMUsw

STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF

Kw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQswCQYDVQQGEwJDWjERMA8GA1UE

ChMIUFZUIGEucy4xETAPBgNVBAsTCDIwMDAwOTAxMSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0

b3JpdGEgSS5DQSAwMDA5AgMB4BIwDQYJKoZIhvcNAQEBBQAEgYBjQe3gKqprZNG20K3O9bBEPWPx

MiHfiupGBw799nMPFuJThITq8aR/JnPusFw9HJMFF+TrAxxk4f9jlYFaVDm9HdrdjODAGh1tP91x

jZ+1By37iibmNV2C23Px1Vq+aoZON0ZDEIqjqnm0D2ruqqrdCa9rpx/j8Pb4nayRi0d2HQAAAAAA

AA==

 

Po dekódování Base64 obdržíme (šestnáctkově):

 

308006092a864886f70d010702a0803080020101310b300906052b0e03021a0500308006092a8648

86f70d01070100003182023a308202360201013064305d310b300906035504061302435a3111300f

060355040a130850565420612e732e3111300f060355040b13083230303030393031312830260603

550403131f436572746966696b61636e69206175746f7269746120492e43412030303039020301e0

12300906052b0e03021a0500a082012c301806092a864886f70d010903310b06092a864886f70d01

0701301c06092a864886f70d010905310f170d3031303330373130333235385a302306092a864886

f70d01090431160414893c8b3b31b4f6a83a4bbd4e6f93878a24b26148305806092a864886f70d01

090f314b3049300a06082a864886f70d0307300e06082a864886f70d030202020080300706052b0e

030207300d06082a864886f70d0302020128300706052b0e03021a300a06082a864886f70d020530

7306092b060104018237100431663064305d310b300906035504061302435a3111300f060355040a

130850565420612e732e3111300f060355040b13083230303030393031312830260603550403131f

436572746966696b61636e69206175746f7269746120492e43412030303039020301e012300d0609

2a864886f70d01010105000481806341ede02aaa6b64d1b6d0adcef5b0443d63f13221df8aea4607

0efdf6730f16e2538484eaf1a47f2673eeb05c3d1c930517e4eb031c64e1ff6395815a5439bd1dda

dd8ce0c01a1d6d3fdd718d9fb5072dfb8a26e6355d82db73f1d55abe6a864e374643108aa3aa79b4

0f6aeeaaaadd09af6ba71fe3f0f6f89dac918b47761d000000000000

 

Nyní si můžeme provést rozbor celé zprávy:

 

SEQUENCE         

    30 80

  OBJECT            :pkcs7-signedData

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

  cont [ 0 ]       

     a0 80

   SEQUENCE         

      30 80

    INTEGER           :01

       02 01 01

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :sha1

         06 05 2b 0e 03 02 1a

      NULL             

         05 00

    SEQUENCE         

       30 80

     OBJECT            :pkcs7-data

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

     EOC              

        00 00

    SET              

       31 82 02 3a

     SEQUENCE         

        30 82 02 36

      INTEGER           :01

         02 01 01

      SEQUENCE          

         30 64

       SEQUENCE         

          30 5d

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        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

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :20000901

             13 08 32 30 30 30 30 39 30 31

        SET              

           31 28

         SEQUENCE         

            30 26

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Certifikacni autorita I.CA 0009

             13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

             69 74 61 20 49 2e 43 41 20 30 30 30 39

       INTEGER           :01E012

          02 03 01 e0 12

      SEQUENCE         

         30 09

       OBJECT            :sha1

          06 05 2b 0e 03 02 1a

       NULL             

          05 00

      cont [ 0 ]       

         a0 82 01 2c

       SEQUENCE         

          30 18

        OBJECT            :contentType

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

        SET              

           31 0b

         OBJECT            :pkcs7-data

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

       SEQUENCE         

          30 1c

        OBJECT            :signingTime

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

        SET              

           31 0f

         UTCTIME           :010307103258Z

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

       SEQUENCE         

          30 23

        OBJECT            :messageDigest

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

        SET              

           31 16

         OCTET STRING     

            04 14 89 3c 8b 3b 31 b4 f6 a8 3a 4b bd 4e 6f 93 87 8a 24 b2

            61 48

       SEQUENCE         

          30 58

        OBJECT            :1.2.840.113549.1.9.15 (S/Mime capabilities)

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

        SET              

           31 4b

         SEQUENCE         

            30 49

          SEQUENCE         

             30 0a

           OBJECT            :des-ede3-cbc

              06 08 2a 86 48 86 f7 0d 03 07

          SEQUENCE         

             30 0e

           OBJECT            :rc2-cbc

              06 08 2a 86 48 86 f7 0d 03 02

           INTEGER           :80

              02 02 00 80

          SEQUENCE         

             30 07

           OBJECT            :des-cbc

              06 05 2b 0e 03 02 07

          SEQUENCE         

             30 0d

           OBJECT            :rc2-cbc

              06 08 2a 86 48 86 f7 0d 03 02

           INTEGER           :28

              02 01 28

          SEQUENCE         

             30 07

           OBJECT            :sha1

              06 05 2b 0e 03 02 1a

          SEQUENCE         

             30 0a

           OBJECT            :md5

              06 08 2a 86 48 86 f7 0d 02 05

       SEQUENCE         

          30 73

        OBJECT            :1.3.6.1.4.1.311.16.4  (1.3.6.1.4.1.311 je OID pro Microsoft)

           06 09 2b 06 01 04 01 82 37 10 04

        SET              

           31 66

         SEQUENCE         

            30 64

          SEQUENCE         

             30 5d

           SET              

              31 0b

            SEQUENCE         

               30 09

             OBJECT            :countryName

                06 03 55 04 06

             PRINTABLESTRING   :CZ

                13 02 43 5a

           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

           SET              

              31 11

            SEQUENCE         

               30 0f

             OBJECT            :organizationalUnitName

                06 03 55 04 0b

             PRINTABLESTRING   :20000901

                13 08 32 30 30 30 30 39 30 31

           SET              

              31 28

            SEQUENCE         

               30 26

             OBJECT            :commonName

                06 03 55 04 03

             PRINTABLESTRING   :Certifikacni autorita I.CA 0009

                13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

                69 74 61 20 49 2e 43 41 20 30 30 30 39

          INTEGER           :01E012

             02 03 01 e0 12

      SEQUENCE         

         30 0d

       OBJECT            :rsaEncryption

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

       NULL             

          05 00

      OCTET STRING     

         04 81 80 63 41 ed e0 2a aa 6b 64 d1 b6 d0 ad ce f5 b0 44 3d

         63 f1 32 21 df 8a ea 46 07 0e fd f6 73 0f 16 e2 53 84 84 ea

         f1 a4 7f 26 73 ee b0 5c 3d 1c 93 05 17 e4 eb 03 1c 64 e1 ff

         63 95 81 5a 54 39 bd 1d da dd 8c e0 c0 1a 1d 6d 3f dd 71 8d

         9f b5 07 2d fb 8a 26 e6 35 5d 82 db 73 f1 d5 5a be 6a 86 4e

         37 46 43 10 8a a3 aa 79 b4 0f 6a ee aa aa dd 09 af 6b a7 1f

         e3 f0 f6 f8 9d ac 91 8b 47 76 1d

    EOC              

       00 00

   EOC              

      00 00

  EOC              

     00 00

8.9.5                      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.6                      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.7                      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.8                      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.9                      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

Zbývá nám tedy popsat tělo CMC zprávy, tj. dvě struktury: PKIData a ResponseBody. Struktura PKIData má následující strukturu:

 

   PKIData ::= SEQUENCE {

         controlSequence    SEQUENCE SIZE(0..MAX) OF TaggedAttribute,

         reqSequence        SEQUENCE SIZE(0..MAX) OF TaggedRequest,

         cmsSequence        SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,

         otherMsgSequence   SEQUENCE SIZE(0..MAX) OF OtherMsg

   }

 

Zpráva PKIData se skládá ze čtyř položek: controlSequence, reqSequence, cmsSequence a otherMsgSequence. Každá z těchto položek je sekvencí tvořenou úseky zprávy. Např. controlSekvence se skládá ze sekvence tvořenou úseky zprávy typu TaggedAttribute. Každý úsek zprávy má svou identifikaci. Identifikací úseku zprávy je celé číslo bodyPartID.  Identifikace bodyPartID umožní odpovědi CA přesně konkretizovat úsek zprávy PKIData; např. přesně konkretizovat úsek, který považuje za chybný, apod.

 

 

Jednotlivé položky struktury PKIData mají následující význam:

    TaggedAttribute ::= SEQUENCE {

        bodyPartID         BodyPartId,

        attrType           OBJECT IDENTIFIER,

        attrValues         SET OF AttributeValue

    }

    TaggedRequest ::= CHOICE {

        tcr               [0] TaggedCertificationRequest,

        crm               [1] CertReqMsg    -- žádost CRMF

 

    }

 

    TaggedCertificationRequest ::= SEQUENCE {

        bodyPartID            BodyPartID,

        certificationRequest  CertificationRequest – žádost PKCS#10

    }

 

Položka cmsSequence je tvořena posloupností zpráv typu TaggedContentInfo skládající se ze sekvence tvořenou dvojicí (identifikátor úseku zprávy, vnořená CMS zpráva):

    TaggedContentInfo ::= SEQUENCE {

        bodyPartID              BodyPartId,

        contentInfo             ContentInfo

    }

 

 

    OtherMsg ::= SEQUENCE {

        bodyPartID        BodyPartID,

        otherMsgType      OBJECT IDENTIFIER,

        otherMsgValue     ANY DEFINED BY otherMsgType }

 

 

Obr. 8-27 Zpráva RA obsahující vnořené zprávy uživatelů

 

Struktura responseBody má tvar:

    ResponseBody ::= SEQUENCE {

        controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,

        cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,

        otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg

    }

Zajímavé je, tato struktura obsahuje stejné položky jako struktura PKIData (pochopitelně kromě položky reqSequence).

 

8.10.2                  Atributy

Některé dále popsané atributy mají obdobný význam jako některé položky žádosti o certifikát tvaru CRMF. Může tak dojít ke kolizím mezi údaji uvedenými v žádosti CRMF a zprávě CMC. Řešení těchto konfliktů je blíže popsáno v kapitole 3.3.2 normy RFC-2797.

 

Pro atributy máme následující identifikátory objektů:

 

id-cmc-cMCStatusInfo   OBJECT IDENTIFIER ::= {id-cmc 1}

id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}

id-cmc-identityProof   OBJECT IDENTIFIER ::= {id-cmc 3}

id-cmc-dataReturn      OBJECT IDENTIFIER ::= {id-cmc 4}

id-cmc-transactionId   OBJECT IDENTIFIER ::= {id-cmc 5}

id-cmc-senderNonce     OBJECT IDENTIFIER ::= {id-cmc 6}

id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}

id-cmc-addExtensions   OBJECT IDENTIFIER ::= {id-cmc 8}      

id-cmc-encryptedPOP    OBJECT IDENTIFIER ::= {id-cmc 9}      

id-cmc-decryptedPOP    OBJECT IDENTIFIER ::= {id-cmc 10}     

id-cmc-lraPOPWitness   OBJECT IDENTIFIER ::= {id-cmc 11}     

id-cmc-getCert         OBJECT IDENTIFIER ::= {id-cmc 15}     

id-cmc-getCRL          OBJECT IDENTIFIER ::= {id-cmc 16}      

id-cmc-revokeRequest   OBJECT IDENTIFIER ::= {id-cmc 17}     

id-cmc-regInfo         OBJECT IDENTIFIER ::= {id-cmc 18}

id-cmc-responseInfo    OBJECT IDENTIFIER ::= {id-cmc 19}

id-cmc-queryPending    OBJECT IDENTIFIER ::= {id-cmc 21}

id-cmc-popLinkRandom   OBJECT IDENTIFIER ::= {id-cmc 22)

id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)

 

Kde:

id-cmc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)

        dod(6) internet(1) security(5) mechanisms(5) pkix(7) 7}

 

Status (CMC Status Info)

Tento atribut s identifikátorem objektu id-cmc-CMCStatusInfo se používá v úplných odpovědích CA pro signalizaci, jak vyřízení požadavku dopadlo, a v případě, že požadavek nemohl být vyřízen, pak obsahuje informaci, z jakého důvodu byl zamítnut.

 

Atributů Status může být v odpovědi i více,. jeden pro každý úsek struktury PKIData.

 

Hodnota tohoto atributu má následující syntaxi:

 

      CMCStatusInfo ::= SEQUENCE {

           cMCStatus           CMCStatus,

           bodyList            SEQUENCE SIZE (1..MAX) OF BodyPartID,

           statusString        UTF8String OPTIONAL,

           otherInfo           CHOICE {

             failInfo            CMCFailInfo,

             pendInfo            PendInfo } OPTIONAL

      }

 

      PendInfo ::= SEQUENCE {

           pendToken           OCTET STRING,

           pendTime            GeneralizedTime

      }

 

Význam jednotlivých položek:

 

 

Identifikace uživatele (Identification and Identity Proof Control Attributes)

Toto rozšíření používá identifikátor objektu id-cmc-identification.  Prakticky se jedná o rozšíření sloužící nejčastěji k vydání prvního certifikátu. Registrační autorita musí identifikovat uživatele, který podává žádost o certifikát.

 

V principu jsou dvě možnosti:

·         Uživatel přinese žádost osobně např. na disketě na RA a prokáže se svým občanským průkazem. V takovém případě použití atributu „Identifikace uživatele“ není potřebné.

·         Uživatel sepíše smlouvu. Součástí tohoto aktu je pak předání sdíleného tajemství uživateli. Uživatel pak toto sdílené tajemství mezi jím a CA využije k prokázání své totožnosti atributem „Identifikace uživatele“.

 

Je v podstatě na provozovateli CA, kterou z možností zvolí. Druhá možnost nevyžaduje fyzický kontakt média uživatele s počítačem RA a tudíž zabraňuje např. zavirování PC na RA. Ovšem pokud má RA zavirovaný počítač, je to mnohem hlubší a podstatnější problém.

 

Hodnota atributu „Identifikace Uživatele (Identification) “ je OCTET STRING obsahující jednorázové heslo, jak jsme jej popsali v kapitole 4. Jednorázové heslo může být generováno např. algoritmem HMAC (RFC-2104) či autentizačním kalkulátorem.

 

Jenže použití jednorázových hesel popsaných v kap. 4 je vázáno na interaktivní komunikaci dotaz/odpověď. Zde žádný dotaz nemáme, a tak se místo z dotazu kontrolní součet počítá ze žádosti o certifikát a sdíleného tajemství (blíže viz RFC-2797).

 

Spojení identifikace uživatele s důkazem o vlastnictví odpovídajícího soukromého klíče

Při podání žádosti o certifikát je nutné nejenom prověřit identifikaci žadatele, ale i zkontrolovat, zda-li uživatel opravdu vlastní soukromý klíč k veřejnému klíči uvedenému v žádosti. Obě kontroly je třeba provázat, aby útočník nemohl zaměnit žádost o certifikát na cestě na CA.

 

Záměna žádosti o certifikát je totiž nejefektivnějším způsobem útoku na PKI vůbec. Pro jednoduchost si představme úplně hloupý útok v případě, že osobně neseme žádost o certifikát formátu PKCS#10 na disketě na RA. Pak úplně nejjednodušší je pro útočníka vám po cestě na RA zaměnit disketu za disketu s žádostí, kterou si útočník pokoutně vygeneroval. (To už vůbec neuvažuji případ, že útočník se nechá zaměstnat jako zaměstnanec RA a zaměňuje žádosti uživatelů za podvržené žádosti .Tomu se lze bránit právě používáním sdíleného tajemství, které vydá někdo jiný než pracovník RA.)

 

Důkaz vlastnictví soukromého klíče se provede elektronickým podpisem využívajícím příslušný soukromý klíč, který je součástí žádosti PKCS#10 i žádosti CRMF. Pokud žádáme o šifrovací certifikát, tak pro tento důkaz slouží speciální atribut popsaný dále.

 

V případě, že se klientovi vydává sdílené tajemství, pak pravděpodobně si při vydávání sdíleného tajemství poznamenáme do databáze i identifikační údaje, které chce mít v předmětu svého certifikátu. Pak stačí při vydávání certifikátu zkontrolovat, zda-li údaje v předmětu souhlasí s údaji v databázi.

 

Tato metoda není univerzální a rozhodně se nehodí pro certifikáty s prázdným předmětem. Proto máme další metodu, která je univerzálnější. Využívá dva atributy: idPOPLinkRandom a idPOPLinkWitness.

 

Žadatel o certifikát vygeneruje náhodné číslo minimálně 512 bitů dlouhé. Toto náhodné číslo zašifruje veřejným klíčem CA a uloží do atributu idPOPLinkRandom. Z náhodného čísla a sdíleného tajemství spočte kontrolní součet (jednorázové heslo), které uloží do atributu idPOPLinkWitness. CA si dešifruje náhodné číslo. Jedná se o autentizaci typu dotaz/odpověď. Náhodné číslo je v tomto případě jako dotaz a obsah atributu idPOPLinkWitness je jako odpověď.

 

V případě obnovování certifikátu umožňujícího elektronický podpis je žádost o certifikát vložena do elektronicky podepsané CMS zprávy Signed Data předchozím ještě platným certifikátem. V takovém případě požadavek žadatele obsahuje dva elektronický podpisy. Vnitřním podpisem žadatel dokazuje, že vlastní příslušný soukromý klíč a vnějším podpisem prokazuje svou identitu.

 

Řetězec dat (Data Return Control Attribute)

 

Tento atribut používá identifikátor objektu id-cmc-dataReturn. Je určen pro předání nějakého sjednaného řetězce. Příkladem použití může být např. informace o tom, že klient používá autentizační kalkulátor, a jeho typ.

 

Další rozšíření certifikátu (Add Extensions Control Attribute)

Při vydávání certifikátů je potíž v tom, že se musí určit, kdo které údaje do certifikátů dodá. Ani co se týče předmětu certifikátu to není zcela jasné. Nelze totiž vzít vše z žádosti, některá relativní jedinečná jména jako serialNumber (nezaměňovat s číslem certifikátu – je to jen shoda názvů!) či dnQualifier může stejně dodat jen certifikační autorita.

 

Otázka, kdo dodá rozšíření, je spíše detektivkou. Rozšíření může uvést žadatel o certifikát do své žádosti, může je dodat RA a konečně je může vytvořit i CA. Právě atribut „Další rozšíření certifikátu“ umožňuje RA přibalit k žádosti o certifikát návrh na rozšíření certifikátu. RA totiž nemůže do žádosti o certifikát nic přidat, protože žádost bývá zpravidla elektronicky podepsána.

 

     AddExtensions ::= SEQUENCE {

         pkiDataReference             BodyPartID

         certReferences               SEQUENCE OF BodyPartID,

         extensions                   SEQUENCE OF Extension

     }

 

Struktura AddExtension se skládá ze tří položek:

·         Položka pkiDataReference je identifikací úseku zprávy.

·         Položka certReferences  obsahuje odkazy na úseky zpráv (tj. na samotné žádosti o certifikáty), kterých se rozšíření uvedená v následující položce týkají.

·         Položka extension obsahuje příslušná rozšíření.

 

Řízení relace (Transaction Management Control Attributes)

Tento atribut slouží k udržení relace přes několik dotazů/odpovědí protokolu CMC (dotazem se myslí struktura PKIData a odpovědí struktura ResponseBody). Klient generuje identifikátor transakce a server jej zkopíruje do své odpovědi.

 

Jako ochrana proti útoku zopakováním zprávy (replay attack) se použijí další dva atributy: recipientNonce a senderNonce. Klient nejprve vygeneruje řetězec, který vloží do atributu senderNonce (na počátku nepoužije atribut recipientNonce). Server příjme zprávu a do atributu recipientNonce své odpovědi zkopíruje řetězec z klientova atributu senderNonce. Do atributu senderNonce vygeneruje svůj řetězec. Klient opět přijatý atribut senderNonce zkopíruje do atributu recipientNonce zprávy PKIData posílající na server atd.

 

Důkaz vlastnictví soukromého klíče pro šifrovací certifikáty (Proof-of-possession (POP) for encryption-only keys)

Je to obdobné, jako jsem popsal u CRMF žádosti. Protokol CMC používá dva atributy: encryptedPOP a decryptedPOP. Zjednodušeně to pracuje tak, že CA vygeneruje náhodné číslo a zašifruje jej veřejným klíčem žadatele. Takto zašifrované náhodné číslo vrátí žadateli jako dotaz ve zprávě obsahující atribut encryptedPOP. Žadatel náhodné číslo dešifruje a vrátí jej v atributu decryptedPOP. Blíže viz RFC-2797.

 

Nikdo jiný nemůže dešifrované náhodné číslo CA vrátit než ten, kdo zná příslušný soukromý klíč (tj. žadatel).

 

Kontrolu provedla RA (LRA POP Witnesses Control Attribute)

Pro případ, že kontrolu provede registrační autorita (např. žadatel se dostavil osobně s disketou na RA), pak není již nutná další elektronická kontrola. RA pouze vyplní atribut lraPOPWitness informující o tom, které žádosti takto zkontrolovala.

 

      LraPopWitness ::= SEQUENCE {

          pkiDataBodyid   BodyPartID,

          bodyIds         SEQUENCE of BodyPartID

      }

 

Hodnotou tohoto atributu je struktura LraPopWitness. Ta se skládá z identifikace úseku zprávy pkiDataBodyID (jako všechny ostatní úseky) a sekvence identifikací žádostí (resp. úseků zpráv) obsahující takto lustrované žádosti o certifikát.

 

 

Žádost o dříve vydaný certifikát (Get Certificate Control Attribute)

Tímto atributem může klient požádat CA o zaslání certifikátu vydaného CA, tj. nemusí žádat o certifikát svůj, ale o libovolný certifikát vydaný CA. Jedná se tedy o obdobnou službu, jakou poskytuje CA např. protokolem LDAP.

 

Hodnotou tohoto atributu je identifikace certifikátu, tj. jedinečné jméno vydavatele a sériové číslo certifikátu:

 

      GetCert ::= SEQUENCE {

          issuerName    GeneralName,

          serialNumber  INTEGER }

 

Zajímavostí je, že server může na úplnou CMC zprávu odpovědět krátkou CMC zprávou s příslušným certifikátem.

 

Žádost o CRL (Get CRL Control Attribute)

Pomocí tohoto atributu lze požádat o CRL, které bylo platné v době udané v atributu.

 

      GetCRL ::= SEQUENCE {

          issuerName    Name,

          cRLName       GeneralName OPTIONAL,

          time          GeneralizedTime OPTIONAL,

          reasons       ReasonFlags OPTIONAL }

 

Hodnotou tohoto atributu je struktura GetCRL skládající se z následujících položek:

·         Položka issuerName obsahuje jedinečné jméno CA.

·         Položka cRLName může obsahovat hodnotu atributu CRLDistributionPoints uváděnou v certifikátu.

·         Položka time může obsahovat čas, ve kterém nás zajímá, zdali certifikát nebyl náhodou odvolán.

·         Položka reasons může obsahovat důvody odvolání.

 

Žádost o odvolání certifikátu (Revocation Request Control Attribute)    

Požádat o odvolání certifikátu elektronickou cestou může klient za pomoci atributu s identifikátorem objektu  id-cmc-revokeRequest. Hodnotou tohoto atributu je struktura:

 

RevRequest ::= SEQUENCE {

          issuerName      Name,

          serialNumber    INTEGER,

          reason          CRLReason,

          invalidityDate  GeneralizedTime OPTIONAL,

          sharedSecret    OCTET STRING OPTIONAL,

          comment         UTF8string OPTIONAL }

 

S následujícími položkami:

·         Položka issuerName obsahuje jedinečné jméno CA.

·         Položka seriálNumber obsahuje sériové číslo odvolávaného certifikátu.

·         Položka reason obsahuje důvod odvolání (viz CRL).

·         Položka ivalidityDate obsahuje datum a čas ztráty nebo zcizení soukromého klíče.

·         Položka sharedSecret obsahuje jednorázové heslo pro odvolání certifikátu, které bylo uživateli vydáno při vydání certifikátu.

·         Položka comment obsahuje další komentář.

 

Elektronicky lze odvolat certifikát dvojím způsobem:

·         Pokud máme k dispozici i prozrazený soukromý klíč, pak pomocí něj elektronicky podepíšeme žádost o odvolání. Tj. není potřeba položka sharedSecret.

·         Pokud již nemáme k dispozici soukromý klíč, pak uvedeme jednorázové tajemství pro odvolání certifikátu. Tajemství není třeba šifrovat, protože se jedná o jednorázové heslo.

 

Pokud nemáme k dispozici ani jedno ani druhé, pak kontaktujeme CA/RA osobně.

 

Dotaz na zpracování požadavku (Query Pending Control Attribute)

Pomocí tohoto atributu se klient může dotázat RA/CA na stav požadavků (jestli už byly zpracovány).

 

Potvrzení o přijetí odpovědi (Confirm Certificate Acceptance)

Některé CA mohou od klienta požadovat, aby jim potvrdil přijetí vydaného certifikátu. Klient pak odpovídá zprávou s tímto atributem. Hodnotou atributu je číslo vydaného certifikátu.

 

8.10.3                  MIME a rozšíření souborů

CMC zprávy mohou být transportovány elektronickou poštou či jinými protokoly používajícími MIME nebo odvozenými od MIME (např. HTTP).

 

Pokud se CMC zprávy transportují těmito protokoly, pak jsou vloženy do zprávy CMS, tj. použije se:

 

 

Content-type:

rozšíření

Jednoduchá žádost

application/pkcs10

.p10

Jednoduchá odpověď

application/pkcs7-mime

.p7m

Úplná žádost

application/pkcs7-mime

.p7c

Úplná odpověď

application/pkcs7-mime

.p7m

 

V případě, že se CMC zprávy předávají přímo např. jako soubory na disketách, pak:

·         Struktura PKIData se předá jako BER kódovaný soubor s příponou .crq

·         Struktura  ResponseBody se předá jako BER kódovaný soubor s příponou .crp.

 

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                  DVCS server

Klient zasílá svůj požadavek (tzv. žádost o DVC certifikát) na DVCS server. Požadavek vždy obsahuje data, jejichž platnost se má ověřit. Požadavek klienta může být (a odpověď serveru musí být) elektronicky podepsána (CMS SignedData).

 

Je-li žádost o DVC certifikát vložena do CMS zprávy (CMS SignedData), pak se jako identifikátor objektu (eContentType) uvede:

 

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

     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7}

 

Obdobně odpověď DVCS serveru (tj. DVC certifikát nebo chybové hlášení) používá identifikátor objektu:

 

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

     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 8 }

 

 

Jako transportní protokol se použije např. HTTPS (tj. HTTP přes SSL/TLS), CMS nebo S/MIME. V případě HTTPS se posílá DER kódovaná zpráva s hlavičkou:

Content-Type: application/dvcs

 

V případě MIME (elektronické pošty) se navíc DER kódovaná zpráva musí ještě kódovat Base64, tj. musí se přidat hlavička:

Content-Transfer-Encoding: Base64

 

DVCS server ověří, zda-li je požadavek platný, a generuje výsledek – DVC certifikát. DVC certifikát je vždy elektronicky podepsán DVCS serverem (konkrétně se jedná  o zprávu CMS Signed Data). DVC certifikát nemusí být vrácen okamžitě stejným kanálem – např. klient pošle svůj požadavek skrze SSL/TLS, ale DVC certifikát mu je vrácen až později protokolem S/MIME.

 

DVCS server musí v DVC certifikátu vždy vracet datum a čas. DVC certifikáty musí mít sériové číslo. Sériová čísla vydaných certifikátů musí tvořit striktně monotónně vzrůstající posloupnost (nesmí vypadnout číslo z této posloupnosti), aby sám DVCS server nemohl popřít, že vydal nějaký DVC certifikát.

 

Klient musí přijatý DVC certifikát verifikovat, tj. musí ověřit, zdali:

·         je čas uvedený v DVC certifikátu pro klienta akceptovatelný;

·         certifikát DVCS serveru je platný;

·         certifikát DVCS serveru je opravdu certifikátem DVCS serveru a je certifikátem toho DVCS serveru, se kterým si přejeme komunikovat;

·         uvedená certifikační politika je přípustná pro klientovu aplikaci.

 

Certifikát DVCS serveru  musí splňovat následující podmínku:

·         Rozšíření certifikátu „Rozšířené použití klíče“ (viz kap. 8.1.10) musí být označeno jako kritické a musí obsahovat následující identifikátor objektu (v položce KeyPurposeId):
id-kp-dvcs     OBJECT IDENTIFIER ::=   {id-kp 10}
Toto rozšíření je konzistentní s rozšířením „Použití klíče“ nastaveným: digitalSignature, nonRepudation, keyCertSing a cRLSign. 

 

Odpověď DVCS serveru (zpráva CMS Signed Data) pak musí splňovat následující podmínku:

·         Elektronický podpis zprávy musí obsahovat podepisovaný atribut „Certifikát určený k ověření podpisu (ESSCertID)“ popsaný v kapitole 10.7.5.

 

Certifikáty podporující protokol DVCSP by měly obsahovat odkaz na DVCS server (obdobně jako certifikáty podporující protokol OCSP obsahují odkaz na OCSP servery). To se zajistí pomocí „privátního rozšíření“ (authorityInfoAccess  - viz kap. 8.1.11) certifikátu tak, že v tomto rozšíření  se jako accessMethod použije identifikátor objektu:

 

id-ad-dvcs      OBJECT IDENTIFIER   ::= { id-ad 4 }

(id-ad  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) 48 })

 

 a v položce accessLocation se uvede URI příslušného serveru (včetně transportního protokolu). Např.:

 

https://dvcs.ca.cz

 

8.12.2                  Žádost o DVC certifikát

Žádost o DVC certifikát je požadavkem klienta zasílaným DVCS serveru k ověření. Jinými slovy, jsou to ověřovaná data zasílaná DVCS serveru.

 

Žádost o DVC certifikát (DVCSRequest) je sekvence o následující struktuře:

 

DVCSRequest ::= SEQUENCE  {

    requestInformation         DVCSRequestInformation,

    data                       Data,

    transactionIdentifier      GeneralName OPTIONAL

}

 

Kde:

 

DVCSRequestInformation ::= SEQUENCE  {

        version                      INTEGER DEFAULT 1 ,

        service                      ServiceType,

        nonce                        INTEGER OPTIONAL,

        requestTime                  DVCSTime OPTIONAL,

        requester                    [0] GeneralNames OPTIONAL,

        requestPolicy                [1] PolicyInformation OPTIONAL,

        dvcs                         [2] GeneralNames OPTIONAL,

        dataLocations                [3] GeneralNames OPTIONAL,

        extensions                   [4] IMPLICIT Extensions OPTIONAL

}

  

Význam jednotlivých polí:

1         Pro  žádost o certifikaci držení dat.

2         Pro žádost o ověření elektronického podpisu dokumentu.

3         Pro žádost o ověření platnosti certifikátu.

4         Pro žádost o časové razítko.

      Data ::= CHOICE {

         message           OCTET STRING,

         messageImprint    DigestInfo,

         certs             SEQUENCE SIZE (1..MAX) OF

                               TargetEtcChain

      }

 

Položka data obsahuje:

1.        Pro žádost o ověření elektronicky podepsaného dokumentu obsahuje CMS zprávu SignedData, která se má ověřovat (tj. obsahuje položku message).

2.        Pro žádost o držení dat obsahuje vlastní data, která se mají ověřovat (tj. obsahuje položku message). DVCS server nesmí data nikterak kontrolovat nebo upravovat.

3.        Pro  žádost o časové razítko obsahuje následující sekvenci skládající se z identifikátoru algoritmu, který je použit pro výpočet kontrolního součtu a z vlastního kontrolního součtu:

     DigestInfo ::= SEQUENCE {

         digestAlgorithm   DigestAlgorithmIdentifier,

         digest            Digest }

4.        Pro žádost o ověření platnosti certifikátu obsahuje sekvenci TargetEtcChain, která slouží jak pro specifikaci ověřovaného certifikátu, tak i pro výsledek ověření, tj. v případě ověřování certifikátu je tato sekvence jak v žádosti, tak i v DVC certifikátu.

 

8.12.3                  Odpověď DVCS serveru

Odpověď DVCS serveru má strukturu:

 

DVCSResponse ::= CHOICE {

    dvCertInfo         DVCSCertInfo ,

    dvErrorNote        [0] DVCSErrorNotice }

 

Odpověď obsahuje buď DVC certifikát dvCertInfo (kladná odpověď) nebo chybovou hlášku dvErrorNote (záporná odpověď). Zápornou odpovědí je např. špatný čas, nepodporovaný požadavek, chybný formát dat apod. Tj. záporná odpověď je záporná ve smyslu protokolu DVCSP – nikoliv ve smyslu zamítnutí ověření. Jinými slovy: DVCS server vrací zápornou odpověď v případě, že se z nějakého důvodu nemohl dostat k samotnému ověřování.

 

Kladnou odpovědí se nemyslí, že požadovaný dokument byl ověřen. DVC certifikát může obsahovat ověření dokumentu nebo zamítnutí ověření. 

8.12.4                  DVC certifikát

DVC certifikát je sekvence o následující struktuře:

 

DVCSCertInfo::= SEQUENCE  {

    version             Integer DEFAULT 1 ,

    dvReqInfo           DVCSRequestInformation,

    messageImprint      DigestInfo,

    serialNumber        Integer,

    responseTime        DVCSTime,

    dvStatus            [0] PKIStatusInfo OPTIONAL,

    policy              [1] PolicyInformation OPTIONAL,

    reqSignature        [2] SignerInfos  OPTIONAL,

    certs               [3] SEQUENCE SIZE (1..MAX) OF

                            TargetEtcChain OPTIONAL,

    extensions          Extensions OPTIONAL }

 

Význam jednotlivých položek:

   DVCSTime ::= CHOICE  {

        genTime               GeneralizedTime,

        timeStampToken        ContentInfo }

Tj. obsahuje buď  obecný čas (GeneralizedTime) jak jej známe např. z doby platnosti certifikátu nebo obsahuje nějaký řetězec poskytovaný příslušným poskytovatelem času.

·         Položka dvStatus je typu PKIStatusInfo (viz kap. 8.8.2) a signalizuje, jak ověření dopadlo. V případě, že výsledek ověřování je úspěšný (SUCCESS), pak tato položka může chybět.

·         Položka policy obsahuje certifikační politiku za které je  vydán tento DVC certifikát.

·         Položka reqSignature je nepovinná a může obsahovat elektronický podpis z žádosti o DVC certifikát. Použití této položky závisí na certifikační politice DVCS serveru.

·         Položka certs je určena pro ověřování certifikátů, kdy obsahuje výsledky ověřování.

8.12.5                  Sekvence TargetEtcChain

Jedná se o na první pohled nepříjemnou sekvencí:

 

   TargetEtcChain ::= SEQUENCE {

        target                       CertEtcToken,

        chain                        SEQUENCE SIZE (1..MAX) OF

                                        CertEtcToken OPTIONAL,

        pathProcInput                [0] PathProcInput OPTIONAL }

Kde

 

   PathProcInput ::= SEQUENCE {

        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF

                                        PolicyInformation,

        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,

        explicitPolicyReqd           BOOLEAN DEFAULT FALSE }

 

 

   CertEtcToken ::= CHOICE {

 

        certificate                  [0] IMPLICIT Certificate ,

        esscertid                    [1] ESSCertId ,

        pkistatus                    [2] IMPLICIT PKIStatusInfo ,

        assertion                    [3] ContentInfo ,

        crl                          [4] IMPLICIT CertificateList,

        ocspcertstatus               [5] IMPLICIT CertStatus,

        oscpcertid                   [6] IMPLICIT CertId ,

        oscpresponse                 [7] IMPLICIT OCSPResponse,

        capabilities                 [8] SMIMECapabilities,

        extension                    Extension }

 

Sekvence TargetEtcChain se používá pro ověřování certifikátů. Používá se jednak v žádosti o DVC certifikát, ale i v samotném DVC certifikátu:

1.        V žádosti o ověření certifikátu (v žádosti o DVC certifikát)  musí mít každý ověřovaný certifikát právě jeden výskyt struktury TargetEtcChain. Ověřovaný certifikát se umístí do položky target. Položka chain může obsahovat řetězce certifikátů, které mohou být užitečné pro ověření certifikátu, je však na DVCS serveru, zdali tuto položku využije. Položka pathProcInput slouží pro zpracování mapování certifikačních politik (Policy mapping).

2.        V DVC certifikátu mohou být v položce chain následující volby:

·         pkistatus a ocspcertstatus pro signalizaci výsledku ověření konkrétního certifikátu. V případě, že ověření dopadlo kladně pro všechny certifikáty uvedené v žádosti, pak asi nemá smysl uvádět tyto informace v položkách pkistatus a ocspcertstatus.

·         assertion, ocspresponse a volba crl jsou určeny pro případ, že DVCS server získal informace nepřímo (např. z jiného serveru).  Položka assertion obsahuje např. DVC certifikát či časové razítko (získané např. z jiného serveru).

·         esscertid a oscpcertid mohou být použity v žádosti i v samotném DVC certifikátu v případě, že to umožňuje konkrétní aplikace.

·         capabilities – viz kap. 10.

 

Specifikace typů: Certificate, PolicyInformation a CertificateList je uvedena v kap. 8.1. Specifikace typu ESSCertId je uvedena v kap. 10. Specifikace typů CertId, OCSPResponse, a CertStatus je uvedena v kap. 8.5 a konečně specifikace typu PKIStatus je popsána v kap. 8.8.

8.12.6                  Chybová hláška DVCS serveru

 DVCS server buď vrací DVC certifikát nebo chybovou zprávu typu DVCSErrorNotice, která má následující strukturu:

 

DVCSErrorNotice ::= SEQUENCE {

   transactionStatus           PKIStatusInfo ,

   transactionIdentifier       GeneralName OPTIONAL }

 

Tj. skládá se z položek:

·         transactionStatus  jež je typu PKIStatusInfo  (viz kap. 8.8.2 – specifikace chyby PKIFailureInfo může mít nastaveny pouze bity: 2, 3, 5, 6 a 7);

·         a případně z položky transactionIdentifier, která se naplní obsahem stejnojmenné položky z žádosti o DVC certifikát. Tj.  položka transactionIdentifier slouží k spárování žádostí o DVC certifikát s odpovědí DVCS serveru v případě chyby.

 

 

8.12.7                  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.8                  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                  Žádost o časové razítko

Žádost o časové razítko je jednoduchá sekvence:

 

TimeStampReq ::= SEQUENCE  {

     version                      INTEGER  { v1(1) },

     messageImprint               MessageImprint,

     reqPolicy             TSAPolicyId              OPTIONAL,

     nonce                 INTEGER                  OPTIONAL,

     certReq               BOOLEAN                  DEFAULT FALSE,

     extensions            [0] IMPLICIT Extensions  OPTIONAL

}

 

Kde:

        MessageImprint ::= SEQUENCE  {

           hashAlgorithm                AlgorithmIdentifier,

           hashedMessage                OCTET STRING  }

·         Volitelná položka reqPolicy se plní identifikátorem objektu politiky TSA, pod kterou má být časové razítko vydáno. Tj. má-li být požadavek archivován, pak je zde uvedeno, jakým algoritmem má být proveden elektronický podpis razítka, jak dlouhý klíč k podpisu bude použit a vše ostatní, co příslušná politika obsahuje.

·         Volitelná položka nonce se plní náhodným číslem, které TSA kopíruje do odpovědi.

·         Příznak certReq použijeme k vyjádření přání, zda-li má TSA spolu s časovým razítkem zasílat svůj příslušný certifikát. TSA zasílá certifikát identifikovaný v podepisovaném atributu elektronického podpisu časového razítka ESSCertId v případě, že  je tato položka vyplněna a nastavena na hodnotu TRUE.

·         Konečně položka extensions  je obdobou rozšíření certifikátu.

 

8.13.2                  Časové razítko

Časové razítko je sekvencí:

 

TimeStampResp ::= SEQUENCE  {

         status                  PKIStatusInfo,

         timeStampToken          TimeStampToken     OPTIONAL

}

 

skládající se ze dvou položek: z výsledkového statusu a vlastního razítka. Výsledkový status je převzat z protokolu CMP (kap. 8.8). Vlastní časové razítko timeStampToken je elektronicky podepsaná zpráva (CMS SignedData). Časové razítko může mít pouze jeden elektronický podpis. Elektronický podpis časového razítka musí obsahovat podepisovaný atribut ESSCertId.

 

Jak je blíže popsáno v kap. 8.9, tak CMS zpráva je sekvencí identifikátoru objektu a vlastních dat vstupujících do procesu elektronického podpisu (podepisovaných dat). V případě časového razítka se podepisuje zpráva TSTInfo o identifikátoru objektu id-ct-TSTInfo.

 

Konkrétně celé časové razítko timeStampToken  je zpráva  SignedData s identifikátorem objektu:

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

 

Avšak vnitřkem této zprávy je zpráva typu TSTInfo o identifikátoru objektu (v terminologii CMS eContentType):

 

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

    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

 

Zpráva TSTInfo je tak vnitřkem časového razítka. Má strukturu:

 

TSTInfo ::= SEQUENCE  {

     version                      INTEGER  { v1(1) },

     policy                       TSAPolicyId,

     messageImprint               MessageImprint,

     serialNumber                 INTEGER,

     genTime                      GeneralizedTime,

     accuracy                     Accuracy                 OPTIONAL,

     ordering                     BOOLEAN             DEFAULT FALSE,

     nonce                        INTEGER                  OPTIONAL,

     tsa                          [0] GeneralName          OPTIONAL,

     extensions                   [1] IMPLICIT Extensions   OPTIONAL

}

 

Význam jednotlivých položek:

        MessageImprint ::= SEQUENCE  {

           hashAlgorithm                AlgorithmIdentifier,

           hashedMessage                OCTET STRING  }

          Accuracy ::= SEQUENCE {

                 seconds        INTEGER              OPTIONAL,

                 millis     [0] INTEGER  (1..999)    OPTIONAL,

                 micros     [1] INTEGER  (1..999)    OPTIONAL

          }

·         Položka ordering specifikuje, zda-li je čas uváděný na časových razítkách tak přesný, že pomocí času mohou být vydaná časová razítka seřazena tak, jak byla vydávána.

·         Volitelná položka nonce se vyplní obsahem stejnojmenné položky z žádosti o časové razítko (byla-li vyplněna).

·         Volitelná položka tsa může obsahovat jméno TSA autority. Rozhodující pro určení jména TSA autority je však podepisovaný atribut elektronického podpisu časového razítka ESSCertId.

·         Konečně položka extensions je obdobou rozšíření certifikátu.

 

8.13.3                  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:

 

 

 

 

 

 

 

 

 

 

 

 


*) Pro kvalifikované certifikáty (dle RFC-3039)

*) Pro kvalifikované certifikáty (RFC-3039)

*) Ono všechno má dvě strany mince. V praxi nejčastěji obdržíte šifrovanou zprávu bezpečnou elektronickou poštou (S/MIME). Pokud je zpráva šifrována, tak by bylo praktické si ji uložit v dešifrované (nezabezpečené) formě. A později ji přenést do archivu a případně zašifrovat klíčem archivu. Jenže na nátlak bezpečnostních odborníků byly většinou poštovní programy upraveny tak, aby jednoduše nešlo uložit dešifrovanou zprávu na disk vašeho PC. Takže většinou musíte zprávu předat do archivu elektronickou cestou šifrovánu klíčem archivu jiné možnosti jsou záměrně pracné. Pokud zprávu pouze ponecháte šifrovánu na PC, pak ztráta soukromého klíče znamená i ztrátu zprávy.

*) Opravdu jsem se díval do slovníku a je to české slovo

*) Je jasné, že kontrolní součet není jednoznačnou reprezentací dat, tj. teoreticky k danému kontrolnímu součtu máme nekonečně mnoho různých textů, který mají tento kontrolní součet.  Např. při délce kontrolního součtu 16 B máme  všeho všudy 216*8 kontrolních součtů.  Avšak  i dnes věříme, že používané  kontrolní součty jsou tak dokonalé, že  ke konkrétnímu dokumentu najít jiný dokument se stejným kontrolním součtem a navíc mající pro útočníka smysl je nemožné.