7:32 a.m.
Hi team,
Lightweight CA key replication is taking shape. I have updated the
design page with juicy details:
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#Key_replication
Could interested parties and Simo please eyeball it. Simo, I
particularly want your feedback on feasibility / implications of
creating a Kerberos principal for each CA replica which will be
authorised as a Custodia client to retrieve sub-CA signing keys.
Alternatively, instead of adding another principal could we use the
existing HTTP/<hostname>@<realm> principal as the Custodia client?
I entertained implementing TLS certificate authentication for
Custodia so that we could authenticate using e.g. CA subsystem cert
but felt that GSS-API would be a smoother path, becaues we already
have Python client code for IPA.
The implementation is in-progress; most of the core Java bits are
done, but not yet the IPA-specific KeyRetriever implementation nor
the Python helper program.
Cheers,
Fraser
P.S. I made a number of other updates to the design page - mostly
updates to bring it in line with what's already been implemented.
7:48 a.m.
On Tue, 2016-03-29 at 22:32 +1000, Fraser Tweedale wrote:
Hi team,
Lightweight CA key replication is taking shape. I have updated the
design page with juicy details:
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#Key_replication
Could interested parties and Simo please eyeball it. Simo, I
particularly want your feedback on feasibility / implications of
creating a Kerberos principal for each CA replica which will be
authorised as a Custodia client to retrieve sub-CA signing keys.
Alternatively, instead of adding another principal could we use the
existing HTTP/<hostname>@<realm> principal as the Custodia client?
The way we deal with it in the replicas case we have double
authentication (and I'd like to keep it that way in the CA case too).
The GSSAPI authentication is the first gate to get access to the service
at all and to identify which replica is asking for keys.
The second gate is a public/private key pair stored in LDAP and
associated with a principal. This pair of kys is used to encrypt and
sign the requests (and conversely the providing server keys are used
to sign/encrypt the response).
I entertained implementing TLS certificate authentication for
Custodia so that we could authenticate using e.g. CA subsystem cert
but felt that GSS-API would be a smoother path, becaues we already
have Python client code for IPA.
Yes it will be smoother given it is already in place.
But x509 auth would be feasible too, it would be terminated in the main
apache instance though, as custodia only listen locally and it is
proxied in via apache.
The implementation is in-progress; most of the core Java bits are
done, but not yet the IPA-specific KeyRetriever implementation nor
the Python helper program.
Cheers,
Fraser
P.S. I made a number of other updates to the design page - mostly
updates to bring it in line with what's already been implemented.
Keep in mind that if you use the same nssdb where the other CA keys are,
you do not need to implement anything new on the server side, just
specify the nick name of they you want to pull and you'll be able to
pull those keys.
Simo.
3189
days inactive
3189
days old
1 comments
2 participants
participants (2)
-
Fraser Tweedale -
Simo Sorce