W pierwszej części przedstawiłem ogólną zasadę działania protokołu OCSP. W tej skupię się na strukturze żądania i odpowiedzi OCSP.

OCSP Request

Online Certificate Status Protocol pozwala na przesyłanie żądań z wykorzystaniem zarówno metody GET jak i POST protokołu HTTP. W moim przykładzie do utworzenia żądania OCSP wykorzystam narzędzie OpenSSL. Polecenie wygląda następująco:

    openssl ocsp -CAfile root.pem -issuer subroot.pem -cert certificate.pem -url http://evca.ocsp.certum.pl -text

W poleceniu, które przesyła żądanie do serwera OCSP z użyciem metody POST, wykorzystałem kilka przełączników:

• -CAfile: certyfikat root, wystawca certyfikatu podanego w przełączniku -issuer,
• -issuer: certyfikat pośredni, wystawca certyfikatu podanego w przełączniku -cert,
• -cert: certyfikat o status którego pytamy,
• -url: adres serwera OCSP, który możemy wyodrębnić z certyfikatu za pomocą polecenia „openssl x509 -in certificate.pem -noout -ocsp_uri”,
• -text: powoduje wyświetlenie zarówno żądania jak i odpowiedzi na konsolę (jeżeli chcemy wyświetlić tylko żądanie używamy -req_text, jeżeli tylko odpowiedź -resp_text).

Struktura żądania OCSP wygląda następująco:

OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 53C989243FC25295A68B31BFB44898A7E7506A52
Issuer Key Hash: C03B0AFA0FD9FE0F4E029865140C8A1E2E008C03
Serial Number: 404E7204AE83E38D95C102DA93A30001
Request Extensions:
OCSP Nonce:
041009E67FA15F0530AC405D5FBD1A09AB64

Pierwszą z przesyłanych danych w żądaniu OCSP jest wersja protokołu określająca między innymi składnię żądania czy obsługiwane rozszerzenia. Obecnie wartość domyślna wersji to 1.

Kolejna sekcja zawiera informacje na temat certyfikatu, który jest podmiotem zapytania. Składa się ona z czterech pól. Pierwsze z nich Hash Algorithm określa jaka funkcja skrótu została użyta do wyliczenia wartości dwóch kolejnych pól: Issuer Name Hash i Issuer Key Hash. Issuer Name Hash to skrót z nazwy wyróżnionej wystawcy (DN – Distinguished Name) certyfikatu o który pytamy. DN obejmuje całe pole Subject (Podmiot) certyfikatu. Z kolei wartością pola Issuer Key Hash jest skrót klucza publicznego wystawcy. Ostanie z pól sekcji Requestor List to numer seryjny certyfikatu, którego aktualny status chcemy poznać.

Żądanie zawiera jeszcze jedno pole będące rozszerzeniem, które jest w przeciwieństwie do innych jest opcjonalne – Nonce. Ta generowana losowo wartość pozwala na powiązanie żądania i odpowiedzi OCSP. Głównym powodem dołączania losowej wartości nonce jest zapobieganie atakom powtórzeniowym (ang. replay attack).

OCSP Response

W odpowiedzi na żądanie przedstawione powyżej serwer OCSP zwrócił poniższą strukturę odpowiedzi. Każda taka odpowiedź musi być podpisana cyfrowo.

OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = PL, O = Unizeto Technologies S.A., CN = Certum Validation Service
Produced At: Jan 24 16:19:10 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 53C989243FC25295A68B31BFB44898A7E7506A52
Issuer Key Hash: C03B0AFA0FD9FE0F4E029865140C8A1E2E008C03
Serial Number: 404E7204AE83E38D95C102DA93A30001
Cert Status: good
This Update: Jan 24 16:19:10 2015 GMT
Next Update: Jan 31 16:19:10 2015 GMT

Response Extensions:
OCSP Nonce: 041009E67FA15F0530AC405D5FBD1A09AB64

Signature Algorithm: sha1WithRSAEncryption
b6:b7:78:9d:4b:33:2f:0b:f1:c0:81:d4:35:b4:41:72:8f:a1:
4b:99:28:d5:8a:4d:b4:55:42:ef:ef:cc:a6:1e:d9:e6:71:66:
05:90:9a:05:2d:a2:76:ee:49:da:02:54:70:65:b3:b7:94:a7:
54:88:22:24:bd:17:aa:ca:8f:70:9b:a1:c5:ac:3b:d0:0c:dd:
67:93:d5:d6:06:26:eb:7e:f3:d7:70:b9:a4:9a:3f:77:1a:0d:
26:eb:f8:ec:b9:a6:59:30:40:7d:80:49:2e:06:a0:f0:10:36:
6a:71:0a:be:35:eb:eb:04:0d:9b:26:81:09:38:08:15:2a:31:
92:0d:99:5a:f2:01:28:0c:4e:42:a7:7c:92:ef:77:c1:09:71:
5b:0b:d8:05:a0:3e:b8:67:f4:74:0d:4a:3b:b5:cd:50:73:e1:
ac:7c:a8:fc:ff:11:f9:b7:70:5e:ea:8a:5a:5f:7e:fc:e5:75:
e9:82:cd:64:fe:3c:66:61:0b:b7:07:ce:03:ae:cc:75:e6:7e:
61:86:c5:d2:b0:72:35:13:b7:0e:39:87:ee:1c:22:c3:be:0b:
e1:2b:d6:b7:80:e0:7a:0e:7a:5c:06:b6:1d:f7:2f:8d:bb:42:
96:15:d4:3f:e1:5c:37:7b:82:9d:fa:da:b7:12:68:b7:b3:b4:
a9:d1:4a:c4

Pierwszą ze zwracanych informacji jest jej status. Pole to może przybrać jedną z sześciu wartości definiowanych przez RFC 2560:

1. successful
2. malformedRequest
3. internalError
4. tryLater
5. sigRequired
6. unauthorized

Te od numeru pierwszego do czwartego nie wymagają chyba większego wyjaśniania. Przedostatnia wartość sigRequired oznacza, że serwer OCSP wymaga od klienta cyfrowego podpisania żądania i dopóki warunek ten nie zostanie spełniony nie zostanie ono poprawnie przetworzone. Status unauthorized zwracany jest z kolei w przypadku, gdy klient nie jest uprawiony do wysyłania danego żądania lub serwer OCSP nie jest w stanie odpowiedzieć autorytatywnie. Przykładem może być sytuacja w której responder OCSP usunął z bazy danych informacje o statusie certyfikatu wygasłego (może to zrobić w celu uniknięcia jej nadmiernego rozrostu).

W naszym przykładzie żądanie zostało obsłużone prawidłowo, dlatego też wartość pola OCSP Response Status to successful. Następnie widzimy typ odpowiedzi, w większości przypadków jest to Basic OCSP Response. Ten typ odpowiedzi musi być bezwzględnie obsługiwany przez każdy serwer świadczący usługę OCSP.

Dalej znajduje się cześć określana jako ResponseData na którą składają się wersja protokołu, identyfikator respondera, data w której odpowiedź została podpisana cyfrowo przez OCSP responder, status certyfikatu oraz ewentualne dodatkowe rozszerzenia.

Pole version w odpowiedzi pełni taką samą rolę jak w żądaniu. Pole responderId może przyjąć wartość pola Subject z certyfikatu użytego do podpisania odpowiedzi (tak jak w tym przypadku) lub być skrótem z klucza publicznego tego samego certyfikatu. Opis pola producedAt pominę teraz, ponieważ zostanie dokładniej przedstawione w dalszej części wpisu. Następnie mamy dane składające się na właściwą odpowiedź, czyli zawierającą informacje o statusie – pole responses. Tutaj widzimy te same pola z identycznymi wartościami jak w żądaniu. Podobnie także jak w żądaniu są one składowymi struktury CertID. Dalsza cześć pola responses to certStatus (w końcu możemy dowiedzieć się czy interesujący nas certyfikat jest ważny czy może został unieważniony) – w tym przypadku zwrócony status to good, co oznacza, że certyfikat nie został unieważniony. Kolejne pola to thisUpdate i nextUpdate o których więcej za chwilę.

Niżej widać rozszerzenie Nonce. Zauważcie, że wartość tego pola jest identyczna jak w żądaniu. Dodanie do żądania tej kryptograficznej wartości wymusza na responderze OCSP umieszczenie jej zwrotnie w odpowiedzi. Jak już wcześniej wspomniałem mechanizm ten chroni proces uzyskania informacji o statusie certyfikatu przed atakami powtórzeniowymi.

Na końcu znajduje się wartość podpisu złożonego na skrócie z odpowiedzi. Algorytm podpisujący odpowiedź w naszym przypadku to sha1WithRSAEncryption. Oznacza to, że skrót z odpowiedzi (a dokładniej, z jej fragmentu – struktury ResponseData), został wyliczony za pomocą funkcji skrótu SHA-1, a następnie podpisany za pomocą klucza prywatnego respondera OCSP i algorytmu RSA.

Cztery ważne czasy

Z odpowiedzią OCSP związane są cztery istotne wartości czasowe:

• producedAt,
• thisUpdate,
• nextUpdate,
• revocationTime.

Trzy z nich znajdowały znajdowały się w przykładowej odpowiedzi zaprezentowanej powyżej. Omówię teraz to, jakie informacje zawierają.

Pierwsza producedAt informuje nas kiedy odpowiedź została podpisana przez certyfikat OCSP respondera. Warto zauważyć, że nie zawsze musi być to czas równy czasowi zwrócenia odpowiedzi. Wynika to z często stosowanej praktyki cache’owania odpowiedzi OCSP – responder może wtedy zwrócić odpowiedź, która została podpisana jakiś czas wcześniej. Oczywiście mając na względzie bezpieczeństwo użytkowników czas cache’owania nie powinien być zbyt długi, ponieważ zwiększa to ryzyko zwrócenia błędnego statusu.

Pole thisUpdate identyfikuje najaktualniejszy czas w którym responder posiada prawidłową odpowiedź dla danego certyfikatu. Podobnie jak w przypadku producedAt czas ten często nie jest równy czasowi w którym została zwrócona odpowiedź. Gdy czas z pola thisUpdate jest późniejszy niż aktualny czas, odpowiedź może być uznawana za niepewną. Często wartość thisUpdate jest identyczna jak wartość producedAt, aczkolwiek nie jest to regułą. Trzeci z czasów nextUpdate określa maksymalny moment w którym responder OCSP będzie musiał zaktualizować informacje o statusie danego certyfikatu. W przypadku, gdy wartość z pola nextUpdate wskazuje na wcześniejszą godzinę niż aktualny czas, odpowiedź nie powinna być uznawana za właściwą. Oba te czasy – thisUpdate i nextUpdate – dzieli z reguły ten sam okres czasu i jest on odpowiednikiem ważności list CRL, która to określana jest przez pola o takich samych nazwach.

Ostatni z czasów revocationTime zwracany jest jedynie w momencie, gdy status certyfikatu o który pytamy to revoked. Zawiera on informacje o dacie i godzinie w której certyfikat został unieważniony.

Certyfikat podpisujący

Jak już wspomniałem każda odpowiedź serwera OCSP musi być podpisana cyfrowo. Odpowiedź może być podpisana z użyciem:

• certyfikatu CA, który jest wystawcą certyfikatu z żądania,
• tzw. Trusted Responder, któremu ufa klient przesyłający żądanie,
• tzw. Authorized Responder, certyfikatu dedykowanego do podpisywania odpowiedzi OCSP, certyfikat taki podpisywany jest przez urząd będący wystawcą certyfikatu o status którego pytamy.

Spośród trzech możliwości najpopularniejsza jest ta ostatnia, polegająca na wygenerowaniu dedykowanego certyfikatu służącego do podpisywania odpowiedzi OCSP w ramach danego CA. Certyfikat taki powinien w rozszerzeniu Extended Key Usage (rozszerzone użycie klucza, OID: 2.5.29.37) posiadać wartość id-kp-OCSPSigning (OID: 1.3.6.1.5.5.7.3.9) oznaczającą możliwość podpisywania odpowiedzi OCSP.

Rozszerzenie Extended Key Usage w certyfikacie OCSP

Innym rozszerzeniem, które może znaleźć się w certyfikacie respondera OCSP jest id-pkix-ocsp-nocheck (OID: 1.3.6.1.5.5.7.48.1.5). O tym rozszerzeniu i jeszcze paru innych ciekawych kwestiach związanych z protokołem OCSP w kolejnej części.