At 2:50 PM +0900 11/11/09, Jim Schaad wrote:
1. Should this document update the mandatory set of algorithms that OCSP responders much support. I do not remember seeing that this had been done anywhere. Given that the last step in section 4.1 is to use a mandatory algorithm, upgrading the set of mandatory algorithms at this point in time would be a good idea.
good idea if we get quick agreement on the upgraded set of mandatory algorithms.
2. The sentence "This requirement is clearly insufficient to ensure interoperability." Should probably end w/ agility rather than interoperability. With one mandatory algorithm there is easily the ability to have interoperability.
OK.
3. For the definition of sigIdentifier - are the parameters always absent or just in this case?
Stefan?
4. s/certtIdentifier/certIdentifier/
OK
5. Old Although this case does not permit the responder to make use of the client data directly, the responder may anticipate the client request and generate a set of signed responses so as to maximize the probability that it is possible to generate a response that is assigned the highest preference weighting following the selection logic in 4.1. Suggested new: The case may not permit the responder to make use of the client request data during the response generation, however the responder still uses the client request data during the selection of the pre-generated response to be returned. Responders may use the historical client requests as part of the input to the decisions of what different algorithms should be used in signing algorithms should be used in creating the pre-generated responses.
OK.
6. I wonder if a security consideration should be added to address the question of a DoS attack on the client by either changing the request data or by not being able to get a match with the server on what algorithms can/should be used for the signing process. Esp w/ cached responses.
good idea.
7. You are generating ASN.1 that is new - you need to have a new ASN.1 module as part of this document.
right. Steve
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.