Hi Ade et al, A few quick questions / requests for comment about the KRA/CA config effort.
1. The CAInfoService currently returns value of ca/CS.cfg:kra.wrappingKeySet as attribute 'WrappingKeySet' (defaulting to 1). This value is supposed to be the same as kra/CS.cfg:kra.storageUnit.wrapping.choice, correct? 2. If that is correct, I suppose I should extend KRAInfoService to include the WrappingKeySet in its response, and the CAInfoService should reflect that (just as it will reflect the 'ArchivalMechanism' advertised by the KRA). 3. I've had a quick look at the IConnector / HTTPConnector interface. There doesn't seem to be a good way to send a simple REST request. I intend to just get the KRAConnectorInfo via KRAConnectorProcess.getConnectorInfo(), and use that info to send a request to the KRA's /kra/rest/info. Unless there is a better way that I do not know about yet! (If so, do tell ^_^) 4. Regarding availability of the data: I propose that we ONLY obtain the info via the KRA. Rationale: if the KRA is not available, the (presumably) imminent request involving the KRA will fail (or at least, not be fully successful) if the KRA is not available. Therefore it is not harmful to fail at the CAInfoService stage. 5. Regarding caching of the data: the KRA configuration concerned is likely to be changed seldom if ever, and changing it is a manual process. Therefore we can cache it in CAInfoService for the lifetime of the CA subsystem process. If the KRA is a separate instance and its configuration changes, this necessitates restarting the CA instance, but for reasons just stated I do not think this is an unreasonable imposition. It just needs to be documented. Thanks, Fraser _______________________________________________ Pki-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/pki-devel
