有人可以帮我解决以下问题吗？
RFC2560 定义了何时可以接受 OCSP 响应者证书(签署响应):

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

我的问题是:
如果OCSP响应者的证书是由验证路径的Trust Anchor签名的，是否也被认为是被接受的？
我的印象是它应该是，但这在上面的 RFC 中没有明确说明，也找不到关于此的明确引用。

从我对 RFC 的阅读来看，即使它是由 TA 签名的，它仍然对 OCSP 响应无效。
感谢任何帮助
注意:我正在用 Java 处理这个问题，以防万一

更新:
在 RFC 的第 2.2 节中:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA

第 2 点对我来说似乎模棱两可。
这可能意味着:
a) 任何PK都是可信的，所以Trust Anchor是可以接受的
或者
b) 具有第一个引用中第 (1) 点的含义，这意味着预先配置一个证书(任何)作为 OCSP 响应者的信任，例如在 java 中完成:

   Security.setProperty("ocsp.responderCertSubjectName",ocspCert.getSubjectDN().getName));
   List<X509Certificate> list = new ArrayList<X509Certificate>();
   list.add(ocspCert);
   CollectionCertStoreParameters p = new CollectionCertStoreParameters(list);  
   CertStore store = CertStore.getInstance("Collection", p);
   PKIXParameters params = new PKIXParameters(Collections.singleton(anchor));
   params.addCertStore(store);      

最佳答案

在 RFC 2560 中，这些表示:

1. Matches a local configuration of OCSP signing authority for the
certificate in question; or

→ 只要始终意识到自己在做什么，就可以做自己想做的事。这是“包罗万象”的条款，这意味着无论您做什么，您很可能会遵守 RFC 2560。但是，如果您是 OCSP 响应的生产者，您将希望避免使用该许可成为标准，因为您更希望响应的用户接受它们，即使他们没有相同的许可比你“本地配置”。

2. Is the certificate of the CA that issued the certificate in
question; or

→ 棘手的一点是信任 anchor 是一个 CA。它不是由证书正式表示的(尽管在许多系统中，信任 anchor 被编码为自签名证书)；但它颁发 证书，因此是一个证书颁发机构。如果 OCSP 响应是使用 TA key 签名的，那么您就是这种情况。

3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
extension and is issued by the CA that issued the certificate in
question."

→ 与上面类似，一个 OCSP 响应者签署了证书 X 的答案，其中 X 似乎是由 TA 颁发的，可以使用也由同一 TA 颁发的响应者证书 R -- 这样，我表示 X 和 R 都是由您将其名称和 key 用作信任 anchor 的证书颁发机构颁发的。

这三种情况描述了收到 OCSP 响应并希望将其用作证书路径验证的一部分的任何人都应执行的验证步骤。 RFC 的第 2.2 节是关于 OCSP 响应者的职责:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a specially
   marked certificate issued directly by the CA, indicating that the responder
   may issue OCSP responses for that CA

这三种情况与我们上面详述的接收器的情况相匹配，顺序为“2、1、3”。同样，“颁发证书的 CA”可以是其名称和公钥将被接收方用作信任 anchor 的实体。

关于java - 我应该接受由信任 anchor 签名的 OCSP 响应者证书吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5888990/