Copyright © 1997 RNDr. Libor Dostálek

MOSS

MOSS je jednou z aplikací normy RFC1847 v praxi. Fylozoficky vychází z PEM. Často slyšíme názor: "MOSS vzalo hlavičky PEM a vtěsnalo je do hlaviček MIME". Je to s určitou nadsázkou pravda. MOSS však rozšiřuje PEM o možnosti nepoužívající certifikáty (MOSS se správou certifikátů vůbec nezabývá).

MOSS umožňuje posílat i jiné zprávy než v US-ASCII kódu (např. video, audio, český text atp.) atd. To je věc právě rozdílné filozofie mezi PEM a MOSS. Není zcela pravda, že by pomocí PEM nešly posílat jiné zprávy než v US-ASCII. Avšak celá problematika by musela být doplněna do PEM (dopracována). PEM si s tím neláme hlavu a předpokládá, že je zpráva v US-ACSII (jak specifikuje RFC822). MOSS se kódováním znakovými sadami nezabývá také, ale jelikož používá rozšíření MIME, tak jednotlivé části zprávy mohou obsahovat i ostatní MIME hlavičky, třeba právě hlavičku Content-Type s parametrem chatset specifikujícím znakovou sadu atp.

MOSS je specifikováno normou RFC1848.

MOSS používá na místě řetězce typ/subtyp (viz RFC1847) buď řetězec application/moss-signature nebo řetězec application/moss-encrypted. Dále specifikuje tu část zprávy, která nese informace o elektronickém podpisu, resp. o šifrovacích klíčích.

Zpráva elektronicky podepsaná používá jako typ/subtyp řetězec application/moss-signature. Do parametru micalg se dosadí první parametr z hlavičky MIC-Info. Formát elektronický podepsané zprávy je znázorněn na následujícícm obrázku:

Informace o elektronickém podpisu mají tvar hlaviček, které jsou podobné hlavičkám PEM. Hlavička Version nese informace o použité verzi protokolu MOSS (tč. 5). Hlavička Originator-ID obsahuje informace identifikující odesilatele (resp. jeho šifrovací klíč). A hlavička MIC-Info pak obsahuje algoritmus použitý k výpočtu kontrolního součtu, algoritmus použitý k zašifrování kontrolního součtu a samotný elektronický podpis.

Jelikož hlavička Originato-ID má stejný tvar jako hlavička Recipient-ID, tak se jejím podpisem budeme zabývat až u šifrované zprávy.

Tvar šifrované zprávy (application/moss-encrypted) je obdobný:

Hlavička version opět vyjadřuje verzi protokolu MOSS. Hlavička DEK-Info specifikuje použitý šifrovací algoritmus (a jeho případné parametry) použitý k šifrování textu zprávy (DEK-klíč podle terminologie PEM). Hlavička Recipient-ID specifikuje příjemce (adresáta), resp. jeho veřejný klíč. Hlavička Key-Info v sobě nese specifikaci šifrovacího algoritmu použitého k zašifrování DEK-klíče a samotný zašifrovaný DEK-klíč.

Originator-ID a Recipient-ID

Hlavička Originator-ID specifikuje soukromý klíč (z dvojice veřejný/soukromý klíč), který odesilatel použil ke tvorbě elektronického podpisu. Hlavička Recipient-ID specifikuje veřejný klíč (z dvojice soukromý/veřejný klíč), který byl použit pro zašifrování DEK-klíče.

Obě hlavičky mají stejnou syntaxi. Např. hlavička Originator-ID:

Originator-ID: typ_identifikace,rozlišující_číslo,identifikační_řetězec

Dvojice (veřejný/soukromý klíč) může být specifikována v MOSS jedním z následujících typů identifikace (první parametr):

  1. E-mailovou adresou vlastníka dvojice klíčů (typ EN). Jelikož uživatel může mít vygenerováno více dvojic klíčů, tak rozlišujícím číslem specifikujeme konkrétní dvojici. V případě, že není třeba rozlišovat (uživatel má pouze jednu dvojici), pak se nejčastěji používa hodnota 1. Identifikační řetězec obsahuje mailovou adresu.
  2. Příklad:
    Originator-ID: EN,1,dostalek@pvt.net

  3. Nějakým libovolným řetězcem (typ STR). Jelikož uživatel může mít vygenerováno více dvojic klíčů, tak rozlišujícím číslem specifikujeme konkrétní dvojici. V případě, že není třeba rozlišovat (uživatel má pouze jednu dvojici), pak se nejčastěji používa hodnota 1.
  4. Příklad:
    Originator-ID: STR,1,abcdefga123456

  5. Distinguished Name (typ DN). Jedná se o identifikaci uživatele podle adresáře popsaného mormou X.500. S touto identifikací jsme se již setkali v poli Subject (specifikace jména) u certifikátu. To je ten tvar, který se textově zapisuje s lomítky (/CN=CZ /SP=Morava /O=PVT /CN=Beda Novak). Obsah je také (jako v případě certifikátu) kódován DER a pak do tisknutelné formy kódován ještě Base64.
  6. Příklad:
    Recipient-ID: DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMPSmFtZXMgT
    S4gR2Fsdmlu

  7. Samotným veřejným klíčem z certifikátu (typ PK). Jedná se vlastně o položku syntaxe Subject Public Key Info z certifikátu.Tj. veřejný klíč je opět kódován DER a posléze Base64. Syntaxe hlavičky se ale liší od předchozích tří případů (tj. EN, STR a DN). Jako rozlišující číslo se použije zakódovaný veřejný klíč. Identifikační řetězec pak identifikuje vlastníka jednou ze tří předchozívh metod. Příklad (identifikace mailovou adresou):

  8. Recipient-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG 4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cB
    hY9DGwq0CDnrpKZV3cQIDAQAB,EN,1,uzivatel@firma.cz

  9. Názvem certifikační autority a sériovým číslem certifikátu (typ IS). Jedná se metodu používanou v PEM. Jako rozlišující číslo se používá DER + Base64 kódovaný název certifikační autority (pole Issuer: v certifikátu). Identifikačním řetězcem je pak sériové číslo certifikátu.
  10. Příklad:
    Recipient-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

    V PEM by se použila hlavička:
    Recipient-ID-Asymmetric:MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

(Poznamenejme jen, že v předchozím textu všude, kde je pro ilustraci pooužita hlavička Originator-ID může být použito hlavičky Recipient-ID a naopak)

Příklad

RFC1848 uvádí řadu příkladu elektronicky podepsaných či šifrovaných zpráv. Uveďme alespoň následující jednoduchý příklad:
 
To: adresat@firma.cz  
Subject:  
MIME-Version: 1.0  
Content-Type: multipart/signed; protocol="application/moss-signature"; micalg="rsa-md5"; boundary=Hranice 

--Hranice  
Content-Type: text/plain; charset="us-ascii"  
Content-ID: . . .  

Elektronicky podepsany text 
--Hranice  
Content-Type: application/moss-signature  
Content-ID: . . . 
Content-Transfer-Encoding: quoted-printable 

Version: 
Originator-ID: EN,2,odesilatel@firma.cz  
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf= MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb= 
sOVJjleV7vTe9yoNp2P8mi/hs7 
--Hranice--

Práce s klíči

Kromě odesílání a příjmání zpráv může odesilatel požadovat: Odesilatel v MIME hlavičce specifikuje, že se jedná o takovýto požadavek pomocí:

Content-Type: application/mosskey-request

V textu zprávy pak kromě hlavičky:

Version: 5

Uvede buď hlavičku:

Jedinou možnou odpovědí na takovouto zprávu je zpráva typu:

Content-Type: application/mosskey-data

která v textu zprávy má jednu z následujících hlaviček:


S/MIME