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 _______________________________________________ Pki-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/pki-devel
