| | | | | | | | |
|
|
|
You're here: Home |
Continuing on the following:[Note that this mechanism could be used for another useful purpose: keeping the client defined, but denying issuance of new certificates, for example due to non-payment. The detailed data can still be kept in the BE, which is good - the only reflection of this on the protocol is the validity time. Alternatively, we can introduce another message/parameter for enabling/disabling new certificate issuance to this client.]
I propose to introduce the following message to signal the state of a child (BE->RE)
(set-child-state :self-id 42
:child deedee
:state enabled )
=> ()
Consequently, the RE can keep track of the child state, and accept/deny
the certificate requests from them.
I'm not sure that a get-child-state message is needed, but give the above, logically it belongs to the protocol too, and it's easy to implement.
Alternatively, the list-resources (RE->BE) message could have a response saying something like "suspended, don't issue now". I'm not sure this would be better, but it could be an option.
Robert