| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new CertRequestProcessedEvent constructor has been added to
encapsulate CERT_REQUEST_PROCESSED events that take an X509CertImpl
object.
Copies of auditInfoCertValue() method in various classes have been
combined and moved into CertRequestProcessedEvent.
https://pagure.io/dogtagpki/issue/2636
Change-Id: Ie234bdb9f1b52399dad4bd1e20f57dcb99d86091
|
|
|
|
|
|
|
|
|
| |
A new SignedAuditConfigRoleEvent class of has been added to
encapsulate the CONFIG_SIGNED_AUDIT events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: I95b897fa0bb73007a7cec009c43ade4cc860f0cd
|
|
|
|
|
|
|
|
|
| |
A new CertRequestProcessedEvent class of has been added to
encapsulate the CERT_REQUEST_PROCESSED events.
https://pagure.io/dogtagpki/issue/2636
Change-Id: Ia79e6ae13d09a3ec6509c60435fc24d5a2fee38f
|
|
|
|
|
|
|
|
|
| |
A new ConfigRoleEvent class of has been added to encapsulate the
CONFIG_ROLE events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: Ie0932131d75897f58afdd8217454c6cf6970d738
|
|
|
|
|
|
|
|
|
| |
A new RoleAssumeEvent class of has been added to encapsulate the
ROLE_ASSUME events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: I12e47ea13198b6532b1fdfee2e20765c0cab15e9
|
|
|
|
|
|
|
|
|
| |
A new AuthzFailEvent class of has been added to encapsulate the
AUTHZ_FAIL events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: Id4ab9bd889a1a9314264c0ef2ff7b2389aed8f9c
|
|
|
|
|
|
|
|
|
| |
A new AuthzSuccessEvent class of has been added to encapsulate the
AUTHZ_SUCCESS events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: I2f45fb2c3ba8acdc82777644cf4ad0ec2eff35a5
|
|
|
|
|
|
|
|
|
| |
A new AuthFailEvent class of has been added to encapsulate the
AUTH_FAIL events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: I870398f6a56df007c9520e50947a7b3c85baf79b
|
|
|
|
|
|
|
|
|
| |
A new AuthSuccessEvent class of has been added to encapsulate the
AUTH_SUCCESS events.
https://pagure.io/dogtagpki/issue/2641
Change-Id: Ie7cc751728ac079e30ece354ca44c5266474bcd3
|
|
|
|
|
|
|
| |
The IAuditor has been modified to define a log() method for
AuditEvent object.
Change-Id: Ie1ad720bd6d3bcd71a4567eed477f0e34a8274c9
|
|
|
|
|
|
| |
A new method has been added to set AuditEvent's parameters.
Change-Id: I1b1e23030a819160b035ed67e908b6fbadedd714
|
|
|
|
|
|
|
|
| |
When an exception is thrown, the connection is currently
not closed, leading to Invalid State exceptions when the
next connection is attempted. This resolves this issue.
Change-Id: I531881434a73affb1c6536dfbb05bce151c854fb
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CRMFPopClient and the pki cert client both can send a CRMF request
to a CA directly. Logic is added to check the CA for the required
KRA wrapping params and use those in place of any that have been
provided by the environment or command line.
Also, additional data for the supported KRA keyset has been added to
the CAInfoService. This will need to be managed by the admin. The
default is "1" which corresponds to AES.
Change-Id: I186f9c610005ec300bccf1b07470493ce7cdfeb4
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a certificate request comes with additional data in the
'cert-request' query param, add that to the request. Profile
components can then use this data.
This is needed to convey the subject principal name to the
ExternalProcessConstraint, when validating FreeIPA certificate
requests after we switch to GSS-API authentication.
Part of: https://pagure.io/dogtagpki/issue/1359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit added a field in the KeyRecord to
specify whether or not a key was encrypted or key wrapped
when archived. This patch modifies the recovery servlets
to use this field to determine how to decrypt/unwrap the
key for transport.
Absence of this field in the key record implies that is
an old record - and we use the value of the CS.cfg parameter
as the default.
Change-Id: Ia8ae679e8b3fe8462d42848d614bff863ef68e50
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whether a secret was encrypted or wrapped in the storage unit
depends on a parameter in CS.cfg. If that parameter is changed,
the Storage unit may use the wrong mechanism to try to decrypt
the stored key. Thats ok for encrypt/wrap using DES or AES-CBC,
but not for AES KeyWrap.
In this patch, we add a field in the Key record to specify whether
the secret was encrypted with stored (or keywrapped if false).
A subsequent patch will change the logic when decrypting to use
this field.
Change-Id: If535156179bd1259cfaaf5e56fd4d36ffdb0eb0e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keys (like symmetric keys and asymmetric keys) are returned
from the KRA either encrypted or key wrapped. Because the
AES keywrapping algorithm cannot be decrypted using AES CBC,
we need special logic to unwrap the keys.
The flow here is as follows:
1. When a key retrieval request is sent to the server,
the client sends the encryption and key wrapping
algorithms it requires the key to be wrapped along
with the wrapping key.
2. If no encryption algorithm or key wrap algorithm is
recieved, the server assumes its talking to an old
client and uses DES3.
3. The key is retrieved and (on server's choice) is wrapped
or encrypted. The return package will have either
encryption or key wrap algorithm set (depending on how
the key was encrypted/wrapped.)
4. client uses that to determine how to unwrap key.
This patch:
1. Makes sure the key wrap algorithm requested by client
is passed through and used to wrap the retrieved key.
2. Adds logic in the python client to unwrap/decrypt.
3. As python-cryptography does not yet support
AES KeyWrap with padding, the python client is configured
to request AES-CBC by default.
Change-Id: I4ba219bade821249b81e4e9a088959c27827ece1
|
|
|
|
|
|
|
| |
The CMS.getLogMessage() has been generalized to take an array of
Objects instead of Strings.
Change-Id: Ifcb96d47983a67961efa27325b8ae0a88d9e0231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the server cannot do key wrapping using the AES KeyWrap,
probably because the backend HSM cannot do key wrapping, then
there is a setting to allow it to use encrypt/decrypt instead.
If the key wrap algorithm is something simple like 3DES or AES-CBC,
then the client can just use key wrapping to wrap the key on its
token, and the server can use an encryption algorithm to decrypt.
The client does not need to know that the server cannot handle a
key wrap, because keywrapping and encryption are pretty much the
same mechanism - just either in server memory or not.
When we do key wrapping using AES KeyWrap though, there is no
corresponding encryption algorithm used to decrypt. So the server
cannot simply decrypt a message wrapped with AES Keywrap (or at least
not in any obvious way). So in this case, the client needs to know
if the server can handle keywrap.
The patch therefore does the following:
1. For CRMFPopClient, adds a command line option to specify if key
wrapping or encryption is required.
2. Reads an environment variable if no option is provided.
3. If encryption is specified, uses key wrapping using AES-CBC
which can be decrypted on the server side.
4. For cert-client, contacts the server to determine from the
CAInfoResource if keywrapping is supported.
Change-Id: If66f51c929cfde1c0ff3b9f39cb57b92fcdc150c
|
|
|
|
| |
Change-Id: Ie05572677de0e8eb1244dc6caf2b4a48514a2542
|
|
|
|
| |
Change-Id: Ib4586443f7e6f759d227975f9736cdd30b8f32e8
|
|
|
|
| |
Change-Id: I407a7a13c4e428e01632536faa27583e7c6d577e
|
|
|
|
| |
Change-Id: Iade8cb7fdf3c3f93afb13ff814da0f72dc8f8049
|
|
|
|
| |
Change-Id: I3eb97554a1d0f4b86c981692ab0130b28c9c5288
|
|
|
|
| |
Change-Id: I7fee37c8369945c6aedae78bd56063bc4488c0f7
|
|
|
|
| |
Change-Id: Ic4a79b0c73812c7b89daca3c804e6a88c738536a
|
|
|
|
| |
Change-Id: Id7845ebf2a14cebe25189a8363cee759030a16cb
|
|
|
|
| |
Change-Id: I73b3a69ffc289ad6bf89eebaa2d95237df25551f
|
|
|
|
|
|
|
|
|
|
| |
This resource (which will be accessed at /ca/rest/info)
will initially return the mechanism for archival.
This is needed by clients to know how to package secrets when
archiving. We may add the transport cert later.
Change-Id: Ib13d52344e38dc9b54c0d2a1645f1211dd84069b
|
|
|
|
|
|
|
|
|
|
| |
This resource (which will be accessed at /kra/rest/info)
will initially return the mechanism for archival or retrieval.
This is needed by clients to know how to package secrets when
archiving.
Change-Id: I6990ebb9c9dafc4158e51ba61a30e773d1d953ec
|
|
|
|
|
|
|
|
|
|
| |
To help troubleshooting the PKIConnection has been modified to
register an SSL socket listener which will display SSL alerts
that it has received or sent.
https://pagure.io/dogtagpki/issue/2625
Change-Id: I8f2e4f55a3d6bc8a7360f666c9b18e4c0d6c6d83
|
|
|
|
|
|
|
| |
New pki audit commands have been added to list and retrieve audit
log files.
Change-Id: I785fa6f55d9b143f513d9210ebf82d04e06eaed5
|
|
|
|
|
|
|
| |
A new PKIRESTProvider has been added to send and receive
StreamingOutput object through REST API.
Change-Id: Iefc513aacb9fc26bc7c8c5cbfb4550a4a98da52e
|
|
|
|
|
|
|
| |
The AuditCLI has been modified to create the AuditClient with lazy
initialization.
Change-Id: I61b08e92a2f2de983fc77513dde89e1d5e1254b9
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up to now, we have only ever used the same algorithm (DES3_CBC)
for key wrapping and encryption. With the change to use AES Keywrap
and AES CBC, we need to know which mechanism was used to encrypt/wrap
the secrets when returned to the client.
This means passing back more information to the client with the key
data, and also modifying the client to use this information to decode
the data correctly.
Change-Id: I7232085c1eedf38c63abad81db08acc912fa1da1
|
|
|
|
| |
adds both client and server support for two cmc controls: id-cmc-identityProofV2 - for supporting RFC5272, and id-cmc-identification - for assisting in shared secret search; Note: for client, only CMCRequest is updated in this patch
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CMSStartServlet has been modified to register an SSL socket
listener called PKIServerSocketListener to TomcatJSS.
The PKIServerSocketListener will receive the alerts generated by
SSL server sockets and generate ACCESS_SESSION_* audit logs.
The CS.cfg for all subsystems have been modified to include
ACCESS_SESSION_* audit events.
https://pagure.io/dogtagpki/issue/2602
Change-Id: If7fb6c1b096ec8c68d1fd08f9132baf099816f11
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the storage unit reuses the same IV each time a record
is stored. This works (probably) for DES3, but not for AES.
The getWrappingParams() method is modified to check the config as follows
(in order):
-- if the iv is defined, use that iv
-- if the length is defined, generate a byte array of that length
-- return null
To ensure that the same IV used to encrypt the secret is stored in the
DB, the wrapping param is defined once in the archival process, and
passed in to the wrapping functions in storageUnit.
Change-Id: Ia6696adf56fc7a4e90f83948c7549b64a38ab854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Refactor code in CryptoUtil to parametrize the algorithms used.
* Moved WrappingParams to utils jar to allow correct compilation.
* Removed code that created a PKIArchiveOptions structure from
CRMFPopClient and replaced with calls to CryptoUtil methods.
Note that the algorithms have been left as DES3. They will be
changed to AES in the next patch.
* Converted code in AuthorityKeyExportCLI to use the new methods
in CryptoUtil.
* Removed DRMTest this code is no longer maintained or used.
Change-Id: I8f625f0310877dca68f6a01285b6ff4e27e7f34a
|
|
|
|
| |
Change-Id: I862c86994e6268860380404113a9bea0d237d60e
|
|
|
|
|
|
| |
Also used the infoClient in the KeyClient
Change-Id: Ie81ee731903cf8d2068783a9a09cdcbaaffc0630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Changed the client to use AES-128-CBC-PAD rather than DES-3.
Because AES-256-CBC-PAD has no OID defined, we use the following
hack:
* Pass in the AES-256-CBC OID as the encrypt algorithm OID
* Use PKCS#1.5 Padding.
* Changed the client to use AES for the wrapping key on retrieval.
* Changed the server to implicitly assume PKCS#1.5 (and a key size
of 128) when recieving the OID for AES.
* Changed the client to send, and the server to pass through
the encryption algorithm expected when retrieving the key.
* Fixed the generate_iv() function to generate an appropriately
sized IV on retrieval.
This code has been tested to successfully create and retrieve
secrets using AES. Ideally, we'd be using GCM rather than CBC,
which then requires no padding - and no hack needed. Hopefully,
we can get that working in a subsequent commit.
Change-Id: Ic9e8d50169be0fe357a48a5a1b1c452c7a3dfad0
|
|
|
|
|
|
| |
This patch provides methods that can be shared between the CA and the ISharedToken plugins:
1. the convenience routines for quick encryption, decryption, hashing methods that take default algorithms.
2. The establishment of Issuance Protection Certificate
|
|
|
|
|
|
|
| |
To prevent conflicts, the code that configures the default SSL
version ranges and ciphers for all SSL sockets created afterwards
has been moved out of PKIConnection into the main program (i.e.
PKI CLI).
|
|
|
|
|
| |
The duplicate code for configuring default SSL version ranges has
been merged into reusable methods in CryptoUtil.
|
|
|
|
|
|
|
|
|
|
| |
Wrapping params can now be specified in CS.cfg as per design.
The default will be AES. If the parameters are not set, then the
old mechanism (DES) will be used instead.
A migration script will be created in a separate commit.
Change-Id: I01a74b99c4ed127d66e5b766357af59a1147839d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many parts of Dogtag expect an IAuthToken, which represents the
authenticated user. The sole implementation, AuthToken, uses some
concepts that do not carry across to externally authenticated
principals, e.g. an external principal does not have an associated
IAuthManager that was used to authenticate the principal. Therefore
something different is needed.
Implement ExternalAuthToken which wraps a GenericPrincipal and
provides access to the data therein.
Part of: https://pagure.io/dogtagpki/issue/1359
|
|
|
|
|
|
|
|
|
| |
Small refactor to define the auth token keys set by
AgentCertAuthentication in IAuthToken, so that consumers do not need
to import AgentCertAuthentication directly, or redefine the
constants.
Part of: https://pagure.io/dogtagpki/issue/1359
|
|
|
|
|
| |
A new constructor has been added into EInvalidCredentials to
support exception chaining.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Developer keyset token operations and key change over supported.
Caveats.
-The diversification step going from master key to card key uses DES3 as required for the token.
-After that point, everything is scp03 to the spec with minor excpetions so far.
Supports 128 bit AES for now. Will resolve this.
Minor config tweaks:
TPS
Symmetric Key Changeover
Use this applet for scp03:
RSA/KeyRecovery/GP211/SCP02/SCP03 applet : 1.5.558cdcff.ijc
TKS:
Symmetric Key Changeover
tks.mk_mappings.#02#03=internal:new_master
tks.defKeySet.mk_mappings.#02#03=internal:new_master
Use the uncommented one because scp03 returns a different key set data string.
ToDo:
-Support the rest of the AES sizes other than 128.
-Support optional RMAC apdu.
-Test and adjust the config capability for other tokens.
-Support AES master key. Right now the standard key ends up creating AES card and session keys.
|