summaryrefslogtreecommitdiffstats
path: root/base/java-tools
Commit message (Collapse)AuthorAgeFilesLines
* Ticket #2616 CMC: id-cmc-statusInfo ==> id-cmc-statusInfoV2Christina Fu2017-06-232-28/+77
| | | | | | | | | | | | | | This patch contains the following update: * Structurely, CMCStatusInfo to CMCStatusInfoV2 update; no extendedFailInfo has been added at this point * In case of EncryptedPOP, instead of returning with CMCStatus pending where PendInfo contains the requestID, it now returns CMCStatus failed whith responseInfo control contains the requestID. On the client side, CMCRequest now processes the responseInfo and returns the DecryptedPOP with requestID in the regInfo control. CMCResponse has been updated to handle the new controls as well. * A number of fail info codes are now being supported by the server to add clarity to CMC failed status, including: badMessageCheck, badRequest, unsuportedExt, badIdentity, popRequired, and popFailed.
* Added pki ca-cert-status.Endi S. Dewata2017-06-172-0/+166
| | | | | | | | | | A new pki ca-cert-status CLI has been added to check certificate validity using OCSP. By default the CLI will use the CA's internal OCSP service. https://pagure.io/dogtagpki/issue/2652 Change-Id: I0fe3b2f1ca8c7979f9e5fa6d048be2c9883a875d
* Added search filter for pki ca-authority-find.Endi S. Dewata2017-06-171-2/+27
| | | | | | | | | | The pki ca-authority-find CLI has been modified to provide search filter based on the authority ID, parent ID, authority DN, and issuer DN. https://pagure.io/dogtagpki/issue/2652 Change-Id: I563a0b93eb7a00ae4771069812455ecc552f407c
* Fixed pki ca-cert-find and ca-cert-show output.Endi S. Dewata2017-06-151-7/+8
| | | | | | | | | The pki ca-cert-find and ca-cert-show output has been modified for consistency. https://pagure.io/dogtagpki/issue/2652 Change-Id: Ieb3550f7c18904ef26bc9a31529e2fa9a87de519
* Fixed initial audit log signature verification.Endi S. Dewata2017-06-151-15/+24
| | | | | | | | | | The AuditVerify has been modified to find the first signature properly and start the signature verification only after finding the first signature. https://pagure.io/dogtagpki/issue/2634 Change-Id: Ic35fc88e75173e65d8786bf7b62407fce0952f3e
* Fixed access banner normalization.Endi S. Dewata2017-06-141-1/+1
| | | | | | | | | | The PKIService has been modified to trim whitespaces in access banner before returning the value to the client. The clients have been modified to no longer trim the banner. https://pagure.io/dogtagpki/issue/2671 Change-Id: I51c5e78d11c89c711e369328def27bb352aa49e6
* Refactored AuditVerify (part 3).Endi S. Dewata2017-06-131-3/+18
| | | | | | | | | The AuditVerify.verify() has been cleaned up and some debug messages have been added for clarity. https://pagure.io/dogtagpki/issue/2634 Change-Id: Id1c510dd0081e3abb4fb34da0737ea6a3a335ba4
* Refactored AuditVerify (part 2).Endi S. Dewata2017-06-131-98/+142
| | | | | | | | | The code that performs the audit log verification in AuditVerify has been moved into a new verify() method. https://pagure.io/dogtagpki/issue/2634 Change-Id: Ic6d0f08b754feaac8779d7051e591ea03726df65
* Refactored AuditVerify (part 1).Endi S. Dewata2017-06-131-36/+49
| | | | | | | | | The code that retrieves and verifies the signing certificate in AuditVerify has been moved into a new setSigningCert() method. https://pagure.io/dogtagpki/issue/2634 Change-Id: I37b9d73a2ff162735359d2eed222296bbb1fcd60
* Add one more possible keywrap algorithm to usageAde Lee2017-06-081-0/+1
| | | | | | | | | Added one more key wrap algorithms to the CRMFPopClient usage statement. Part of BZ #1458047 Change-Id: Ic52410a6a23f850944a6b96385b26a9bba12b51a
* Add possible keywrap algorithms to usageAde Lee2017-06-081-0/+2
| | | | | | | | | Added possible key wrap algorithms to the CRMFPopClient usage statement to make it clear what options are available. Part of BZ #1458047 Change-Id: Ie49ec9cd9bbb5c112668469f701363b967695ef3
* Ticket #2619 Allow CA to process user-signed CMC revocation requestsChristina Fu2017-06-082-149/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First of all, the original CMC revocation only supports agent-signed CMC revocation requests from the UI where CMCRevReqServlet handles it with CMCAuth. It is in violation with https://tools.ietf.org/html/rfc5273 CMC Transport Protocols, as for HTTP/HTTPS, the body of the message is the binary value of the BER encoding of the PKI Request or Response,so HTML is not an approved method.The other way is through profileSubmitCMCFullServlet (or maybe not, as it was completely broken). One thing that's much less crucial, but goes along with rfc update is the name of the revocation request ASN1 structure. In the new rfc5272, it is now called RevokeRequest insead of RevRequest. This patch revamped the CMC revocation provision and fixing what's broken and adding what's missing. On the client side: CMCRequest - Commented out the code where it made an assumption to use OtherMsg for the signer information. This makes no sense as the outer layer SignedData would have the same information when signing happens. - removed the revRequest.nickname parameter from the configuration. From the code it seems like it expects the certificate to be revoked to exist in the user database, and it uses the same certificate to sign the revocation request. The RFC does allow for self-signed revocation, but it also allows for signing with another certificate provided that it has same subject. By removing the revRequest.nickname parameter, I am using the "nickname" parameter as the signer cert, which may or may not be the same certificate specified in revRequest.serial. It is less confusing. The change also eliminate the need for the cert to be revoked to be present in the db. In addition, revRequest.issuer only needs to be specified if revRequest.sharedSecret is used. The code will extract the issuer info from the signing cert. - added support for unsigned data in support of shared secret in both CMCRequest and server; The original code assumed that a cmc revocation request that relies on shared secret still requires agent signing. CMCRevoke - The original code assumed that the nss db password is the same as Shared Secret (!!). This patch added a "-t" to accept shred secret, and keep the -p for the nss db password. - The original code printed out b64 encoded request to the screen output as well as the file CMCRevoke.out. Both are unusable directly. This patch fixes it so that the output to the screen can be directly copied and pasted into the CMC revocate ui at ee (processed by CMCRevReqServlet); Again, this is not RFC conforming, but I fixed it anyways; - The output to the file CMCRevoke.out has been fixed so that it is the BER encoding of the request, which can be fed directly into the updated server that now conforms to the RFC (see below) - This code still requires the signer certificate nickname to run, making the shared secret method moot. Since CMCRequest has been updated to work properly, we can leave this for now. On the server side. CMCUserSignedAuth has been updated to handle unsigned DATA; Recall that the original CMC revocation only handled SIGNED_DATA (making assumption that agent always signs the requests). This addition is important to support shared secrets properly. Another thing that's important change on the server side is that it now checks the revoking cert's subject against the signer's subject, if authenticated by CMCUserSignedAuth. The original code did not do that, I think it is because it always checks if it's an agent or not. Something that could be improved on is to have its own servlet. However, due to the time restriction, I only updated existing EnrollProfile, ProfileSubmitCMCServlet, and CMCOutputTemplate to handle the rfc conforming cmc revocation requests. The shared secret handling is left in the CMCOutputTemplate for now. Logically it would make sense to go into CMCUserSignedAuth. This could be left as a possible later ticket for improvement. Shared Token plugin implementation will be added in later ticket as well. Previously missed signing cert validation is also added for more complete check. Some SHA1 are turned into SHA2 Finally, some auditing are added, but it is not finalized. It will be done in the next ticket(s).
* Stop using hardcoded IV in CMCAde Lee2017-06-081-5/+8
| | | | | | Bugzilla #BZ 1458055 Change-Id: I229d7f18c46f0b55ec83f051614de1b59e125b82
* Server side changes to correctly parse the new PKIArchiveOptionsAde Lee2017-06-071-5/+15
| | | | | | | The server is modified to read the new OIDs in the PKIArchiveOptions and handle them correctly. Change-Id: I328df4d6588b3c2c26a387ab2e9ed742d36824d4
* Refactor client to not use keysetsAde Lee2017-06-072-110/+77
| | | | | | | | | | | | | | | | | | It is simpler to simply tell the client which algorithm to use for key wrapping and encryption, rather than use key sets. Therefore: * KRAInfo and CAInfo are refactored to provide the algorithms required for key wrapping and encryption. * Client is modified to use these parameters to determine which algorithms to use. * We specify the OIDs that will be used in the PKIARchiveOptions more correctly. The options are basically: AES-128-CBC, DES3-CBC, AES KeyWrap/Pad Change-Id: Ic3fca902bbc45f7f72bcd4676c994f8a89c3a409
* Fixed default CA cert trust flags in pki CLI.Endi S. Dewata2017-06-031-2/+2
| | | | | | | | | The pki CLI has been modified to use CT,C,C as the default trust flags for CA certificate import operations. https://pagure.io/dogtagpki/issue/2726 Change-Id: I68c5a0303459319cc746a77703d0a420f4f68377
* Fixed pki client-cert-import CLI.Endi S. Dewata2017-06-031-28/+66
| | | | | | | | | The pki client-cert-import CLI has been modified to provide a password file when invoking the certutil -A command. https://pagure.io/dogtagpki/issue/2717 Change-Id: If32f9eeb39d140aaef38c9bc1933f3ae0f57a5a2
* Refactored CLI.runExternal().Endi S. Dewata2017-06-037-100/+65
| | | | | | | | | The methods for running external commands in various CLI classes have been merged into CLI.runExternal(). https://pagure.io/dogtagpki/issue/2717 Change-Id: I5b6d136db699d3bb48e4f36f7f187d0240bbbf62
* Refactored MainCLI.loadPassword() (part 3).Endi S. Dewata2017-06-031-12/+9
| | | | | | | | | The MainCLI.loadPassword() has been modified to use try-with- resources. Some log messages have been added for clarity. https://pagure.io/dogtagpki/issue/2717 Change-Id: Ic4950ba677613565f548b51d1f985177c6726510
* Refactored MainCLI.loadPassword() (part 2).Endi S. Dewata2017-06-031-24/+25
| | | | | | | | | The MainCLI.loadPassword() has been modified to fix the code indentation. https://pagure.io/dogtagpki/issue/2717 Change-Id: I7d208f1f4568f2fb1323ab206f45af5c0338b53f
* Refactored MainCLI.loadPassword() (part 1).Endi S. Dewata2017-06-031-11/+13
| | | | | | | | | | The method that loads password from a file in MainCLI has been renamed into loadPassword() and modified to return early for clarity. https://pagure.io/dogtagpki/issue/2717 Change-Id: I9b031c31040c2d00f04d9997abcdae38163bf6d5
* Convert CMC code to use AESAde Lee2017-05-311-2/+16
| | | | | | | | | | | | | | | * Switched out CrytoUtil calls that use DES and replaced them with AES equivalents. Removed these now unneeded methods. * Added 16 byte constant IV for AES operations. This must be replaced by a randomly generated IV. Added TODOs where IVs should be replaced. * Corrected misspellings of "enreypted" in both request fields and variable names * Removed some code from null checks where the result could never be null. These cases were flagged in eclipse as dead code. Change-Id: Iec0c0e86fd772af8b3c9588f11a0ea1e517776fb
* Ticket#2618 feature: pre-signed CMC renewal requestChristina Fu2017-05-221-6/+8
| | | | | | | This patch provides the feature implementation to allow CA to process pre-signed CMC renewal requests. In the world of CMC, renewal request are full CMC requests that are signed by previously issued signing certificate. The implementation approach is to use the caFullCMCUserSignedCert with the enhanced profile constraint: UniqueKeyConstraint. UniqueKeyConstraint has been updated to disallow renewal of same key shared by a revoked certificate. It also saves the origNotAfter of the newest certificate sharing the same key in the request to be used by the RenewGracePeriodConstraint. To not interfere with the existing "renewal by serial" flow, if an existing origNotAfter is found, it is not overwritten. The profile caFullCMCUserSignedCert.cfg has been updated to have both UniqueKeyConstraint and RenewGracePeriodConstraint. They must be placed in the correct order. By default in the UniqueKeyConstraint the constraint parameter allowSameKeyRenewal=true.
* Tocket2673- CMC: allow enrollment key signed (self-signed) CMC with identity ↵Christina Fu2017-05-173-72/+213
| | | | | | proof This patch implements the self-signed CMC requests, where the request is signed by the public key of the underlying request (PKCS#10 or CRMF). The scenario for when this method is used is when there was no existing signing cert for the user has been issued before, and once it is issued, it can be used to sign subsequent cert requests by the same user. The new enrollment profile introduced is : caFullCMCSelfSignedCert.cfg The new option introduced to both CRMFPopClient and PKCS10Client is "-y" which will add the required SubjectKeyIdentifier to the underlying request. When a CMC request is self-signed, no auditSubjectID is available until Identification Proof (v2) is verified, however, the cert subject DN is recorded in log as soon as it was available for additional information. Auditing is adjusted. More will come in the next couple CMC patches.
* PKCS12Util: use AES to encrypt private keysFraser Tweedale2017-04-292-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update PKCS12Util to use AES-256-CBC to encrypt private keys. Use JSS CryptoStore methods to ensure that all key wrapping and unwrapping is done on the token. Specifically, CryptoStore.getEncryptedPrivateKeyInfo replaces the previous process where a symmetric key was generated, the private key wrapped to the symmetric key, then decryted into Dogtag's memory, then re-encrypted under the supplied passphrase. Now the key gets wrapped directly to the supplied passphrase. Similarly, for import, the EncryptedPrivateKeyInfo was decrypted using the supplied passphrase, then encrypted to a freshly generated symmetric key, which was then used to unwrap the key into the token. Now, the new JSS method CryptoStore.importEncryptedPrivateKeyInfo is used to unwrap the EncryptedPrivateKeyInfo directly into the token, using the supplied passphrase. As a result, the PKCS12KeyInfo class, which previously stored unencrypted key material (a PrivateKeyInfo object), it now only deals with PrivateKey (an opaque handle to an PKCS #11 object) on export and encoded (byte[]) EncryptedPrivateKeyInfo data on import. This split suggests that PKCS12KeyInfo should be decomposed into two classes - one containing a PrivateKey and the other containing a byte[] encryptedPrivateKeyInfo - but this refactoring is left for another day. Part of: https://pagure.io/dogtagpki/issue/2610 Change-Id: I75d48de4d7040c9fb3a9a6d1e920c191aa757b70 (cherry picked from commit 2e198ddbe9ec5000ee7e14df0aa364b600d3aa92)
* Ticket #2717 CMC user-signed enrollment requestChristina Fu2017-04-281-1/+1
| | | | | | | | | | | 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
* Modify cert clients to check server for wrapping paramsAde Lee2017-04-192-19/+84
| | | | | | | | | | | | | 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
* Ticket #2614 CMC: id-cmc-popLinkWitnessV2 feature implementation This patch ↵Christina Fu2017-04-133-44/+446
| | | | provides the feature for CMC on handling id-cmc-popLinkWitnessV2
* Modified CRMFPopClient to use correct wrapping for encrypt caseAde Lee2017-04-122-8/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Deprecated -t option for pki CLI.Endi S. Dewata2017-04-101-4/+6
| | | | | | | The MainCLI has been modified to generate a deprecation warning for the -t option. Change-Id: I28ac45954a900f6944528ef52913982d72896c92
* Fixed pki user and group commands.Endi S. Dewata2017-04-102-2/+4
| | | | | | | | | The UserCLI and GroupCLI have been fixed to use the subsystem name in the client configuration object if available. https://pagure.io/dogtagpki/issue/2626 Change-Id: Ibf099cefe880a238468fad7fb2aabc9cc2d55c1f
* Added CLIs to access audit log files.Endi S. Dewata2017-04-043-0/+188
| | | | | | | New pki audit commands have been added to list and retrieve audit log files. Change-Id: I785fa6f55d9b143f513d9210ebf82d04e06eaed5
* Added PKIRESTProvider.Endi S. Dewata2017-04-041-7/+0
| | | | | | | A new PKIRESTProvider has been added to send and receive StreamingOutput object through REST API. Change-Id: Iefc513aacb9fc26bc7c8c5cbfb4550a4a98da52e
* Added audit service and CLI to all subsystems.Endi S. Dewata2017-04-044-0/+8
| | | | | | | Previously the audit service and CLI were only available on TPS. Now they have been added to all subsystems. Change-Id: I3b472254641eb887289c5122df390c46ccd97d47
* Fix generation of CRMF request for ECC keysAde Lee2017-04-031-15/+1
| | | | | | | | | | | Old CRMFPopClients add the OID for ECC public keys in the encryption algorithm OID for no obvious reason (considering the OID was never read on the server side to begin with). Now that we do read and use that field, we need to set it properly, and also special case on the server side to handle old clients. Change-Id: I0d753e572206e9062746c879ce683978e5e657bd
* Refactored AuditCLI.Endi S. Dewata2017-03-311-3/+7
| | | | | | | The AuditCLI has been modified to create the AuditClient with lazy initialization. Change-Id: I61b08e92a2f2de983fc77513dde89e1d5e1254b9
* Fixed default subsystems for top-level CLI commands.Endi S. Dewata2017-03-315-10/+39
| | | | | | | | | | The top-level CLI commands have been modified to get the subsystem name from the parent subsystem CLI if available, otherwise they will use a hard-coded default value. https://pagure.io/dogtagpki/issue/2626 Change-Id: Ieef45abfdfb4a6fc63fd06a6ccda4e70366de4a0
* Fix retrieval for symmetric keysAde Lee2017-03-281-1/+1
| | | | | | | | | | | | | 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
* Bug 1419742: CMC RFE: provide Proof of Possession for encryption cert ↵Christina Fu2017-03-283-242/+683
| | | | requests CMC encryptedPOP and decrypedPOP (Phase 1) also disable lraPOPwitness This patch implements the Proof of Possession for encryption only keys. This is a preliminary implementation with limitations. It does not support more than one request. ECC keys are untested. This version only uses default algorithms at some internal places. Not all limitations are listed here.
* Bug 1419734 CMC: id-cmc-identityProofV2 feature implementation This patch ↵Christina Fu2017-03-281-5/+179
| | | | 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
* Refactored TPS ConnectorCLI.Endi S. Dewata2017-03-286-9/+22
| | | | | The TPS ConnectorCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored TPS TokenCLI.Endi S. Dewata2017-03-286-9/+23
| | | | | The TPS TokenCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored TPS ProfileCLI.Endi S. Dewata2017-03-286-9/+22
| | | | | The TPS ProfileCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored TPS ConfigCLI.Endi S. Dewata2017-03-283-5/+12
| | | | | The TPS ConfigCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored TPSCertCLI.Endi S. Dewata2017-03-283-5/+12
| | | | | The TPSCertCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored AuthenticatorCLI.Endi S. Dewata2017-03-286-9/+22
| | | | | The AuthenticatorCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored AuditCLI.Endi S. Dewata2017-03-283-6/+13
| | | | | The AuditCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored ActivityCLI.Endi S. Dewata2017-03-283-5/+12
| | | | | The ActivityCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored TPSConnectorCLI for TKS.Endi S. Dewata2017-03-276-8/+21
| | | | | The TPSConnectorCLI for TKS and its submodules have been modified to use lazy initialization to get the PKIClient object.
* Refactored SelfTestCLI.Endi S. Dewata2017-03-274-7/+16
| | | | | The SelfTestCLI and its submodules have been modified to use lazy initialization to get the PKIClient object.
generated by cgit (git 2.34.1) at 2024-06-06 09:16:56 +0000