Subject: [sidr] some questions / comments on provisioning (up/down)

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 14 Jul 2010 11:05:21 +0200

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

---

From: Geoff Huston <[email-masked]>
Date: Wed, 14 Jul 2010 21:51:03 +1000

On 14/07/2010, at 7:05 PM, Tim Bruijnzeels wrote:

> 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

good call.

> requests? If so I suggest an additional error response in section 3.6:

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.

> code: 1104 - request scheduled for processing.
> 
> Also it would be good

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

Why wouldn't the server go slower and simply respond with

    1101          already processing request

?

> the server _could_ send clients an error response to this effect. E.g.

I'm not sure its an altogether good idea personally.

i.e. "DOS attack is working, keep it up" ?

regards,

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jul 2010 10:27:12 -0400

At 11:05 AM +0200 7/14/10, Tim Bruijnzeels wrote:
>...

I would say no.  Cert are revoked, not keys, so black-listing a key is
not an appropriate side effect of a cert revocation request.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 19 Jul 2010 15:27:52 +0200

Hi,

> conversation some years on.

I also asked this question in another email sent 26 May this year.
Without getting any response. I have been on the list for a while, but
have nothing on this in my archives and I can not find anything in the
online list archives either.

So if someone remembers I would appreciate some pointers.

As I said I think we can just re-use the existing 1101 code for this.
But.. it seems to me that this may be ambiguous. Also if we have an
explicit 'async' response, this will force clients to be able to handle
such a case.

>     1101          already processing request

well, I feel that would only be valid if it's actually processing the
requests. It may be that they are all different. In which case the
answer would be wrong. And it still takes processing power, see below..

I don't want to go slower, because then I am loosing connectors and the
pool is limited.

> i.e. "DOS attack is working, keep it up" ?

True. But as it is now the server is required to come up with some sort
of response anyway. So I think that might even be worse.

Would you suggest that we just drop the connection silently and don't
answer at all? If this is so, then maybe the draft should say something
about this. There could be false positives and clients should be aware
that this can happen.

I proposed the dedicated code because I figured we could bounce this
back when we see the same IP hammering us, without having to inspect the
actual request (which requires validating the CMS etc). However now that
I think about it a bit more, this would still require that we generate a
CMS for the response...

So to conclude: I think I would prefer an http status return in this
case to minimise server processing power. Maybe something similar to
validation failure in paragraph 3.2: HTTP 400 Bad Data

What do you think?

Cheers,
Tim