Re: [Pki-devel] OCSP Configuration Problem

[John Magne]

Hi:

Should you set something like the following so it can find the security domain?


pki_security_domain_hostname=


- Original Message -
> From: "Nadeera Galagedara" 
> To: pki-devel@redhat.com
> Sent: Wednesday, May 13, 2020 10:30:17 PM
> Subject: [Pki-devel] OCSP Configuration Problem
> 
> Dear,
> 
> I have Root CA and Issue CA in my network. The issue CA is signed by the Root
> CA. Both these CAs are installed in CentOS 7 and Dogtag Version 10.5. Now I
> am going to Install the OCSP for the Issue CA. There is no OCSP for the
> CentOS 7, so I installed the OCSP (10.8) in fedora. I tried to connect the
> OCSP to Issue CA with both Interactive and Manual configuration method. I
> still got an error.
> 
> Error comes while tried to install the OCSP
> 
> INFO: Loading subsystem config: /var/lib/pki/pki-tomcat/ocsp/conf/CS.cfg
> INFO: Checking existing SSL server cert: Server-Cert cert-pki-tomcat
> INFO: Creating temp SSL server cert for ocsp.mycompany.lk
> Notice: Trust flag u is set automatically if the private key is present.
> INFO: Joining existing domain
> INFO: Getting token for installing OCSP on ocsp. mycompany .lk
> 
> Installation failed:
> com.netscape.certsrv.base.PKIException: error result
> 
> Please check the OCSP logs in /var/log/pki/pki-tomcat/ocsp.
> 
> 
> There is no error shows in the log file. If I use the pkispawn it also
> generate the same error.
> 
> 
> 
> 
> 
> 
> My OCSP configuration
> 
> [DEFAULT]
> pki_server_database_password=Secret.123
> 
> [OCSP]
> pki_admin_cert_file=/home/user/Desktop/ca_admin_cert.p12 [ i used the p12
> admin file from issue ca server]
> pki_admin_email=ocspad...@example.com
> pki_admin_name=ocspadmin
> pki_admin_nickname=ocspadmin
> pki_admin_password=Secret.123
> pki_admin_uid=ocspadmin
> 
> pki_client_database_password=Secret.123
> pki_client_database_purge=False
> pki_client_pkcs12_password=Secret.123
> 
> pki_ds_base_dn=dc=ocsp,dc= mycompany ,dc=lk
> pki_ds_database=ocsp
> pki_ds_password=Secret.123
> 
> pki_clone_pkcs12_password=Secret.123
> 
> pki_security_domain_name=MYDOMAIN
> pki_security_domain_user=caadmin
> pki_security_domain_password=Secret.123
> 
> pki_token_password=Secret.123
> 
> 
> pki_security_domain_hostname=issueca. mycompany .lk
> 
> 
> 
> 
> 
> 
> My Issue CA configuration.
> 
> [CA]
> pki_admin_email=caad...@example.com
> pki_admin_name=caadmin
> pki_admin_nickname=caadmin
> pki_admin_password=Secret.123
> pki_admin_uid=caadmin
> 
> pki_client_database_password=Secret.123
> pki_client_database_purge=False
> pki_client_pkcs12_password=Secret.123
> 
> pki_ds_base_dn=dc=issueca,dc=mycompany,dc=lk
> pki_ds_database=ca
> pki_ds_password=Secret.123
> 
> pki_security_domain_name=MYDOMAIN
> pki_token_password=Secret.123
> 
> pki_external=True
> pki_external_step_two=True
> 
> pki_ca_signing_csr_path=ca_signing.csr
> pki_ca_signing_cert_path=ca_signing.crt
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Ticket-2737-CMC-check-HTTPS-client-authentication-ce.patch

[John Magne]

I have seen a demo of this in action and it appears to work.

The code looks as expected.

ACK

- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Wednesday, June 14, 2017 3:04:38 PM
Subject: [Pki-devel] [PATCH]
Ticket-2737-CMC-check-HTTPS-client-authentication-ce.patch



This patch addresses: 

https://pagure.io/dogtagpki/issue/2737 CMC: check HTTPS client authentication 
cert against CMC signer 

Please review, 

Thanks 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0095-Resolve-1663-Add-SCP03-support.patch

[John Magne]

PUshed to master:

commit a614eb15476adb00df571d3ea05fdd8ea282141d
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Fri Jun 2 15:40:52 2017 -0700

Resolve  #1663 Add SCP03 support .

This particular fix resolves a simple issue when formatting a token in FIPS 
mode for SCP03.


- Original Message -
From: "Matthew Harmsen" <mharm...@redhat.com>
To: "John Magne" <jma...@redhat.com>, "pki-devel" <pki-devel@redhat.com>
Sent: Friday, June 2, 2017 4:01:14 PM
Subject: Re: [Pki-devel] [pki-devel][PATCH] 
0095-Resolve-1663-Add-SCP03-support.patch

On 06/02/2017 04:44 PM, John Magne wrote:
>
>
>
> Ticket: Resolve  #1663 Add SCP03 support .
>  
>  This particular fix resolves a simple issue when formatting a token in 
> FIPS mode for SCP03.
>
>
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

Confirmed that import statements were removed by Eclipse, and that 
commented out block of code is there for future testing.

As jmagne confirmed that this had been tested (including on the 
offending machine configuration) --- ACK

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Ticket-2618-feature-pre-signed-CMC-renewal-request.patch

[John Magne]

ACK:

Just make sure these changed constraints don't have any negative effect on 
existing profiles that use those constraints..

- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Friday, May 19, 2017 5:31:37 PM
Subject: [Pki-devel] [PATCH]
Ticket-2618-feature-pre-signed-CMC-renewal-request.patch



This patch is for https://pagure.io/dogtagpki/issue/2618 allow CA to process 
pre-signed CMC renewal cert requests 

Ticket#2618 feature: pre-signed CMC renewal request 

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. 
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. 


Thanks, 

Christina 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] - Correct section headings in user deployment configuration file

[John Magne]

Looks simple and valuable to clean up a few possible error cases.

Conditional ACK with one minor thing.

Maybe just check for "[KEYWORD" to catch a case where someone
might leave out the closing bracket. Who knows what havoc that
might have on an install.



- Original Message -
> From: "Matthew Harmsen" 
> To: "pki-devel" 
> Sent: Wednesday, May 17, 2017 11:54:45 AM
> Subject: [Pki-devel] [PATCH] - Correct section headings in user deployment 
> configuration file
> 
> 
> 
> Please review the attached patch for:
> 
> * Bugzilla Bug #1447144 - CA brought down during separate KRA instance
> creation
> 
> 
> Note that the Python method itself was tested in a standalone fashion against
> various sample configuration files to make certain that the only thing
> altered was an invalid section heading.
> 
> It was run against the previously modified files noted in the bug and made
> the following changes to the user deployment configuration files:
> 
> 
> 
> # diff mlh_ca.cfg.orig mlh_ca.cfg
> 24c24
> < [TOMCAT]
> ---
> > [Tomcat]
> 
> # diff mlh_kra.cfg.orig mlh_kra.cfg
> 31c31
> < [TOMCAT]
> ---
> > [Tomcat]
> Application of this patch allowed the KRA to be installed successfully, and
> did not shutdown the CA.
> 
> 
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Bug-1447080-CC-CMC-allow-enrollment-key-signed-self-.patch

[John Magne]

I have already seen the demo for this.


Seems to make sense.

I've called out some extraneous calls to System.out.println,that might pollute 
the logs and the output for a client.

Conditional ACK.

Also, some of this affects the CRMFPopClient class when we add the switch for 
self signed.
We should at least check with Endi to make sure this doesn't have any negative 
effect on the pki command
which uses the same code in certain situations.

- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Tuesday, May 16, 2017 11:36:55 AM
Subject: Re: [Pki-devel] [PATCH] 
Bug-1447080-CC-CMC-allow-enrollment-key-signed-self-.patch



Per discussion with Ade and Endi on unrelated audit-event-specific topic, we 
decide to not split events into SUCCESS and FAILURE. 

This updated patch un-split the events that I split prior to the 
conversation/decision. 

thanks, 

Christina 

On 05/15/2017 06:29 PM, Christina Fu wrote: 


(pague ticket is yet to be cloned) 

Bug 1447080 - CC: CMC: allow enrollment key signed (self-signed) CMC with 
identity proof 

This patch implements handling of 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. 

thanks! 

Christina 



___
Pki-devel mailing list Pki-devel@redhat.com 
https://www.redhat.com/mailman/listinfo/pki-devel 


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] - CA installation with HSM in FIPS mode fails

[John Magne]

This looks nice and simple and solves the problem.
I agree that using http is ok here since the servlet in question
is public anyway.

I have also participated in and seen the results of a successful test
of this patch working.

ACK.


- Original Message -
> From: "Matthew Harmsen" 
> To: "pki-devel" , "Jack Magne" 
> Sent: Friday, May 12, 2017 4:24:14 PM
> Subject: [PATCH] - CA installation with HSM in FIPS mode fails
> 
> Please review the attached patch for:
> 
>   * Bugizilla Bug #1450143 - CA installation with HSM in FIPS mode fails
> 
> 
> Thanks,
> -- Matt
> 
> 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] Non server keygen issue in SCP03.

[John Magne]

[PATCH] Non server keygen issue in SCP03.

Ticket 1663 Add SCP03 support: https://pagure.io/dogtagpki/issue/1663

We discovered a minor issue when trying to log values that don't exist when 
performing the non server side keygen case. For instance , we don't need to 
generate a kek session key in this case, and we were trying to print info about 
it to the logs. This fix allows this case to work without issue.
From d58e929de707ad5139c57cd493fae5485ca3acae Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 5 May 2017 11:44:17 -0700
Subject: [PATCH] Non server keygen issue in SCP03.

Ticket 1663 Add SCP03 support: https://pagure.io/dogtagpki/issue/1663

We discovered a minor issue when trying to log values that don't exist when performing the non server side keygen case. For instance , we don't need to generate a kek session key in this case, and we were trying to print info about it to the logs. This fix allows this case to work without issue.
---
 .../server/tps/channel/SecureChannel.java  |  4 +-
 .../server/tps/processor/TPSProcessor.java | 51 +++---
 2 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java b/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
index fc5472c..5e5646b 100644
--- a/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
+++ b/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
@@ -148,8 +148,8 @@ public class SecureChannel {
 
 CMS.debug("SecureChannel.SecureChannel: For SCP03. :  ");
 
-CMS.debug("kekDesKey: " + kekDesKey.toHexString());
-CMS.debug("keyCheck: " + keyCheck.toHexString());
+if (keyCheck != null)
+CMS.debug("keyCheck: " + keyCheck.toHexString());
 
 this.platProtInfo = platformInfo;
 this.processor = processor;
diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/TPSProcessor.java b/base/tps/src/org/dogtagpki/server/tps/processor/TPSProcessor.java
index 0cfac59..0f96915 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSProcessor.java
@@ -33,6 +33,8 @@ import java.util.List;
 import java.util.Map;
 import java.util.Set;
 
+import netscape.security.x509.RevocationReason;
+
 import org.dogtagpki.server.tps.TPSSession;
 import org.dogtagpki.server.tps.TPSSubsystem;
 import org.dogtagpki.server.tps.authentication.AuthUIParameter;
@@ -100,8 +102,6 @@ import com.netscape.cms.servlet.tks.SecureChannelProtocol;
 import com.netscape.cmsutil.crypto.CryptoUtil;
 import com.netscape.symkey.SessionKey;
 
-import netscape.security.x509.RevocationReason;
-
 public class TPSProcessor {
 
 public static final int RESULT_NO_ERROR = 0;
@@ -923,20 +923,39 @@ public class TPSProcessor {
 TPSBuffer drmDesKeyBuff = resp.getDRM_Trans_DesKey();
 TPSBuffer kekDesKeyBuff = resp.getKekWrappedDesKey();
 
-CMS.debug(method + " encSessionKeyBuff: " + encSessionKeyBuff.toHexString());
-CMS.debug(method + " kekSessionKeyBuff: " + kekSessionKeyBuff.toHexString());
-CMS.debug(method + " macSessionKeyBuff: " + macSessionKeyBuff.toHexString());
-CMS.debug(method + " hostCryptogramBuff: " + hostCryptogramBuff.toHexString());
-CMS.debug(method + " keyCheckBuff: " + keyCheckBuff.toHexString());
-CMS.debug(method + " drmDessKeyBuff: " + drmDesKeyBuff.toHexString());
-CMS.debug(method + " kekDesKeyBuff: " + kekDesKeyBuff.toHexString());
-
-encSessionKeySCP03 = (PK11SymKey) protocol.unwrapWrappedSymKeyOnToken(token, sharedSecret,
-encSessionKeyBuff.toBytesArray(), false, SymmetricKey.AES);
-macSessionKeySCP03 = (PK11SymKey) protocol.unwrapWrappedSymKeyOnToken(token, sharedSecret,
-macSessionKeyBuff.toBytesArray(), false, SymmetricKey.AES);
-kekSessionKeySCP03 = (PK11SymKey) protocol.unwrapWrappedSymKeyOnToken(token, sharedSecret,
-kekSessionKeyBuff.toBytesArray(), false, SymmetricKey.AES);
+if (encSessionKeyBuff != null)
+CMS.debug(method + " encSessionKeyBuff: " + encSessionKeyBuff.toHexString());
+
+if (kekSessionKeyBuff != null)
+CMS.debug(method + " kekSessionKeyBuff: " + kekSessionKeyBuff.toHexString());
+
+if (macSessionKeyBuff != null)
+CMS.debug(method + " macSessionKeyBuff: " + macSessionKeyBuff.toHexString());
+
+if (hostCryptogramBuff != null)
+CMS.debug(method + " hostCryptogramBuff: " + hostCryptogramBuff.toHexString());
+
+if (keyCheckBuff != null)
+CMS.debug(method + " keyCheckBuff: " + keyCheckBuff.toHexString());
+
+if (drmDesKeyBuff != null)
+CMS.debug(method + " drmDessKeyBuff: " + 

[Pki-devel] [pki-devel][PATCH]

[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/2520From 91d7f82be94532a691768021a0661efd6a93e093 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Wed, 26 Apr 2017 15:21:39 -0700
Subject: [PATCH] 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.
---
 .../src/com/netscape/cms/profile/def/CAValidityDefault.java  | 12 ++--
 .../cms/profile/def/PrivateKeyUsagePeriodExtDefault.java |  4 ++--
 .../netscape/cms/profile/def/RandomizedValidityDefault.java  |  2 +-
 .../src/com/netscape/cms/profile/def/ValidityDefault.java| 10 +-
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/base/server/cms/src/com/netscape/cms/profile/def/CAValidityDefault.java b/base/server/cms/src/com/netscape/cms/profile/def/CAValidityDefault.java
index 2df256e..2ecd484 100644
--- a/base/server/cms/src/com/netscape/cms/profile/def/CAValidityDefault.java
+++ b/base/server/cms/src/com/netscape/cms/profile/def/CAValidityDefault.java
@@ -24,6 +24,11 @@ import java.util.Calendar;
 import java.util.Date;
 import java.util.Locale;
 
+import netscape.security.x509.BasicConstraintsExtension;
+import netscape.security.x509.CertificateValidity;
+import netscape.security.x509.PKIXExtensions;
+import netscape.security.x509.X509CertInfo;
+
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.IConfigStore;
 import com.netscape.certsrv.ca.ICertificateAuthority;
@@ -34,11 +39,6 @@ import com.netscape.certsrv.property.EPropertyException;
 import com.netscape.certsrv.property.IDescriptor;
 import com.netscape.certsrv.request.IRequest;
 
-import netscape.security.x509.BasicConstraintsExtension;
-import netscape.security.x509.CertificateValidity;
-import netscape.security.x509.PKIXExtensions;
-import netscape.security.x509.X509CertInfo;
-
 /**
  * This class implements a CA signing cert enrollment default policy
  * that populates a server-side configurable validity
@@ -348,7 +348,7 @@ public class CAValidityDefault extends EnrollDefault {
 if (startTimeStr == null || startTimeStr.equals("")) {
 startTimeStr = "60";
 }
-int startTime = Integer.parseInt(startTimeStr);
+long startTime = Long.parseLong(startTimeStr);
 
 Date notBefore = new Date(CMS.getCurrentDate().getTime() + (1000 * startTime));
 CMS.debug("CAValidityDefault: not before: " + notBefore);
diff --git a/base/server/cms/src/com/netscape/cms/profile/def/PrivateKeyUsagePeriodExtDefault.java b/base/server/cms/src/com/netscape/cms/profile/def/PrivateKeyUsagePeriodExtDefault.java
index 6532a13..2f05f32 100644
--- a/base/server/cms/src/com/netscape/cms/profile/def/PrivateKeyUsagePeriodExtDefault.java
+++ b/base/server/cms/src/com/netscape/cms/profile/def/PrivateKeyUsagePeriodExtDefault.java
@@ -296,13 +296,13 @@ public class PrivateKeyUsagePeriodExtDefault extends EnrollExtDefault {
 if (startTimeStr == null || startTimeStr.equals("")) {
 startTimeStr = "60";
 }
-int startTime = Integer.parseInt(startTimeStr);
+long startTime = Long.parseLong(startTimeStr);
 Date notBefore = new Date(CMS.getCurrentDate().getTime() +
 (1000 * startTime));
 long notAfterVal = 0;
 
 notAfterVal = notBefore.getTime() +
-(mDefault * Integer.parseInt(getConfig(CONFIG_DURATION)));
+(mDefault * Long.parseLong(getConfig(CONFIG_DURATION)));
 Date notAfter = new Date(notAfterVal);
 
 ext = new PrivateKeyUsageExtension(notBefore, notAfter);
diff --git 

Re: [Pki-devel] [PATCH] #2614 CMC: id-cmc-popLinkWitnessV2 feature implementation

[John Magne]

Cond ACK.


Looks good.

I just put a few minor suggestions to take care of in the attachment, which is 
merely the original patch with comments
interspersed, identified with 


- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Thursday, April 13, 2017 5:03:06 PM
Subject: [Pki-devel] [PATCH] #2614 CMC: id-cmc-popLinkWitnessV2 feature 
implementation

Please review.

thanks!

Christina


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel>From 23f532da661f2528c47df67c8663a0f4f96401ea Mon Sep 17 00:00:00 2001
From: Christina Fu 
Date: Thu, 13 Apr 2017 16:53:58 -0700
Subject: [PATCH] Ticket #2614 CMC: id-cmc-popLinkWitnessV2 feature
 implementation This patch provides the feature for CMC on handling
 id-cmc-popLinkWitnessV2

---
 .../src/com/netscape/cmstools/CMCRequest.java  | 445 +++--
 .../src/com/netscape/cmstools/CRMFPopClient.java   |  10 +-
 .../src/com/netscape/cmstools/PKCS10Client.java|  22 +-
 .../netscape/cms/profile/common/EnrollProfile.java | 416 ++-
 .../cms/servlet/common/CMCOutputTemplate.java  |  12 +
 base/server/cmsbundle/src/UserMessages.properties  |   2 +
 6 files changed, 752 insertions(+), 155 deletions(-)

diff --git a/base/java-tools/src/com/netscape/cmstools/CMCRequest.java b/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
index a2aca8a..004b81d 100644
--- a/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
+++ b/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
@@ -34,6 +34,7 @@ import java.security.NoSuchAlgorithmException;
 import java.text.SimpleDateFormat;
 import java.util.Arrays;
 import java.util.Date;
+import java.util.Random;
 import java.util.StringTokenizer;
 
 import org.mozilla.jss.CryptoManager;
@@ -53,10 +54,12 @@ import org.mozilla.jss.crypto.CryptoToken;
 import org.mozilla.jss.crypto.DigestAlgorithm;
 import org.mozilla.jss.crypto.ObjectNotFoundException;
 import org.mozilla.jss.crypto.PrivateKey;
+import org.mozilla.jss.crypto.Signature;
 import org.mozilla.jss.crypto.SignatureAlgorithm;
 import org.mozilla.jss.crypto.SymmetricKey;
 import org.mozilla.jss.crypto.X509Certificate;
 import org.mozilla.jss.pkcs10.CertificationRequest;
+import org.mozilla.jss.pkcs10.CertificationRequestInfo;
 import org.mozilla.jss.pkix.cmc.CMCCertId;
 import org.mozilla.jss.pkix.cmc.CMCStatusInfo;
 import org.mozilla.jss.pkix.cmc.DecryptedPOP;
@@ -68,6 +71,7 @@ import org.mozilla.jss.pkix.cmc.OtherInfo;
 import org.mozilla.jss.pkix.cmc.OtherMsg;
 import org.mozilla.jss.pkix.cmc.PKIData;
 import org.mozilla.jss.pkix.cmc.PendInfo;
+import org.mozilla.jss.pkix.cmc.PopLinkWitnessV2;
 import org.mozilla.jss.pkix.cmc.ResponseBody;
 import org.mozilla.jss.pkix.cmc.TaggedAttribute;
 import org.mozilla.jss.pkix.cmc.TaggedCertificationRequest;
@@ -85,7 +89,11 @@ import org.mozilla.jss.pkix.cms.SignerInfo;
 import org.mozilla.jss.pkix.crmf.CertReqMsg;
 import org.mozilla.jss.pkix.crmf.CertRequest;
 import org.mozilla.jss.pkix.crmf.CertTemplate;
+import org.mozilla.jss.pkix.crmf.POPOSigningKey;
+import org.mozilla.jss.pkix.crmf.ProofOfPossession;
+import org.mozilla.jss.pkix.primitive.AVA;
 import org.mozilla.jss.pkix.primitive.AlgorithmIdentifier;
+import org.mozilla.jss.pkix.primitive.Attribute;
 import org.mozilla.jss.pkix.primitive.Name;
 import org.mozilla.jss.pkix.primitive.SubjectPublicKeyInfo;
 import org.mozilla.jss.util.Password;
@@ -148,6 +156,37 @@ public class CMCRequest {
 }
 
 /**
+ * getSigningAlgFromPrivate
+ *
+ */



check for null to avoid null pointer exception. I know it's just the tool, but it would be ugly for the user






+static SignatureAlgorithm getSigningAlgFromPrivate (java.security.PrivateKey privKey) {
+String method = "getSigningAlgFromPrivate: ";
+System.out.println(method + "begins.");
+SignatureAlgorithm signAlg = null;
+/*
+org.mozilla.jss.crypto.PrivateKey.Type signingKeyType =
+((org.mozilla.jss.crypto.PrivateKey) privKey)
+.getType();
+*/
+// TODO: allow more options later
+String signingKeyType = privKey.getAlgorithm();
+System.out.println(method + "found signingKeyType=" + signingKeyType);
+if (signingKeyType.equalsIgnoreCase("RSA")) {
+signAlg = SignatureAlgorithm.RSASignatureWithSHA256Digest;
+} else if (signingKeyType.equalsIgnoreCase("EC")) {
+signAlg = SignatureAlgorithm.ECSignatureWithSHA256Digest;
+} else {
+System.out.println(method + "Algorithm not supported:" +
+signingKeyType);
+return null;
+}
+System.out.println(method + "using SignatureAlgorithm: " +
+signAlg.toString());
+
+return signAlg;
+}
+
+/**
  * signData signs the request 

Re: [Pki-devel] [PATCH] pki-cfu-0159-Ticket-1741-ECDSA-certs-Alg-IDs-contian-parameter-fi.patch

[John Magne]

Looks good. ACK


- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Friday, January 20, 2017 5:00:02 PM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0159-Ticket-1741-ECDSA-certs-Alg-IDs-contian-parameter-fi.patch

This patch addresses:

https://fedorahosted.org/pki/ticket/1741 ECDSA Certificates Generated by 
Certificate System fail NIST validation test with parameter field.

Note: Since we do not support DSA, this patch does not attempt to 
address that.  Also, although we do not claim to support sha224, for 
completeness, it has code to recognize sha224 oid and process it as such 
to avoid the parameter field, but it does not offer it as part of the 
hashing alg for signing algorithms, as that is not the purpose of this 
ticket, and would cost more time if to be added.

thanks!

Christina


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] pki-cfu-0157-Ticket-2534-additional-reset-cert-status-after-succe.patch

[John Magne]

Looks good.

Looks like we are now updating the proper entry each time when unrevoking.

If tested to work, ACK



- Original Message -
> From: "Christina Fu" 
> To: pki-devel@redhat.com
> Sent: Wednesday, January 4, 2017 11:26:14 AM
> Subject: [Pki-devel] [PATCH] 
> pki-cfu-0157-Ticket-2534-additional-reset-cert-status-after-succe.patch
> 
> This patch addresses additional issue found after last fix for
> 
> https://fedorahosted.org/pki/ticket/2534 Automatic recovery of
> encryption cert - CA and TPS tokendb shows different certificate status
> 
> where the cert status still shows revoked_on_hold, even though the cert
> was just unrevoked successfully on the CA.
> 
> thanks,
> 
> Christina
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0086-Ticket-2569-Token-memory-not-wiped-after-key-deletio.patch

[John Magne]

Author: Jack Magne 
Date:   Fri Dec 16 16:25:48 2016 -0800

Ticket #2569: Token memory not wiped after key deletion

This is the dogtag upstream side of the TPS portion of this ticket.
This fix also involves an applet fix, handled in another bug.
From 08fa0ff96d7dd6ed6c3b11527251e604b93f045a Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 16 Dec 2016 16:25:48 -0800
Subject: [PATCH] Ticket #2569: Token memory not wiped after key deletion

This is the dogtag upstream side of the TPS portion of this ticket.
This fix also involves an applet fix, handled in another bug.
---
 base/common/src/org/dogtagpki/tps/apdu/APDU.java   |  3 +-
 .../org/dogtagpki/tps/apdu/ClearKeySlotsAPDU.java  | 24 ++
 .../server/tps/channel/SecureChannel.java  | 36 +
 .../org/dogtagpki/server/tps/main/PKCS11Obj.java   | 90 +-
 .../server/tps/processor/TPSEnrollProcessor.java   | 22 --
 5 files changed, 165 insertions(+), 10 deletions(-)
 create mode 100644 base/common/src/org/dogtagpki/tps/apdu/ClearKeySlotsAPDU.java

diff --git a/base/common/src/org/dogtagpki/tps/apdu/APDU.java b/base/common/src/org/dogtagpki/tps/apdu/APDU.java
index 390252f..009c470 100644
--- a/base/common/src/org/dogtagpki/tps/apdu/APDU.java
+++ b/base/common/src/org/dogtagpki/tps/apdu/APDU.java
@@ -57,7 +57,8 @@ public abstract class APDU {
 APDU_SET_ISSUERINFO,
 APDU_GET_ISSUERINFO,
 APDU_GENERATE_KEY_ECC,
-APDU_GET_LIFECYCLE
+APDU_GET_LIFECYCLE,
+APDU_CLEAR_KEY_SLOTS
 }
 
 protected byte cla;
diff --git a/base/common/src/org/dogtagpki/tps/apdu/ClearKeySlotsAPDU.java b/base/common/src/org/dogtagpki/tps/apdu/ClearKeySlotsAPDU.java
new file mode 100644
index 000..b3d71c4
--- /dev/null
+++ b/base/common/src/org/dogtagpki/tps/apdu/ClearKeySlotsAPDU.java
@@ -0,0 +1,24 @@
+package org.dogtagpki.tps.apdu;
+
+import org.dogtagpki.tps.main.TPSBuffer;
+
+
+public class ClearKeySlotsAPDU extends APDU {
+public ClearKeySlotsAPDU(byte[] slotList) {
+setCLA((byte) 0x84);
+setINS((byte) 0x55);
+setP1((byte) 0x0);
+setP2((byte) 0x0);
+
+data = new TPSBuffer();
+data.addBytes(slotList);
+
+}
+
+@Override
+public Type getType()
+{
+return Type.APDU_CLEAR_KEY_SLOTS;
+}
+
+}
diff --git a/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java b/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
index 8860f48..13fb534 100644
--- a/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
+++ b/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
@@ -23,6 +23,7 @@ import org.dogtagpki.server.tps.engine.TPSEngine;
 import org.dogtagpki.server.tps.processor.TPSProcessor;
 import org.dogtagpki.tps.apdu.APDU;
 import org.dogtagpki.tps.apdu.APDUResponse;
+import org.dogtagpki.tps.apdu.ClearKeySlotsAPDU;
 import org.dogtagpki.tps.apdu.CreateObjectAPDU;
 import org.dogtagpki.tps.apdu.CreatePinAPDU;
 import org.dogtagpki.tps.apdu.DeleteFileAPDU;
@@ -850,6 +851,41 @@ public class SecureChannel {
 return keyInfoData;
 }
 
+//Call the applet to clear unused key slots
+public void clearAppletKeySlotData(TPSBuffer data) {
+String method = "SecureChannel.clearAppletKeySlotData: ";
+
+CMS.debug(method + " entering ...");
+
+if(data == null) {
+CMS.debug(method + " Invalid input data returning...");
+return;
+}
+
+
+
+   // CMS.debug(method + " apdu sending: " + clearKey.getEncoding().toHexString());
+
+
+
+APDUResponse response;
+try {
+
+ClearKeySlotsAPDU  clearKey = new ClearKeySlotsAPDU(data.toBytesArray());
+computeAPDU(clearKey);
+response = processor.handleAPDURequest(clearKey);
+} catch (TPSException | IOException e) {
+CMS.debug(method + " bad apdu return!");
+return;
+
+}
+
+if (!response.checkResult()) {
+CMS.debug(method + " bad apdu return!");
+}
+
+}
+
 public void writeObject(TPSBuffer objectID, TPSBuffer objectData) throws TPSException, IOException {
 CMS.debug("SecureChannel.writeObject: entering ...");
 
diff --git a/base/tps/src/org/dogtagpki/server/tps/main/PKCS11Obj.java b/base/tps/src/org/dogtagpki/server/tps/main/PKCS11Obj.java
index 6af39a7..ccfcbb7 100644
--- a/base/tps/src/org/dogtagpki/server/tps/main/PKCS11Obj.java
+++ b/base/tps/src/org/dogtagpki/server/tps/main/PKCS11Obj.java
@@ -265,6 +265,92 @@ public class PKCS11Obj {
 
 }
 
+public TPSBuffer getKeyIndexList() {
+
+TPSBuffer data = new TPSBuffer();
+
+
+int objectCount = getObjectSpecCount();
+
+
+CMS.debug("PKCS11Obj:getKeyIndexList: objectCount: " + objectCount);
+
+  //Add first byte for length, set to 0 for now
+
+byte keyListCount = 0;
+
+

Re: [Pki-devel] Fwd: [PATCH] - remove xenroll.dll from pki-core

[John Magne]

ACK

Participated in demo of the code and was able to enroll for and import a cert 
using IE.

- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Sent: Friday, December 9, 2016 3:07:20 PM
Subject: [Pki-devel] Fwd: [PATCH] - remove xenroll.dll from pki-core



Attached REVISED patch. 


 Forwarded Message  
Subject:[PATCH] - remove xenroll.dll from pki-core 
Date:   Thu, 8 Dec 2016 18:47:00 -0700 
From:   Matthew Harmsen  
To: pki-devel  



Please review the attached patch addresses the following bug: 

* PKI TRAC Ticket #2524 - Remove xenroll.dll from pki-core 


Thanks, 
-- Matt 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0086-Resolve-pkispawn-does-not-change-default-ecc-key-siz.patch

[John Magne]

Simple patch will provide a fix to this issue.From e7821b4061d22d23013f7d00c066fc6e59d83167 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Thu, 8 Dec 2016 16:35:20 -0800
Subject: [PATCH] Resolve: pkispawn does not change default ecc key size from
 nistp256 when nistp384 is specified in spawn config

Ticket #2552.

This fix turned out simple. The client was correctly setting the required data, but it was putting the curveName in the
"keySize" field of the SystemCertData object sent to the back end. The configuration routine was trying to find the name in the "curveName" field when its really in the "keySize" field. This issue is restricted to the ECC case. It is fine to simply fix this in the server, since the "keySize" is a string anyway and it makes decent sense.
---
 .../cms/src/org/dogtagpki/server/rest/SystemConfigService.java| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/base/server/cms/src/org/dogtagpki/server/rest/SystemConfigService.java b/base/server/cms/src/org/dogtagpki/server/rest/SystemConfigService.java
index 2f9d0d6..40f4b58 100644
--- a/base/server/cms/src/org/dogtagpki/server/rest/SystemConfigService.java
+++ b/base/server/cms/src/org/dogtagpki/server/rest/SystemConfigService.java
@@ -34,6 +34,8 @@ import javax.ws.rs.core.HttpHeaders;
 import javax.ws.rs.core.Request;
 import javax.ws.rs.core.UriInfo;
 
+import netscape.security.x509.X509CertImpl;
+
 import org.apache.commons.lang.StringUtils;
 import org.apache.commons.lang.mutable.MutableBoolean;
 import org.mozilla.jss.CryptoManager;
@@ -66,8 +68,6 @@ import com.netscape.cms.servlet.csadmin.SystemCertDataFactory;
 import com.netscape.cmsutil.crypto.CryptoUtil;
 import com.netscape.cmsutil.util.Utils;
 
-import netscape.security.x509.X509CertImpl;
-
 /**
  * @author alee
  *
@@ -453,8 +453,8 @@ public class SystemConfigService extends PKIService implements SystemConfigResou
 
 } else if (!request.getStepTwo()) {
 if (keytype.equals("ecc")) {
-String curvename = certData.getKeyCurveName() != null ?
-certData.getKeyCurveName() : cs.getString("keys.ecc.curve.default");
+String curvename = certData.getKeySize() != null ?
+certData.getKeySize() : cs.getString("keys.ecc.curve.default");
 cs.putString("preop.cert." + tag + ".curvename.name", curvename);
 ConfigurationUtils.createECCKeyPair(token, curvename, cs, tag);
 
-- 
2.5.0

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH]

[John Magne]

Verbally discussed issue with cfu, was given cond ack upon fixing the issue:

Issue has been fixed, checked into master.

commit cdb8d2f7a3655b4ba97b70a9460721e0d2d8afe7
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Tue Nov 15 17:37:07 2016 -0800

Change lifecycle at end of enrollment if it is not already set.

TPS throws "err=6" when attempting to format and enroll G 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.


Closed ticket # 2544



- Original Message -
> From: "Christina Fu" <c...@redhat.com>
> To: pki-devel@redhat.com
> Sent: Wednesday, November 16, 2016 6:25:49 PM
> Subject: Re: [Pki-devel] [pki-devel][PATCH]
> 
> 
> 
> I compared this patch with the original C patch. There was a check in C that
> does not exist in your Java patch:
>   1019
> if(data.size() != 3){
> 
>   1020
> lifecycle = 0xf0;
> 
>   1021
> RA::Error(LL_PER_PDU, "RA_Processor::GetLifecycle", "apdu response is the
> wrong size, the size is: %x", data.size());
> 
>   1022
> goto loser;
> 
>   1023
> }
> 
> Why does it not apply in Java?
> 
> Thanks,
> Christina
> 
> On 11/15/2016 06:20 PM, John Magne wrote:
> 
> 
> 
> Ticket: TPS throws "err=6" when attempting to format and e :
> https://fedorahosted.org/pki/ticket/2544 Fix tested on standard card, it
> does what it is supposed to do. It checks first to make sure the lifecycle
> state needs to be changed before attempting to do so. This will prevent any
> cards that return an error when
> one tries to over write the value with the same value it had before.
> 
> 
> ___
> Pki-devel mailing list Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 331-333 add support for synchronous key archival and recovery requests.

[John Magne]

Looked over all these and it looks good. Post checkin ACK :)

Just a couple of questions:

1. Code like this:

if (!synchronous) {
+// Has to be in this state or it won't go anywhere.
+request.setRequestStatus(RequestStatus.BEGIN);
+queue.processRequest(request);
+} else {
+kra.processSynchronousRequest(request);
+}

I know we are handling the synchronous request with a processor and such, but 
the standard async request is being
handled with the same queue method. Would it look nicer to have a layer for the 
standard case, like processAsynchRequest?
No big deal.


2. Did we do a sanity sweep of the various scenarios to make sure that they 
refactor is good with respect to legacy code paths?
I"m sure we have but was just asking.


3. Also I realize that the "realm" param is not yet supported but is a hook for 
future code, if we have to touch anything again, might help to give a comment
in the key methods as to why it is not yet being used.

thanks,
jack

- Original Message -
> From: "Ade Lee" 
> To: pki-devel@redhat.com
> Sent: Friday, November 4, 2016 1:11:03 PM
> Subject: [Pki-devel] [PATCH] 331-333 add support for synchronous key archival 
> and recovery requests.
> 
> Hi all,
> 
> This is in support of Ticket https://fedorahosted.org/pki/ticket/2532
> 
> This is preliminary set of patches - just so you can see what I'm doing
> in case I need to change anything.
> 
> Note: With the changes, you can archive a secret like this:
> 
> pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
> `hostname` -p 8443 key-archive --passphrase "ooga booga" --clientKeyID
> "test_1"
> 
> pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
> `hostname` -p 8443 key-archive --passphrase "ooga booga" --clientKeyID
> "test_2" --express
> 
> The first invocation will archive a secret and create an archival
> request in LDAP.  The second will create one only in memory - and will
> not store it in LDAP.
> 
> You can of course, see the requests created using -
> 
> pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
> `hostname` -p 8443 key-request-find
> 
> For retrieving the secret, you can do either:
> 
> pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
> aleeredhat.laptop -p 8443 key-retrieve --keyID  0x5
> 
> pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h
> aleeredhat.laptop -p 8443 key-retrieve --keyID  0x5 --express
> 
> The first will retrieve the secret while creating a retrieval request.
> The second will create a retrieval request only in memory, and will not
> write it to LDAP.
> 
> In both cases, there should be audit logs both for retrieval and
> archival.
>  
> Thanks,
> Ade
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 485 Fixed TPS UI system menu.

[John Magne]

Have seen demo, and it looks good.
ACK


- Original Message -
> From: "Endi Sukma Dewata" 
> To: "pki-devel" 
> Sent: Thursday, October 20, 2016 2:21:43 PM
> Subject: [Pki-devel] [PATCH] 485 Fixed TPS UI system menu.
> 
> The TPS UI has been modified to adjust the system menu based
> on the list of accessible components obtained during login.
> 
> The TPSApplication has been modified to use TPSAccountService
> which returns the list of accessible components based on the
> following properties in the CS.cfg:
> * admin: target.configure.list
> * agent: target.agent_approve.list
> 
> The AccountInfo has been changed to extend the ResourceMessage
> such that it can be used to pass the list of accessible
> components as an attribute.
> 
> https://fedorahosted.org/pki/ticket/2523
> 
> --
> Endi S. Dewata
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 486 Fixed TPS UI for agent approval.

[John Magne]

Have seen demo and looks good.
ACK



- Original Message -
> From: "Endi Sukma Dewata" 
> To: "pki-devel" 
> Sent: Thursday, October 20, 2016 2:21:49 PM
> Subject: [Pki-devel] [PATCH] 486 Fixed TPS UI for agent approval.
> 
> The TPS UI has been updated to support TPS agent approval process
> for changes in authenticators, connectors, and profile mappings in
> addition to profiles.
> 
> The ConfigEntryPage has been updated to display the action links
> consistently in the above components for all possible role and
> status combinations.
> 
> The ProfilePage has been removed since the code has been merged
> into its super class.
> 
> https://fedorahosted.org/pki/ticket/2523
> 
> --
> Endi S. Dewata
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0084-TPS-token-enrollment-fails-to-setupSecureChannel-whe.patch

[John Magne]

TPS token enrollment fails to setupSecureChannel when TPS and TKS security db 
is on fips mode.

Ticket #2513.

Simple fix allows the TPS and TKS the ability to obtain the proper internal 
token, even in FiPS mode.
From 00bba5092fa32b956d646b4711411b8c57bd8f75 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Thu, 20 Oct 2016 15:18:12 -0700
Subject: [PATCH] TPS token enrollment fails to setupSecureChannel when TPS and
 TKS security db is on fips mode.

Ticket #2513.

Simple fix allows the TPS and TKS the ability to obtain the proper internal token, even in FiPS mode.
---
 .../cms/src/com/netscape/cms/servlet/tks/SecureChannelProtocol.java| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/base/server/cms/src/com/netscape/cms/servlet/tks/SecureChannelProtocol.java b/base/server/cms/src/com/netscape/cms/servlet/tks/SecureChannelProtocol.java
index db42cab..1997d11 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/tks/SecureChannelProtocol.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/tks/SecureChannelProtocol.java
@@ -688,10 +688,11 @@ public class SecureChannelProtocol {
 
 public CryptoToken returnTokenByName(String name, CryptoManager manager) throws NoSuchTokenException {
 
+CMS.debug("returnTokenByName: requested name: " + name);
 if (name == null || manager == null)
 throw new NoSuchTokenException();
 
-if (name.equals("internal") || name.equals("Internal KeyStorage Token")) {
+if (name.equals("internal") || name.equals("Internal Key Storage Token")) {
 return manager.getInternalKeyStorageToken();
 } else {
 return manager.getTokenByName(name);
-- 
2.5.0

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0082-Cert-Key-recovery-is-successful-when-the-cert-serial.patch

[John Magne]

Pushed to master:

commit 9090451aa9f1a2dfcef8b852bb1e1d13d270098d
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Tue Oct 18 15:08:44 2016 -0700

 Cert/Key recovery is successful when the cert serial number and key id on 
the ldap user mismatches

 Fixes this bug #1381375.
The portion this patch fixes involves URL encoding glitch we encountered 
when recovering keys using
the "by cert" method.

Also this bug addresses:

Bug 1379379 - Unable to read an encrypted email using renewed tokens
The URL encoding problem was affecting the proper verification of this bug.

and

Bug 1379749 - Automatic recovery of encryption cert is not working when a 
token is physically damaged and a temporary token is issued

The URI encoding was also making this bug appear to fail more than it 
should have.
There is also a minor fix to the feature that makes sure it works.

This small fix is in TPSEngine.java where the constant for 
GenerateNewAndRecoverLast scheme is declared.

- Original Message -
From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Tuesday, October 18, 2016 4:24:08 PM
Subject: Re: [Pki-devel] [pki-devel][PATCH] 
0082-Cert-Key-recovery-is-successful-when-the-cert-serial.patch



If tested to work for all cases, ACK. 

Christina 

On 10/18/2016 03:22 PM, John Magne wrote: 



Cert/Key recovery is successful when the cert serial number and key id on the 
ldap user mismatches

 Fixes this bug #1381375.
The portion this patch fixes involves URL encoding glitch we encountered 
when recovering keys using
the "by cert" method.

Also this bug addresses:

Bug 1379379 - Unable to read an encrypted email using renewed tokens
The URL encoding problem was affecting the proper verification of this bug.

and

Bug 1379749 - Automatic recovery of encryption cert is not working when a 
token is physically damaged and a temporary token is issued

The URI encoding was also making this bug appear to fail more than it 
should have.
There is also a minor fix to the feature that makes sure it works.

This small fix is in TPSEngine.java where the constant for 
GenerateNewAndRecoverLast scheme is declared. 


___
Pki-devel mailing list Pki-devel@redhat.com 
https://www.redhat.com/mailman/listinfo/pki-devel 


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0083-PIN_RESET-policy-is-not-giving-expected-results-when.patch

[John Magne]

PIN_RESET policy is not giving expected results when set on a token.

Simple fix to actually honor the PIN_RESET=or policy for a given 
token.
Minor logging improvements added as well for this error condition.

Ticket #2510.


From 09dba122f01881b93d32a03a51d0be37c247cb30 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Tue, 18 Oct 2016 18:58:21 -0700
Subject: [PATCH] PIN_RESET policy is not giving expected results when set on a
 token.

Simple fix to actually honor the PIN_RESET=or policy for a given token.

Ticket #2510.
---
 .../server/tps/processor/TPSPinResetProcessor.java | 34 --
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/TPSPinResetProcessor.java b/base/tps/src/org/dogtagpki/server/tps/processor/TPSPinResetProcessor.java
index 9d0625a..fe3f801 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSPinResetProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSPinResetProcessor.java
@@ -21,6 +21,7 @@ import java.io.IOException;
 
 import org.dogtagpki.server.tps.TPSSession;
 import org.dogtagpki.server.tps.TPSSubsystem;
+import org.dogtagpki.server.tps.TPSTokenPolicy;
 import org.dogtagpki.server.tps.channel.SecureChannel;
 import org.dogtagpki.server.tps.dbs.ActivityDatabase;
 import org.dogtagpki.server.tps.dbs.TokenRecord;
@@ -98,15 +99,7 @@ public class TPSPinResetProcessor extends TPSProcessor {
 TPSStatus.STATUS_ERROR_MAC_RESET_PIN_PDU);
 }
 
-TokenStatus status = tokenRecord.getTokenStatus();
-
-CMS.debug(method + ": Token status: " + status);
-
-if (!status.equals(TokenStatus.ACTIVE)) {
-throw new TPSException(method + " Attempt to reset pin of token not currently active!",
-TPSStatus.STATUS_ERROR_MAC_RESET_PIN_PDU);
-
-}
+TPSTokenPolicy tokenPolicy = new TPSTokenPolicy(tps);
 
 session.setTokenRecord(tokenRecord);
 
@@ -142,6 +135,29 @@ public class TPSPinResetProcessor extends TPSProcessor {
 
 checkAndAuthenticateUser(appletInfo, tokenType);
 
+TokenStatus status = tokenRecord.getTokenStatus();
+
+CMS.debug(method + ": Token status: " + status);
+
+if (!status.equals(TokenStatus.ACTIVE)) {
+logMsg = method + "Can not reset the pin of a non active token.";
+auditPinReset(session.getIpAddress(), userid, appletInfo, "failure", null, logMsg);
+throw new TPSException(method + " Attempt to reset pin of token not currently active!",
+TPSStatus.STATUS_ERROR_MAC_RESET_PIN_PDU);
+
+}
+
+boolean pinResetAllowed = tokenPolicy.isAllowedPinReset(tokenRecord.getId());
+
+CMS.debug(method + ": PinResetPolicy: Pin Reset Allowed:  " + pinResetAllowed);
+logMsg = method + " PinReset Policy forbids pin reset operation.";
+if (pinResetAllowed == false) {
+auditPinReset(session.getIpAddress(), userid, appletInfo, "failure", null, logMsg);
+throw new TPSException(method + " Attempt to reset pin when token policy disallows it.!",
+TPSStatus.STATUS_ERROR_MAC_RESET_PIN_PDU);
+
+}
+
 checkAndUpgradeApplet(appletInfo);
 appletInfo = getAppletInfo();
 
-- 
2.5.0

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0082-Cert-Key-recovery-is-successful-when-the-cert-serial.patch

[John Magne]

Cert/Key recovery is successful when the cert serial number and key id on the 
ldap user mismatches

 Fixes this bug #1381375.
The portion this patch fixes involves URL encoding glitch we encountered 
when recovering keys using
the "by cert" method.

Also this bug addresses:

Bug 1379379 - Unable to read an encrypted email using renewed tokens
The URL encoding problem was affecting the proper verification of this bug.

and

Bug 1379749 - Automatic recovery of encryption cert is not working when a 
token is physically damaged and a temporary token is issued

The URI encoding was also making this bug appear to fail more than it 
should have.
There is also a minor fix to the feature that makes sure it works.

This small fix is in TPSEngine.java where the constant for 
GenerateNewAndRecoverLast scheme is declared.
From a1f1e030298c38e0c08a514852a435e77d88a2b9 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Tue, 18 Oct 2016 15:08:44 -0700
Subject: [PATCH]  Cert/Key recovery is successful when the cert serial number
 and key id on the ldap user mismatches

 Fixes this bug #1381375.
The portion this patch fixes involves URL encoding glitch we encountered when recovering keys using
the "by cert" method.

Also this bug addresses:

Bug 1379379 - Unable to read an encrypted email using renewed tokens
The URL encoding problem was affecting the proper verification of this bug.

and

Bug 1379749 - Automatic recovery of encryption cert is not working when a token is physically damaged and a temporary token is issued

The URI encoding was also making this bug appear to fail more than it should have.
There is also a minor fix to the feature that makes sure it works.

This small fix is in TPSEngine.java where the constant for GenerateNewAndRecoverLast scheme is declared.
---
 .../server/tps/cms/KRARemoteRequestHandler.java|  9 ++--
 .../org/dogtagpki/server/tps/engine/TPSEngine.java | 15 --
 .../server/tps/processor/TPSEnrollProcessor.java   | 63 --
 3 files changed, 50 insertions(+), 37 deletions(-)

diff --git a/base/tps/src/org/dogtagpki/server/tps/cms/KRARemoteRequestHandler.java b/base/tps/src/org/dogtagpki/server/tps/cms/KRARemoteRequestHandler.java
index 80439ca..3674526 100644
--- a/base/tps/src/org/dogtagpki/server/tps/cms/KRARemoteRequestHandler.java
+++ b/base/tps/src/org/dogtagpki/server/tps/cms/KRARemoteRequestHandler.java
@@ -23,7 +23,6 @@ import java.util.Hashtable;
 
 import org.dogtagpki.server.connector.IRemoteRequest;
 import org.dogtagpki.server.tps.TPSSubsystem;
-import org.dogtagpki.tps.main.Util;
 
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.EBaseException;
@@ -265,15 +264,15 @@ public class KRARemoteRequestHandler extends RemoteRequestHandler
 String sendMsg = null;
 try {
 if (b64cert != null) { // recover by cert
-// CMS.debug("KRARemoteRequestHandler: recoverKey(): uriEncoded cert= " + Util.uriEncode(b64cert));
+// CMS.debug("KRARemoteRequestHandler: recoverKey(): uriEncoded cert= " + b64cert);
 sendMsg = IRemoteRequest.TOKEN_CUID + "=" +
 cuid +
 "&" + IRemoteRequest.KRA_UserId + "=" +
 userid +
 "&" + IRemoteRequest.KRA_RECOVERY_CERT + "=" +
-Util.uriEncode(b64cert) +
+b64cert  +
 "&" + IRemoteRequest.KRA_Trans_DesKey + "=" +
-Util.uriEncode(sDesKey);
+sDesKey;
 } else if (keyid != BigInteger.valueOf(0)) { // recover by keyid ... keyid != BigInteger.valueOf(0)
 CMS.debug("KRARemoteRequestHandler: recoverKey(): keyid = " + keyid);
 sendMsg = IRemoteRequest.TOKEN_CUID + "=" +
@@ -283,7 +282,7 @@ public class KRARemoteRequestHandler extends RemoteRequestHandler
 "&" + IRemoteRequest.KRA_RECOVERY_KEYID + "=" +
 keyid.toString() +
 "&" + IRemoteRequest.KRA_Trans_DesKey + "=" +
-Util.uriEncode(sDesKey);
+sDesKey;
 }
 } catch (Exception e) {
 CMS.debug("KRARemoteRequestHandler: recoverKey(): uriEncode failed: " + e);
diff --git a/base/tps/src/org/dogtagpki/server/tps/engine/TPSEngine.java b/base/tps/src/org/dogtagpki/server/tps/engine/TPSEngine.java
index 93edfde..319ff67 100644
--- a/base/tps/src/org/dogtagpki/server/tps/engine/TPSEngine.java
+++ b/base/tps/src/org/dogtagpki/server/tps/engine/TPSEngine.java
@@ -185,7 +185,7 @@ public class TPSEngine {
 public static final String CFG_PIN_RESET_STRING = "create_pin.string";
 
 public static final String CFG_SCHEME = "scheme";
-public static final String 

Re: [Pki-devel] Fwd: [pli-devel][PATCH] 0081-Fix-for-Add-ability-to-disallow-TPS-to-enroll-a-sing.patch

[John Magne]

ACKED by cfu and she verbally acked a quick additon to eh fix for #1664

Pushed to master.

- Original Message -
From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Friday, October 7, 2016 5:06:51 PM
Subject: Re: [Pki-devel] Fwd: [pli-devel][PATCH] 
0081-Fix-for-Add-ability-to-disallow-TPS-to-enroll-a-sing.patch



Code looks good. One suggestion. Since we have to appease to the current NSS 
way of looking up certs, how about making the default true so that it will keep 
the old encryption certs by default? 

Of course we are taking up more space now on the token when it's true, so we 
should plan to revert it when/if NSS changes. 


conditional ACK if you do that. 


Christina 

On 10/07/2016 02:01 PM, John Magne wrote: 



Actually attach the patch.

- Forwarded Message -----
From: "John Magne" <jma...@redhat.com> To: "pki-devel" <pki-devel@redhat.com> 
Sent: Friday, October 7, 2016 11:45:17 AM
Subject: [pli-devel][PATCH] 
0081-Fix-for-Add-ability-to-disallow-TPS-to-enroll-a-sing.patch

Fix for: Add ability to disallow TPS to enroll a single user on multiple 
tokens. #1664

This bug was previously not completely fixed where we left a loophole to 
allow a user to
end up with 2 active tokens. This fix closes that loophole.

Also:

Fix for: Unable to read an encrypted email using renewed tokens. #2483

This fix provides for a new optional renewal based token policy, that
allows the user to retain or recover old encryption certs for that profile,
that get overwritten by the renewal process.

An example is:

RENEW=YES;RENEW_KEEP_OLD_ENC_CERTS=YES

The second part of the policy is new.

When this is set to "YES", the system will make sure the old enc cert
will remain on the token. If it's missing or "NO", no such attempt will be 
made. 


___
Pki-devel mailing list Pki-devel@redhat.com 
https://www.redhat.com/mailman/listinfo/pki-devel 


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH]pki-cfu-0155-Ticket-2498-Token-format-with-external-reg-fails-whe.patch

[John Magne]

ACK

Looks good and non risky.

- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Monday, October 10, 2016 5:20:11 PM
Subject: [Pki-devel]
[PATCH]pki-cfu-0155-Ticket-2498-Token-format-with-external-reg-fails-whe.patch

This patch addresses:

https://fedorahosted.org/pki/ticket/2498 Token format with external reg 
fails when op.format.externalRegAddToToken.revokeCert=true

It actually could be easily worked around by manually adding the missing 
params

op.format.externalRegAddToToken.auth.id=ldap1
op.format.externalRegAddToToken.ca.conn=ca1

op.format.externalRegAddToToken.tks.conn=tks1

While fixing the CS.cfg, it was observed that there were some references 
of non-defined ldap2 and ldap3, so they are also changed to ldap1.

A couple useful debug messages are added as well.

Christina


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Fwd: [pli-devel][PATCH] 0081-Fix-for-Add-ability-to-disallow-TPS-to-enroll-a-sing.patch

[John Magne]

Actually attach the patch.

- Forwarded Message -
From: "John Magne" <jma...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>
Sent: Friday, October 7, 2016 11:45:17 AM
Subject: [pli-devel][PATCH] 
0081-Fix-for-Add-ability-to-disallow-TPS-to-enroll-a-sing.patch

Fix for: Add ability to disallow TPS to enroll a single user on multiple 
tokens. #1664

This bug was previously not completely fixed where we left a loophole to 
allow a user to
end up with 2 active tokens. This fix closes that loophole.

Also:

Fix for: Unable to read an encrypted email using renewed tokens. #2483

This fix provides for a new optional renewal based token policy, that
allows the user to retain or recover old encryption certs for that profile,
that get overwritten by the renewal process.

An example is:

RENEW=YES;RENEW_KEEP_OLD_ENC_CERTS=YES

The second part of the policy is new.

When this is set to "YES", the system will make sure the old enc cert
will remain on the token. If it's missing or "NO", no such attempt will be 
made.
From 582819dc3156a2543935e1a2dec49f3d6cf1e25b Mon Sep 17 00:00:00 2001
From: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date: Wed, 5 Oct 2016 18:16:35 -0700
Subject: [PATCH] Fix for: Add ability to disallow TPS to enroll a single user
 on multiple tokens. #1664

This bug was previously not completely fixed where we left a loophole to allow a user to
end up with 2 active tokens. This fix closes that loophole.

Also:

Fix for: Unable to read an encrypted email using renewed tokens. #2483

This fix provides for a new optional renewal based token policy, that
allows the user to retain or recover old encryption certs for that profile,
that get overwritten by the renewal process.

An example is:

RENEW=YES;RENEW_KEEP_OLD_ENC_CERTS=YES

The second part of the policy is new.

When this is set to "YES", the system will make sure the old enc cert
will remain on the token. If it's missing or "NO", no such attempt will be made.
---
 base/tps/shared/conf/CS.cfg|  2 +-
 .../org/dogtagpki/server/tps/TPSTokenPolicy.java   | 10 ++-
 .../org/dogtagpki/server/tps/main/PKCS11Obj.java   |  3 +-
 .../server/tps/processor/EnrolledCertsInfo.java|  4 +
 .../server/tps/processor/TPSEnrollProcessor.java   | 94 +-
 5 files changed, 109 insertions(+), 4 deletions(-)

diff --git a/base/tps/shared/conf/CS.cfg b/base/tps/shared/conf/CS.cfg
index a8499a2..cdc45d05 100644
--- a/base/tps/shared/conf/CS.cfg
+++ b/base/tps/shared/conf/CS.cfg
@@ -2130,7 +2130,7 @@ tokendb.bindPassPath=[PKI_INSTANCE_PATH]/conf/password.conf
 tokendb.certBaseDN=ou=Certificates,[TOKENDB_ROOT]
 tokendb.confirmConfigChangesTemplate=confirmConfigChanges.template
 tokendb.confirmDeleteConfigTemplate=confirmDeleteConfig.template
-tokendb.defaultPolicy=RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO
+tokendb.defaultPolicy=RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO;RENEW_KEEP_OLD_ENC_CERTS=NO
 tokendb.deleteResultTemplate=deleteResults.template
 tokendb.deleteTemplate=delete.template
 tokendb.doTokenConfirmTemplate=doTokenConfirm.template
diff --git a/base/tps/src/org/dogtagpki/server/tps/TPSTokenPolicy.java b/base/tps/src/org/dogtagpki/server/tps/TPSTokenPolicy.java
index 1a866f7..158815b 100644
--- a/base/tps/src/org/dogtagpki/server/tps/TPSTokenPolicy.java
+++ b/base/tps/src/org/dogtagpki/server/tps/TPSTokenPolicy.java
@@ -33,9 +33,10 @@ import com.netscape.certsrv.base.IConfigStore;
 public class TPSTokenPolicy {
 private TPSSubsystem tps;
 private static final String DEFAULT_POLICY_SET_STRING =
-"RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO";
+"RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO;RENEW_KEEP_OLD_ENC_CERTS=NO";
 private boolean re_enroll = true;
 private boolean renew = false;
+private boolean renew_keep_old_enc_certs = false;
 private boolean force_format = false;
 private boolean pin_reset = true;
 private boolean reset_pin_reset_to_no = false;
@@ -85,6 +86,8 @@ public class TPSTokenPolicy {
 pin_reset = getBool(policy[1], false);
 else if (policy[0].equalsIgnoreCase("RESET_PIN_RESET_TO_NO"))
 reset_pin_reset_to_no = getBool(policy[1], false);
+else if (policy[0].equalsIgnoreCase("RENEW_KEEP_OLD_ENC_CERTS"))
+renew_keep_old_enc_certs = getBool(policy[1],false);
 //else no change, just take the default;
 }
 }
@@ -150,6 +153,11 @@ public class TPSTokenPolicy {
 return re_enroll;
 }
 
+public boolean isAllowdRenewSaveOldEncCerts(String cuid) {
+getUpdatedPolicy(cuid);
+return renew_keep_old_e

[Pki-devel] [pli-devel][PATCH] 0081-Fix-for-Add-ability-to-disallow-TPS-to-enroll-a-sing.patch

[John Magne]

Fix for: Add ability to disallow TPS to enroll a single user on multiple 
tokens. #1664

This bug was previously not completely fixed where we left a loophole to 
allow a user to
end up with 2 active tokens. This fix closes that loophole.

Also:

Fix for: Unable to read an encrypted email using renewed tokens. #2483

This fix provides for a new optional renewal based token policy, that
allows the user to retain or recover old encryption certs for that profile,
that get overwritten by the renewal process.

An example is:

RENEW=YES;RENEW_KEEP_OLD_ENC_CERTS=YES

The second part of the policy is new.

When this is set to "YES", the system will make sure the old enc cert
will remain on the token. If it's missing or "NO", no such attempt will be 
made.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] CMCEnroll man page + (proposed) HEADER/FOOTER changes

[John Magne]

ACK with a couple of caveats to fix:

Comments:


SYNOPSIS
   CMCEnroll  -d  -n 
 -r 
   -p 

The -d entry might be a little misleading. I think just saying this is a 
directory with the NSS db containing the agent cert should clarify.


  (4) Submit the signed certificate through the CA end-entities page:

  (a) Open the end-entities page.

This one I think should be "Submit the signed certificate request" 


That's it




- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Sent: Thursday, August 18, 2016 5:46:15 PM
Subject: [Pki-devel] [PATCH] CMCEnroll man page + (proposed) HEADER/FOOTER  
changes



Please review the following patches which add a CMCEnroll man page AND proposes 
code changes to the command line tools to allow them to used the preferred RFC 
7468 HEADERS and TRAILERS (see https://www.rfc-editor.org/rfc/rfc7468.txt ): 

* PKI TRAC Ticket #690 - [MAN] pki-tools man pages 
* PKI TRAC Ticket #2436 - Dogtag 10.3.6: Miscellaneous Enhancements 


The first patch contains all of the code changes, and the second patch simply 
contains the associated spec file change. 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Jack PTO Starting Monday Aug 22

[John Magne]

Returning Day after labor day.


Will be easily reachable if needed by mobile the whole time.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Added python-urllib3 dependency

[John Magne]

Looks reasonable:

ACK with all the customary tested to work disclaimers.

This statement has not been evaluated by the FDA

- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Sent: Friday, August 5, 2016 1:38:24 PM
Subject: [Pki-devel] [PATCH] Added python-urllib3 dependency



Please review this patch which addresses the following ticket: 

* PKI TRAC Ticket #2431 - Errors noticed during ipa server upgrade. 


-- Matt 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 327 - small fix for SERVER_KEYGEN slot substitution

[John Magne]

Tried this out myself, seems to work just fine.

ACK.


- Original Message -
From: "Ade Lee" 
To: pki-devel@redhat.com
Sent: Friday, July 29, 2016 4:30:28 AM
Subject: [Pki-devel] [PATCH] 327 - small fix for SERVER_KEYGEN slot 
substitution

Addresses Ticket 2418 - 
Some template substitution didn't happen during installation

(specifically SERVER_KEYGEN) 

Please review,
Ade

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0077-Make-starting-CRL-Number-configurable.patch

[John Magne]

Verbally acked by edewata thanks! :

pushed to master

Closing ticket: #2406



- Original Message -
> From: "John Magne" <jma...@redhat.com>
> To: "pki-devel" <pki-devel@redhat.com>
> Sent: Wednesday, July 27, 2016 11:53:34 AM
> Subject: [Pki-devel] [pki-devel][PATCH]   
> 0077-Make-starting-CRL-Number-configurable.patch
> 
> Make starting CRL Number configurable.
> 
> Ticket #2406 Make starting CRL Number configurable
> 
> This simple patch provides a pkispawn config param that passes
> some starting crl number value to the config process.
> 
> Here is a sample:
> 
> [CA]
> pki_ca_starting_crl_number=4000
> 
> After the CA comes up the value of "crlNumber" in the db will
> reflect that value of 4000.
> 
> Currently no other values are changed. We can talk about if we
> need more values reset in the given case.
> 
> Also, this creates a setting in the CS.cfg
> 
> ca.crl.MasterCrl.startingCrlNumber=4000
> 
> This setting is only consulted when the crl Issuing Point record is
> created
> for the first time.
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0076-MAN-Apply-generateCRMFRequest-removed-from-Firefox-w.patch

[John Magne]

Conditionally ACKED by cfu.
She wanted me to test the new ECC signing cert only profile I added:

Test was a success.

Pushed to master
Closing ticket #1285


Also release note bug on how to use the new profiles here:
https://bugzilla.redhat.com/show_bug.cgi?id=1355849

- Original Message -
From: "John Magne" <jma...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>, pki-devel@redhat.com
Cc: c...@redhat.com
Sent: Thursday, July 14, 2016 11:42:36 AM
Subject: [pki-devel][PATCH] 
0076-MAN-Apply-generateCRMFRequest-removed-from-Firefox-w.patch

 [MAN] Apply 'generateCRMFRequest() removed from Firefox'
 workarounds to appropriate 'pki' man page

Ticket #1285 

This fix will involve the following changes to the source tree.

1. Fixes to the CS.cfg to add two new cert profiles.
2. Make the caDualCert.cfg profile invisible since it has little chance of
working any more in Firefox.
3. Create caSigningUserCert.cfg and caSigningECUserCert.cfg to allow the CLI
to have convenient profiles from which to enroll signing ONLY certificates.

To go along with this I have filed a downstream release note bug that shows 
exactly how to
deploy the new  profile to separately create one signing cert and one 
encryption cert (with archival),
which allows one to accomplish what the formater caDualCert profile used to do 
when Firefox supported it.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] pki-cfu-0146-Ticket-978-PS-connector-man-page-add-revocation-rout.patch

[John Magne]

ACK:

One optional minor suggestion.
All over the place we now have stuff like this:

tps.connector.ca

Maybe just somewhere make it clear that  represents an integer between 1 and 
whatever we support.
Maybe just say that in the section talking about the ca list   : "ca1,ca2"

- Original Message -
From: "Christina Fu" 
To: "pki-devel" 
Sent: Thursday, 7 July, 2016 2:04:37 PM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0146-Ticket-978-PS-connector-man-page-add-revocation-rout.patch

Attached please find the patch that addresses:
https://fedorahosted.org/pki/ticket/978 TPS connector man page: add 
revocation routing info

thanks,
Christina

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0073-Separated-TPS-does-not-automatically-receive-shared-.patch

[John Magne]

ACKED verbally by cfu, with some very minor changes.

Pushed to master:


commit 0f056221d096a30307834265ecd1c527087bb0f7
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Mon Jun 13 11:27:59 2016 -0700

Separated TPS does not automatically receive shared secret from remote TKS.



Closing ticket # 2349




- Original Message -
From: "John Magne" <jma...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>
Sent: Thursday, June 23, 2016 3:33:44 PM
Subject: [pki-devel][PATCH] 
0073-Separated-TPS-does-not-automatically-receive-shared-.patch



[PATCH] Separated TPS does not automatically receive shared secret
 from remote TKS.

Support to allow the TPS to do the following:

1. Request that the TKS creates a shared secret with the proper ID, pointing to 
the TPS.
2. Have the TKS securely return the shared secret back to the TPS during the 
end of configuration.
3. The TPS then imports the wrapped shared secret into it's own internal NSS db 
permanenty and.
4. Given a name that is mapped to the TPS's id string.

Additional fixes:

1. The TKS was modified to actually be able to use multiple shared secrets 
registered by
multiple TPS instances.

Caveat:

At this point if the same remote TPS instance is created over and over again, 
the TPS's user
in the TKS will accumulate "userCert" attributes, making the exportation of teh 
shared secret
not functional. At this point we need to assume that the TPS user has ONE 
"userCert" registered
at this time.


Tested with a remote TPS talking to a shared TMS system consisting of a TPS, 
TKS, and KRA .

The shared secret was imported successfully after manually deleting the user 
representing the TPS from previous installs.
This way I was assured one cert stored for the user, since it had to be created 
fresh.

Also tested that the TKS can work successfully with the new TPS AND the prior 
shared TPS on the original instance.
The TKS can now host more than one shared secret in it's db and address the 
correct one when a given TPS makes a request of it.

Please forgive some spurious changes that happened when formatting a couple of 
the files in question. Every legit change is related to the shared secret and 
can be found easily.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0075-Generting-Symmetric-key-fails-with-key-generate-when.patch

[John Magne]

Pushed to master, ACK from mharmsen

Closing #1114


commit cfab57d057c7ada71ea9c360c278249d14e018d9
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Fri Jun 24 17:04:15 2016 -0700

Generting Symmetric key fails with key-generate when --usages verify is 
passed

Ticket #1114

Minor adjustment to the man page for the key management commands to say
which usages are appropriate for sym keys and those appropriate for asym 
keys.



- Original Message -
From: "Matthew Harmsen" <mharm...@redhat.com>
To: "John Magne" <jma...@redhat.com>, "pki-devel" <pki-devel@redhat.com>
Sent: Thursday, June 30, 2016 2:54:29 PM
Subject: Re: [Pki-devel] [pki-devel][PATCH] 
0075-Generting-Symmetric-key-fails-with-key-generate-when.patch

On 06/24/2016 06:23 PM, John Magne wrote:
> Generting Symmetric key fails with key-generate when --usages verify is passed
>  
>  Ticket #1114
>  
>  Minor adjustment to the man page for the key management commands to say
>  which usages are appropriate for sym keys and those appropriate for asym 
> keys.
>  
>
>
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [Patch] Add HSM information

[John Magne]

Tried it out the man pages, looks good.

ACK



- Original Message -
> From: "Matthew Harmsen" 
> To: "pki-devel" 
> Sent: Friday, July 1, 2016 1:52:02 PM
> Subject: [Pki-devel] [Patch] Add HSM information
> 
> Please review the attached patch which addresses the following ticket:
> 
> 
> * PKI TRAC Ticket #1405 - [MAN] Add additional HSM details to
> 'pki_default.cfg' & 'pkispawn' man pages
> 
> 
> This ticket adds text to the pki_default.cfg.5 and pkispawn.8 man pages to
> more adequatey describe the
> use of hardware security modules (HSM) with PKI subsystems.
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Separate PKI Instances versus Shared PKI Instances

[John Magne]

ACK

- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Sent: Wednesday, June 29, 2016 7:57:34 PM
Subject: [Pki-devel] [PATCH] Separate PKI Instances versus Shared PKI   
Instances

Please review the attached patch which addresses the following ticket: 


* PKI TRAC Ticket #1607 - [MAN] man pkispawn has inadequate description for 
shared vs non shared tomcat instance installation 


This ticket adds text to the pkispawn.8 man page to more adequately describe 
the differences between 
separated PKI instances and shared PKI instances including increasing the 
verbosity of the two examples 
related to these two deployment alternatives. 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0075-Generting-Symmetric-key-fails-with-key-generate-when.patch

[John Magne]

Generting Symmetric key fails with key-generate when --usages verify is passed

Ticket #1114

Minor adjustment to the man page for the key management commands to say
which usages are appropriate for sym keys and those appropriate for asym 
keys.

From a211222ee4b30ad390228adeb96645fd840be3ad Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 24 Jun 2016 17:04:15 -0700
Subject: [PATCH] Generting Symmetric key fails with key-generate when --usages
 verify is passed

Ticket #1114

Minor adjustment to the man page for the key management commands to say
which usages are appropriate for sym keys and those appropriate for asym keys.

t
---
 base/java-tools/man/man1/pki-key.1 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/base/java-tools/man/man1/pki-key.1 b/base/java-tools/man/man1/pki-key.1
index 30ac909..669ab86 100644
--- a/base/java-tools/man/man1/pki-key.1
+++ b/base/java-tools/man/man1/pki-key.1
@@ -329,7 +329,9 @@ Following is the description of the various parameters in the key retrieval temp
 -- clientKeyID - Client specified unique key identifier
 -- keyAlgorithm - Algorithm to be used to generate key (AES/DES/DES3/DESede/RC2/RC4)
 -- keySize - Value for the size of the key to be generated.
--- keyUsage - usages of the generated key(wrap,unwrap,sign,verify,encrypt,decrypt)
+-- keyUsage - usages of the generated key
+useful for Symmetric Keys (DES3,AES,etc) (wrap,unwrap,encrypt,decrypt)
+useful for Asymmetric Keys (RSA, EC,etc) (wrap,unwrap,encrypt,decrypt,sign,verify,sign_recover,verify_recover)
 
 To create a key generation request using the template file:
 
-- 
2.5.0

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0073-Separated-TPS-does-not-automatically-receive-shared-.patch

[John Magne]

[PATCH] Separated TPS does not automatically receive shared secret
 from remote TKS.

Support to allow the TPS to do the following:

1. Request that the TKS creates a shared secret with the proper ID, pointing to 
the TPS.
2. Have the TKS securely return the shared secret back to the TPS during the 
end of configuration.
3. The TPS then imports the wrapped shared secret into it's own internal NSS db 
permanenty and.
4. Given a name that is mapped to the TPS's id string.

Additional fixes:

1. The TKS was modified to actually be able to use multiple shared secrets 
registered by
multiple TPS instances.

Caveat:

At this point if the same remote TPS instance is created over and over again, 
the TPS's user
in the TKS will accumulate "userCert" attributes, making the exportation of teh 
shared secret
not functional. At this point we need to assume that the TPS user has ONE 
"userCert" registered
at this time.


Tested with a remote TPS talking to a shared TMS system consisting of a TPS, 
TKS, and KRA .

The shared secret was imported successfully after manually deleting the user 
representing the TPS from previous installs.
This way I was assured one cert stored for the user, since it had to be created 
fresh.

Also tested that the TKS can work successfully with the new TPS AND the prior 
shared TPS on the original instance.
The TKS can now host more than one shared secret in it's db and address the 
correct one when a given TPS makes a request of it.

Please forgive some spurious changes that happened when formatting a couple of 
the files in question. Every legit change is related to the shared secret and 
can be found easily.From ef5d954d1160002f6ed0ff05894f5968d7982d24 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Mon, 13 Jun 2016 11:27:59 -0700
Subject: [PATCH] Separated TPS does not automatically receive shared secret
 from remote TKS.

Support to allow the TPS to do the following:

1. Request that the TKS creates a shared secret with the proper ID, pointing to the TPS.
2. Have the TKS securely return the shared secret back to the TPS during the end of configuration.
3. The TPS then imports the wrapped shared secret into it's own internal NSS db permanenty and.
4. Given a name that is mapped to the TPS's id string.

Additional fixes:

1. The TKS was modified to actually be able to use multiple shared secrets registered by
multiple TPS instances.

Caveat:

At this point if the same remote TPS instance is created over and over again, the TPS's user
in the TKS will accumulate "userCert" attributes, making the exportation of teh shared secret
not functional. At this point we need to assume that the TPS user has ONE "userCert" registered
at this time.
---
 .../src/com/netscape/certsrv/key/KeyData.java  |  17 +-
 .../cms/servlet/csadmin/ConfigurationUtils.java| 252 -
 .../cms/servlet/tks/SecureChannelProtocol.java |   3 +-
 .../com/netscape/cms/servlet/tks/TokenServlet.java |  26 ++-
 .../server/tks/rest/TPSConnectorService.java   | 147 +---
 .../server/tps/processor/TPSProcessor.java |   8 +-
 .../server/tps/rest/TPSInstallerService.java   |  12 +-
 .../com/netscape/cmsutil/crypto/CryptoUtil.java| 157 +
 8 files changed, 426 insertions(+), 196 deletions(-)

diff --git a/base/common/src/com/netscape/certsrv/key/KeyData.java b/base/common/src/com/netscape/certsrv/key/KeyData.java
index 6da4d38..d50c9ec 100644
--- a/base/common/src/com/netscape/certsrv/key/KeyData.java
+++ b/base/common/src/com/netscape/certsrv/key/KeyData.java
@@ -48,7 +48,8 @@ public class KeyData {
 @XmlElement
 Integer size;
 
-String privateData;
+@XmlElement
+String additionalWrappedPrivateData;
 
 public KeyData() {
 // required for JAXB (defaults)
@@ -68,6 +69,14 @@ public class KeyData {
 this.wrappedPrivateData = wrappedPrivateData;
 }
 
+public String getAdditionalWrappedPrivateData() {
+return additionalWrappedPrivateData;
+}
+
+public void setAdditionalWrappedPrivateData(String additionalWrappedPrivateData) {
+this.additionalWrappedPrivateData = additionalWrappedPrivateData;
+}
+
 /**
  * @return the nonceData
  */
@@ -126,11 +135,5 @@ public class KeyData {
 this.size = size;
 }
 
-public String getPrivateData() {
-return privateData;
-}
 
-public void setPrivateData(String privateData) {
-this.privateData = privateData;
-}
 }
diff --git a/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java b/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java
index 2da4e48..56ee9fa 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java
@@ -15,7 +15,7 @@
 // (C) 2012 Red Hat, Inc.
 // All rights reserved.
 // --- END COPYRIGHT BLOCK ---
- 

Re: [Pki-devel] [pki-devel][PATCH] 0072-Revocation-failure-causes-AUDIT_PRIVATE_KEY_ARCHIVE_.patch

[John Magne]

ACK'd by cfu:

Pushed to master, closing ticket #2340

   
- Original Message -
From: "John Magne" <jma...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>
Sent: Tuesday, June 14, 2016 4:07:49 PM
Subject: [pki-devel][PATCH] 
0072-Revocation-failure-causes-AUDIT_PRIVATE_KEY_ARCHIVE_.patch

Revocation failure causes AUDIT_PRIVATE_KEY_ARCHIVE_REQUEST

The fix here is to make sure no archive related audits get issued for doing
things other than key archivals.

Other operations such as revoking and unrevoking cert in the code path 
laready
have audit logs issued separately for success or failure.

Ticket #2340.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Fix to ticket: [RFE] Enableocsp checking on KRA with CA's secure port shows self test failure

[John Magne]

https://fedorahosted.org/pki/ticket/1507

Pushed to master: 92cb1fc3271f5928e9ad0db798b67a5761aefdb1

Under the trivial check in rule, which consisted of a modification to a comment.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch

[John Magne]

Pushed to master based on cfu's verbal conditional ACK for this 
(after I modded it the way she requested)

Tested to work.

commit 3cd58a98022141da2af4bf0bad29ab1dbdc86fbe
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Wed Jun 1 15:05:20 2016 -0700




Closing ticket #1512

- Original Message -
> From: "Christina Fu" <c...@redhat.com>
> To: pki-devel@redhat.com
> Sent: Friday, June 3, 2016 2:46:28 PM
> Subject: Re: [Pki-devel] [pki-devel][PATCH] 
> 0069-Show-KeyOwner-info-when-viewing-recovery-requests.patch
> 
> while the patch works, I think the original code logic is somehow flawed in a
> way that it uses the "profile" attribute to determine whether the request
> was non-TMS archival requests, and if null it treats it as TMS. It would
> make better sense if we add a separate case instead of lumping the handling
> of recovery requests inside where the TMS handling is at.
> 
> thanks,
> Christina
> 
> On 06/01/2016 03:13 PM, John Magne wrote:
> 
> 
> 
> Show KeyOwner info when viewing recovery requests.
> 
> This simple fix will grab the subject info out of the cert
> associated with either pending or complete recovery requests being
> viewed in the KRA UI.
> 
> For example:
> 
> KeyOwner:  UID=jmagne, O=Token Key User
> 
> Will be displayed.
> Have seen this display for both pending and completed recovery requests.
> 
> This simple fix should be good enough for this round, despite the bug
> asking about agent info and such. Those enhancements for later.
> 
> Ticket : Ticket #1512 : Key owner info missing from the Search results of
> Recovery request
> 
> 
> ___
> Pki-devel mailing list Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch

[John Magne]

ACK

Does the job with little fuss.

One thing I would push for is to leave the original labels for standard requests
the way they were and NOT call them "Non Token " requests.

This we the old behavior remains and the user can explore the new options 
provided
for TMS related requests if they so choose.




- Original Message -
> From: "Christina Fu" 
> To: "pki-devel" 
> Sent: Friday, June 3, 2016 10:22:07 AM
> Subject: [Pki-devel] [PATCH] 
> pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch
> 
> https://fedorahosted.org/pki/ticket/2352
>  Ticket #2352 [TMS] missing netkeyKeyRecovery requests option in KRA
> agent for "List Request"
>  This patch allows KRA agent to list netkeyKeyRecovery requests
> 
> thanks,
> Christina
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Fix unknown TKS host and port error during TPS removal

[John Magne]

ACK

- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Sent: Wednesday, June 1, 2016 10:19:51 AM
Subject: [Pki-devel] [PATCH] Fix unknown TKS host and port error during TPS 
removal

Please review the attached patch which addresses the following ticket: 


* PKI TRAC #1677 - Pkidestroy of a TPS instance installed in a shared 
tomcat throws error. 


Without the patch: 


# pkidestroy 
Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: TPS 
Instance [pki-tomcat]: 

Begin uninstallation (Yes/No/Quit)? Yes 

Log file: /var/log/pki/pki-tps-destroy.20160601102651.log 
Loading deployment configuration from 
/var/lib/pki/pki-tomcat/tps/registry/tps/deployment.cfg. 
Uninstalling TPS from /var/lib/pki/pki-tomcat. 
pkidestroy : WARNING ... Failed to update TPS connector on TKS 
pkidestroy : ERROR ... TKS Host or Port is undefined 

Uninstallation complete. 
With the patch: 


# pkidestroy 
Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: TPS 
Instance [pki-tomcat]: 

Begin uninstallation (Yes/No/Quit)? Yes 

Log file: /var/log/pki/pki-tps-destroy.20160601110057.log 
Loading deployment configuration from 
/var/lib/pki/pki-tomcat/tps/registry/tps/deployment.cfg. 
Uninstalling TPS from /var/lib/pki/pki-tomcat. 

Uninstallation complete. 


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] pki-cfu-0123-Ticket-1665-Cert-Revocation-Reasons-not-being-update.patch

[John Magne]

Looks good:

Just a minor suggestion:

The bookean to markAsRevoked, you might want to rename as
"isAlreadyRevoked" to tell the reader more clearly what is going on.
We know we want to revoke a cert, but this boolean covers the case when the
cert to be revoked is already in the unique (on hold) status.

ACK then if tested to work, especially that routine that calculates if a cert
is currently on hold. If that has any issues, could be an issue.




- Original Message -
> From: "Christina Fu" 
> To: "pki-devel" 
> Sent: Tuesday, May 24, 2016 6:18:25 PM
> Subject: [Pki-devel] [PATCH] 
> pki-cfu-0123-Ticket-1665-Cert-Revocation-Reasons-not-being-update.patch
> 
> https://fedorahosted.org/pki/ticket/1665 Certificate Revocation Reasons
> not being updated in some cases
> 
> Ticket 1665 - Cert Revocation
> Reasons not being updated when on-hold
>  This patch fixes the following areas:
>  * In the CA, when revokeCert is called, make it possible to move
> from on_hold
>  to revoke.
>  * In the servlet that handles TPS revoke (DoRevokeTPS), make sure
> it allows
>  the on_hold cert to be put in the bucket to be revoked.
>  * there are a few minor fixes such as typos and one have to do with the
>  populate method in SubjectDNInput.java needs better handling of
> subject in
>  case it's null.
>  Note: This patch does not make attempt to allow agents to revoke
> certs that
>  are on_hold from agent interface.  The search filter needs to be
> modified to
>  allow that.
> 
> thanks,
> Christina
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0064-Port-symkey-JNI-to-Java-classes.patch

[John Magne]

Checked into master:

commit 1d60c55940e310aa77befe09c970db3831bb5042
Author: Jack Magne <jma...@dhcp-16-206.sjc.redhat.com>
Date:   Tue Mar 29 10:39:27 2016 -0700

Port symkey JNI to Java classes.
Ticket #801 : Merge pki-symkey into jss

What is supported:

1. Everything that is needed to support Secure Channel Protocol 01.
2. Supports the nist sp800 kdf and the original kdf.
3. Supports key unwrapping used by TPS which was formerly in the symkey JNI.

Requires:

1. A new JSS that supports more advanced symkey operations such as key 
derivation, more advanced key
unwrapping , and a way to list and identify a given symmetric key by name. 
Version of new Jss will be forthcoming.

Still to do:

1. Port over the 2 or 3 SCP02 routines from Symkey to use this code.
2. The original symkey will remain in place until we can port over 
everything.
3. SCP03 support can be added later.


New ticket created for future refinements:

https://fedorahosted.org/pki/ticket/2337


Closing #801


- Original Message -
From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Monday, May 23, 2016 8:56:40 AM
Subject: Re: [Pki-devel] [pki-devel][PATCH] 
0064-Port-symkey-JNI-to-Java-classes.patch

Just realized that I missed this comment for conditional ack:

It was already communicated to Jack. Please file a  ticket for this.
derivedKey = encryptDes3.derive();
  it throws exception when fail (in nethsm it seems to be the case now), 
and then default to encryption.
  It'd be better to provide a config param to turn on and off derive 
v.s. encryption in case we know for sure a certain hsm does not handle 
such thing, then the process won't waste the consistent exceptions.

Once again, great job on such daunting task!!
thanks,
Christina

On 05/18/2016 06:31 PM, Christina Fu wrote:
> This is the re-review of the patches that addressed my original comments.
> Overall I think it's good for this round.  I only have a few comments 
> and most have already been communicated to jack.
>
> Conditional ACK upon completion of the following, and of course, 
> tested to work:
>
> * Please open the new tickets for tasks you wish to push for later. 
> Feel free to combine things in same area into one ticket if it makes 
> sense. Please list the ticket(s) at commit response.
> * Please write a wrapper function computeKekKey() to call the 
> computeSessionKey_SCP01() with null null, so for people who read the 
> code it's clear that it's actually getting the kek key handle rather 
> than a session key.
> * wrapSessionKey() now takes a wrapping key, and if it's null, it 
> takes a global transportKey.  Please put this in a top block method 
> comment to make it clear what this method does
> * you defined cryptogram types (per my earlier comment), but you did 
> not replace the 0 and 1 in the calling method.
> * the top of method comment convention is usually using /* ...*/ 
> instead of a whole bunch of //'s
>
>
> thanks!
> Christina
>
>
> On 05/17/2016 06:44 PM, John Magne wrote:
>> Enclosed revised patches:
>>
>> Thanks to cfu for careful review.
>>
>> Also enclosed responses to comments ,for convenience.
>>
>>
>>
>>
>> - Original Message -
>>> From: "Christina Fu" <c...@redhat.com>
>>> To: pki-devel@redhat.com
>>> Sent: Friday, May 13, 2016 11:34:17 AM
>>> Subject: Re: [Pki-devel] [pki-devel][PATCH] 
>>> 0064-Port-symkey-JNI-to-Java-classes.patch
>>>
>>> Hi,
>>> First of all, I have to say that Jack did a wonderful job on such 
>>> daunting
>>> task. The sheer amount of code and complexity does make the review more
>>> challenging, but I dug through them with my teeth and claws 
>>> regardless ;-).
>>>
>>> We discussed and think we should postpone the checkin to next 
>>> release so we
>>> can make sure it gets the kind of attention in details that it 
>>> deserves.
>>>
>>> For the first round of reviews, I sent him two separate sets of review
>>> comments last week. One for JSS, and one for the rest.
>>> The JSS patch was not attached to his original email request for 
>>> review. It
>>> is attached to the following ticket:
>>> https://fedorahosted.org/pki/ticket/801
>>>
>>> You can find my review comments attached to this email.
>>>
>>> thanks,
>>> Christina
>>>
>>> On 04/15/2016 07:03 PM, John Magne wrote:
>>>
>>>
>>>
>>> Subject: [PATCH] Port symkey JNI to Java classes. Ticket #801 : Merge
>>>   pki-symkey into jss
>>>
>>> Wha

Re: [Pki-devel] [PATCH] pki-cfu-0122-Ticket-1527-reopened-retrieved-wrong-ca-connector-co.patch

[John Magne]

Looks good.

If tested to work conditional ACK.

Just one thing, when throwing a TPSException at the end of the patch,
please give it the error code, TPSStatus.STATUS_ERROR_CONTACT_ADMIN

- Original Message -
> From: "Christina Fu" 
> To: "pki-devel" 
> Sent: Tuesday, May 17, 2016 6:13:01 PM
> Subject: [Pki-devel] [PATCH] 
> pki-cfu-0122-Ticket-1527-reopened-retrieved-wrong-ca-connector-co.patch
> 
> Ticket #1527 (reopened) retrieved wrong ca connector config parameter
>  This ticket was reopened due to retrieving wrong ca connector
> config param under the situation when format is performed during enrollment.
>  The following is attempted:
>  op.enroll.userKey.ca.conn
>  while the following is intended:
>  op.format.userKey.ca.conn
>  In addition, this patch also fixes the following issues;
>  a. reason param name is not conforming: "reason" instead of
> "revokeReason"
>  b. adding default reason to format TPS profiles
>  c. by default mappingResolver.formatProfileMappingResolver resolves
> to tokenKey, while enroll resolves to userKey.
> -> now changed the userKey
>  d. if revocation fails during format, it was forgiving.
> -> now changed so that error is logged in activity log and exception
>thrown and bail out
> 
> Tested to work.
> 
> thanks,
> Christina
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Added Chrome keygen warning

[John Magne]

Took a look at this.

Seems pretty good, so ACK, with a concern or two.

I think we might want to consider seeing if we can somehow short circuit
the display to something that won't let them send to the server, when we
know we don't even have the keygen tag available.

So if tested to work with Firefox and Chrome, etc, ACK once again.

- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Cc: "Jack Magne" 
Sent: Thursday, May 12, 2016 3:45:11 PM
Subject: [PATCH] Added Chrome keygen warning

While testing chrome, we discovered that (a) keygen would soon not be 
supported:

  * 
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/pX5NbX0Xack

(b) although keygen is still supported, it has been disabled by default 
with a workaround provided to re-enable it:

  * 
https://support.quovadisglobal.com/kb/a470/deprecation-of-keygen-tag-in-chrome-chromium-browsers.aspx

Please review the attached patch which supplies a warning message and 
instructions on how to re-enable keygen
on Chrome browsers that support this:

  * PKI TRAC #2323 - Firefox Warning appears in EE page launched from
within Chrome 

Additionally, an attempt was made to identify the case when KeyGen would 
not be available on Firefox and Chrome.

-- Matt

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH]0061-Enhance-tkstool-for-capabilities-and-security.patch

[John Magne]

Ticket #1641 Enhance tkstool for capabilities and security

The key is now generated with the flags needed to keep the data from being 
displayed
with simple tools such as symkeyutil.


As per cfu's instructions,
I was able to test this with the nethsm only.

I also was able to make the key des3 and everything works fine with the master 
key.
This will help all the warnings we get about insecure des2 keys.

If there is a problem with luna, we can file another ticket.
Also there could be a built in tool for luna to generate keys such as is 
present on hsm.

Pushed to master.

- Original Message -
From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Wednesday, January 27, 2016 10:24:26 AM
Subject: Re: [Pki-devel] 
[pki-devel][PATCH]0061-Enhance-tkstool-for-capabilities-and-security.patch

I think I will be more conservative and give conditional ACK to this patch 
pending on tests on servers running on both LunaSA and nethsm. Although the 
code in the patch might very well work for both, those two HSM's are known to 
require different sets of pk11AtrFlags and often one set would work for one but 
not the other. 

thanks, 
Christina 

On 01/15/2016 04:24 PM, John Magne wrote: 



Enhance tkstool for capabilities and security

This simple ticket is to fix tkstool to allow it
to create the master key with the proper flags to make
the key data private such that it can't be easily viewed when
using tools to print out sym keys on the token.

Fix tested on the "internal" token by trying the various tkstool
cmds to make sure having the key private does not cause issues.
Also tried a simple key changeover operation with tpsclient to make
sure that symkey can still do what it needs to do witht the master key.

Further testing with a full hsm will be required.
The goal was the create the key with the same flags that are used with the
previous "PK11_GenKeyOnToken" (name approx) is used. This version had no
flags and created a default set. This fix uses the version With flags and
does what the old one did, but made sure the key is private and sensitive.

Master key can be tested by using the tool:

/usr/lib64/nss/unsupported-tools/symkeyutil -d ./ -L 


___
Pki-devel mailing list Pki-devel@redhat.com 
https://www.redhat.com/mailman/listinfo/pki-devel 


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] Fixed adminEnroll servlet browser import issue

[John Magne]

I tested myself by pointing to mharmsen's system, seems to work fine.

Conditional ACK on the patch, just remove some of the entries in we were not 
sure
you needed. We tested with just the bare minimum and it works.


- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Sent: Tuesday, May 3, 2016 11:42:02 AM
Subject: [Pki-devel] [PATCH] Fixed adminEnroll servlet browser import issue

Please review the attached patch which addresses: 


* PKI TRAC Ticket #1669 - adminEnroll servlet EnrollSuccess.template 
succeeds but fails on import into browser 

This was tested on Fedora 23 by doing the following: 


* installed and configured a CA 
* Successfully tested enrollment in a browser after importing the original 
Admin certificate 
* systemctl stop pki-tomcatd@pki-tomcat.service 
* edited /etc/pki/pki-tomcat/ca/CS.cfg to set: 


* ca.Policy.enable=true 
* cmsgateway.enableAdminEnroll=true 
* systemctl start pki-tomcatd@pki-tomcat.service 
* created a new Firefox profile 
* traversed to the EE page, went to the Retrieval tab, imported the CA 
cert, and trusted it 
* within this new profile, traversed to 
https://pki.example.com:8443/ca/admin/ca/adminEnroll.html , and filled out the 
form 
* with this patch installed, it should generate a new admin certificate and 
import it successfully into this new profile -- to check, attempt to use the 
imported admin certificate to traverse to the Agents page 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0066-TPS-auth-special-characters-fix.patch

[John Magne]

TPS auth special characters fix.

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.
From e6bcb9f1fac9c7db95a1aa4767cdfe6ac4ccbd16 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Wed, 27 Apr 2016 13:52:10 -0700
Subject: [PATCH] TPS auth special characters fix.

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.
---
 base/common/src/org/dogtagpki/tps/msg/TPSMessage.java | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/base/common/src/org/dogtagpki/tps/msg/TPSMessage.java b/base/common/src/org/dogtagpki/tps/msg/TPSMessage.java
index 84e991e..f622b9b 100644
--- a/base/common/src/org/dogtagpki/tps/msg/TPSMessage.java
+++ b/base/common/src/org/dogtagpki/tps/msg/TPSMessage.java
@@ -456,17 +456,17 @@ public class TPSMessage {
 break;
 case MSG_EXTENDED_LOGIN_RESPONSE:
 result =
-new ExtendedLoginResponseMsg(op_val,
-get(UID_NAME),
-get(PASSWORD_NAME),
-extsMap);
+new ExtendedLoginResponseMsg(op_val,
+Util.uriDecode(get(UID_NAME)),
+Util.uriDecode(get(PASSWORD_NAME)),
+extsMap);
 break;
 case MSG_LOGIN_REQUEST:
 break;
 case MSG_LOGIN_RESPONSE:
 result =
-new LoginResponseMsg(get(SCREEN_NAME_NAME),
-get(PASSWORD_NAME_1));
+new LoginResponseMsg(Util.uriDecode(get(SCREEN_NAME_NAME)),
+Util.uriDecode(get(PASSWORD_NAME_1)));
 break;
 case MSG_NEW_PIN_REQUEST:
 break;
-- 
2.5.0

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication support

[John Magne]

I took a look at the stuff alee asked for.

CFU even took a quick look when I asked her a couple of questions.
She was unsure of something (as was I) and she would like to be able
to take a closer look next week. I will give my quick thoughts.

1. I agree that HSM support is not in the patch, seems fine to move that
to a future ticket.

Here is one thing I was kind of worried about:
This is the code that imports the archive of the desired private key.


ublic static PrivateKey importPKIArchiveOptions(
+CryptoToken token, PrivateKey unwrappingKey,
+PublicKey pubkey, byte[] data)
+throws InvalidBERException, Exception {
+ByteArrayInputStream in = new ByteArrayInputStream(data);
+PKIArchiveOptions options = (PKIArchiveOptions)
+(new PKIArchiveOptions.Template()).decode(in);
+EncryptedKey encKey = options.getEncryptedKey();
+EncryptedValue encVal = encKey.getEncryptedValue();
+AlgorithmIdentifier algId = encVal.getSymmAlg();
+BIT_STRING encSymKey = encVal.getEncSymmKey();
+BIT_STRING encPrivKey = encVal.getEncValue();

This the wrapper object that is build off of the caSigningUnit key gotten
in the other patch, the RetrieverThread like this:



 PrivateKey unwrappingKey = hostCA.mSigningUnit.getPrivateKey();



The code below works fine if said key is RSA. I talked over with CFU and she 
said there
could be a chance this key is ECC for an ECC CA.

We both think the rest of the code in this routine is fine, except for possibly 
that.
She is also not even sure if JSS can support an ECC private key wrapper.

She requests you guys give her a day or two to look at it.

Except for the hsm issue, the code that calls this routine in the thread seems 
fine too.

+
+KeyWrapper wrapper = token.getKeyWrapper(KeyWrapAlgorithm.RSA);
+wrapper.initUnwrap(unwrappingKey, null);






+SymmetricKey sk = wrapper.unwrapSymmetric(
+encSymKey.getBits(), SymmetricKey.Type.DES3, 0);
+
+ASN1Value v = algId.getParameters();
+v = ((ANY) v).decodeWith(new OCTET_STRING.Template());
+byte iv[] = ((OCTET_STRING) v).toByteArray();
+IVParameterSpec ivps = new IVParameterSpec(iv);
+
+wrapper = token.getKeyWrapper(KeyWrapAlgorithm.DES3_CBC_PAD);
+wrapper.initUnwrap(sk, ivps);
+PrivateKey.Type keyType = pubkey.getAlgorithm().equals("EC")
+? PrivateKey.Type.EC
+: PrivateKey.Type.RSA;
+return wrapper.unwrapPrivate(encPrivKey.getBits(), keyType, pubkey);
+}


- Original Message -
> From: "Fraser Tweedale" 
> To: "Ade Lee" 
> Cc: pki-devel@redhat.com
> Sent: Wednesday, April 20, 2016 9:58:54 PM
> Subject: Re: [Pki-devel] [PATCH] 0084..0086 Lightweight CA replication
> support
> 
> Thanks Ade.  Updated patch 0096 attached.  Comments inline.
> 
> On Wed, Apr 20, 2016 at 11:30:52AM -0400, Ade Lee wrote:
> > Comments:
> > 
> > 95 - ack
> > 
> > 96 -
> > 
> > 1. You have made the return type of initSigUnit() to be boolean.
> >  Should you be checking the return value in init()?
> > 
> It is not needed to check it here; only when re-entering init from
> the KeyReplicatorRunner thread.
> 
> > 2. In addInstanceToAuthorityKeyHosts(), you are still using only the
> > hostname.  Should be host:port
> > 
> Good pickup.  Fixed in latest patch.
> 
> > 3. The logic in the KeyRetrieverRunner class looks OK to me, but I'd
> > like cfu and/or jmagne to check it and make sure we are calling the
> > right primitives to wrap/unwrap inside the cryptographic token.
> > 
> > Also I'd like them to confirm that this would wor for an HSM.
> > Statements like the following make me question that:
> >CryptoToken token = manager.getInternalKeyStorageToken()
> > 
> It won't work on HSM.  Can I get an HSM to test with? ;) I've filed
> a ticket for HSM support[1].  FreeIPA does not yet support HSM[2] so
> I think we can put it in 10.4 milestone (I've put it there for now).
> 
> [1] https://fedorahosted.org/pki/ticket/2292
> [2] https://fedorahosted.org/freeipa/ticket/5608
> 
> > 4. Can you explain what happens if for some reason the script fails to
> > retrieve the key?  Do we end up retrying later and if so, when?
> > 
> If the script fails to retrieve the key, it does not retry
> automatically.  I filed a ticket[3] to implement retry with
> backoff (this patchset is big enough already!) and put it in
> 10.3.1 milestone (that's up for discussion).
> 
> [3] https://fedorahosted.org/pki/ticket/2293
> 
> Right now, the following events cause authority reinitialisation,
> entailing key retrieval if necessary:
> 
> - Dogtag is restarted
> - LDAP disconnect-reconnect
> - LDAP modification of authority replicated from another clone
> 
> > 97- ACK
> > 
> > 98 - ACK
> >  
> Thanks.  Any feedback on patch 0099?
> 
> ___
> Pki-devel mailing list
> 

Re: [Pki-devel] [PATCH] pki-cfu-0117-Ticket-1519-token-format-should-delete-certs-from-to.patch

[John Magne]

ACK:

Just maybe make a method out of that in case we might need it elsewhere.

- Original Message -
From: "Christina Fu" 
To: "pki-devel" 
Sent: Tuesday, 5 April, 2016 4:04:58 PM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0117-Ticket-1519-token-format-should-delete-certs-from-to.patch

This patch fixes the following ticket:
https://fedorahosted.org/pki/ticket/1519 TPS UI lists the certs on the 
token when the token is in uninitialized state

It deletes certificates from token record when the token is formatted.

thanks,
Christina

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCH] pki-cfu-0116-Ticket-1006-Audit-logging-for-TPS-REST-operations.patch

[John Magne]

Looks fine:

What was done:

1. Creating some convenience functions to do the actual auditing.
2. Making sure we have auditing for the calls where things are changed
such as configuration /profile changes, or changing a token's state.
3. Making sure there are audit messages for the various error conditions caught
in exceptions.

I also took a look at a bunch of samples and they look good.
I did not spend days making sure every possible case it covered, but the code
and the framework looks good. Any holes will be discovered later.

ACK



- Original Message -
> From: "Christina Fu" 
> To: "pki-devel" 
> Sent: Thursday, 24 March, 2016 4:32:56 PM
> Subject: [Pki-devel] [PATCH] 
> pki-cfu-0116-Ticket-1006-Audit-logging-for-TPS-REST-operations.patch
> 
> Attached please find the patch for ticket 1006:
> https://fedorahosted.org/pki/ticket/1006 Audit logging for TPS REST
> operations
> 
> Most of the work is on
> 1. finding the right places to place the audit calls
> 2. deciding on what should be audited: since all read operations are
> captured by AUTZ, the REST operations audited are only write operations
> 3. deciding on the audit events that should be provided for the operations
> 4. making needed information available at the places where auditing is
> happening
> 
> thanks
> Christina
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [PATCHES] Updated tomcatjss and pki-core to work with Tomcat 7.0.68 on F22

[John Magne]

Looks fine :

ACK

I presume once all this is in,certain packages have to be available in koji or 
the build wont work.

- Original Message -
From: "Matthew Harmsen" 
To: "pki-devel" 
Cc: "Jack Magne" , "Matthew Harmsen" 
Sent: Wednesday, March 16, 2016 5:51:11 PM
Subject: [PATCHES] Updated tomcatjss and pki-core to work with Tomcat 7.0.68 on 
F22

Everyone,

Bodhi contains a proposed Fedora 22 update to Tomcat 7.0.68:

  * tomcat-7.0.68-3.fc22


This required changes to both tomcatjss (attached) and pki-core (attached).

These changes are specific to the Fedora 22 platform only; they have 
only been tested out via a Dogtag CA, not yet on FreeIPA, and require 
all of the following packages to be installed:

  * pki-base-10.2.6-12.fc22.noarch
  * pki-ca-10.2.6-12.fc22.noarch
  * pki-server-10.2.6-12.fc22.noarch
  * pki-tools-10.2.6-12.fc22.x86_64
  * tomcat-jsp-2.2-api-7.0.68-3.fc22.noarch
  * tomcat-servlet-3.0-api-7.0.68-3.fc22.noarch
  * tomcat-7.0.68-3.fc22.noarch
  * tomcat-lib-7.0.68-3.fc22.noarch
  * tomcat-el-2.2-api-7.0.68-3.fc22.noarch
  * tomcatjss-7.1.2-2.fc22.noarch

-- Matt

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] [pki-devel][PATCH] 0062-Allow-cert-and-key-indexes-9.patch

[John Magne]

ACKED by cfu:

Pushed to master: commit 9bd94a0a54793a0720b803846ce2291e5064c2ae

Various fedora libcoolkey builds done with patch to support this, winding 
through the system.

Closing #1734.

- Original Message -
From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Friday, February 5, 2016 4:22:40 PM
Subject: Re: [Pki-devel] [pki-devel][PATCH] 
0062-Allow-cert-and-key-indexes-9.patch

the code looks good. 
I applied the patch and upgraded my libcoolkey and played with it. I was able 
to enroll for 2 certs and "recover" 5 (makes a total of 7), and then continued 
to run externalReg enrollment again to delete one cert and recover another. 

ACK, 
Christina 

On 02/02/2016 06:46 PM, John Magne wrote: 



Subject: [PATCH] Allow cert and key indexes > 9.

Ticket: Ticket #1734 : TPS issue with overflowing PKCS#11 cert index numbers

This patch contains the following:

1. Fixes in TPS to allow the server to set and read muscle object ID's that are 
greater than 9.

The id is stored as a single ASCII byte in the object id. Previous libcoolkey 
patches exist to now support numbers
larger than 9, by the following:

0-9 is represented by the ascii chars for 0 through 9,.
10 - 35 represented by the ascii chars for 'A' through 'Z'.
36 - 61 represented by the ascii chars for 'a' through 'z'.

Once coolkey is updated it will be able to read these id's.

TPS with this patch will be able to both read number 0 - 62 and to set them 
when creating pkcs#11 objects to be stored on the token.

When the proper libcoolkey is installed, the coolkey driver will be able to 
read certs and keys with id's > 9. Thus, for instance a cert with an id of C6, 
with keys of k12, and k13, will be supported and viewable in the Firefox cert 
viewer. Also the certs will be usable for operations.

2. A fix to the routine that finds a free id number to assign to a soon to be 
recovered cert will now have the ability to find unused slots instead of just 
inrementing one over the highest currently used index.

3. Made a couple of minor cleanup fixes to externalReg functionality discovered 
during testing of this feature.

Tested up to 7 certs on the token. Also did some re-tests of cfu's cert 
retention feature and those checked. 


___
Pki-devel mailing list Pki-devel@redhat.com 
https://www.redhat.com/mailman/listinfo/pki-devel 


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [pki-devel][PATCH] 0062-Allow-cert-and-key-indexes-9.patch

[John Magne]

Subject: [PATCH] Allow cert and key indexes > 9.

Ticket: Ticket #1734 : TPS issue with overflowing PKCS#11 cert index numbers

This patch contains the following:

1. Fixes in TPS to allow the server to set and read muscle object ID's that are 
greater than 9.

The id is stored as a single ASCII byte in the object id. Previous libcoolkey 
patches exist to now support numbers
larger than 9, by the following:

0-9 is represented by the ascii chars for 0 through 9,.
10 - 35 represented by the ascii chars for 'A' through 'Z'.
36 - 61 represented by the ascii chars for 'a' through 'z'.

Once coolkey is updated it will be able to read these id's.

TPS with this patch will be able to both read number 0 - 62 and to set them 
when creating pkcs#11 objects to be stored on the token.

When the proper libcoolkey is installed, the coolkey driver will be able to 
read certs and keys with id's > 9. Thus, for instance a cert with an id of C6, 
with keys of k12, and k13, will be supported and viewable in the Firefox cert 
viewer. Also the certs will be usable for operations.

2. A fix to the routine that finds a free id number to assign to a soon to be 
recovered cert will now have the ability to find unused slots instead of just 
inrementing one over the highest currently used index.

3. Made a couple of minor cleanup fixes to externalReg functionality discovered 
during testing of this feature.

Tested up to 7 certs on the token. Also did some re-tests of cfu's cert 
retention feature and those checked.
From 911d7fde7a49d2f854f391ea95771b4000c8535e Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 22 Jan 2016 18:03:36 -0800
Subject: [PATCH] Allow cert and key indexes > 9.

Ticket: Ticket #1734 : TPS issue with overflowing PKCS#11 cert index numbers

This patch contains the following:

1. Fixes in TPS to allow the server to set and read muscle object ID's that are greater than 9.

The id is stored as a single ASCII byte in the object id. Previous libcoolkey patches exist to now support numbers
larger than 9, by the following:

0-9 is represented by the ascii chars for 0 through 9,.
10 - 35 represented by the ascii chars for 'A' through 'Z'.
36 - 61 represented by the ascii chars for 'a' through 'z'.

Once coolkey is updated it will be able to read these id's.

TPS with this patch will be able to both read number 0 - 62 and to set them when creating pkcs#11 objects to be stored on the token.

When the proper libcoolkey is installed, the coolkey driver will be able to read certs and keys with id's > 9. Thus, for instance a cert with an id of C6, with keys of k12, and k13, will be supported and viewable in the Firefox cert viewer. Also the certs will be usable for operations.

2. A fix to the routine that finds a free id number to assign to a soon to be recovered cert will now have the ability to find unused slots instead of just inrementing one over the highest currently used index.

3. Made a couple of minor cleanup fixes to externalReg functionality discovered during testing of this feature.
---
 .../org/dogtagpki/server/tps/main/ObjectSpec.java  | 208 +++-
 .../org/dogtagpki/server/tps/main/PKCS11Obj.java   |  92 -
 .../server/tps/processor/CertEnrollInfo.java   |   9 +-
 .../server/tps/processor/EnrolledCertsInfo.java|   7 +
 .../server/tps/processor/TPSEnrollProcessor.java   | 213 -
 5 files changed, 380 insertions(+), 149 deletions(-)

diff --git a/base/tps/src/org/dogtagpki/server/tps/main/ObjectSpec.java b/base/tps/src/org/dogtagpki/server/tps/main/ObjectSpec.java
index a8dbdb1..00cc447 100644
--- a/base/tps/src/org/dogtagpki/server/tps/main/ObjectSpec.java
+++ b/base/tps/src/org/dogtagpki/server/tps/main/ObjectSpec.java
@@ -236,7 +236,8 @@ public class ObjectSpec {
 // down to the cert's id, the code below changes both "4" and "5" back
 // to "2".
 
-int val = (objectID.charAt(1) - '0');
+int val = objectSpec.getObjectIndex();
+
 switch (objectID.charAt(0)) {
 case 'c':
 
@@ -290,7 +291,7 @@ public class ObjectSpec {
 
 fixedAttrs = 0x0080; /* CKA_TOKEN */
 xclass = (int) PKCS11Constants.CKO_CERTIFICATE;
-id = objectID.charAt(1) - '0';
+id = objectSpec.getObjectIndex();
 
 objectSpec.setFixedAttributes(fixedAttrs | (xclass << 4) | id);
 }
@@ -453,4 +454,207 @@ public class ObjectSpec {
 return data;
 }
 
+public int getObjectIndex() {
+return ObjectSpec.getObjectIndex(this.objectID);
+}
+
+public static int getObjectIndex(long objectID) {
+char char_index = (char) ((objectID >> 16) & 0xff);
+int index = -1;
+
+if (char_index >= '0' && char_index <= '9') {
+index = char_index - '0';
+}
+if (char_index >= 'A' && char_index <= 'Z') {
+index = char_index - 'A' + 10;
+}
+if (char_index >= 'a' && char_index <= 'z') {
+