[Pki-devel] making CAInfoService reflect KRA configuration

Fraser Tweedale ftweedal at redhat.com
Thu Apr 27 14:07:07 UTC 2017


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




More information about the Pki-devel mailing list