Könnte mir bitte jemand bei folgenden Fragen helfen?
RFC2560 definiert, wann ein OCSP-Responder-Zertifikat (Signatur der Antwort) akzeptiert werden kann:
Meine Frage ist:
Wenn das Zertifikat des OCSP-Responders vom Vertrauensanker des Validierungspfads signiert ist, wird es auch als akzeptiert betrachtet?
Ich habe den Eindruck, dass es sein sollte, aber dies ist nicht explizit oben aus RFC angegeben und konnte keinen expliziten Hinweis darauf finden.
Aus meiner Lektüre des RFC ist jedoch, dass selbst wenn es vom TA signiert ist, es immer noch nicht für OCSP-Antwort gültig ist.
Jede Hilfe wird geschätzt
Hinweis: Ich arbeite in Java, falls es darauf ankommt
UPDATE:
In Abschnitt 2.2 des RFC:
Alle endgültigen Antwortnachrichten MUSS digital signiert sein. Der Schlüssel
verwendet, um die Antwort zu unterzeichnen muss gehören zu einem der folgenden:- die CA, die die ausgegeben hat Zertifikat in Frage
- ein vertrauenswürdiger Responder, dessen öffentlicher Schlüssel dem Anforderer vertraut ist - ein designierter CA-Responder (Autorisierter Responder), der ein speziell gekennzeichnetes Zertifikat besitzt, das direkt von der Zertifizierungsstelle ausgestellt wurde und anzeigt, dass der Responder OCSP-Antworten für diese CA ausstellen kann.
Punkt 2 erscheint mir mehrdeutig.
Es könnte bedeuten:
a) Jede PK ist vertrauenswürdig, also ist Trust Anchor akzeptabel
oder
b) Die Bedeutung von Punkt (1) im ersten Zitat haben, was bedeutet, ein Zertifikat (irgendeines) voranzustellen, das als OCSP-Responder vertrauenswürdig ist, wie es beispielsweise in Java gemacht wird:
In RFC 2560 bedeutet das:
%Vor%→ Sie können tun, was Sie wollen, solange Sie sich dessen bewusst sind, was Sie tun. Dies ist die "Catch-All" -Klausel, was bedeutet, dass Sie wahrscheinlich RFC 2560 entsprechen werden, was auch immer Sie tun. Wenn Sie jedoch der Produzent von OCSP-Antworten sind, sollten Sie die Verwendung dieses Lizenzstandards vermeiden, da Sie die Benutzer Ihrer Antworten bevorzugen würden, sie zu akzeptieren, auch wenn sie nicht die gleichen haben "lokale Konfiguration" als Sie.
%Vor%→ Der knifflige Punkt ist, dass der Vertrauensanker eine CA ist. Es wird nicht formal durch ein Zertifikat repräsentiert (obwohl in vielen Systemen Trust-Anker als selbstsignierte Zertifikate kodiert sind); aber stellt Zertifikate aus und ist somit eine Zertifizierungsstelle. Sie befinden sich in diesem Fall, wenn die OCSP-Antwort mit dem TA-Schlüssel signiert wurde.
%Vor%→ Ähnlich wie oben kann ein OCSP-Responder, der eine Antwort für das Zertifikat X signiert, wobei X anscheinend vom TA ausgestellt wurde, ein Responderzertifikat R verwenden, das ebenfalls von demselben TA ausgegeben wurde - damit I bedeutet, dass sowohl X als auch R von der Zertifizierungsstelle ausgestellt wurden, deren Name und Schlüssel Sie als Vertrauensanker verwenden.
In diesen drei Fällen werden die Verifizierungsschritte beschrieben, die von wem auch immer empfängt eine OCSP-Antwort ausgeführt werden, und es als Teil einer Zertifikatpfad-Überprüfung verwenden möchten. In Abschnitt 2.2 des RFC geht es um die Aufgaben des OCSP-Responders:
%Vor%Diese drei Fälle stimmen mit denen für den Empfänger überein, den wir oben in der Reihenfolge "2, 1, 3" beschrieben haben. Auch hier kann die "CA, die das Zertifikat ausgestellt hat" die Entität sein, deren Name und öffentlicher Schlüssel vom Empfänger als Vertrauensanker verwendet wird.
Tags und Links java security cryptography pki ocsp