RE: DPD & DPV requirements - to nonce or not to nonce?

[Stephen Kent <kent@xxxxxxx>]

Peter,

> X.511 enables signed requests and signed responses to be linked by nonce values. X.500 however had no
> clear statements about nonce handling. I implemented an online responder for certificates status
> values using X.511 signed request/response pairs several years ago. I maintained at the server a
> hash-tree of nonce values provided to, and generated by the server, and checked that a nonce value
> was not repeated in a certain period. As X.500 operations are rather more complex than simple OCSP, requiring support for multicasting, result reconstruction/resigning and n-level chaining of operations
> between master and slave servers, the issues of nonces seemed important beyond merely the issue of linking one request to the initiating servers response to thwart replay. The party who generates
> the information element in the response may not be the party that provides it (once resigned) to the
> relying party. The nonce value says nothing about the timeliness of the information, only the issuing
> time of the signed response PDU; the source of response data, under X.500 reconstruction rules
> may be cached data held by the server as a slave or replicate of a master DSA responsible
> for the status-data DIB. (*)
>
>
> Today, for NR reasons, Id use a hash-tree (just like CRTs!) that is persistent and stored as part
> of the NR records showing the proper conduct of the server when acting for the relying party. The thing
> that has changed in 10 years is the realization that the server is really the agent of the
> relying party: its not a frontend of the CA. The server now needs to ensure that it
> can show it fulfilled its obligations under the relying party agreement/policy.
>
>
> (*) Careful configuration of multi-mastering replication, to assure the relying-party that cache
> attacks are not in place, is used to address this in modern X.500 versions, btw)

Not sure I see the need for the nonce hash tree you described, though it is a clever approach, but it also might run afoul of the time stamp patents of some folks.

It's up to a client to produce an example of a signed response from a sever which it maintains provided a "wring" answer, if I understand the context of your example. What is needed here is an ability to verify the context of the request and response, to ensure that later examination of response can be put into the proper time frame and parameter setting. If we allow reference to validation policies by reference, we'll have to make sure the reference includes a hash of the policy, to avoid problems. But, I bet we have several options ways to ensure that the client and server can later verify what the parameter set was, and we have a time stamping protocol to nail down the time context, as Denis has reminded us.

Steve