| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
The code that reads the access banner from file has been modified
to explicitly use UTF-8 encoding.
The Info class and the PKI UI have been modified not to encode the
access banner in Base64 since it is not necessary.
https://pagure.io/dogtagpki/issue/2671
Change-Id: I5f41a8ebac0bc91623b27f14608bca294bc9bc38
|
| |
|
|
|
|
|
|
|
|
| |
The Info service and client have been modified to transmit access
banner in Base64-encoded form. The PKI UI has been modified to
decode the access banner properly.
https://pagure.io/dogtagpki/issue/2671
Change-Id: Ic8526bac4c4d6b99e627aced64ab24cf675f5d50
|
| |
|
|
|
|
|
| |
The server is modified to read the new OIDs in the PKIArchiveOptions
and handle them correctly.
Change-Id: I328df4d6588b3c2c26a387ab2e9ed742d36824d4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: I862c86994e6268860380404113a9bea0d237d60e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
New REST services classes have been added to PKIApplication.
The InfoService provides general information about the server
including version number and access banner. The LoginService
provides a way to notify the server that the banner has been
displayed on the client, which in that case the InfoService
will no longer return the banner again in the same session.
https://fedorahosted.org/pki/ticket/2582
|
| |
|
|
|
| |
This is the dogtag upstream side of the TPS portion of this ticket.
This fix also involves an applet fix, handled in another bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TPS throws "err=6" when attempting to format and enroll G&D Cards.
https://bugzilla.redhat.com/show_bug.cgi?id=1320283
This fix addresses this bug , but also:
Fixes this issue:
Applet upgrade during rekey operation results in formatted token.
Also, it takes care of a related issue where the new apdu needed for the
lifecycle state causes the testing tool "tpslcient" to seg fault.
The fix here is a minimal fix to have tpsclient return an error when it gets
this apdu it can't handle, instead of crashing.
|
| |
|
|
|
|
|
| |
To discourage the use of policy framework, the framework classes
have been moved into org.dogtagpki.legacy.
https://fedorahosted.org/pki/ticket/6
|
| |
|
|
|
|
|
| |
This patch comments out unneeded data in TMS debug logs (TPS&TKS);
It reduces the size of the debug logs by a lot.
Note that for ease of later development debugging, the debug lines
are commented out instead of being removed
|
| |
|
|
|
|
|
|
| |
Ticket #1636.
Smartcard token enroll/format fails when the ldap user has special characters in userid or password
Tested with both esc and tpsclient. The problem was when using a real card because the client uri encodes
the authentication creds and the server needs to decode them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TokenService.setTokenStatus() has been modified to restore
the temporarily lost token back into either uninitialized or
active state based on whether the token has certificates.
The TPSTokendb.tdbGetCertRecordsByCUID() has been modified to use
only tokenID attribute to search for token certificates more
accurately. It also has been simplified to return the certificate
records collection object directly.
Some constructors were added to the TPSException to allow chaining
the exception cause.
https://fedorahosted.org/pki/ticket/1808
|
| |
|
|
|
|
| |
With the latest TPS the ESC auth dialog has displayed the password field before the UID field.
This patch addresses this in the simplest fashion by modifying the class that presents the field
data to the client to make sure that UID field is encountered first.
|
| |
|
|
| |
cards for ExternalReg This patch is mainly refactoring the names of the Mapping Resolver framework in preparation for ticket 1307 to support keySet mapping in addition to the original purpose of resolving tokenType mapping. The reason to separate out refactoring from the real code is for ease of reviewing. TPS is currently a Tech Preview feature, so upgrade is not of consideration at the moment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First cut of gp211 and scp protocol 02 for tokens.
Allow token operations using a GP211 token over secure channel protocol 02.
This patch supports the following:
1. Token operations with a GP211 card and SCP02 protocol, implementation 15.
2. Token still supports GP201 cards with SCP01.
3. SCP02 tested with SC650 gp211/scp02 card.
Things still to do:
1. Right now the SCP02 support has been tested with the current gp201 applet and
enrollment and formatting works just fine. We need to modify and compile the applet
against the GP211 spec and retest to see if any further changes are needed.
2. The nistSP800 key derivation stuff is not completed for the SCP02 protocol. Some
of the routines are self contained vs similar SCP01 ones. We have another ticket to
complete the nistSP800 support from end to end. This work will be done for that ticket.
3. One of the new scp02 deriviation functions can make use of a new NSS derive mechanism.
As of now this work is done by simple encryption, this can be done later.
4. The security APDU level of "RMAC" is not supported because the card does not support it.
It could have been done to the spec, but it having the card to test is more convenient and there
were more crucial issues to this point.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following features implemented for enrollment.
1. Standard enrollment of a list of RSA certificates.
2. Certificates are only done with token side keygen.
3. Minimual enrollment based pin reset functionality implemented to create
a pin for the enrolled token.
4. Much work done to the PKCS11 object code, which allows us to write the
compressed object blob to the token, allowing coolkey to access it and use
the certs and keys on the token.
5. Tested with Bob Relyea's "smartcard" utility to prove that signing and encryption
operations worked as expected.
6. Some work done to get authentication working with esc.
7. Added stub for stand alone Pin Reset processor.
8. CFU review fixes.
|
| |
|
|
| |
revoke/unrevoke processor
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. Changed the names of some message classes.
2. Did some minor refactoring of methods needed by both the enroll and tps processor.
3. Created classes to handle the parsing and archival of PKCS#11 token data.
4. Created prep code for enrollment that reads in a bunch of config params and creates
convenience objects to carry the data instead of lengthy parameter lists we have had before.
5. Code to generate key on token, tested tpsclient so far.
6. Additional review changes, and merging.
Review changes.
|
| |
|
|
|
|
|
|
|
| |
This patch provides the framework that allows people to
1. write their own authentication plugins using the authentication
plugin framework
2. map the authenticaiton credential from client side (e.g. ESC or alike)
in both display language characters and numbers of credential parameters
to the specified authentication plugin required parameters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following changes have been done:
1. Applet Upgrade for real token. The applet is written and an instance of applet created.
2. 95% of the format operation done. This includes proper status update progreass bar
for esc and writing the phone home url to the token. Once this operation is complete,
the token can be entered into esc and esc will be able to phone home and point to TPS
for further operations such as enrollment and pin reset when they are implemented.
3. The phoneHome xml file changed slightly to prevent esc from reading exttraneous line
feeds when phoning home.
4. The CS.cfg has been changed to correctly reflect the phone home url we want to write to
the token.
The following to be done to fully finish format, later tickets.
1.Updating the tokendb with tne newly formatted token. Future ticket.
2.Revoking tokens current certificates, if any. Future ticket.
3.Symmetric Key changeover. Future ticket.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows the current secure channel functionality to work with
both tpsclient and esc. In order to get esc to work the following changes
were needed.
1. It turns out the server has been been forcing chunked encoding format upon the
outgoing data. Turns out that the system already knows how to do this so we were
getting double chunk size values and getting twice the amount of CRLF chars.
2. There was a minor error where I was not attempting to select the card manager
applet but the coolkey applet, which does not exist yet.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. Read applet into memory to prepare to write to token.
2. With tpsclient create secure channel by implementing Initialize Update and ExternalAuthenticate messages.
3. Support for MAC and encryption for messages going on after secure channel has been created.
4. Implemented method to remove an aid file or instance from the token.
5. Added some symkey methods to allow TPS to manipulate session keys.
6. Performed some cfu feedback fixes such as changing al the names of APDU classes to have APDU in the name.
Have not tried this with real token as of yet. The tpsclient does verify of the MAC coming from the server and decrypts encrypted messages. Decrypted messages have to be correct for the MAC verification to work.
Next step will be to add the phone home servlet to the TPS and give it a try with a real token and esc.
|
| |
|
|
|
|
|
|
|
|
|
| |
1. Method to calculate the token type.
2. Some added convenience methods to get various config params for the Format operation.
3. More progress for the format operation up until we attempt to upgrade the applet.
4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client.
5. Error handling.
6. Get rid of TPSFormatProcessor class, for now.
7. More error handling.
8. Moving around some constants.
|
| | |
|
| |
|
|
|
|
|
| |
1. Change the location of some more of the classes.
2. Change the file names to reflect naming convention.
3. Change leftover method names to reflect convention.
4. Resolved some script building ommissions and build dependencies.
|
|
|
1. Change the location of some of the classes.
2. Change the file names to reflect naming convention.
3. Change some of the method names to reflect convention.
4. Variable naming changes to reflect convention.
|
