On 14/07/2010, at 7:05 PM, Tim Bruijnzeels wrote:
> 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,
That text was written a long time ago. As I recall the intent of that sentence
was to avoid a name clash when using object names that are derived from the
hash of the subject's public key, but I cannot recall off hand the precise
circumstances.
So I believe that was 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.
>
good call.
>
>
> @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
>
>
I don't believe so. If the issue here is a potential name clash when using
object names derived from the hash of the public key, then the above constraint
is all about simultaneous use of the same key across multiple resource classes.
>
>
> @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.
>
>
This synchronous / asynch issue was last discussed about two years ago. I
have some (indistinct) memory about issues over synchronization over issuance
and revocation requests, but I'm not sure I can accurately reproduce the
conversation some years on.
>
> @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.
>
>
Why wouldn't the server go slower and simply respond with
1101 already processing request
?
>
> 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
> .
>
I'm not sure its an altogether good idea personally.
i.e. "DOS attack is working, keep it up" ?
regards,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
