Standardul MIME (Multiporpose Internet Mail Extensions) defineste formatul continutului unui mesaj e-mail pe Internet, mesaj care poate avea orice format, nu numai cel de text. El consta din doua parti: corpul mesajului si header-e. Header-ele formeaza o colectie de perechi camp/valoare, structurate conform RFC 822, pe cand corpul mesajului este structurat conform MIME. d2t17tf
MOSS (MIME Object Security Services) se bazeaza, in cea mai mare parte, pe protocolul PEM, definit in RFC 1421. MOSS este un standard prin care se executa servicii de semnatura digitala si criptare pentru obiecte MIME. Serviciile sunt oferite prin folosirea criptografiei capat la capat (end-to-end), intre expeditor si destinatar, la nivel aplicatie. El este mult asemanator standardului PEM descris anterior.

3.1 Serviciul MOSS de semnatura digitala

Folosirea unui serviciu de semnatura digitala MOSS presupune sa se dispuna de urmatoarele componente:
- datele pentru semnat;
- cheia secreta a expeditorului;
Semnatura digitala este creata prin aplicarea unei functii hash asupra datelor ce se doresc a fi transmise si criptarea valorii obtinute cu cheia secreta a expeditorului. Serviciul de semnatura digitala MOSS se aplica asipracorpului obiectului MIME. Urmatoarea secventa de operatii reprzinta algoritmul de aplicare a unei semnaturi digitale. a) corpul obiectului MIME trebuie adus in forma canonica, b) se genereaza semnatura digitala si informatiile de control, c) se includ informatiile de control in tipurile corespunzatoare din continutul MIME; d) partea de informatii de control si partea de date din corpul obiectului MIME include in tipul-continut “multipart/signed”.
Fiecare din acesti pasi este descris in continuare: a) Canonicitatea -; corpul obiectului MIME -; trebuie convertit intr-o forma canonica, reprezentata unic si neambigua, atat pentru expeditor, cat si pentru destinatar. Transformarea intr-o forma canonica se face in doi pasi:
- conversia corpului MIME intr-o forma neambigua, reprezentativa pentru cele mai multe calculatoare gazda;
- convertirea delimitatoarelor de linii intr-o reprezentare unica si neambigua.
Reprezentarea aleasa pentru indeplinirea primului pas este de 7 biti. Cel mai semnifcativ bit din fiecare octet de date trebuie sa fie 0. In cadrul acestui pas, daca se vor codifica corespunzator pentru transferul continutului si se va adauga header-ul Content-Transfer-Encoding.
Secventa de caractere desemnate a reprezenta un delimitator de linii este “<CR> <LF>”. In al doilea pasal conversiei la forma canonica, se face inlocuirea delimitatorilor de linii locali cu secventa de caractere “<CR> <LF>”. Conversia acestor delimitatori este necesara doar pentru a nu apare erori in cazul calculului semnaturii digitale. Expeditorul trebuie sa faca mai intai conversia delimitatorilor si apoi saa calculeze semnatura digitala, insa trebuie sa transfere datele fara conversia delimitatorilor. Similar, destinatarul va aplica mai intai conversia delimitatorilor si apoi va calcula semnatura digitala. b) Informatiile de control pentru semnatura digitala -; informatiile de control genrate de serviciul de semnatura digitala vor cuprinde header-ele si semnatura propriu-zisa, care nu este altceva decat un numar. Fiecare header si valoarea sa corespunzatoare generata de serviciul de semnatura digitala trebuie sa incapa pe o singura linie.
Setul complet de header-e este urmatorul:
- Version: indica versiunea protocolului MOSS;
- Originator-ID: contine identificatorul proprietarului cheii secrete folosite la crearea semnaturii digitale si a cheii publice corespunzatoare, ce va fi folosita pentru verificarea semnaturii;
- MIC-Info: contine identificatorul algoritmului de hash, identificatorul algoritmului de semnare si valoarea semnaturii digitale (semnatura propriu-zisa).
Fiecare apel al serviciului de semnatura digitala poate crea un singur header-Version si cel putin o pereche de header-e Originator-ID - MIC-Info. Ultimele doua header-e vor fi generate intotdeauna perechi, pentru toti destinatarii, iar ordine este indicata mai sus.
Tipul-continut “application/moss-signature” cuprinde semnatura datelor din corpul MIME si alte informatii de control necesare la verificarea semnaturii. Corpul unui “application/moss-signature” este construit astfel:

Content-Type: “application/moss-signature”
<mosssig>::= <version> (1*<origasymflds>)
<version>::= “ Version: “ “ 5 “ CRLF
<origasymflds>::= <origid> <micinfo>
<origid>::= “ Originator-ID: “ <id> CRLF
<micinfo>::= “Mic-Info:” <micalgid>”,”<ikalgid>”,”<asymsignmic> CRLF

De exemplu, un mesaj MOSS semnat are structura:

--Signed Message
Content-Type: “application/moss-signature”

Version: 5
Originator-ID: Informatie de identificare cheie publica emitator
Mic-Info: RSA-MD5, RSA, Semnatura propriu-zisa
--Signed Message

3.2 Serviciul MOSS de criptare

Aplicarea serviciului de criptare va genera informatii de control care includ si pe cele de criptare a datelor. Sintaxa informatiilor de control este data in RFC 822. Setul complet de header-e generate de serviciul de criptare este urmatorul:
- DEK-info: indica algoritmul si modul de folosire a acestuia in criptarea datelor;
- Recipient-ID: permite identificarea cheii publice folosite la cifrarea cheii de sesiune cu care au fost criptate datele;
- Key-Info: contine doua valori -; identificatorul algoritmului de criptare a cheii cu care au fost cifrate datele si valoarea criptata, cu cheia publica a destinatarului, a cheii folosite la criptarea datelor.
Fiecare apel al serviciului de criptare creeaza un singur header Version, un singur header DEK-Info si cel putin o pereche de header-e Recipient-ID -; Key-Info.
Corpul unui tip application/moss-keys este construit ca mai jos:

Content-Type: “application/moss-keys”
<mosskeys>::= <version> <dekinfo> 1*<recipasymflds>
<version>::= “ Version: “ “ 5 “ CRLF
<dekinfo>::= “DEK-Info””:”<dekalgid>a“,”<dekparameters>i CRLF
<recipasymflds>::= <recipid> <asymkeyinfo>
<recipid>::= “Recipient-ID:” <id> CRLF
<asymkeyinfo>::= “Key-Info””:”<ikalgid>””,”<asymencdek> CRLF

De exemplu, un obiect MIME, criptat dupa standardul MOSS, arata astfel:

-- Encrypted Message
Content-Type: “application/moss-keys”
Version: 5
Dek-Info: DES-CBC, Informatii de DEK
Recipient-ID: Informatii de identificare cheie publica destinatar
Key-Info: RSA, Cheia de sesiune criptata

-- Encrypted Message
Content-Type: “application/octet-stream”

Date cifrate
-- Encrypted Message

3.3 Identificarea expeditorului, destinatarului si a cheilor acestora

In specificatiile PEM, cheile publice trebuie incluse in certificate. Un certificat este un obiect care leaga fiecare cheie publica de un nume. Acesta reprezinta numele prin care este identificat proprietarul acelei chei. In standardul MOSS, un utilizator nu trebuie sa aiba un certificat. Orice serviciu MOSS impune ca utilizatorul sa cel putin o pereche de chei cheie-publica/cheie-secreta. MOSS cere serviciilor de semnatura digitala si de criptare sa emita header-ul potrivit Originator-ID, respectiv header-ul Recipient-ID. O valoare posibila pentru aceste header-e ar fi cheile publice ale ambilor participanti in comunicatie.
In cadrul header-elor Originator-ID si Recipient-ID, MOSS defineste alti doi identificatori: forma numelui si selectorul cheii. Forma numelui este aleasa si declarata de proprietarul perechii de chei. In documentul MOSS sunt specificate trei forme ale numelui: un sir arbitrar, adresa de e-mail si un nume distinct X500 (pentru a pastra compatibilitatea cu PEM). In cazul in care un utilizator are mai multe chei publice si doreste sa foloseasca acelasi nume pentru toate, atunci mai este necesar inca un parametru, pentru a putea identifica cheia. De aceea, trebuie asignat un selector unic fiecarei chei.