Formati i mesazheve të sigurta elektronike S/MIME

S/MIME është plotësim i MIME (Multipurpose Internet Mail Extensions) në aspektin e sigurisë, mbështetet kryesisht në në teknologjinë që përdoret edhe nga RSA Data Security. S/MIME njësoj si PGP bëjnë pjesë në IETF standardet. Përderisa PGP-ja kryesisht përdoret për sigurinë e e-mail-ave personal të shumë shfrytëzuesve, S/MIME paraqitet si standard industrial për përdorim komercial. S/MIME definohet permes disa dokumenteve, më të rëndsishmet janë RFC-të : 3370, 3850, 3852. Para se te sqarohet S/MIME duhet kuptuar formati i e-mail-ve mbi te cilet mbështetet ajo – MIME. Formati tradicional i electronic mail mesazhve pershkruhet përmes standarteve RFC 822 dhe versionit RFC 5322 ( Internet Message Format).

MIME – Multipurpose Internet Message Extensions

MIME është vazhdim i RFC 5322 dhe si ka si për qëllim adresimin e disa problemeve dhe kufizimeve që shfaqen si pasojë e SMTP e definuar në RFC 821 dhe specifikacioneve që vinjë nga RFC 5322. Kufizimet që sjellin skemat SMTP/RFC 5322 janë:

1. Pamundësia që përmes SMTP të barten fajllat ekzekutiv (.exe ) apo objekte tjera të dhëna vetëm në formë binare. Ekzistojnë disa disa skema të konvertimit te fajllave binarë në tekstual, të cilët pastaj mund të barten përmes SMTP sistemit tonë. Ndër skemat më të njohura është UNIX Uencode/Udecode, megjithatë asnjëra nga modelet e përdorura nuk është e standardizuar.
2. SMTP mbështetet në karaktere ASCII (7 bit) , pra nuk mundëson dërgimin/pranimin e të dhënave tekstuale që kodohen me 8 bita.
3. SMTP serverët mund të mos pranojnë mesazhe që kalojnë një madhësi të caktuar.
4. SMTP portat hyrëse/dalëse që perkthejnë karakteret ASCII në EBCDIC karaktere nuk përdorin mapim të qëndrueshëm prandaj shfaqen probleme në përkthim.
5. Disa implementime të SMTP nuk janë plotesisht të definuara në në SMTP standardet – RFC 821.

Probleme te zakonshme që shfaqen në këtë rast një:

• Fshirja, shtimi apo rirenditja e carriage return dhe line feed.
• Kalimi në rresht të ri, për të respektuar gjtësinë maksimale të rreshitit që është 76 karaktere.
• Heqja e hapëirave të zbrazëta në fund ( tab dhe space karaktereve)
• Paddingu i rreshtave ashtu që rreshtat të kenë numër të njejtë të karaktereve.
• Shndërrimi i tab karaktereve ne disa space karaktere.

MIME mundëson zgjidhjen e këtyre problemeve ashtu që zgjidhjet e ofruara të jenë kompatibile me implmentimet e RFC 5322. MIME specifikacionet përmbajnë këto elemente:

1. Janë definuar 5 header të ri të cilët mund të përfshihen në RFC 5322. Këto fusha përmbajnë informatat e nevojshme për brendinë e mesazhit.
2. Janë definuar një numër i caktuar i formateve të përmabjtjeve (contents) duke standardizuar formën se si do të paraqitne të dhënat.
3. Transfer encoding bën të mundur shnëderrimin e përmabjtjes së mesazhit në një formë e cila nuk do të ndryshohet nga mail sistemi.

5 fushat e header-it të definuara në MIME janë:

• MIME Version
• Content Type
• Content Transfer Encoding
• Content ID
• Content Description

Këto fusha mund të gjenden në një header të mesazhit të shkruar sipas RFC 5322. Një implementim i mirëfillt i këtij standardi duhet të përkrahë fushat MIME Version, Content Type si dhe Content Transfer Encoding; fushat Content ID dhe Content Description janë opcionale.

Content type

Për shkak të shumë llojshmërisë së përmbajtjeve ka lind nevoja për një klasifikim të këtyre formave. Përmes RFC 2046 janë përcaktuar 7 tipe kryesore të përmajtjes të ndara në gjithsej 15 nëntipe, ku Content Type përshkruan tipin e të dhënave kurse Content Subtype formatin e atyre të dhënave.

Text – ky është tipi më i thjeshtë i të dhënave. Dallohen dy nëntipe: plain dhe enriched. Përderisa text/plain paraqet tekst të paformatizuar, karakteret janë konform standardit ASCII apo ISO 8857, text/enriched mundëson fleksibilitet më të madh duke ofruar mundësi për formatizim të tekstit.

Multipart – tregon se trupi i mesazhit përbëhet nga pjesë të pavarura mes veti. Kur vlera e Content Type është multipart ajo fushë përmbanë edhe një parametër tjetër të quajtur boundary që tregon kurfirin mes pjesëve të pavarura. Ky kufi nuk paraqitet në asnjërën nga pjesët e mesazhit. Secili boudery fillon me me një rresht të ri, dy vija lidhëse pastaj shkruhet vlera e boudery-t (emri i tij i definuar ne header). Boudery i fundit që tregon përfundimin e pjesës së fundit dallon nga boudery-t e zakonshëm sepse perfundon me dy vija lidhëse. Brenda secilës pjesë se pavarur mund të përfshihet një MIME header i zakonshem, por kjo nuk është e domosdoshme.

Multipart/Mixed – përdoret për lidhjen e më shumë pjesëve të pavarura mes veti të cilat duhet të shfaqen në një renditje të caktuar.

Multipart/Parallel – renditja e pjesëeve të lidhura nuk është me rëndësi, ato mund të shfaqën paralisht. P.sh. një fotografi apo një tekst mund të shoqërohet nga një audio e cila dëgjohet në kohën kur për shfrytëzuesin shfaqet fotografia apo teksti.

Multipart/Alternative – pjesët e lidhura janë reprezentim i të njëjtit informacion. Renditja e tyre bëhet në bazë të performansave, ku më lartë vendoste pjesa që ofron performansa më të larta. P.sh në qoftë se është e mundur shfaqja e tekstit në formatin text/enriched bëhet kjo gjë, në të kundërtën teksti shfaqet në formatin text/plain.

Multipart/digest – përdoret kur pjesët e veçanta në trupin e mesazheve interpretohen si mesazhe konform RFC 5322 standardit. Kjo munëson ndërtimin e mesazheve që në vete përmbajnë mesazhe tjera.

Message – pjesa që gjendet në trupin e mesazhit(body) është vet një mesazh i plotë sipas RFC 822 që ka header-in e vet me Content-type tjetër.

Message/rfc822 – është nëntipi kryesor që tregon se trupi i mesazhit është një tjetër mesazh i enkapsulur që ka header-in dhe turpin e vet. Mesazhi i enkapsuluar në këtë rast mund të jetë qfardo MIME mesazhi.

Message/partial – përdoret kur mesazhi origjinal duhet të fragmentohet për arsye të madhësisë, kurse kjo është vetëm njëra nga pjesët e mesazhit. Të gjitha fragmentet e mesazhit origjinal duhet të rigrupuhen në destinacion nga MIME, për këtë arsye nevojiten tre parametra shtesë që janë: ID – është e njejtë për të gjitha pjesët e fragmentuara, sequence number – unike për secilën pjesë dhe total – numri i përgjithshëm i fragmenteve.

Message/external-body – përdoret sidomos në rastet kur trupi i mesazhit bëhet shumë i madh, atëherë në trup (body) vendoset vetëm pointeri që na dërgon te objekti i cili ekziston diku tjetër. Trupi i mesazht në këtë rast përmabanë vetëm informatat e nevojshme për qasje në të dhëna. Ky nëntip ka një header të jashtëm dhe mesazhin e enkapsuluar që përmbanë header-in e vet (brendshëm). Fusha e jashtme e header-ti Content-Type duhet të përmbajë një parametër të qasjes që tergon metodën e qasjes, p.sh FTP(File Transfer Protocol).

Image – mesazhi origjinal përmbanë një imazh statik,nuk ka animacione. Dy nëntipe që përdoren janë: JPEG (Joint Photographic Experts Group) dhe GIF (Graphics Interchange Format) .

Video – mesazhi paraqet animacion. Nëntipi i vetëm i ofruar është MPEG (Motion Picture Experts Group). Në qoftë se imazhi i animuar përmbanë edhe zë, ai dërgohet ndaras duke shfrytëzuar tipin Audio.

Audio – si nëntip të vetëm ka ‘basic’. Përdoret kur mesazhi i dërguar përmbanë zë.

Application – përfshinë të dhënat e tipeve tjera që nuk u takojn tipeve të përmendura më lartë. Janë dy nëntipe që definohen për këtë tip: octet stream dhe PostScript. Octet stream janë të dhëna që paraqiten në formen binare, 8 bita për një byte. Kurse PostScript përdoret kur të dhënat janë në formtin Adobe PostScript që do të shfrytëzohen nga printer që përkrahin PostScript formatin. Në rastin kur fusha e header-it Content Type nuk është definuar në mënyrë eksplicite për asrye të ndonjë gabimi apo për shkak të versionit të MIME së palës dërguese (user agent), merret vlera e nënkuptuar : "Content-type: text/plain; charset=us-ascii".

MIME Transfer Encodings

Fusha e header-it Content Transfer Encoding mund të pranoj gjashtë vlera të ndryshme, ndonëse vetëm dy prej tyre paraqesin metoda për enkodimin e të dhënave. Specifikacionet mbi enkodimin e mesazhit për të siguruar dërgim të besushëm të të dhënave nëpër mjedise të ndryshme gjenden në RFC 2045. Shumica e të dhënave multimediale që barten përmes email-it janë të formatit binary, përkatësisht mund të parqaiten si karaktere 8 bitshe. Mirpo të dhëna në këtë formë nuk mund të transmetohen përmes disa protokoleve të caktuara. P.sh përmes SMTP mund të transmetohen vetëm ASCII karaktere si dhe gjatësia e rreshtave nuk duhet të jetë më e madhe se 1000 karaktere. Prandaj është paraqitur nevoja për të për enkodimin e të dhënave ashtu që ato të plotësojnë krtiteret e caktuara. Vlerat që mund të marr fusha Content Transfer Encoding janë:

7 bit – të dhënat janë ASCII karaktere, vlera decmale e secilit karakter nuk e kalon 127, rreshtat duhet te kenë maksimumi 1000 karaktere përfshirë këtu edhe Carrige Return (13-vlera decimale) dhe Line Feed (10-vlera decimale).

8 bit – rreshtat po ashtu janë të shkurtër(deri në 1000 karaktere) mirpo mund të paraqiten edhe karaktere që nuk janë ASCII. Me që shtresat e SMTP-së janë në gjendje të bartin të dhënat në këtë format MIME nuk kryen fare enkodim në këtë rast.

Binary – të dhënat e kësaj forme jo vetëm që përmbajnë karaktere jo ASCII por rreshta nuk janë domosdoshmërisht të shkurtër si në rastet e mësipërme. Me që SMTP-ja është ne gjendje të dërgoj/pranoj të dhëna binare, MIME nuk kryen kurfar enkodimi as në këtë rast, megjithatë kjo formë e shkëmbimit të të dhënave nuk është e rekomandueshme. Përderisa format e përmendura më lart nuk paraqesin enkodim, ato vetëm i tregojnë për natyrën e të dhënave. Përmes Base64 dhe Quoted Printable bëhet transformi i të dhenave në hyrje nga një domen i qfardoshëm në karaktere 7 bitshe, duke i bërë kështu të ‘sigurta’ për transport sidomos ndaj protokoleve me kufizime të larta.

Base64 – përdoret për të enkoduar sekuenca arbitrare të okteteve binare ashtu që të plotësojnë rregullën e 7 bitave. Është mjaft e dobishme për të enkoduar të dhëna binare dhe karaktere 8-bitëshe , nganjëherë përdoret për të enkoduar edhe të dhëna tekstuale që shpesh përdorin karaktere jo ASCII.

Quoted-Printable – njësoj si Base64 shërben për enkodimin e sekuencave binare, e dobishme sidomos kur të dhënat paraqesin numër të madh të okteteve që korespondojnë ne ASCII karaktere të printueshme. Është e dizajnuar që të jetë e lexueshme për njerëzit për shkak se kryesisht përëhet nga ASCII karakteret, ndonëse del edhe jasht tyre ndonjëherë.

S/MIME Funksionaliteti

S / MIME mund të përdoret me qfardo sistemi që bartë MIME data , por po ashtu mund të përdoret nga MUAs (Mail User Agents) tradicional për të ofruar shërbimin e kriptogarfisë dhe sigurisë. S/MIME njësoj si PGP ofron mundësinë për të nënshkrur dhe/ose enkriptuar të dhënat. S / MIME ofron shërbimet e mëposhtme të sigurisë dhe kriptografisë:

1. Autentifikimin
2. Integritetin e mesazhit
3. Jo-mohueshmërinë (Non-repudiation)
4. Priavtësinë dhe sigurinë e të dhënave

Tri shërbimet e para arrihen përmes nënshkrimit digjital kurse e fundit përmes enkriptimit. S/MIME bazohet në Cryptographic Message Syntax (CMS). S/MIME agjenti paraqet softëare-in e perdoruesit që mund të jetë në rolin e dërguesit të të dhënave, pranuesit apo të dyja. Para se të përdoret celqsi publik përmes të cilit arrihet komunikimi i sigurt palët duhet të vërtetojnë valditetin e tij, kjo arrihet duke përdorur PKIX (X.509 Public-Key Infrastructure) certifikatat.

S/MIME punon me këto tipe të të dhënave (Content Type): Enveloped Data, Sign Data, Clear-Sign Data dhe Signed and Enveloped Data.

Enveloped Data – përdoret për tu ofruar privatësi mesazheve tona. Ky tip përbëhet nga të dhëna të enkriptuara apo celësa të enkriptuar që do të përdoren për enkriptim nga një apo më shumë shfrytëzues. Kombinimi i përmbajtjes së enkripuar dhe celësave për enkriptim qëjanë po ashtu të enkriptuar njihet si digital envelope (zarfi digjial).

Signed Data – paraqet të dhënat e nënshkruara nga dërguesi. Qfardo tipi i të dhënave mund të nenshkruhet nga një apo më shumë nënshkrues paralelisht.

Clear-Signed Data – procesi i formimit të nënshkrimit digjital është i njejtë si në rastin për Signed Data, i vetmi dallim është se në procesin e enkodimit në Base64 hyn vetëm nënshkrimi digjital jo edhe mesazhi.

Signed and Enveloped Data – nënshkrimi dhe enkriptimi i të dhënave mund te bëhet ndaras pastaj hasen kombiminme të tyre. Kështu të dhënat e enkriptuara mund të nënshkruhen, po ashtu të dhënat e nënshkruara ( signed data apo clear-signed data) mund të enkriptohen.

Algoritmet kriptografike

S/MIME përfshinë 3 algoritme për celësin publik. Algoritmi i preferuar për nënshkrim digjital është DSS( Digital Signature Security ). Për enkriptimin e celësave të sesionit (session keys) përdoret një version i Diffie-Helman i njohur si El Gamel dhe mundëson enkriptim dhe dekripim. Alternativë për të dyja këto algoritme është RSA-ja që mund të përdoret si për nënshkrim digjital ashtu edhe për enkriptim të celësit të sesionit. Si algoritëm për llogaritjen e hash-it të mesazhit që nevojitet te nënshkrimi digjital përdoret SHA1 (dalja 160 bit) mirpo rekomandohet që pala marrëse të përkrahë edhe algoritmin tjetër MD5 (dalja 128 bit) për të arritur kompatibilitet me versionet e mëhershme të S/MIME-s. Për enkriptim të mesazhit përdoret tripleDES-i, mirpo rekomandohet që pala marrëse të përkrahë RC2. Ndonëse RC2 është algoritëm i dobët ai është në pajtim rregullat ligjet mbi eksportin e algoritmeve kriptogarfike në SHBA.

Algoritmet kriptografike të përdorura në S/MIME:

FUNKSIONI	KËRKESAT
Llogaritja e hash-it të mesazhit	Duhet të pëkrahin SHA1, rekomandohet përdorimi i SHA1; pala marrëse rekomandohet të përkrahë MD5 për kompatibilitet me S/MIME v2
Fromimi i nënshkrimit digjital	Duhet të përkrahet DSS; pala pranuese rekomandohet të mbështes verifikimin e RSA nënshkrimit me celës 512 – 1024 bit
Enkriptimi i session key-ve	Të dy palët duhet të përkrahin Diffie-Hellman; pala dërguese/ marrëse rekomandohen të përkrahin RSA encryption/decryption
Enkriptimi i mesazhit me celvsin e sesionit	Të dy palët duhet të përkrahin 3DES; pala pranuse rekomandoket të përkrahë dekriptimin përmes RC2
Krijimi i kodit për autentifikim të mesazhit	Pala marrëse(dërguese) duhet (rekomandohet) të përkrah HMAC me SHA1

S/MIME specifikacionet sqarojnë proceduren rreth vendosjes se cili algoritëm kriptogarfik do të përdoret. Në esencë agjenti që dërgon mesazhin duhet ti marrë dy vendime:

1. duhet të përcaktoj nëse pala marrëse do të jetë në gjendje të dekriptoj mesazhin e marrë duke përdorur algoritmin e caktuar për enkriptim
2. nëse pala marëse do të jetë në gjendje të dekriptoj të dhënat e enkriptuara vetëm me një algoritëm më të dobët (më lehtë të thyeshëm), pala dërguese duhet të vendosë nëse është e pranueshme që të dhëna të dërgohen në atë formë

Për të mundësuar këtë vendim pala dërguese duhet të ketë informatat e nevojshme për aftesitë dekriptuese të palës marrëse të renditura sipas preferences. Zgjedhja e algoritmit për enkriptim:

• në rastin kur pala dërguese ka njohuri për aftësitë dekriptuese të palës marrëse zgjedhet algoritmi me prioritetin më të lartë
• në rastin kur dërguesi nuk ka një listë me aftësitë dekriptuese të palës tjetër po r ka komunikuar me të në të kaluarën, atëherë zgjedhet algoritmi i përdorur në komunikimin e fundit mes palëve
• nëse dërguesi nuk ka njohuri mbi aftësitë dekrtiptuese të pranuesit dhe dëshiron të rrezikoj ashtu që pranuesi mund të mos jetë në gjendje të dekriptoj mesazhin, atëherë si algoritëm për enkriptim përdoret tripleDES-s
• nëse dërguesi nuk ka njohuri mbi aftësitë dekriptuese të marrësit dhe nuk dëshiron të rrezikoj që marrësi të mos jetë në gjendje të dekriptoj mesazhin, duhet përdorur RC2 si algoritëm për enkriptim

Nëse një mesazh duhet dërguar më shumë personave atëherë një algoritëm i zakonshëm nuk mund të përdoret për të gjithë marrësit, pala dërguese duhet ti dërgoj dy mesazhe duke përdorur të dyja algoritmet kriptografike. Sidoqoftë në këtë rast duhet pas parasysh se siguria e mesazhit është lënduar me që njëra kopje e mesazhit është dërguar me siguri më të vogël.

S/MIME MESSAGES

Enveloped Data

Mbështjellja e të dhënave

Përdoret për të ofruar privatësinë të mesazhet që shkëmbejmë. Hapat për përgatitjen e një envelopedData MIME entitet janë:

1. Gjenerimi i një sesion-çelësi pseudorandom me një algoritëm të veçantë simetrik enkripitimi (RC2/40 apo tripleDES).
2. Për çdo marrës(pranues), enkriptimi i sesion-çelësit bëhet me çelësin publik RSA të marrësit.
3. Për çdo marrës, përgatitja e një blloku të njohur si RecipientInfo që përmban një identifikues të certifikatës për çelësin publik të marrësit, 4 identifikues të algoritmit qe përdoret për të enkriptuar sesion-çelësin, dhe sesion-çelësin e enkriptuar.
4. Enkriptimi i përmbajtjes së mesazhit me sesion-çelësin.

Kjo informatë së pari kodohet me base64 .

Për të rikthyer mesazhin e enkriptuar dhe lëxuar përmbajtjen e tij, marresi së pari bënë dekodimin me base64. Pastaj nga një pjesë e mesazhit dhe përmes çelësit privat të tij, ai e dekripton sesion-çelësin. Së fundi, me anë të këtij sesion-çelësit edhe përmbajtja e mesazhit dekriptohet.

Signed Data

Nenshkrimi i të dhënave

Paraqet të dhënat e nënshkruara nga dërguesi dhe mund të përdoret me një ose më shumë nënshkrues. Hapat për përgatitjen e një signedData MIME-entitet janë:

1. Zgjidhja e një hash algoritmi MD5 ose SHA1(message digest ).
2. Gjetja(Llogaritja) e hashit të mesazhit.
3. Enkriptimi i hashit të mesazhit me çelësin privat të dërguesit.
4. Përgatitja e një blloku të njohur si SignerInfo që përmban certifikatën për çelësin publik të nënshkruesit, një identifikues të hash algoritmit, një identifikues i algoritmit që përdoret për të enkriptuar hashin dhe mesazhin e enkriptuar.

Entiteti signedData përbëhet nga një seri e blloqeve, duke përfshirë një identifikues i hashit, mesazhin duke u nënshkruar, dhe SignerInfo. Ky informacion është i koduar pastaj në base64.

Për të rikthyer mesazhin e nënshkruar dhe të verifikojmë nënshkrimin, marresi fillimisht dekodon kodimin me base64. Pastaj marrësi dekripton nënshkrimin digjital duke përdorur çelësin publik të dërguesit(nënshkruesit), e pastaj hashin e fituar e krahason me hashin e mesazhit të pranuar.Kështu edhe verifikohet nënshkrimi, në qoftëse hashet janë të njejta, personi në fjalë është ai që ka potencuar që është.

Clear Signing

Shembulli S/MIME

Arritet duke përdorur Multipart-Type me një signed-subtype. Një mesazh multipart/signed ka dy pjesë. Pjesa e parë mund të jetë e çdo lloji MIME, por duhet të jetë e përgatitur ashtuqë ajo të mos të ndryshojë gjatë transferimit nga burimi në destination. Kjo do të thotë se në qoftë se pjesa e parë nuk është 7bit, atëherë ajo duhet të kodohet duke përdorur base64 apo quoted-printable . Pastaj kjo pjesë përpunohet në të njëjtën mënyrë si SignData, por në këtë rast në procesin e kodimit base64, nuk hyn përmbajtja e mesazhit, d.m.th.: ka fushë të zbrazet përmbajtjen e mesazhit. Ky objekt është një detached signature . Pastaj është transferuar duke u koduar me base64 për t'u bërë pjesë e dytë e Multipart/Signed mesazhit. Pjesa e dytë ka tipin e pëmbajtjes MIME dhe nëntipin pkcs7-signature. Marrësi mund të verifikojë nënshkrimin duke marrë hashin e pjesës së parë dhe krahasuar me hashin që është rikthyer nga nënshkrimi në pjesën e dytë.

Registration request

Kerkesa e regjistrimit

Një aplikacion ose përdorues do të pranohet tek një autoritet certifikues për një certifikate për çelës publik. Aplikacioni /pkcs10 S/MIME përdoret për të transferuar një kërkesë certifikimi.

Kërkesa e certifikimit përfshin RequestInfo bllokun e çertifikimit, të ndjekur nga një identifikues i algoritmit te enkriptimit të çelësit publik, pasuar nga nënshkrimi i bllokut certification RequestInfo i bërë duke përdorur çelësin privat të dërguesit.

Blloku CertificationRequestInfo përfshin emrin e subjektit të çertificates dhe një bit-string representation të çelësit publik të përdoruesit.

Certificate-Only Message

Një mesazh që përmban vetem certifikata ose një CRL (Certificate Revocation List) mund të dërgohet në përgjigje të një kërkese të regjistrimit. Mesazhi është një lloj aplicationi/pkcs7-mime/subtype me një parametër smime-subtype Degenerate. Hapat e përfshira janë të njëjta si ato për të krijuar një mesazh signedData, përveç që nuk ka përmbajtje mesazhi dhe fusha signerInfo është bosh.

S/MIME CERTIFICATE PROCESSING

S / MIME përdor çertifikatat për çelësat publik që përputhen me versionin 3 të skemës së X.509. Skema e Key-Management e përdorur nga S/MIME në disa mënyra është një hibrid mes një hierarki strikte të X. 509 certifikimit dhe PGP-së.

Si me modelin PGP, S/MIME menaxherët dhe/ose përdoruesit duhet të konfigurojne çdo klient me një listë të çelësave të besuar dhe me listat e revokimit të certifikatave. Përgjegjësia është lokale për ruajtjen e çertifikatave të nevojshme për të verifikuar nënshkrimet hyrëse dhe enkriptimin e mesazheve dalëse. Nga ana tjetër, çertifikatat janë nënshkruar nga autoriteti certifikues.

USER AGENT ROLE

Një S/MIME përdorues ka edhe disa key-management për të kryer funksionet

• Key generation: DUHET të jetë i aftë për gjenerimin e ndarë Diffie-Hellman dhe DSS çifteve të çelësave dhe duhet të jetë i aftë për të gjeneruar RSA çifte të çelësave. Çdo palë çelësi duhet të jetë e gjeneruar nga një burim i mirë i hyrjes jo deterministike të rastit dhe të mbrohen në një mënyrë të sigurt. Një agjent përdorues DUHET të gjenerojë palë çelësash RSA me një gjatësi në rangun e 768-1024 bita dhe NUK DUHET të gjenerojë një gjatësi prej më pak se 512 bit.
• Registration: Çelësi publik i një përdoruesi duhet të jetë regjistruar nga një autoritet i certifikimit në mënyrë që të marrë një X. 509 certifikatë për çelës publik.
• Certificate storage and retrieval: Një përdorues kërkon qasje në një listë lokale të certifikatave në mënyrë që të verifikojë nënshkrimet hyrëse dhe të enkriptojë mesazhet dalëse.

VERISIGN CERTIFICATES

Autoriteti Certifikues

Ka disa kompani që ofrojnë autoritetin e sherbimeve të certifikimit(CA). Janë një numër i Internet CA-ve, duke përfshirë VeriSign, GTE dhe Shërbimi Postar të SHBA-ve. Nga këto, më të përdorura është CA VeriSign service, e cila ofron një shërbim CA që është menduar të jetë në përputhje me S/MIME dhe një shumëllojshmëri çështjesh të tjera aplicationeve. VeriSign lëshon X. 509 certifikata me emrin e produktit VeriSign Digital ID. Informatat që gjinden në një Digital ID varen nga lloji i Digital ID dhe përdorimi i tij.Minimumi që, secili Digital ID përmban:

• Çelësin publik pronarit
• Emri i pronarit ose pseudonimin e tij
• Data e skadimit të Digital ID
• Numrin serik të Digital ID
• Emrin e autoritetit çertifikues që e ka lëshuar Digital ID
• Nënshkrimin digjital të autoritetit certifikues që e ka lëshuar Digital ID
• Digital ID mund të përmbajnë gjithashtu të dhëna të tjera të përdoruesit, si:
• Adresa
• E-mail
• Informata themelore të regjistrimit (vendi, kodi zip, mosha dhe gjinia)