Identifikace objektu

Na vrcholu klasifikacniho stromu jsou samy normalizacni urady, protoze jestlize se neco klasifikuje, pak nejprve musi byt stanoveno kdo klasifikaci provadi. Nejvyssimi polozkami jsou ccitt, iso a joint-iso-ccitt (spolecne ISO a CCITT). Pod polozkou ccitt jsou podrizene polozky, ktere urcuje CCITT, pod polozkou iso jsou polozky stanovovane ISO a pod polozkou joint-iso-ccitt jsou polozky, ktere stanovuje ISO ve spolecne s CCITT.

ISO je tzv. registracni autorita podstromu zacinajiciho polozkou iso, tj. registruje a je zodpovedna za objekty umistene ve stromove strukture pod polozkou iso.

Registracni autorita (napr. ISO) muze delegovat pravomoci pro registraci objektu na registracni autoritu nizssi urovne tak, ze ji urci polozku, pod kterou muze registrovat sve objekty. Mechanizmus je podobny mechanizmu pridelovani subdomen v DNS.

Poznamka: termin registracni autorita nema zadnou sovislost s terminem registracni autorita z kapitoly o certifikatech podle doporuceni  X.509.

Opet slovni vyjadreni nazvu jednotlivych polozek je pouze vhodne pro komunikaci lidi. Norma ISO 8824 zavadi ciselne oznaceni jednotlivych polozek.  Cisla se uvadi v kulatych zavorkach za nazvem polozky:

Polozka je pak urcena cisly vsech polozek, ktere vedou od korene az k polozce. Jednotlive cislice se v textovem zapisu oddeluji mezerou nebo teckou. Napr. polozku question(1) muzeme zapsat jako {0.1}.

Ve vetsine pripadu je strom znacne rozvetveny a cesta vede pres mnoho polozek. Je mozne do slozenych zavorek napsat podstrom cele struktury. Jako prvni polozka se ve slozenych zavorkach pak napise jmeno polozky tvorici koren podstromu nasledovane mezerou s cislem polozky nizsi urovne.

Cely mechanizmus je nazorne videt na slozitejsim pripade. Nejprve si vsak uvedme pripad rozsahlejisho stromu:

Polozka internet(1) lze zapsat jako {iso(1) org(3) dod(6) 1} nebo jako {1.3.6.1}- nazvy jsou nadbytecne. Dokonce i na predchozim obrazku je uvedeno identified-organization(3) a v zapisu org(3) a vyznam je stejny - podstatna je  trojka.

Nove objekty se definuji pomoci operatoru ::= . Napr. objekt internet se definuje:

internet OBJECT IDENTIFIER ::= {iso org(3) dod(6) 1}

nebo jednoduseji:

internet OBJECT IDENTIFIER ::= {1.3.6.1}.

Dalsi objekty lze definovat uz i za vyuziti podstromu. Napr.:

directory OBJECT IDENTIFIER ::= {internet 1}
mgmt OBJECT IDENTIFIER ::= {internet 2}
mib OBJECT IDENTIFIER ::= {mgmt 1}
atd.

Cviceni: Nakreselete si  strom pro polozky:
pkcs-7 OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 7}
signedData OBJECT IDENTIFIER ::= {pkcs-7 2}
envelopedData OBJECT IDENTIFIER ::= {pkcs-7 3}
 

Kodovani identifikace objektu v BER

Identifikace  objektu rsadsi vyjadrena ve slozenych zavorkach je tedy {1.2.840.1135949}. Pri konverzi do BER se jinym zpusobem konvertuji prvni dve cisla jinym ostatni:

• Konverze prvnich dvou cisel je jina, protoze prvni cislo nabyva hodnot 0,1 a 2. Druhe cislo pak hodnot 0 az 39. Provede se vypocet 1.cislo x 40₁₀ + 2.cislo.

Pro nas pripad je 1 x 40₁₀ + 2 =  42₁₀ = 2A_16.
• Nasledujici cisla se pak koduji jiz samostatne. Jelikoz ne kazde cislo se vejde do jednoho bajtu je nutne dlouha cisla umistovat do nekolika bajtu. Jenze jak zjistit z kolika bajtu se ktere cislo sklada? Pouzije se trik. Ke kodovani se pouzije pouze 7 bitu z kazdeho bajtu. Osmy bit (nejvyssi tj. levy bit) slouzi ke specifikaci konce cisla. Tj.  pokud je nejvyssi bit nastaven na 1, pak i nasledujici bajt patri k tomuto cislu. Posledni bajt cisla ma nejvyssi bit roven nule.

Problem spociva v tom, ze do kazdeho bajtu se tedy vejde nejvice 128 hodnot - vse tedy musi byt pocitano modulo 128.

Priklad: Cislo 1135949:
113549 = 06 x 128² + 77₁₆ x 128¹+ 0D₁₆ x 128⁰  coz by se dalo zapsat jako 06 77 0D jenze k prvnim a druhemu bajtu nesmime zapomenou pripocist sestnactkove 80, protoze to nejsou posledni bajty cisla. Takze vysledek 86 F7 0D.

Priklad: Vyjadrete v BER identifikator objektu {1 2 840 1135949}:

• Pole typu dat je 0 (univeralni objekt) + 0 (jednoduchy objekt, tj. dale jiz nestrukturovany) + 6 (OBJECT IDENTIFIER) = 06
• Pole delky je 06
• Datove pole je 2A 80 48 86 F7 0D (Viz predchozi priklady)

Cviceni: Vyjadrete v BER identifikator objektu {1.3.6.1.2.1.1.1}, tj. objekt sysDescr pouzivany protokolem SNMP. (je to jednoduche protoze neni treba nic pocitat modulo 128) Vysledek se opet proverte konvertorem. Dostanete:
 OBJECT            :1 3 6 1 2 1 1 1
    06 07 2b 06 01 02 01 01 01

Poznamka:  Identifikator objektu identifikuje objekt, tj. napr. identifikator sysDescr identifikuje objekt "popis pocitace". Jenze konkretni pocitac ma sve jmeno napr. "AlphaServer ...". V praxi je tedy treba svazat objekt s nejakym typem, ktery naplni objekt obsahem. I hovorove rekneme: "pocitac: AlphaServer".

V ASN.1 se pro svazani objektu s jeho obsahem zpravidla pouziva typ SEQUENCE. Napr.
        SEQUENCE {
                sysDescr        OBJECT IDENTIFIER,
                popis              OCTED STRING}

V kodovani BER si odvodte popis pro tuto sekvenci jako cviceni (vysledek jsem si overil v konvertoru):
 SEQUENCE
    30 16
  OBJECT            :1 3 6 1 2 1 1 1
     06 07 2b 06 01 02 01 01 01
  OCTET STRING      :AlphaServer
     04 0b 41 6c 70 68 61 53 65 72 76 65 72
 
 

 Odvozene typy

1. Zavest identifikator objektu vyska, objektu sirka a objektu hloubka. Nasi mnozinu pak sestavit ze tri sekvenci (SEQUENCE). Kazda by se skladala z prislusneho identifikatoru a hodnoty. Toto reseni je mozne, ale trochu slozite pro takto jednoduchy pripad.
2. Misto typu SET pouzit typ SEQUENCE. Jenze s typem SEQUENCE jsou podobne potize v pripade, ze nektere prvky SEQUENCE jsou volitelne. Napr. muze byt volitelna vyska a sirka (pouzije se jen je-li jina nez bezna) a uz nevime zdali je prvni hodnota vyska nebo sirka.
3. Muzeme odvodit od typu INTEGET nove tri typy, ktere budou (vramci kontextu, aplikace  nebo firmy)  specifikovat vysku sirku a hloubku - odvodime novy typ.

Na nasledujicich prikladech ukazeme jak se nove typy odvozuji.

Priklad A: Urcete typy pro sirku, vysku a hloubku tak, aby byly platne v ramci vasi firmy (tj. zavadime privatni typ). Jako tagy si zvolte cisla 1 (vyska), 2 (sirka) a 3 (hloubka).
Takze jedna se o privatni typy (+ C0₁₆) jednoduche dale nestrukturovane typy (+ 0) plus prislusny tag, takze dostaneme C1, C2 a C3.

Priklad B: V kodovani BER zapiste podle predchoziho prikladu predmet vyskoky 1, siroky 2 a hluboky 1.

Vysledkem bude 30 09 c1 01 01 c2 01 02 c3 01 01 (overeno konvertorem):
 
SEQUENCE
    30 09
  priv [ 1 ]
     c1 01 01
  priv [ 2 ]
     c2 01 02
  priv [ 3 ]
     c3 01 01

Zapis priv [1] znamena, ze se jedna o typ tridy PRIVATE s tagem 1.

U takto definovanych typu musi prijemce vedet, ze typ C1 je odvozen od typu INTEGER (nikde uvnitr nove zavedeneho typu neni puvodni typ INTEGER nikterak zakodovan). Takto definove typy se nazyvaji implicitne odvozene typy.

U expicitne odvozenych typu je navic uvedeno z jakeho typu je odvozen. Jedna se tedy o slozeny (konstruovany) typ obsahujici  jednu polozku, ale ta se sklada z pole typu, pole delky a pole dat.

Priklad A (obdoba pro explicitne odvozene typy): Jelikoz explicitne odvozeny typ je typem konstruovanym, tak nesmime zapomenou pricist sestnactkove 20.
Vyska bude mit typ C0₁₆ (privatni trida) plus 20₁₆ (konstruovany typ) plus 1 (vyska), tedy E1. Obdobne sirka E2 a hloubka E3.

Priklad B (obdoba pro explicitne odvozeny typ): Nyni musime kazdy rozmer popsat samostatne. Napr. vyska:

• Pole typ je E1 (viz priklad A).
• Pole data obsahuje hodnotu 1, tj. typ INTEGER, delka 1 a datove pole opet 1. Vysledek je 02 01 01.
• Pole delka je tedy 03.

Vysledek (overeno konvertorem):

 SEQUENCE
    30 0f
  priv [ 1 ]
     e1 03
   INTEGER           :01
      02 01 01
  priv [ 2 ]
     e2 03
   INTEGER           :02
      02 01 02
  priv [ 3 ]
     e3 03
   INTEGER           :01
      02 01 01

V ASN.1 je syntaxe odvozenych typu vyjadrena nasledujicim prirazenim:

ImplicitniOdvozenyTyp ::= [trida tag] IMPLICIT typ

resp.

ExplicitniOdvozenyTyp ::= [trida tag] EXPLICIT typ

Je treba si uvedomit, ze dvojice trida flag se koduje do jednoho bajtu (trida je v prvnich dvou bitech). V pripade, ze neni trida specifikovana, pak se mysli trida content-specific.

Primo v doporuceni X.209 je velice pekny priklad, na kterem je pekne ilustrovana syntaxe:
 

Mejme definovany nasledujici typy:   Type1 ::=  VisibleString   Type2 ::=  [APPLICATION 3] IMPLICIT Type1   Type3 ::=  [2] Type2   Type4 ::=  [APPLICATION 7] IMPLICIT Type3   Type5 ::=  [2] IMPLICIT Type2  Hodnota retezce je:             "Jones" (4A6F6E657316)  V BER dostaneme:   Type1:                  VisibleString    Delka    Datove pole                 1A16              0516     4A6F6E657316                    Type2:                 [Application 3]  Delka    Datove pole                 4316              0516     4A6F6E657316                     Type3:                 [2]              Delka    Datove pole                 A216              0716                    [Application 3]  Delka    Datove pole                   4316              0516     4A6F6E657316      Type4:                 [Application 7]  Delka    Datove pole                 6716               0716                    [Application 3]  Delka    Datove pole                    4316             0516       4A6F6E657316       Type5:                 [2]              Delka    Datove pole                 8216              0516     4A6F6E657316

 

CHOICE

Napr. v norme PKCS#7 se zavadi struktura

ExtendedCertificateOrCertificate :== CHOICE {
  certificate Certificate,
  extendedCertificate [0] IMPLICIT ExtendedCertificate
}

Tim se chce rici, ze struktura ExtendedCertificateOrCertificate je bud
    certificate Certificate
nebo
    extendedCertificate [0] IMPLICIT ExtendedCertificate

(bud certifikat podle X.509 verze 1 nebo podle X.509 verze 3). Jenze prijemci je nutne sdelit, jaky typ certifikatu je mu posilan, takze v pripade certifikatu verze 1 je poslan samotny certifikat a v pripade rozsireneho certifikatu (verze 3) je rozsireny certifikat predchazen nulou (trida content-specific, tag nula, tj. "80 delka  datove_pole", kde datove_pole je certifikat verze 3).
 
 

Z hlediska kodovani BER, ANY se CHOICE nikterak nekoduje, protoze se vzdy koduje pouze alternativa, ktera je vybrana.
 

ANY

Priklad opet z certifikatu X.509:

AlgorithmIdentifier ::= SEQUENCE {
                algorithm    OBJECT IDENTIFIER,
                parametrs    ANY DEFINED BY algorithm OPTIIONAL}

V prikladu se chce vyjadrit, ze identifikator parametrs muze nabyvat jakychkoliv typu. Ovsem ne zcela jakychkoliv, ale jen tech, ktere jsou definovany pri definici identifikatoru algorithm. Slovo OPTIONAL specifikuje, ze nektere algoritmy nemusi mit parametr zadny, tj. identifikator parametrs pak nabyva typu NULL.
 

Priklad