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}
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:
Priklad: Cislo 1135949:
113549 = 06 x 1282 + 7716 x 1281+
0D16 x 1280 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}:
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
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 (+ C016) 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 C016 (privatni trida) plus 2016
(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:
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
Hodnota retezce je: "Jones" (4A6F6E657316) V BER dostaneme: Type1:
|
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.
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.