Hi all, I had another look at the up-down document. And I have a couple of comments / questions:
@3.4.1 Certificate Issuance Request “The client must use different key pairs for each distinct resource class” Is this a MUST, SHOULD? Or just a recommendation? MUST the server verify this? If so I suggest an additional error response in section 3.6: 1204 request - bad key. @3.5.1 Certificate Revocation Request SHOULD (MUST?) the server black list this key for future issuance requests? If so I suggest an additional error response in section 3.6: 1204 request - bad key @3.6 Request-Not-Performed Response This document is about the communication protocol not the actual implementation. However, for server implementations it may be useful to be able to do the following: 1) process requests asynchronously 2) throttle client requests ...@1: asynchronous processing A use case for this is when additional manual security checks such as FIPS-140-2 level 3 authentication are required to sign a certificate. We are running into this one now that we are thinking of using the provisioning protocol between our production CA and our local test TA CA. In this case it would be good if the server could respond with a dedicated code informing the client that the request has been received and okay’d but processing will take time. The existing code 1101 seems ambiguous. I would suggest an additional code: 1104 - request scheduled for processing. Also it would be good to include advisory text for the client. In this case I think the client should send the same request some time later, eg 24 hours. If the request has been performed by then it will get back the proper response. Otherwise the same error as above. @2: throttle requests It may prove necessary to throttle client access. For example if a client sets up an automated system (misconfigures), to see if new classes are available, and/or requests new certificates every five minutes.. this may cause a big load on a system. I think we lack practical experience to know for sure whether this is going to be problematic in the real world (and what an acceptable access rate should be), but on the protocol level I think it would be useful if the server _could_ send clients an error response to this effect. E.g. 1105 - too many requests . Cheers, Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
