On Fri, 2017-04-28 at 00:07 +1000, Fraser Tweedale wrote:
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?
No, its what the KRA supports for transport. What it uses internally for its storage mechanism is irrelevant. In the other java and python clients, I have been checking the KRA for its version (version >= 10.4 implies 1 (AES); else 0)
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).
No, see above, Check KRA version.
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 ^_^)
You can query the KRA version using the InfoService on the KRA (InfoClient). You will also need to determine whether or not we support encryption / key wrapping. That information is provided by the KRAInfoService on the KRA.
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.
Well .. no. The KRA information is only used when the cert request is processed - which can be done manually at a later time. If the KRA is unavailable, the request stays in the queue and can be manually acted on by an agent at a later time.
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.
I'm OK with this solution given that the data does not change often (if at all). I think though, that we need to change the default. If the KRA is not available on startup - or if we're talking to a KRA thats old and therefore does not have a InfoService or KRAInfoService, then we need to default to the lowest common denominator - which is DES3 + Keywrapping. This is guaranteed to always work. Ade
Thanks, Fraser