[Pki-devel] making CAInfoService reflect KRA configuration

[Ade Lee]

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