[PATCH] Ticket-2717-CMC-user-signed-enrollment-request.patch
by Christina Fu
https://pagure.io/dogtagpki/issue/2617
This patch provides implementation that allows user-signed CMC requests
to be processed; The resulting certificate will bear the same subjectDN
as that of the signing cert;
The new uri to access is /ca/ee/ca/profileSubmitUserSignedCMCFull where
the new profile is to be used: caFullCMCUserSignedCert.cfg which utilizes
the new authentication plugin: CMCUserSignedAuth and
new profile default plugin: CMCUserSignedSubjectNameDefault and
new profile constraint plugin: CMCUserSignedSubjectNameConstraint
A separate ticket will be filed to handle Non-pre-signed user cmc cert
requests.
thanks,
Christina
7 years, 7 months
[pki-devel][PATCH]
by John Magne
CA in the certificate profiles the startTime parameter is not working as expected.
This simple fix addresses an overflow in the "startTime" paramenter in 4 places in the code. I felt that honing in only on the startTime value was the best way to go. In some of the files other than ValidityDefault.java, there were possibly some values that could be changed from int to long. Due to the complexity of some of the calculations involved in some of those cases, it is best to fix the exact issue at hand instead of introducing some other possible side effects.
Tested with a simple enrollment in the caUserCert profile by setting the startTime constraint to the offending value listed in the ticket/bug. The correct start time 30 days in the future was calculated and made part of the cert.
Issue:
https://pagure.io/dogtagpki/issue/2520
7 years, 7 months
availability/behaviour of internal NSS token in FIPS mode
by Fraser Tweedale
or, "can I pretty please delete all this code?" ^_^
Hi Christina,
Ade has reviewed my PKCS #12 AES patches for CC effort (thanks Ade!)
We have one main area where we need your feedback.
The KRA PKCS #12 recovery process for encrypted (cf. wrapped) keys
previously performed the encryption and assembled the
EncryptedPrivateKeyInfo structure in a rather "manual" way (~80
LOC). In my patch to convert this code path to use AES encrypted, I
take an alternative (and much fewer LOC) approach: importing the
private key to the *internal* key storage token, as a *temporary*
key, and then invoking the same routine as is used for the wrapped
key case.
Our question: is this fine to do when the system is in FIPS mode?
The assumption is that the internal crypto token is always available
and that it can do raw (unencrypted) private key import, and
wrapping private keys to a symmetric key, while in FIPS mode. We
just need to check this assumption.
The gerrit review of the patch involved is here:
https://review.gerrithub.io/#/c/359027/
Thanks,
Fraser
7 years, 7 months
[PATCH] pki-0178, jss-0000..0002 - PKCS #12 key bag AES encryption
by Fraser Tweedale
Hi team,
Please review attached patches for JSS and Dogtag that:
- add some new EncryptedPrivateKeyInfo export and import functions
to JSS
- update Dogtag's `pki pkcs12' command to use the new functions to
achieve AES encryption of the key bags, with wrapping/unwrapping
occurring on the token.
PKCS #12 files produced by current releases continue to import
properly (of course, this is an important test vector).
These patches do not address the PKCS #12 KRA recovery export; This
is my next task and separate patches will be produced.
Thanks,
Fraser
7 years, 7 months
making CAInfoService reflect KRA configuration
by Fraser Tweedale
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
7 years, 7 months
