9:07 a.m.
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
9:32 a.m.
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
2804
days inactive
2804
days old
1 comments
2 participants
participants (2)
-
Ade Lee -
Fraser Tweedale