Re: Revising OCSP
koichi sugimoto <koichi.sugimoto <at> globalsign.com>
2010-07-07 01:31:27 GMT
Let me comment.
> 1.2. OCSP Responder Architectures
I think we cannot ignore Microsoft's certificate status check logic
I think "Designated OCSP Responders" must include this case.
> [Editor's note: I don't understand how this extension works. Is the
> client telling the OCSP server where to route the request? Can a
> single request include multiple certificates, each with a different
> value for the service locator field? If so, which responder signs
> the response? Is the response always signed by the server that
> directly received the request from the client, even though that
> server is just routing the request to the authoritative server(s)?
> Can anyone provide text for this section that provides more clarity
> on the semantics of this extension?]
OCSP service locator is used the case of OCSP proxy.
For example, identrus 4 corner model adopted this extension.
In this case, a OCSP client have a "Locally Trusted OCSP Responder" that may
not know the status of status of the requested certificate.
The OCSP client generates OCSP request with OCSP service locator taken from
the certificate's AIA extension.
If the "Locally Trusted OCSP Responder" does not have the status of the
certificate, that proxies this request to the other OCSP responder described as
the service locator that knows the status of the certificate.
>2.3.1. Certificate Revocation Status
Certain product responds "unknown" in case of the requested certificate
had not been published when the corresponding CRL was created.
I think this response is wrong, it must be "good".
Removing this ambiguous, I propose to add this case to "good".
> [Editor's note: RFC 5019 says that "Clients that do not include a
> nonce in the request MUST ignore any nonce that may be present in the
> response." Is it permissible for a server to include a nonce in the
> response if there was no nonce in the request? If the request
> included a nonce, may the server send a response that includes a
> different nonce?]
I think the possible combinations are:
1) o o
2) o -
3) - -
Where, "o" means exist nonce and "-" means absent.
In the case 1), the responder must include the same nonce to the request.
If the responder caches the response, nonce should not be included in it.
I think the server must not generate the case "4) - o" but in this case,
client should ignore the nonce.
pkix mailing list
pkix <at> ietf.org