Zrób Sobie Firmę

IPSec i tym podobne chronią transmisję danych od końca do końca przez Internet. Oprócz tej ochrony wymagamy również metod zapewniających, że aplikacje mogą być prowadzone w podobnie bezpieczny i zweryfikowany sposób. Jedną z najprostszych, ale najczęściej wykorzystywanych aplikacji wymagających bezpieczeństwa, jest prosta transakcja między komputerem klienckim a usługą WWW, np. przy przekazywaniu szczegółów w celu autoryzacji płatności. Wymagany jest proces bezpieczeństwa, który znajduje się między warstwą aplikacji a ogólnym połączeniem TCP/IP, które przebiega pod nią. Jedną z bardzo popularnych metod jest protokół Secure Sockets Layer (SSL), pierwotnie opracowany przez firmę Netscape . Szczegóły transakcji są dość złożone, ale mechanizm jest stosunkowo prosty: dane między klientem a serwerem są szyfrowane w ramach warstwy rekordu SSL. Konieczne jest, aby klient ustalił zasady tego szyfrowania, a serwer zgodził się na to i działał zgodnie z nimi. Zrobione podczas uzgadniania SSL.

† Klient rozpoczyna transakcję wysyłając do serwera losową liczbę.

† Serwer odpowiada, wydając numer połączenia i swój klucz publiczny.

† Klient odpowiada komunikatem zaszyfrowanym przy użyciu klucza publicznego serwera, który zawiera informacje o kluczu (które będą używane do szyfrowania szczegółów transakcji, np. za pomocą DES) oraz kilka kluczy sk1 i sk2, które będą używane do walidacji wiadomości między klientem a serwerem.

† Używając swojego klucza prywatnego, serwer dekoduje te informacje i czeka.

† Klient używa sk1 do szyfrowania identyfikatora połączenia pierwotnie wydanego przez serwer i wysyła go do serwera.

† Serwer ma sk1, więc może zdekodować wiadomość, aby znaleźć identyfikator połączenia, który jest rzeczywiście ważny między serwerem a klientem.

† Serwer szyfruje teraz losowe „wyzwanie” wysyłane przez klienta na początku uzgadniania za pomocą sk2 i wysyła je do klienta.

† Klient może to odszyfrować i sprawdzić, czy rzeczywiście jest to właściwy serwer, z którym się komunikuje.

Obie strony udostępniają teraz bezpieczne klucze i mogą kontynuować transakcję. SSL jest w dużym stopniu zgodny z zasadą dobrego bezpieczeństwa, która wymaga niewiele od projektanta aplikacji: wszystko, co należy zrobić, to zamienić wywołanie narzędzia TCP na jedno na SSL. To był jeden z powodów, dla których SSL stał się najczęściej używanym protokołem bezpieczeństwa przeglądarki. Powinniśmy wspomnieć o jeszcze jednym udoskonaleniu, które zmienia technologię bezpieczeństwa SSL w bezpieczny proces: uwierzytelnianie klucza publicznego serwera. Tylko sprytni (lub nieco bystrzy?) spośród nas pomyśleliby o możliwości, że serwer WWW, z którym mamy do czynienia, nie jest tym, za kogo się podaje. Tak, deklaruje klucz publiczny, ale niekoniecznie taki, który należy do firmy, za którą się podaje. Ludzie, którzy zaprojektowali SSL, pomyśleli o tym: tak naprawdę nie jest to sam klucz publiczny, który może być oferowany przez serwer; może to być certyfikat cyfrowy, wystawiony przez urząd certyfikacji, potwierdzający tożsamość serwera.

Omawiamy kluczową rolę ekstranetów i intranetów w budowie logistyki business-to-business i intrabusiness przedsiębiorstwa elektronicznego. Kluczowe znaczenie dla tych usług ma możliwość zapewnienia poufnej i gwarantowanej komunikacji między witrynami połączonymi za pośrednictwem publicznego Internetu. Jak dotąd nasza dyskusja na temat IPSec dotyczyła pierwszej części. Ale nie ma sensu budowanie sieci, która naszym zdaniem może zostać zaatakowana i która może przenosić tajemnice, jeśli te tajemnice nie zostaną dostarczone we właściwe miejsce, ponieważ ktoś przesłał je gdzie indziej. Sieć nie ma większego sensu, jeśli ktoś może zalać ją ruchem, który wydaje się pochodzić z legalnych punktów, ale w rzeczywistości jest wstrzykiwany przez stronę trzecią w celu zmylenia lub zakłócenia. Dlatego jednym z dodatkowych wymagań dla IPSec i innych protokołów bezpieczeństwa jest zagwarantowanie miejsca pochodzenia i miejsca dostarczenia pakietów IP. Protokół IPSec rozwiązuje ten problem na dwa sposoby, w zależności od tego, czy transport danych pochodzi z oryginalnego hosta (tryb transportu), czy też jednym z końców bezpiecznej ścieżki jest tylko brama (na przykład zapora, Rysunek 2.24). Ponownie, szczegóły są złożone, ale główna różnica polega po prostu na tym, jak widoczne jest trasowanie pakietu od końca do końca do strony trzeciej obserwującej łącze. Bezpieczeństwo łącza jest definiowane jednokierunkowo, co oznacza, że ​​istnieją oddzielne zabezpieczenia dla ruchu przechodzącego w przeciwnych kierunkach. Tunelowanie to podstawowa funkcja bezpieczeństwa technologii wirtualnej sieci prywatnej (VPN).

Widzieliśmy, że podstawowy protokół transmisji pakietów w Internecie, IP, jest zakładnikiem fortuny, jeśli chodzi o prawidłowe dostarczanie pakietów we właściwej kolejności i bez błędów, i dyskutowaliśmy, w jaki sposób może to być podatne na ataki. W przypadku aplikacji wymagających bezpieczeństwa istnieje protokół IPSec , który leży w warstwie IP i stara się zapewnić, że pakiety są autentyczne, nieuszkodzone i poufne. IPSec jest opisywany przez Internet Engineering Taskforce jako „struktura”, która może ewoluować z czasem w celu zapewnienia trwałej bezpieczeństwo sieci. Jedną z jego zalet jest to, że jest on udoskonalany zgodnie z rozwojem IETF dla późniejszych wersji standardu IP, zwłaszcza wersji IP 6. Szczegóły są złożone i nie będą tutaj omawiane, ale podstawowe zasady są proste: w ramach standardu Pakiet IP, IPSEC definiuje kilka nagłówków; jeden z nich określa szczegóły uwierzytelniania, a drugi określa stosowane szyfrowanie. Klucze publiczne z certyfikacją cyfrową (aby udowodnić, że rzeczywiście należą do komunikujących się stron) są najpierw używane do szyfrowania i przesyłania tajnych kluczy. Niektóre z tych kluczy są następnie wykorzystywane do szyfrowania ruchu pakietowego, aby uniemożliwić jego odczytanie bez uprawnień, np. za pomocą DES. Inne klucze są używane do algorytmów mieszających, które dołączają sygnatury mieszające do pakietów danych w celu uwierzytelnienia ich przed uszkodzeniem. Protokół IPSec został zaprojektowany, aby umożliwić włączanie nowych algorytmów szyfrowania, gdy zostaną one opracowane i sprawdzone. Oprócz zapewnienia ochrony przed podsłuchaniem i uszkodzeniem danych, protokół IPsec może również chronić przed atakiem typu man-in-the middle (przechwytywaniem legalnych pakietów i odtwarzaniem ich w późniejszym czasie). Robi to, dodając do pakietu zaszyfrowany numer sekwencji i zwiększa go za każdym razem, gdy ten sam pakiet jest retransmitowany. Może to również pokonać ataki, takie jak wspomniany wcześniej atak defragmentacyjny.

Teraz, gdy omówiliśmy zasady szyfrowania cyfrowego, możemy przyjrzeć się jednemu lub dwóm standardowym procesom, które wykorzystują je jako sposób świadczenia usług bezpieczeństwa w sieciach komputerowych. Środki bezpieczeństwa muszą uwzględniać fakt, że ataki mogą być przeprowadzane na różnych poziomach w sieciowym systemie komputerowym. Problem z zapewnieniem bezpieczeństwa w aplikacji polega na tym, że utrudnia to zapewnienie, że żadne pułapki na niższych poziomach nie zostały otwarte, a także nakłada odpowiedzialność za bezpieczeństwo na każdego dewelopera aplikacji, co może być nieefektywne, prawdopodobnie niepewne. Zaczynamy na poziomie pakietu.

Część lub nawet cały tekst dokumentu jest przekazywany do urządzenia  kryptograficznego , generatora skrótu, który jest zagruntowany tajnym kluczem. To urządzenie następnie pobiera podany tekst i konwertuje go na wartość skrótu, która jest zaszyfrowanym podsumowaniem dokumentu. Algorytm używany do haszowania dokumentu został zaprojektowany tak, aby w większości przypadków zmiana oryginału powodowała zmianę funkcji haszującej. Możemy to zrobić na wiele sposobów. Jednym prostym podejściem może być policzenie całkowitej liczby znaków w dokumencie, zaszyfrowanie tej wartości w jakiś sposób i użycie tej zaszyfrowanej wartości jako funkcji skrótu. Większość zmian w dokumencie spowodowałaby różnicę między oryginalną funkcją skrótu a funkcją skrótu obliczoną dla nowego dokumentu. Oczywiście jest to strasznie niepewny przykład; gdyby ktoś dowiedział się, że używasz tego algorytmu mieszającego, może łatwo wygenerować zmiany w dokumencie, które go oszukają. Praktyczne algorytmy haszujące muszą spełniać szereg bardziej rygorystycznych warunków. Niech tekst, który chcemy haszować, będzie x. Niech operacja haszowania będzie h, a wynikiem haszowania x będzie h (x). Zatem dobra funkcja skrótu, h, to taka, która ma następujące właściwości:

1 Obliczalność: powinno być możliwe obliczenie h (x).

2 Opór jednokierunkowy: przy danej wartości skrótu y, generalnie nie można znaleźć wartości x takiej, że h (x) = y.

3 Słaba odporność na zderzenia: przy danych x i h (x) nie można znaleźć x *, gdzie x * nie jest równe x, takie że h (x *) = h (x).

4 Silna odporność na kolizje: niemożliwe jest znalezienie różnych danych wejściowych x i x *, gdzie h (x *) = h (x).

5 Kompresja: niezależnie od długości x, h (x) powinno mieć stałą długość, n.

Warunki 1–4 sugerują, że funkcja skrótu jest jednokierunkowa, ponieważ łatwiej jest ją utworzyć niż wrócić do oryginalnego tekstu. (Zwróć uwagę na podobieństwo do systemów klucza publicznego.) Warunki sugerują również, że funkcja skrótu ma tendencję do utrzymywania „dobrej separacji” między różnymi tekstami: chociaż ogólnie mapuje je na mniejszą liczbę bitów niż w ich oryginalnej formie, stara się znaleźć jak najbardziej odmienne rozwiązanie dla każdego z nich. Załóżmy, że myślimy o każdym bicie oryginalnej wiadomości jako zapisanym w innym „wymiarze” w przestrzeni wiadomości. Wówczas wiadomość o długości M bitów można uznać za punkt w przestrzeni wielowymiarowej. (Na przykład trzybitowa wiadomość ‘1,21,1’ ma współrzędne {1,21,1} w trzech przestrzeniach). wymiarowość n). Dobrze zaprojektowana funkcja mieszająca będzie miała tendencję do rozmieszczania odpowiedzi dla zestawu wszystkich wiadomości, aby były jak najdalej od siebie w ograniczonej przestrzeni wymiarowej. Ma również tę właściwość, że przyjmuje dwie wiadomości, które są bardzo podobne i tworzy wartości skrótów, które na ogół nie są szczególnie blisko siebie, co utrudnia pracę wstecz, a także unika możliwości przypadkowego wygenerowania wykonalnych, podobnych wiadomości, gdy podjęto próbę fałszywego dekodowania. Funkcje skrótu można generować w sposób podobny do metod szyfrowania. Jedna metoda, dyskretna potęga, jest odwrotnością opisanego wcześniej problemu dyskretnego logarytmu. Jest to jednak dość intensywne obliczeniowo i czasami stosuje się inne, szybsze metody. Przykładami są bezpieczny algorytm skrótu (SHA-1), który jest używany jako część amerykańskiego standardu Digital Signature Standard oraz standardu MD5, który jest bardzo powszechny w przypadku aplikacji internetowych. Aby użyć funkcji skrótu do ochrony integralności zestawu danych, nadawca musi udostępnić bezpieczny klucz prywatny odbiorcy. Można to łatwo zrobić, jeśli odbiorca najpierw opublikował klucz publiczny, który może być następnie użyty przez nadawcę do zaszyfrowania uwierzytelniania klucza prywatnego. Oczywiście, oprócz potwierdzenia, że ​​nie doszło do nadużyć w imieniu obu stron umowy, funkcja skrótu może być wykorzystana do ochrony integralności dokumentu „w tranzycie”, np. w celu ochrony przed modyfikacją umowy przez osobę trzecią, być może w celu „oddrobnienia” wartości dodatkowej z transakcji finansowej.

Skrajnym przeciwieństwem wyidealizowanego powyżej scenariusza militarnego jest sytuacja, w której nie można zakładać, że partnerzy transakcji działają w dobrej wierze. A zawiera umowę z B na dostawę towarów pod pewnymi warunkami – a przynajmniej tak myśli B. Handlowali na kontynentach bez fizycznego spotkania i mogą wymieniać umowy tylko drogą elektroniczną. B jest rozczarowany, ponieważ uważa, że ​​A nie spełnił warunków zawartej przez siebie umowy, ale pojawia się zamieszanie, ponieważ A wydaje się mieć inne sformułowanie. Jak można tego uniknąć? Na długo przed wymianą kontraktów elektronicznych, fizyczne kontrakty na papierze zostały celowo rozdarte na dwie części i każda ze stron trzymała jedną z części. Łza była postrzępiona i trudna do podrobienia. Połączenie tych dwóch części dostarczyło dowodu, że był to oryginał uzgodnionej umowy. Nieco inne podejście stosuje się do zabezpieczania wrażliwych dokumentów przed nieautoryzowanym otwarciem – koperty zawierające instrukcje „otwierać tylko w nagłych wypadkach” są czasami podpisane na klapkach i klapach zaklejonych taśmą klejącą, która niszczy podpis przy próbach usunąć to. To są tylko częściowe dowody. Możemy zrobić lepiej elektronicznie. Jeszcze bardziej przekonujący byłby sposób ochrony każdego fragmentu wiadomości przed manipulacją. Załóżmy, że ktoś zmienia 100 USD na 1000 USD, chcemy być w stanie zidentyfikować, że zmiana została dokonana i najlepiej w jakiej formie. Chcemy móc zażądać, aby nadawca dołączył jakąś formę podpisu cyfrowego, który uwierzytelnia dane (i nadawcę).

Do tej pory mówiliśmy dość ogólnie o technikach szyfrowania, bez jakiejkolwiek rzeczywistej próby kategoryzacji ich aplikacji. Przyjrzeliśmy się poszczególnym aspektom: kryptografii jako sposobu przetwarzania wiadomości w celu uodpornienia ich na nadużycie przez osobę nieuprawnioną oraz tworzeniu certyfikatu cyfrowego przez urząd certyfikacji. Są jednak inne przypadki: być może chcemy podpisać to przesłanie, aby udowodnić, że rzeczywiście pochodzi ono od nas; być może chcemy się upewnić, że nie może zostać celowo skorumpowany przez osobę, która go otrzymała, a następnie przedstawiła w celu uzasadnienia fałszywego roszczenia. W kolejnych sekcjach przyjrzymy się kilku najczęstszym zastosowaniom kryptografii, które można znaleźć w eBiznesie. Najpierw musimy sobie przypomnieć, że model systemu bezpieczeństwa wojskowego nie jest adekwatnym sposobem opisu sytuacji komercyjnej. Nie mamy dwóch bezwarunkowo „dobrych facetów”, w pełni wyszkolonych i zdolnych do walki, po jednym na każdym końcu transakcji, atakowanych przez „złego faceta”. Istnieje wiele innych alternatyw.

Przy tworzeniu sieci korporacyjnej prawie nieuniknione będzie zastanowienie się nad różnymi kluczami bezpieczeństwa. Czyniąc to, należy rozważyć, czy będzie to całkowicie zamknięta sieć, w takim przypadku można zastosować rozwiązanie wewnętrzne. Jednak wraz z rozwojem operacji business to business rozsądniej może być rozważenie wyboru szeroko stosowanego systemu. (Nie ma jednego „standardu.) Jedną dobrą ogólną zasadą, którą należy wziąć pod uwagę, jest możliwość zintegrowania kluczowego zadania zarządzania z resztą oprogramowania do planowania zasobów i sterowania procesami, w szczególności korzystanie z korporacyjnego katalogu pracowników jako centrum kontroli praw dostępu i uprawnień.  Powszechną praktyką jest łączenie LDAP ze standardem X.509 dla certyfikatów cyfrowych. Ponieważ X.509 dotyczy przede wszystkim powiązania nazwiska osoby z certyfikatem cyfrowym, widzimy, że sensowne jest połączenie go z naturalnym źródłem nazw firmowych – usługą katalogową.

W zasadzie każdy może być urzędem certyfikacji, ale w praktyce wymagany jest bardzo duży stopień wiarygodności (zaufanie, znowu!). Rolę tę mogą przejąć duże, znane i dobrze założone firmy o reputacji firmy zajmującej się bezpieczeństwem (na przykład banki i inne instytucje finansowe), podobnie jak urzędy pocztowe i firmy telekomunikacyjne. Niektóre duże firmy początkowo utworzyły własne urzędy certyfikacji, ale odnotowano tendencję do „wydzielania” urzędów certyfikacji joint venture, które działają pod aurą godną zaufania rodziców. Organy rządowe lub quasi-rządowe (ocena jest subiektywna) również mogą być zaangażowane w certyfikację.

Czasami termin zaufana strona trzecia jest używany jako synonim urzędu certyfikacji. To chyba nie jest dobry pomysł, ponieważ może łączyć ideę uwierzytelnienia czyjejś dobrej wiary i tożsamości z pojęciem dostępu do klucza lub depozytu klucza, co wiąże się z potrzebą walki z przestępczością i wspierania bezpieczeństwa państwa. Rządy, zwłaszcza Stany Zjednoczone i, w mniejszym stopniu, Wielka Brytania, próbują ograniczyć stosowanie silnego szyfrowania do działań, które określają jako uzasadnione. Zdają sobie jednak sprawę, że może to nie być całkowicie wykonalne. Zamiast tego próbują przekonać swoich obywateli, że każdy, kto używa silnych metod szyfrowania, musi przekazać klucz odszyfrowujący zaufanej stronie trzeciej, która w odpowiednich nakazach, przedstawi go władzom. Rządy i inne oficjalne organy skłaniają się do faworyzowania podejścia zaufanej strony trzeciej i/lub urzędu certyfikacji. Niepokoi to niektórych ludzi, którzy widzą w tym potencjalną drogę do wyzysku przez niekoniecznie łagodne państwo. Maher uważa, że ​​takie „podejścia licencyjne, które jawnie ograniczają wolność otwartych rynków” będą destrukcyjne. Lomas i Crispo ostrzegają, że: „… ważne jest, aby pamiętać, że„ zaufane ”i„ godne zaufania ”to nie to samo”. Ale jeśli mamy usunąć oficjalnie sankcjonowaną stronę trzecią, jak mamy być w stanie wygenerować niezbędny poziom zaufania między stronami transakcji? Jedną z opcji jest wykorzystanie sieci zaufania, zdecentralizowanej sieci, polegającej na uwierzytelnianiu innych przez same strony handlowe .

Załóżmy, że chce handlować z B, ale nic nie wie o B. W szczególności A nie wie, czy można ufać, że cyfrowo poświadczona wiadomość od B jest niepodważalna, czy nawet faktycznie od B. Na szczęście A zna C i C, poprzez osobiste kontakty z B może ręczyć za ważność certyfikatów B. (Być może C już wcześniej fizycznie odwiedzał witrynę B i uzyskał dostęp do informacji klucza publicznego B w gwarantowany sposób.) Możliwe jest wówczas, że deklarowane szczegóły B zostaną umieszczone w opakowaniu z C, przy użyciu standardowego na przykład haszowanie szyfrowania, aby A wiedział, że otrzymuje ważne dane certyfikacyjne, których może bezpiecznie używać w handlu z B

W ten sposób sieć zaufania zawsze opiera się na zaufanym pośredniku, a nie na „wyższym autorytecie”. Eliminuje to biurokratyczne komplikacje hierarchicznego drzewa urzędów certyfikacji, a także pozwala odpocząć od wszelkich obaw dotyczących ich uczciwości w użyciu lub niewłaściwego użycia klucza (poważny problem dotyczący praw obywatelskich w niektórych krajach). Z drugiej strony są problemy skalowalności (a raczej jej braku) i możliwości złych praktyk w imieniu zaufanego partnera. Najczęściej stosowanym schematem opartym na sieciach zaufania jest Pretty Good Privacy (PGP)

Jak już wielokrotnie mówiliśmy, problem rozwiązuje się wokół zaufania i zasad, które sprawiają, że zaufanie to jest uzasadnione. Jedną z przydatnych definicji, która odnosi się do tego, jest certyfikacja: „ocena, czy produkt jest odpowiedni dla danego zastosowania”. Certyfikat w naszym przypadku jest pewnym wiarygodnym dowodem na to, że zidentyfikowana osoba ma prawo do zbioru przywilejów. Certyfikat wydaje urząd certyfikacji. Weźmy prosty przykład, w jaki sposób może to umożliwić transakcję. Załóżmy, że ktoś podający się za „Alicję” publikuje klucz publiczny. Bob chce prowadzić interesy z prawdziwą Alicją. Skąd wie, że ona i „Alice” to rzeczywiście ta sama osoba? To, czego wymaga Bob, to niepodrabialny dokument od publicznie znanego organu, który wiąże klucz publiczny „Alicji” z prawdziwą Alicją. Jak pokazano na rysunku, Alicja zwraca się do urzędu certyfikacji i prosi go o zweryfikowanie jej klucza publicznego

Po przeprowadzeniu należytej staranności, a może nawet spotkania na żywo między Alicją a członkiem władz, ten ostatni zgadza się, że Alicja jest tym, za kogo się podaje. Teraz Alicja musi zaufać: musi założyć, że urząd certyfikacji jest powszechnie znany i monitorowany do tego stopnia, że ​​po opublikowaniu „jego” klucza publicznego ma pewność, że „to” naprawdę. Po wykonaniu tej czynności organ tworzy zaszyfrowaną wiadomość ze swoim kluczem prywatnym, który zawiera klucz publiczny Alicji. Alicja wysyła tę wiadomość, certyfikat, do Boba, zanim przystąpią do negocjacji biznesowych. Wszystko, co Bob musi zrobić, to użyć klucza publicznego certyfikatu do odszyfrowania certyfikatu, a tym samym ustalenia tożsamości „Alicji”. Bob wie, że klucz autorytetu jest prawdziwy i wie, że autorytet zna klucz „Alice”, aby naprawdę pochodzić od Alicji. Wspomnieliśmy o zaufaniu. Fakt, że pierwsza i druga strona transakcji są gotowe zaufać osobie trzeciej (urzędowi certyfikacji), ma kluczowe znaczenie dla procesu. Zaufanie musi działać na dwa sposoby: strony muszą wierzyć, że organ jest tym, za kogo się podaje, a także ufać, że jego procesy są uczciwe i kompetentne. Zapewnienie obu tych warunków jest trudne dla jednego organu. Jest bardzo mało prawdopodobne, aby jedna organizacja mogła przeprowadzić rzetelny audyt wszystkich stron, które chciały zawrzeć duże i małe transakcje na całym kontynencie.

Jednym ze sposobów obejścia tego problemu skalowalności jest stworzenie wielopoziomowej hierarchicznej struktury urzędów certyfikacji [85]. Wyższe, bardziej ogólne władze uwierzytelniałyby klucze publiczne niższych, bardziej wyspecjalizowanych władz. Można nawet wyobrazić sobie sieć zamiast drzewa hierarchii zaufania z kilkoma niezależnymi organami weryfikującymi certyfikat. Certyfikat musi potwierdzać klucz publiczny strony, którą kontrolował, ale może, a nawet powinien, zawierać również inne informacje. Musi określać algorytm szyfrowania, do którego odnosi się klucz publiczny strony uwierzytelnianej, a także zawierać datę wygaśnięcia certyfikatu. Ta ostatnia jest bardzo ważną informacją i musi wynikać z oceny wartości w imieniu urzędu certyfikacji jako  jak długo strona uwierzytelniona może zachować integralność prywatnego klucza. (Zwróć uwagę na zwykły kompromis między bezpieczeństwem a wygodą: im częściej klucz jest ponownie certyfikowany, tym więcej kłopotów, ale bardziej prawdopodobne, że jest ważny). Certyfikat może również zawierać inne informacje istotne dla ogólnych relacji handlowych; na przykład może przechowywać informacje o licencjach na zajmowanie się pewnymi informacjami i przeprowadzanie regulowanych procesów (lekarze, usuwanie niebezpiecznych odpadów itp.). Może również zawierać warunki umowne – limity ubezpieczenia, władze w organizacji (np. „oficer finansowy”) i tak dalej. Niektóre z nich mają szczególne zastosowanie w transakcjach między przedsiębiorstwami i zaczynają rozszerzać rolę certyfikacji organów poza zwykłą certyfikację finansową. Podobieństwa i możliwości integracji tego z organami ratingowymi PICS i P3P powinny być jasne.