MOSS

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

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.

Příklad:
Originator-ID: EN,1,dostalek@pvt.net

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

Příklad:
Originator-ID: STR,1,abcdefga123456

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

Příklad:
Recipient-ID: DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMPSmFtZXMgT
S4gR2Fsdmlu

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

Recipient-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG 4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cB
hY9DGwq0CDnrpKZV3cQIDAQAB,EN,1,uzivatel@firma.cz
5. 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.

Příklad:
Recipient-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

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

Příklad

Práce s klíči

• Vystavení certifikátu (odesílá sám sebou podepsaný certifikát jako žádost).
• CRL
• Veřejný klíč (či certifikát). Aby byl schopen odeslat adresátovi první dopis, musí nějak získat jeho veřejný klíč.

Content-Type: application/mosskey-request

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

Version: 5

Uvede buď hlavičku:

• Certification: samopodepsaný_certifikát (jako žádost o certifikát)
• Issuer: identifikace_CA (jako žádost o CRL)
• Subject: Identifikace_jako_v_Recipient-ID (žádost o veřejný klíč nebo certifikát)

Content-Type: application/mosskey-data

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

• Key: PK,veřejný_klíč,identifika_vlastníka (vrací požadovaný veřejný klíč)
• Certificate: řetězec_certifikátů_od_certifikátu_uživatele_až_po_ROOT (vrací požadovaný certifikát)
• CRL: CRL (vrací požadované CRL).