[pki-devel][PATCH] 0024-Ticket-TPS-Rewrite-Implement-Secure-Channel-Protocol.patch
by John Magne
Subject: [PATCH] Ticket: TPS Rewrite: Implement Secure Channel Protocol 02
(#883).
First cut of gp211 and secure channel 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.
4. Formatting ,e nrollment, and pin reset tested to work.
5. Symmetric key changeover upgrade and downgrade tested to work.
6. APDU security methods of CMAC and Encryption supported, as well as the combination
of the two.
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.
5. Right now the security apdu level is set hard coded to the max supported level for scp01 and 02.
Need to make that more configurable, although there is no reason to downgrade the apdu security.
9 years, 7 months
RAEnrollProfile class; no longer needed?
by Fraser Tweedale
On master, I see no references to RAEnrollProfile outside the
definition of the class itself. Can it be removed? Read on for
context.
I need to modify CAEnrollProfile to populate the certificate Issuer
Subject Name with the DN of the appropriate CA. Possible options
are.
- Change the signature of abstract method ``X500Name
getIssuerName()`` to take a "sub-CA reference" argument. I will
have to modify subclasses (CAEnrollProfile and RAEnrollProfile)
accordingly.
- Implement precisely the logic I need in the 'setDefaultCertInfo'
instead of a call to 'getIssuerName()'
- Remove RAEnrollProfile if it is not needed any more, and merge
EnrollProfile and CAEnrollProfile (it will no longer be abstract).
Update 'getIssuerName' to take "sub-CA reference" argument.
Regards,
Fraser
9 years, 7 months
[PATCH] pki-cfu-0044-ticket-822-creates-root-CA-subject-DN-when-renewing-.patch
by Christina Fu
This is a small patch for
https://fedorahosted.org/pki/ticket/822 rhcs81 caManualRenewal with
original profile modified for empty params.name creates root CA subject DN
I am actually not able to reproduce the reported issue on either latest
Dogtag or RHCS8.1, possibly due to some other fix on
SubjectNameDefault. However, the investigation showed that a cert's
subjectName has always been initialized to the issuerName. To avoid
future possible errors in newer profile plugins, I am changing the
initialization to "CN=null".
thanks,
Christina
9 years, 7 months
[PATCH] Ticket#1028 Phase1:TPS rewrite: provide externalReg functionality
by Christina Fu
attached please find the Phase 1 code for
https://fedorahosted.org/pki/ticket/1028
Ticket#1028 TPS rewrite: provide externalReg functionality
Due to a recent change of task priorities, I am to check in this feature
in two phases (coming back to phase 2 at a later time).
In this Phase 1, the code for this feature is in place, but may not be
in the most optimal condition.
The goal for Phase 1 is to:
1. not break existing functionality (non ExternalReg -- which is default)
2. when ExternalReg is turned on, it works for the basic case (didn't
test for more complicated cases)... e.g. I don't know if say an existing
cert on the token is missing from the externalReg user record, whether
it will be removed or not.
3. it is not guaranteed to work with more complicated scenario
4. code has been run through and cleaned up in Eclipse
Later, for Phase 2:
1. really clean up and add bells and whistles (more error checkings, more efficient code,
proper logging, etc.)
2. test/cover all cases
Jack has already helped testing it with a real token with ExternalReg turned off (didn't seem to break the existing functionalities);
Jack has also helped testing it with a real token with ExternalReg turned on for simple enrollment/recovery
and Jack is going to review this Phase 1 code. Thank you Jack!
Christina
9 years, 8 months
[PATCH] 551 Fixed pylint report.
by Endi Sukma Dewata
Previously pylint report was saved it into a file which may not be
accessible on a build system. The pylint-build-scan.sh has been
changed to display the report so it will appear in the build log.
The pylint configuration has also been modified to disable C and R
messages by default. This way when other errors or warnings occur
the build will fail without having to check for specific codes.
Some Python codes have been modified to reduce the number of pylint
warnings.
https://fedorahosted.org/pki/ticket/703
--
Endi S. Dewata
9 years, 8 months
