Re: [Pki-devel] OCSP Configuration Problem

2020-05-14 Thread 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



[Pki-devel] dogtag: #2878 Missing faillure resumption detection and audit event logging at startup

2018-02-02 Thread John Magne

Review:

https://review.gerrithub.io/#/c/398121/


cfu has already accepted..


https://pagure.io/dogtagpki/issue/2878

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


[Pki-devel] [pki-devel][PATCH] 0098-SCP03-support-fix-Key-Changeover-with-HSM-RHCS.patch

2017-06-29 Thread John Magne
[PATCH] SCP03 support: fix Key Changeover with HSM (RHCS)

Ticket #2764.

This relatively simple fix involves making sure the correct crypto token is 
being used to search for the master key int the case of symmetric key changover 
where the master key resides on an HSM.
From e992fcdfbb6805e5f9310f8365398106e81fe357 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Thu, 29 Jun 2017 14:23:47 -0700
Subject: [PATCH] SCP03 support: fix Key Changeover with HSM (RHCS)

Ticket #2764.

This relatively simple fix involves making sure the correct crypto token is being used to search for the master key int the case of symmetric key changover where the master key resides on an HSM.
---
 .../cms/servlet/tks/SecureChannelProtocol.java | 29 ++
 1 file changed, 18 insertions(+), 11 deletions(-)

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 0542470..c3b3952 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
@@ -25,12 +25,12 @@ import org.mozilla.jss.crypto.SymmetricKey.NotExtractableException;
 import org.mozilla.jss.crypto.SymmetricKeyDeriver;
 import org.mozilla.jss.crypto.TokenException;
 
+import sun.security.pkcs11.wrapper.PKCS11Constants;
+
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.cmsutil.crypto.CryptoUtil;
 
-import sun.security.pkcs11.wrapper.PKCS11Constants;
-
 public class SecureChannelProtocol {
 
 static String sharedSecretKeyName = null;
@@ -1874,13 +1874,13 @@ public class SecureChannelProtocol {
 kekKey = returnDeveloperSymKey(newToken, SecureChannelProtocol.kekType, keySet, null,"DES3");
 } else if (protocol == PROTOCOL_THREE) {
 CMS.debug(method + " Special case or returning to the dev key set (or ver 1) for DiversifyKey, protocol 3!");
-encKey = this.computeSessionKey_SCP03(tokenName, newMasterKeyName, newKeyInfo,
+encKey = this.computeSessionKey_SCP03(newTokenName, newMasterKeyName, newKeyInfo,
 SecureChannelProtocol.encType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
-macKey = this.computeSessionKey_SCP03(tokenName, newMasterKeyName, newKeyInfo,
+macKey = this.computeSessionKey_SCP03(newTokenName, newMasterKeyName, newKeyInfo,
 SecureChannelProtocol.macType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
-kekKey = this.computeSessionKey_SCP03(tokenName, newMasterKeyName, newKeyInfo,
+kekKey = this.computeSessionKey_SCP03(newTokenName, newMasterKeyName, newKeyInfo,
 SecureChannelProtocol.kekType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
 }
@@ -1916,13 +1916,14 @@ public class SecureChannelProtocol {
 } else { // protocol 3
 
 CMS.debug(method + " Generating new card keys to upgrade to, protocol 3.");
-encKey = this.computeSessionKey_SCP03(tokenName, newMasterKeyName, oldKeyInfo,
+CMS.debug("tokenName: " + tokenName + " newTokenName: " + newTokenName);
+encKey = this.computeSessionKey_SCP03(newTokenName, newMasterKeyName, oldKeyInfo,
 SecureChannelProtocol.encType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
-macKey = this.computeSessionKey_SCP03(tokenName, newMasterKeyName, oldKeyInfo,
+macKey = this.computeSessionKey_SCP03(newTokenName, newMasterKeyName, oldKeyInfo,
 SecureChannelProtocol.macType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
-kekKey = this.computeSessionKey_SCP03(tokenName, newMasterKeyName, oldKeyInfo,
+kekKey = this.computeSessionKey_SCP03(newTokenName, newMasterKeyName, oldKeyInfo,
 SecureChannelProtocol.kekType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
 
@@ -1931,6 +1932,7 @@ public class SecureChannelProtocol {
 old_kek_sym_key = this.computeSessionKey_SCP03(tokenName, oldMasterKeyName, oldKeyInfo,
 SecureChannelProtocol.kekType, kekKeyArray,
 keySet, CUIDValue, KDD, null, null, transportKeyName, params);
+
 }
 
 if (encKey == null || macKey == null || kekKey == null) {
@@ -2076,9 +2078,14 @@ public class SecureChannelProtocol {
 encrypted_mac_key = this.wrapSessionKey(tokenName, 

Re: [Pki-devel] [PATCH] Ticket-2616-CMC-replace-id-cmc-statusInfo-with-id-cm.patch

2017-06-22 Thread John Magne
ACK

Makes sense to upgrade the error reporting and adhere to a newer standard.

Have seen a code walk through and a demo showcasing some of the new cases.



- Original Message -
> From: "Christina Fu" 
> To: pki-devel@redhat.com
> Sent: Wednesday, June 21, 2017 5:38:01 PM
> Subject: Re: [Pki-devel] [PATCH] 
> Ticket-2616-CMC-replace-id-cmc-statusInfo-with-id-cm.patch
> 
> 
> 
> and here is the patch...
> 
> On 06/21/2017 05:29 PM, Christina Fu wrote:
> 
> 
> 
> 
> This patch addresses:
> 
> https://pagure.io/dogtagpki/issue/2616 CMC: replace id-cmc-statusInfo with
> id-cmc-statusInfoV2
> 
> See patch comment for detail.
> 
> 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] Ticket-2737-CMC-check-HTTPS-client-authentication-ce.patch

2017-06-15 Thread 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] [PATCH] Ticket-2619-Allow-CA-to-process-user-signed-CMC-revo.patch

2017-06-08 Thread John Magne

Have seen a demo of the functionality working , as well as a live
walk through of the code by cfu, highlighting the crucial parts.



Looks good, one quick thing to change.

1.

static ContentInfo getCMCBlob(SignedData signedData, byte[] data) {

Could we just put a check to make sure that one or the other of the params are 
non null.
Also make sure that both are not null, which would result in a null pointer 
exception at some point.


ACK with the quick fix for #1


- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Wednesday, June 7, 2017 6:16:56 PM
Subject: [Pki-devel] [PATCH]
Ticket-2619-Allow-CA-to-process-user-signed-CMC-revo.patch



This patch is the implementation for ticket 
https://pagure.io/dogtagpki/issue/2619 Allow CA to process pre-signed CMC 
revocation non-signing cert requests 

Patch description in patch comment area. 


please review. 

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] 0095-Resolve-1663-Add-SCP03-support.patch

2017-06-02 Thread John Magne
PUshed to master:

commit a614eb15476adb00df571d3ea05fdd8ea282141d
Author: Jack Magne 
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" 
To: "John Magne" , "pki-devel" 
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


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

2017-06-02 Thread John Magne




Ticket: Resolve  #1663 Add SCP03 support .

This particular fix resolves a simple issue when formatting a token in FIPS 
mode for SCP03.
From de74c600391473759bec495dc4ccafda787959bd Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 2 Jun 2017 15:40:52 -0700
Subject: [PATCH] Resolve  #1663 Add SCP03 support .

This particular fix resolves a simple issue when formatting a token in FIPS mode for SCP03.
---
 .../netscape/cms/servlet/tks/NistSP800_108KDF.java | 28 +-
 .../server/tps/channel/SecureChannel.java  |  7 +++---
 .../server/tps/processor/TPSProcessor.java |  4 
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/base/server/cms/src/com/netscape/cms/servlet/tks/NistSP800_108KDF.java b/base/server/cms/src/com/netscape/cms/servlet/tks/NistSP800_108KDF.java
index 9e079aa..2d9e963 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/tks/NistSP800_108KDF.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/tks/NistSP800_108KDF.java
@@ -9,13 +9,6 @@ import java.util.Arrays;
 import java.util.HashMap;
 import java.util.Map;
 
-import org.apache.commons.cli.CommandLine;
-import org.apache.commons.cli.CommandLineParser;
-import org.apache.commons.cli.DefaultParser;
-import org.apache.commons.cli.Options;
-import org.apache.commons.cli.ParseException;
-import org.mozilla.jss.CryptoManager;
-import org.mozilla.jss.crypto.AlreadyInitializedException;
 import org.mozilla.jss.crypto.BadPaddingException;
 import org.mozilla.jss.crypto.Cipher;
 import org.mozilla.jss.crypto.CryptoToken;
@@ -468,7 +461,7 @@ public class NistSP800_108KDF extends KDF {
 // Collection of informal invocations of api used to create various session keys
 // Done with test data.
 public static void main(String[] args) {
-
+/*
  Options options = new Options();
 
 options.addOption("d", true, "Directory for tokendb");
@@ -480,16 +473,29 @@ public class NistSP800_108KDF extends KDF {
 (byte) 0x47, (byte) 0x48, (byte) 0x49, (byte) 0x4a, (byte) 0x4b, (byte) 0x4c, (byte) 0x4d, (byte) 0x4e,
 (byte) 0x4f };
 
+
+byte devKeyGem[] = { (byte) 0x47, (byte) 0x45, (byte) 0x4d, (byte) 0x58, (byte) 0x50, (byte) 0x52, (byte) 0x45,
+(byte) 0x53, (byte) 0x53, (byte) 0x4f, (byte) 0x53, (byte) 0x41, (byte) 0x4d, (byte) 0x50, (byte) 0x4c,
+(byte) 0x45 };
+
 byte test_cuid[] = { (byte) 0x47,(byte) 0x90,(byte)0x50,(byte)0x37,(byte)0x72,(byte)0x71,(byte)0x97,(byte)0x00,(byte)0x74,(byte)0xA9 };
 byte test_kdd[] = { 0x00 ,0x00, 0x04 ,(byte)0x47 ,0x00 ,(byte)0x1F ,0x00 ,(byte)0x46 ,(byte)0xA7 ,0x02 };
 
 
+byte test_kdd_gem[] = {};
+
+
 byte test_host_challenge[]  = { (byte)0x2F ,(byte)0xB7 ,(byte)0x9F ,(byte)0xB7 ,(byte)0x04 ,(byte)0xFA ,(byte)0x60 ,(byte)0xE8 };
 byte test_card_challenge[]  = { (byte)0xB9,(byte) 0x69 ,(byte)0xB0 ,(byte)0xCA ,(byte)0x37 ,(byte)0x27 ,(byte)0x2F ,(byte)0x89};
 
 byte test_host_challenge_1[] = { (byte)0xD9 ,(byte)0xA0 ,(byte)0x0E ,(byte)0x36 ,(byte)0x69 ,(byte)0x67 ,(byte)0xFA ,(byte)0xFB };
 byte test_card_challenge_1[] = {(byte)0x08 ,(byte) 0xF3 ,(byte) 0xE2 ,(byte)0xC3 ,0x72 ,(byte)0xF0 ,(byte)0xBE ,0x26 };
 
+
+byte test_host_challenge_gem[] = {(byte)0x5F, 02 ,(byte) 0x8A , 0x17,  0x35,(byte) 0x0B ,0x33,(byte) 0xA6};
+byte test_card_challenge_gem[] = { 0x7C,(byte) 0x81,(byte) 0xCB, 0x2D,(byte) 0xA2,(byte) 0xD4, 0x6B,(byte) 0xA9 };
+
+
 byte test_key_info[] = { (byte) 0x01,(byte) 03,(byte) 70 };
 byte test_old_key_info[] = {0x01,0x03,0x00};
 
@@ -525,8 +531,8 @@ public class NistSP800_108KDF extends KDF {
 SymmetricKey masterKey =  SecureChannelProtocol.getSymKeyByName(token,"new_master");
 
 GPParams params = new GPParams();
-params.setVersion1DiversificationScheme("emv");
-params.setDiversificationScheme("emv");
+params.setVersion1DiversificationScheme("visa2");
+params.setDiversificationScheme("visa2");
 params.setDevKeyType(GPParams.AES);
 params.setMasterKeyType(GPParams.AES);
 
@@ -576,6 +582,6 @@ public class NistSP800_108KDF extends KDF {
 System.err.println("JSS error!" + e);
 System.exit(1);
 }
-
+*/
 }
 }
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 5e5646b..3b80f27 100644
--- a/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
+++ b/base/tps/src/org/dogtagpki/server/tps/channel/SecureChannel.java
@@ -421,10 +421,11 @@ public class SecureChannel {
 throw new TPSException(method + "Failed to calculate card cryptogram!", TPSStatus.STATUS_ERROR_SECURE_CHANNEL);
 }
 
-CMS.debug(method + " dumped macSessionKey: " + new TPSBuffer(macSessionKey.getEncoded()).toHexString() );
+ 

Re: [Pki-devel] [pki-devel][PATCH] 0094-Tkstool-FIPS-Mode-fix.patch

2017-05-24 Thread John Magne



Provided cleanup and checked in:

commit 84f3958dc9c1c5bfab4a8789e621d621a28cbdd6
Author: Jack Magne 
Date:   Mon Apr 10 11:27:12 2017 -0700

Now the program can create and import shared secret keys while under FIPS 
mode.

Closed  #2540 Creating symmetric key (sharedSecret) using tkstool is failing 
when operating system is in FIPS mode. 

- Original Message -
> From: "Matthew Harmsen" 
> To: "John Magne" , "pki-devel" 
> Sent: Tuesday, May 23, 2017 4:44:42 PM
> Subject: Re: [Pki-devel] [pki-devel][PATCH] 0094-Tkstool-FIPS-Mode-fix.patch
> 
> On 05/22/2017 07:27 PM, John Magne wrote:
> >   #2540 Creating symmetric key (sharedSecret) using tkstool is failing when
> >   operating system is in FIPS mode.
> >
> >
> >
> >
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> Be sure to cleanup "context" if it exists in the "cleanup:" section.
> 
> Conditional ACK if tested to work.
> 
> 

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


[Pki-devel] [pki-devel][PATCH] 0094-Tkstool-FIPS-Mode-fix.patch

2017-05-22 Thread John Magne
 #2540 Creating symmetric key (sharedSecret) using tkstool is failing when 
operating system is in FIPS mode. 


From 820b3f16d1cb3f0532a464aee399512725c2a858 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Mon, 10 Apr 2017 11:27:12 -0700
Subject: [PATCH] Tkstool, FIPS Mode fix.

Now the program can create and import shared secret keys while under FIPS mode.
---
 base/native-tools/src/tkstool/key.c | 96 ++---
 base/native-tools/src/tkstool/tkstool.c |  4 +-
 base/native-tools/src/tkstool/tkstool.h |  3 +-
 3 files changed, 81 insertions(+), 22 deletions(-)

diff --git a/base/native-tools/src/tkstool/key.c b/base/native-tools/src/tkstool/key.c
index 4fd3796..a027d27 100644
--- a/base/native-tools/src/tkstool/key.c
+++ b/base/native-tools/src/tkstool/key.c
@@ -19,6 +19,11 @@
 
 #include "tkstool.h"
 
+secuPWDatapwdata = { PW_NONE,
+  0 };
+
+
+
 /***/
 /**  local private functions  **/
 /***/
@@ -534,16 +539,26 @@ TKS_ComputeAndDisplayKCV( PRUint8*newKey,
 goto done;
 }
 
-key = PK11_ImportSymKeyWithFlags(
-  /* slot   */slot,
-  /* mechanism type */CKM_DES3_ECB,
-  /* origin */PK11_OriginGenerated,
-  /* operation  */CKA_ENCRYPT,
-  /* key*/&keyItem,
-  /* flags  */CKF_ENCRYPT,
-  /* isPerm */PR_FALSE,
-  /* wincx  */0 );
+key =  TKS_ImportSymmetricKey( NULL,
+slot,
+CKM_DES3_ECB,
+CKA_ENCRYPT,
+&keyItem,
+&pwdata, PR_FALSE );
 
+
+
+
+ /*   key = PK11_ImportSymKeyWithFlags(
+  slot,
+  CKM_DES3_ECB,
+  PK11_OriginGenerated,
+  CKA_ENCRYPT,
+  &keyItem,
+  CKF_ENCRYPT,
+  PR_FALSE,
+  0 );
+ */
 if( ! key ) {
 PR_fprintf( PR_STDERR,
 "ERROR:  Failed to import %s key!\n\n\n",
@@ -1062,10 +1077,18 @@ TKS_ImportSymmetricKey( char  *symmetricKeyName,
 CK_MECHANISM_TYPE  mechanism,
 CK_ATTRIBUTE_TYPE  operation,
 SECItem   *sessionKeyShare,
-secuPWData*pwdata )
+secuPWData*pwdata, PRBool isPerm )
 {
 PK11Origin  origin = PK11_OriginGenerated;
 PK11SymKey *symKey = NULL;
+PK11SymKey *sessKey = NULL;
+PK11Context *context = NULL;
+static SECItem noParams = { siBuffer, NULL, 0 };
+SECItem wrappeditem = { siBuffer, NULL, 0 };
+
+int len = 0;
+unsigned char wrappedkey[DES_LENGTH * 3];
+SECStatus s = SECSuccess;
 
 if( slot == NULL ) {
 return NULL;
@@ -1077,15 +1100,50 @@ TKS_ImportSymmetricKey( char  *symmetricKeyName,
 "Generating %s symmetric key . . .\n\n",
 symmetricKeyName );
 
-symKey = PK11_ImportSymKeyWithFlags( 
- /* slot   */slot,
- /* mechanism type */mechanism,
- /* origin */origin,
- /* operation  */operation,
- /* key*/sessionKeyShare,
- /* flags  */0,
- /* isPerm */PR_FALSE,
- /* wincx  */pwdata );
+sessKey =  PK11_TokenKeyGenWithFlags(slot,   // slot handle
+   CKM_DES3_KEY_GEN,   // mechanism type
+   NULL,   // pointer to params (SECItem structure)
+   0,  // keySize (per documentation in pk11skey.c, must be 0 for fixed key length algorithms)
+   0,  // pointer to keyid (SECItem structure)
+   CKF_WRAP | CKF_UNWRAP | CKF_ENCRYPT | CKF_DECRYPT, // opFlags
+   PK11_ATTR_PRIVATE | PK11_ATTR_UNEXTRACTABLE | PK11_ATTR_SENSITIVE, // attrFlags (AC: this is my "best guess" as to what flags should be set)
+   NULL);
+
+if( sessKey == NULL ) {
+goto cleanup;
+}
+
+// Import the key onto the token using the temp session key and the key data.
+//
+
+context = PK11_CreateContextBySymKey(CKM_DES3_ECB, CKA_ENCRYPT,
+sessKey,
+&noParams);
+
+if (context == NULL) {
+goto cleanup;
+}
+
+len = sessionKeyShare->len;
+/* encrypt the key with the master key */
+s = PK11_CipherOp(context, wrappedkey, &len, DES_LENGTH * 3 , sessionKeyShare->data ,DES_LENGTH * 3 );
+if (s != SECSuccess)
+{
+goto cleanup;
+

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

2017-05-19 Thread 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

2017-05-17 Thread 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

2017-05-16 Thread 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

2017-05-12 Thread 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.

2017-05-05 Thread 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: " + drmDesKeyBuff.toHexString());
+
+ 

Re: [Pki-devel] [PATCH] Bug-1447145-CMC-cmc.popLinkWitnessRequired-false-wou.patch

2017-05-02 Thread John Magne

Makes sense.

ACK if tested to work.


- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Monday, May 1, 2017 5:54:19 PM
Subject: [Pki-devel] [PATCH]
Bug-1447145-CMC-cmc.popLinkWitnessRequired-false-wou.patch

The popLinkWitnessRequired check was placed in the wrong location which 
resulted in 0 requests if

popLinkWitnessRequired=false.

Workaround was to always set it to true.

This patch fixes it.

It also adds a missing authenticator CMCUserSignedAuth in CS.cfg for 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]

2017-04-26 Thread 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 a/base/server/cms/src/com/netscape/cms/profile/def/RandomizedValidityDefault.java b/base/server/c

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

2017-04-13 Thread 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 PKIData
  *
  * @param sign

[Pki-devel] [pki-devel][PATCH] 0091-SCP03 support for g&d 7 card.patch

2017-03-29 Thread John Magne
[PATCH] SCP03 support for g&d sc 7 card.

Ticket:

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


This allows the use of the g&d 7 card.
This will require the following:

1. An out of band method is needed to generate an AES based master key.
We do not as of yet have support with tkstool for this:

Ex:

/usr/lib64/nss/unsupported-tools/symkeyutil -d . -K -n new_master_aes -t aes -s 
16

2. There are some new config params that can be adjusted to support either the 
6.0 or 7.0 cards:

Ex:

tks.defKeySet._005=## tks.prot3   , protocol 3 specific settings
tks.defKeySet._006=## divers= emv,visa2 : Values for the master key case, or > 
version one.
tks.defKeySet._007=## diversVer1 = emv,visa2, or none. This is for developer or 
version one keyset
tks.defKeySet._008=## devKeyType = DES3or AES. This is for the key type of 
developer or version one keys.
tks.defKeySet._009=## masterKeyType = DES3 or AES. This is for the type of key 
for the master key.
tks.defKeySet._010=##
tks.defKeySet._011=## Only supports two tokens now: G&D Smart Cafe 6 and Smart 
Cafe 7, use these exact settings
tks.defKeySet._013=## Smart Cafe 6 settings:
tks.defKeySet._014=##tks.defKeySet.prot3.divers=emv
tks.defKeySet._015=##tks.defKeySet.prot3.diversVer1Keys=emv
tks.defKeySet._016=##tks.defKeySet.prot3.devKeyType=DES3
tks.defKeySet._017=##tks.defKeySet.prot3.masterKeyType=DES3
tks.defKeySet._018=##Smart Cafe 7 settings:
tks.defKeySet._019=##tks.defKeySet.prot3.divers=none
tks.defKeySet._020=##tks.defKeySet.prot3.diversVer1Keys=none
tks.defKeySet._021=##tks.defKeySet.prot3.devKeyType=AES
tks.defKeySet._022=##tks.defKeySet.prot3.masterKeyType=AES
tks.defKeySet._023=##
tks.defKeySet._024=##
From 171aa6fa5fcd1189cbd2e71dd162b677ba36180b Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 24 Mar 2017 15:56:17 -0700
Subject: [PATCH] SCP03 support for g&d sc 7 card.

This allows the use of the g&d 7 card.
This will require the following:

1. An out of band method is needed to generate an AES based master key.
We do not as of yet have support with tkstool for this:

Ex:

/usr/lib64/nss/unsupported-tools/symkeyutil -d . -K -n new_master_aes -t aes -s 16

2. There are some new config params that can be adjusted to support either the 6.0 or 7.0 cards:

Ex:

tks.defKeySet._005=## tks.prot3   , protocol 3 specific settings
tks.defKeySet._006=## divers= emv,visa2 : Values for the master key case, or > version one.
tks.defKeySet._007=## diversVer1 = emv,visa2, or none. This is for developer or version one keyset
tks.defKeySet._008=## devKeyType = DES3or AES. This is for the key type of developer or version one keys.
tks.defKeySet._009=## masterKeyType = DES3 or AES. This is for the type of key for the master key.
tks.defKeySet._010=##
tks.defKeySet._011=## Only supports two tokens now: G&D Smart Cafe 6 and Smart Cafe 7, use these exact settings
tks.defKeySet._013=## Smart Cafe 6 settings:
tks.defKeySet._014=##tks.defKeySet.prot3.divers=emv
tks.defKeySet._015=##tks.defKeySet.prot3.diversVer1Keys=emv
tks.defKeySet._016=##tks.defKeySet.prot3.devKeyType=DES3
tks.defKeySet._017=##tks.defKeySet.prot3.masterKeyType=DES3
tks.defKeySet._018=##Smart Cafe 7 settings:
tks.defKeySet._019=##tks.defKeySet.prot3.divers=none
tks.defKeySet._020=##tks.defKeySet.prot3.diversVer1Keys=none
tks.defKeySet._021=##tks.defKeySet.prot3.devKeyType=AES
tks.defKeySet._022=##tks.defKeySet.prot3.masterKeyType=AES
tks.defKeySet._023=##
tks.defKeySet._024=##
---
 .../src/com/netscape/cms/servlet/tks/GPParams.java |  21 
 .../netscape/cms/servlet/tks/NistSP800_108KDF.java | 114 +
 .../cms/servlet/tks/SecureChannelProtocol.java | 107 ++-
 .../com/netscape/cms/servlet/tks/TokenServlet.java |  20 
 base/tks/shared/conf/CS.cfg|  24 +
 base/tps/shared/conf/CS.cfg|   2 +-
 6 files changed, 174 insertions(+), 114 deletions(-)

diff --git a/base/server/cms/src/com/netscape/cms/servlet/tks/GPParams.java b/base/server/cms/src/com/netscape/cms/servlet/tks/GPParams.java
index f16481b..bda4e66 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/tks/GPParams.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/tks/GPParams.java
@@ -30,6 +30,8 @@ public class GPParams {
 public static String DIVER_NONE = "none";
 public static String DIVER_VISA2 = "visa2";
 public static String NIST_SP800 = "nistsp_800";
+public static String AES = "AES";
+public static String DES3 ="DES3";
 
 public GPParams() {
 }
@@ -39,6 +41,25 @@ public class GPParams {
 //Diversification scheme for just version one or developer keys
 private String version1DiversificationScheme;
 
+private String devKeyType;
+private String masterKeyType;
+
+public String getDevKeyType() {
+return devKeyType;
+}
+
+public String getMasterKeyType() {
+return masterKeyType;
+}
+
+public

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

2017-01-23 Thread 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

2017-01-04 Thread 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

2016-12-16 Thread 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;
+
+for (int i = 0; i < objectCount; i++) {
+ObjectSpec spec =

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

2016-12-09 Thread 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


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

2016-12-09 Thread John Magne
ACKED, by mharmsen, thanks!

Pushed to master:

commit ae350a3d4e0ae9b82fa44ebdfa37654f0083b4c1
Author: Jack Magne 
Date:   Thu Dec 8 16:35:20 2016 -0800

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.


Closing ticket #2552



- Original Message -
> From: "Matthew Harmsen" 
> To: "John Magne" , "pki-devel" 
> Sent: Thursday, December 8, 2016 5:36:24 PM
> Subject: Re: [Pki-devel] [pki-devel][PATCH] 
> 0086-Resolve-pkispawn-does-not-change-default-ecc-key-siz.patch
> 
> On 12/08/2016 05:42 PM, John Magne wrote:
> > Simple patch will provide a fix to this issue.
> >
> >
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> Tested original code to confirm incorrect ECC signing curve; tested
> patched code to confirm correct ECC signing curve.
> 
> ACK
> 
> 

___
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

2016-12-08 Thread 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]

2016-11-22 Thread 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 
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&D Cards.
https://bugzilla.redhat.com/show_bug.cgi?id=1320283

This fix addresses this bug , but also:
Fixes this issue:

Applet upgrade during rekey operation results in formatted token.

 Also, it takes care of a related issue where the new apdu needed for the
lifecycle state causes the testing tool "tpslcient" to seg fault.
The fix here is a minimal fix to have tpsclient return an error when it gets
this apdu it can't handle, instead of crashing.


Closed ticket # 2544



- Original Message -
> From: "Christina Fu" 
> 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


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

2016-11-15 Thread John Magne


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.

From bc03fc3c6f124dfaac33946c6983bde9b106af89 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Tue, 15 Nov 2016 17:37:07 -0800
Subject: [PATCH] Change lifecycle at end of enrollment if it is not already
 set.

---
 base/common/src/org/dogtagpki/tps/apdu/APDU.java   |  3 +-
 .../org/dogtagpki/tps/apdu/GetLifecycleAPDU.java   | 19 ++
 .../server/tps/processor/TPSEnrollProcessor.java   | 17 -
 .../server/tps/processor/TPSProcessor.java | 41 ++
 4 files changed, 78 insertions(+), 2 deletions(-)
 create mode 100644 base/common/src/org/dogtagpki/tps/apdu/GetLifecycleAPDU.java

diff --git a/base/common/src/org/dogtagpki/tps/apdu/APDU.java b/base/common/src/org/dogtagpki/tps/apdu/APDU.java
index 86f07ee..390252f 100644
--- a/base/common/src/org/dogtagpki/tps/apdu/APDU.java
+++ b/base/common/src/org/dogtagpki/tps/apdu/APDU.java
@@ -56,7 +56,8 @@ public abstract class APDU {
 APDU_IMPORT_KEY_ENC,
 APDU_SET_ISSUERINFO,
 APDU_GET_ISSUERINFO,
-APDU_GENERATE_KEY_ECC
+APDU_GENERATE_KEY_ECC,
+APDU_GET_LIFECYCLE
 }
 
 protected byte cla;
diff --git a/base/common/src/org/dogtagpki/tps/apdu/GetLifecycleAPDU.java b/base/common/src/org/dogtagpki/tps/apdu/GetLifecycleAPDU.java
new file mode 100644
index 000..3f82be1
--- /dev/null
+++ b/base/common/src/org/dogtagpki/tps/apdu/GetLifecycleAPDU.java
@@ -0,0 +1,19 @@
+package org.dogtagpki.tps.apdu;
+
+
+public class GetLifecycleAPDU extends APDU {
+public GetLifecycleAPDU() {
+setCLA((byte) 0xB0);
+setINS((byte) 0xf2);
+setP1((byte) 0x0);
+setP2((byte) 0x0);
+}
+
+@Override
+public Type getType()
+{
+return Type.APDU_GET_LIFECYCLE;
+}
+
+
+}
diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
index 31d3eed..1bdcf02 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
@@ -100,6 +100,12 @@ public class TPSEnrollProcessor extends TPSProcessor {
 
 AppletInfo appletInfo = null;
 TokenRecord tokenRecord = null;
+
+byte lifecycleState = (byte) 0xf0;
+
+
+lifecycleState = getLifecycleState();
+
 try {
 appletInfo = getAppletInfo();
 auditOpRequest("enroll", appletInfo, "success", null);
@@ -542,7 +548,16 @@ public class TPSEnrollProcessor extends TPSProcessor {
 writeIssuerInfoToToken(channel, appletInfo);
 
 statusUpdate(99, "PROGRESS_SET_LIFECYCLE");
-channel.setLifeycleState((byte) 0x0f);
+
+
+
+if( lifecycleState != 0x0f) {
+channel.setLifeycleState((byte) 0x0f);
+} else {
+CMS.debug(method + " No need to reset lifecycle state, it is already at the proper value.");
+}
+
+
 //update the tokendb with new certs
 CMS.debug(method + " updating tokendb with certs.");
 try {
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 582e3f9..75314b7 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSProcessor.java
@@ -60,6 +60,7 @@ import org.dogtagpki.server.tps.mapping.FilterMappingParams;
 import org.dogtagpki.tps.apdu.APDU;
 import org.dogtagpki.tps.apdu.APDUResponse;
 import org.dogtagpki.tps.apdu.GetDataAPDU;
+import org.dogtagpki.tps.apdu.GetLifecycleAPDU;
 import org.dogtagpki.tps.apdu.GetStatusAPDU;
 import org.dogtagpki.tps.apdu.GetVersionAPDU;
 import org.dogtagpki.tps.apdu.InitializeUpdateAPDU;
@@ -387,6 +388,44 @@ public class TPSProcessor {
 
 }
 
+protected byte getLifecycleState() {
+
+byte resultState = 0xf;
+
+String method = "TPSProcessor.getLifecycleState:";
+CMS.debug(".getLifecycleState: ");
+
+GetLifecycleAPDU getLifecycle = new GetLifecycleAPDU();
+
+try {
+
+selectCoolKeyApplet();
+
+APDUResponse response = handleAPDURequest(getLifecycle);
+
+if (!response.checkResult()) {
+return resultState;
+}
+
+TPSBuffer result = response.getResultDataNoCode();
+
+CMS.debug(method + " result size: " + result.size());
+
+if (result.size() >= 1) {
+resultState = result.at(0);
+
+CMS.debug(method + " result: "

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

2016-11-10 Thread 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.

2016-10-20 Thread 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.

2016-10-20 Thread 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

2016-10-20 Thread 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

2016-10-19 Thread John Magne
Pushed to master:

commit 9090451aa9f1a2dfcef8b852bb1e1d13d270098d
Author: Jack Magne 
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" 
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

2016-10-18 Thread 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

2016-10-18 Thread 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 RECOVERY_SCHEME_GENERATE_NEW_KEY_AND_RECOVER_LAST = "GenerateNewKeyandRecoverLast";

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

2016-10-10 Thread 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" 
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"  To: "pki-devel"  
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

2016-10-10 Thread 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

2016-10-07 Thread John Magne
Actually attach the patch.

- Forwarded Message -
From: "John Magne" 
To: "pki-devel" 
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 
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_enc_certs;
+}
+
 public boolean isAllowdTokenRenew(String cuid) {
 getUp

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

2016-10-07 Thread 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] pki-cfu-0153-Ticket-2496-Cert-Key-recovery-is-successful-when-the.patch

2016-10-07 Thread John Magne
ACK


One minor issue:

The explaining text in the CS.cfg is incorrect. It has the meaning
of the new flag reverse to what is intended:

When recovering by keyid: externalReg.recover.byKeyID=false
+externalReg._024=#   - keyid in record indicates actual recovery;
+externalReg._025=# e.g. (certstoadd: 36,ca1,5,kra1)
+externalReg._026=#   - missing of which means retention;
+externalReg._027=# e.g. (certstoadd: 36,ca1)
+externalReg._028=# When recovering by cert: 
externalReg.recover.byKeyID=true
+externalReg._029=#   - keyid field needs to be present
+externalReg._030=# but the value is not relevant and will be ignored
+externalReg._031=# (a "0" would be fine)
+externalReg._032=# e.g. (certstoadd: 36,ca1,0,kra1)
+externalReg._033=#   - missing of keyid still means retention;
+externalReg._034=# e.g. (certstoadd: 36,ca1)

false and true for byKeID is switched.


Also, since there is a small chance of impact to certain external reg features, 
such as retention,
it might make sense to recommend a quick sanity test of the external reg 
feature after this.

In the future we might want to more strongly discourage the keyid pathway.


- Original Message -
> From: "Christina Fu" 
> To: pki-devel@redhat.com
> Sent: Thursday, October 6, 2016 2:18:49 PM
> Subject: [Pki-devel] [PATCH] 
> pki-cfu-0153-Ticket-2496-Cert-Key-recovery-is-successful-when-the.patch
> 
> Attached  please find the patch for
> 
> https://fedorahosted.org/pki/ticket/2496 Cert/Key recovery is successful
> when the cert serial number and key id on the ldap user mismatches
> 
> Description is in patch summary.
> 
> 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] 0080-Authentication-Instance-Id-PinDirEnrollment-with-aut.patch

2016-08-19 Thread John Magne
Verbal cond ACK from CFU:


Minor issue taken care of:

commit e5ef4374eae5219a8b5e9a216c1c2ed77fb3e709
Author: Jack Magne 
Date:   Tue Aug 16 16:58:49 2016 -0700

Authentication Instance Id PinDirEnrollment with authType value as 
SslclientAuth is not working.

Pushed to master, closing ticket #1578



- Original Message -
> From: "John Magne" 
> To: "pki-devel" 
> Sent: Tuesday, August 16, 2016 5:15:49 PM
> Subject: [pki-devel][PATCH] 
> 0080-Authentication-Instance-Id-PinDirEnrollment-with-aut.patch
> 
> [PATCH] Authentication Instance Id PinDirEnrollment with authType
>  value as SslclientAuth is not working.
> 
> Ticket #1578
> 
> The fixing of this problem required the following:
> 
> 1. Hook up a java callback that is designed to allow the selection of a
> candidate
> client auth cert to be sent to Ldap in the LdapSSLSocket factory object.
> 
> Previously we simply manually set the desired client auth cert nickname,
> which is provided
> by the console interface when cofiguring the "removePin" portion of the
> UidPinDir Authentication method.
> 
> Doing it this way has the benefit of giving us some logging to show when the
> actual client auth cert is being
> requested by the server. We get to see the list of candidate certs and when
> we match one of those with the requested
> cert name, established by the console.
> 
> This client auth problem applies ONLY to the connection pool that is used to
> remove the pin attribute from
> an external authentication directory.
> 
> 2. Previously the code, when setting up client auth for "removePin", would
> make one single call to create the SSL socket
> to connect to ldap over client auth. Now, based on some code I saw in the JSS
> test suite, the socket is constructed in two
> steps. Doing this causes things to work. Further investigation down the line
> could figure out what is going on at the lower level.
> 
> 3. Was able to test this to work with the reported problem directory server
> provided by QE. Note: for pin removal to work, we must also
> make sure that the user we authenticating to (through client auth) has the
> power to actually remove the pin attribute from various users.
> 

___
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

2016-08-19 Thread 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

2016-08-18 Thread 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


[Pki-devel] [pki-devel][PATCH] 0080-Authentication-Instance-Id-PinDirEnrollment-with-aut.patch

2016-08-16 Thread John Magne
[PATCH] Authentication Instance Id PinDirEnrollment with authType
 value as SslclientAuth is not working.

Ticket #1578

The fixing of this problem required the following:

1. Hook up a java callback that is designed to allow the selection of a 
candidate
client auth cert to be sent to Ldap in the LdapSSLSocket factory object.

Previously we simply manually set the desired client auth cert nickname, which 
is provided
by the console interface when cofiguring the "removePin" portion of the 
UidPinDir Authentication method.

Doing it this way has the benefit of giving us some logging to show when the 
actual client auth cert is being
requested by the server. We get to see the list of candidate certs and when we 
match one of those with the requested
cert name, established by the console.

This client auth problem applies ONLY to the connection pool that is used to 
remove the pin attribute from
an external authentication directory.

2. Previously the code, when setting up client auth for "removePin", would make 
one single call to create the SSL socket
to connect to ldap over client auth. Now, based on some code I saw in the JSS 
test suite, the socket is constructed in two
steps. Doing this causes things to work. Further investigation down the line 
could figure out what is going on at the lower level.

3. Was able to test this to work with the reported problem directory server 
provided by QE. Note: for pin removal to work, we must also
make sure that the user we authenticating to (through client auth) has the 
power to actually remove the pin attribute from various users.
From 9dd3ac2da23ea053f4784356823213d6354c35f8 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Tue, 16 Aug 2016 16:58:49 -0700
Subject: [PATCH] Authentication Instance Id PinDirEnrollment with authType
 value as SslclientAuth is not working.

Ticket #1578

The fixing of this problem required the following:

1. Hook up a java callback that is designed to allow the selection of a candidate
client auth cert to be sent to Ldap in the LdapSSLSocket factory object.

Previously we simply manually set the desired client auth cert nickname, which is provided
by the console interface when cofiguring the "removePin" portion of the UidPinDir Authentication method.

Doing it this way has the benefit of giving us some logging to show when the actual client auth cert is being
requested by the server. We get to see the list of candidate certs and when we match one of those with the requested
cert name, established by the console.

This client auth problem applies ONLY to the connection pool that is used to remove the pin attribute from
an external authentication directory.

2. Previously the code, when setting up client auth for "removePin", would make one single call to create the SSL socket
to connect to ldap over client auth. Now, based on some code I saw in the JSS test suite, the socket is constructed in two
steps. Doing this causes things to work. Further investigation down the line could figure out what is going on at the lower level.

3. Was able to test this to work with the reported problem directory server provided by QE. Note: for pin removal to work, we must also
make sure that the user we authenticating to (through client auth) has the power to actually remove the pin attribute from various users.
---
 .../cmscore/ldapconn/LdapJssSSLSocketFactory.java  | 69 --
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/base/server/cmscore/src/com/netscape/cmscore/ldapconn/LdapJssSSLSocketFactory.java b/base/server/cmscore/src/com/netscape/cmscore/ldapconn/LdapJssSSLSocketFactory.java
index 182812c..0396ca9 100644
--- a/base/server/cmscore/src/com/netscape/cmscore/ldapconn/LdapJssSSLSocketFactory.java
+++ b/base/server/cmscore/src/com/netscape/cmscore/ldapconn/LdapJssSSLSocketFactory.java
@@ -18,9 +18,16 @@
 package com.netscape.cmscore.ldapconn;
 
 import java.io.IOException;
+import java.net.InetAddress;
 import java.net.Socket;
 import java.net.UnknownHostException;
+import java.util.Iterator;
+import java.util.Vector;
 
+import netscape.ldap.LDAPException;
+import netscape.ldap.LDAPSSLSocketFactoryExt;
+
+import org.mozilla.jss.ssl.SSLClientCertificateSelectionCallback;
 import org.mozilla.jss.ssl.SSLHandshakeCompletedEvent;
 import org.mozilla.jss.ssl.SSLHandshakeCompletedListener;
 import org.mozilla.jss.ssl.SSLSocket;
@@ -28,9 +35,6 @@ import org.mozilla.jss.ssl.SSLSocket;
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.logging.ILogger;
 
-import netscape.ldap.LDAPException;
-import netscape.ldap.LDAPSSLSocketFactoryExt;
-
 /**
  * Uses HCL ssl socket.
  *
@@ -54,7 +58,22 @@ public class LdapJssSSLSocketFactory implements LDAPSSLSocketFactoryExt {
 /*
  * let inherit TLS range and cipher settings
  */
-s = new SSLSocket(host, port);
+
+if (mClientAuthCertNickname == null) {
+s = new SSLSocket(host, port);
+ 

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

2016-08-05 Thread 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

2016-07-29 Thread 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

2016-07-27 Thread John Magne
Verbally acked by edewata thanks! :

pushed to master

Closing ticket: #2406



- Original Message -
> From: "John Magne" 
> To: "pki-devel" 
> 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


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

2016-07-27 Thread John Magne
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.
From f514cf776fd2918935bdd26939151f22f335cbe6 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Wed, 27 Jul 2016 11:43:33 -0700
Subject: [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.
---
 base/ca/src/com/netscape/ca/CRLIssuingPoint.java   | 65 +++---
 .../server/ca/rest/CAInstallerService.java |  7 +++
 .../certsrv/system/ConfigurationRequest.java   | 12 
 base/server/etc/default.cfg|  1 +
 .../python/pki/server/deployment/pkihelper.py  |  4 ++
 5 files changed, 69 insertions(+), 20 deletions(-)

diff --git a/base/ca/src/com/netscape/ca/CRLIssuingPoint.java b/base/ca/src/com/netscape/ca/CRLIssuingPoint.java
index fc9e6a3..a593eb8 100644
--- a/base/ca/src/com/netscape/ca/CRLIssuingPoint.java
+++ b/base/ca/src/com/netscape/ca/CRLIssuingPoint.java
@@ -31,6 +31,23 @@ import java.util.StringTokenizer;
 import java.util.TimeZone;
 import java.util.Vector;
 
+import netscape.security.util.BitArray;
+import netscape.security.x509.AlgorithmId;
+import netscape.security.x509.CRLExtensions;
+import netscape.security.x509.CRLNumberExtension;
+import netscape.security.x509.CRLReasonExtension;
+import netscape.security.x509.DeltaCRLIndicatorExtension;
+import netscape.security.x509.Extension;
+import netscape.security.x509.FreshestCRLExtension;
+import netscape.security.x509.IssuingDistributionPoint;
+import netscape.security.x509.IssuingDistributionPointExtension;
+import netscape.security.x509.RevocationReason;
+import netscape.security.x509.RevokedCertImpl;
+import netscape.security.x509.RevokedCertificate;
+import netscape.security.x509.X509CRLImpl;
+import netscape.security.x509.X509CertImpl;
+import netscape.security.x509.X509ExtensionException;
+
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.certsrv.base.IConfigStore;
@@ -66,23 +83,6 @@ import com.netscape.cmscore.dbs.CertRecord;
 import com.netscape.cmscore.dbs.CertificateRepository;
 import com.netscape.cmscore.util.Debug;
 
-import netscape.security.util.BitArray;
-import netscape.security.x509.AlgorithmId;
-import netscape.security.x509.CRLExtensions;
-import netscape.security.x509.CRLNumberExtension;
-import netscape.security.x509.CRLReasonExtension;
-import netscape.security.x509.DeltaCRLIndicatorExtension;
-import netscape.security.x509.Extension;
-import netscape.security.x509.FreshestCRLExtension;
-import netscape.security.x509.IssuingDistributionPoint;
-import netscape.security.x509.IssuingDistributionPointExtension;
-import netscape.security.x509.RevocationReason;
-import netscape.security.x509.RevokedCertImpl;
-import netscape.security.x509.RevokedCertificate;
-import netscape.security.x509.X509CRLImpl;
-import netscape.security.x509.X509CertImpl;
-import netscape.security.x509.X509ExtensionException;
-
 /**
  * This class encapsulates CRL issuing mechanism. CertificateAuthority
  * contains a map of CRLIssuingPoint indexed by string ids. Each issuing
@@ -112,6 +112,8 @@ public class CRLIssuingPoint implements ICRLIssuingPoint, Runnable {
 
 private static final int CRL_PAGE_SIZE = 1;
 
+private static final String PROP_CRL_STARTING_NUMBER = "startingCrlNumber";
+
 /* configuration file property names */
 
 public IPublisherProcessor mPublisherProcessor = null;
@@ -923,13 +925,36 @@ public class CRLIssuingPoint implements ICRLIssuingPoint, Runnable {
 if (crlRecord == null) {
 // no crl was ever created, or crl in db is corrupted.
 // create new one.
+
+IConfigStore ipStore = mCA.getConfigStore().getSubStore(ICertificateAuthority.PROP_CRL_SUBSTORE).g

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

2016-07-14 Thread 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" 
To: "pki-devel" , 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


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

2016-07-14 Thread John Magne
 [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.From 925f7a81a9e1cd898235ca512d4e0e198785ad56 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Wed, 13 Jul 2016 17:15:14 -0700
Subject: [PATCH] [MAN] Apply 'generateCRMFRequest() removed from Firefox'
 workarounds to appropriate 'pki' man page

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.
---
 base/ca/shared/conf/CS.cfg |  6 +-
 base/ca/shared/profiles/ca/caDualCert.cfg  |  2 +-
 base/ca/shared/profiles/ca/caSigningECUserCert.cfg | 86 ++
 base/ca/shared/profiles/ca/caSigningUserCert.cfg   | 86 ++
 4 files changed, 178 insertions(+), 2 deletions(-)
 create mode 100644 base/ca/shared/profiles/ca/caSigningECUserCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caSigningUserCert.cfg

diff --git a/base/ca/shared/conf/CS.cfg b/base/ca/shared/conf/CS.cfg
index 288f0d5..68e79a4 100644
--- a/base/ca/shared/conf/CS.cfg
+++ b/base/ca/shared/conf/CS.cfg
@@ -966,7 +966,7 @@ oidmap.pse.oid=2.16.840.1.113730.1.18
 oidmap.subject_info_access.class=netscape.security.extensions.SubjectInfoAccessExtension
 oidmap.subject_info_access.oid=1.3.6.1.5.5.7.1.11
 os.userid=nobody
-profile.list=caUserCert,caECUserCert,caUserSMIMEcapCert,caDualCert,caDirBasedDualCert,caECDualCert,AdminCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caSubsystemCert,caOtherCert,caCACert,caCrossSignedCACert,caInstallCACert,caRACert,caOCSPCert,caStorageCert,caTransportCert,caDirPinUserCert,caDirUserCert,caECDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthDRMstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,caInternalAuthAuditSigningCert,DomainController,caDualRAuserCert,caRAagentCert,caRAserverCert,caUUIDdeviceCert,caSSLClientSelfRenewal,caDirUserRenewal,caManualRenewal,caTokenMSLoginEnrollment,caTokenUserSigningKeyRenewal,caTokenUserEncryptionKeyRenewal,caTokenUserAuthKeyRenewal,caJarSigningCert,caIPAserviceCert,caEncUserCert,caEncECUserCert,caTokenUserDelegateAuthKeyEnrollment,caTokenUserDelegateSigningKeyEnrollment
+profile.list=caUserCert,caECUserCert,caUserSMIMEcapCert,caDualCert,caDirBasedDualCert,caECDualCert,AdminCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caSubsystemCert,caOtherCert,caCACert,caCrossSignedCACert,caInstallCACert,caRACert,caOCSPCert,caStorageCert,caTransportCert,caDirPinUserCert,caDirUserCert,caECDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthDRMstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,caInternalAuthAuditSigningCert,DomainController,caDualRAuserCert,caRAagentCert,caRAserverCert,caUUIDdeviceCert,caSSLClientSelfRenewal,caDirUserRenewal,caManualRenewal,caTokenMSLoginEnrollment,caTokenUserSigningKeyRenewal,caTokenUserEncryptionKeyRenewal,caTokenUserAuthKeyRenewal,caJarSigningCert,caIPAserviceCert,caEncUserCert,caSigningUserCert,caSigningECUserCert,caEncECUserCert,caTokenUserDelegateAuthKeyEnrollment,caTokenUserDelegateSigningKeyEnrollment
 profile.caUUIDdeviceCert.class_id=caEnrollImpl
 profile.caUUIDdeviceCert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/ca/caUUIDdeviceCert.cfg
 profile.caManualRenewal.class_id=caEnrollImpl
@@ -1037,6 +1037,10 @@ profile.caServerCert.class_id=caEnrollImpl
 profile.caServer

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

2016-07-08 Thread 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

2016-07-01 Thread John Magne
ACKED verbally by cfu, with some very minor changes.

Pushed to master:


commit 0f056221d096a30307834265ecd1c527087bb0f7
Author: Jack Magne 
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" 
To: "pki-devel" 
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

2016-07-01 Thread John Magne
Pushed to master, ACK from mharmsen

Closing #1114


commit cfab57d057c7ada71ea9c360c278249d14e018d9
Author: Jack Magne 
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" 
To: "John Magne" , "pki-devel" 
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

2016-07-01 Thread 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] [pki-devel] [PATCH] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch

2016-06-30 Thread John Magne

Addressed cfu's concerns and pushed to master for cond ACK.

commit e326cd2f06bd651cdd87646eea94622e18cec28d

Closing tiecket #1664

- Original Message -
> From: "Christina Fu" 
> To: pki-devel@redhat.com
> Sent: Monday, June 27, 2016 2:25:33 PM
> Subject: Re: [Pki-devel] [pki-devel] [PATCH] 
> 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch
> 
> Just a few minor ones.
> 
> * configuration parameters referencing token existence in tokendb should use
> names begin with "tokendb". e.g.

Done: Changed the names of the params as suggested.

> tokendb.allowMultiActiveTokensPerUser.externalReg=false
> tokendb.allowMultiActiveTokensPerUser.nonExternalReg=false
> 
> * boolean allowMultiCerts -- I think the name is misleading. how about
> alowMultiTokens
> 
> * existing calls to tps.tdb.tdbHasActiveToken() need to be decided:
> e.g.

Both of these blocks of code I simply removed the action taken if the user has 
an active token,
since they can no longer get there.
The alternate case has been left untouched.

The second occurrence is not likely to even happen since the transitions allowed
will not usually allow to go from SUSPENDED to ACTIVE anyway. Case retained as
a fallback.


> 1. TPSEnrollProcessor.java search for tdbHasActiveToken (first occurrence) ,
> you will find that it is called with "TODO:" comment. I believe that whole
> try/catch with the tps.tdb.tdbHasActiveToken(userid); call can be removed
> since you already call that earlier in your patch
> 2. TPSEnrollProcessor.java, the 2nd occurrence is when the enrolling token is
> suspended. You need to look into what it is doing at the point and whether
> that check can also be eliminated.
> 
> thanks,
> Christina
> 
> On 06/24/2016 11:08 AM, John Magne wrote:
> 
> 
> 
> Add ability to disallow TPS to enroll a single user on multiple tokens.
> 
> This patch will install a check during the early portion of the
> enrollment
> process check a configurable policy whether or not a user should be
> allowed
> to have more that one active token.
> 
> This check will take place only for brand new tokens not seen before.
> The check will prevent the enrollment to proceed and will exit before the
> system
> has a chance to add this new token to the TPS tokendb.
> 
> The behavior will be configurable for the the external reg and not
> external reg scenarios
> as follows:
> 
> op.enroll.nonExternalReg.allowMultiActiveTokensUser=false
> op.enroll.externalReg.allowMultiActiveTokensUser=false
> 
> 
> ___
> 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] Separate PKI Instances versus Shared PKI Instances

2016-06-30 Thread 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

2016-06-24 Thread 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] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch

2016-06-24 Thread John Magne

Add ability to disallow TPS to enroll a single user on multiple tokens.

This patch will install a check during the early portion of the enrollment
process check a configurable policy whether or not a user should be allowed
to have more that one active token.

This check will take place only for brand new tokens not seen before.
The check will prevent the enrollment to proceed and will exit before the 
system
has a chance to add this new token to the TPS tokendb.

The behavior will be configurable for the the external reg and not external 
reg scenarios
as follows:

op.enroll.nonExternalReg.allowMultiActiveTokensUser=false
op.enroll.externalReg.allowMultiActiveTokensUser=false
From f37a31bd9e59e6d93b9c9ea270a427d723a6d423 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Fri, 24 Jun 2016 11:02:35 -0700
Subject: [PATCH] Add ability to disallow TPS to enroll a single user on
 multiple tokens.

This patch will install a check during the early portion of the enrollment
process check a configurable policy whether or not a user should be allowed
to have more that one active token.

This check will take place only for brand new tokens not seen before.
The check will prevent the enrollment to proceed and will exit before the system
has a chance to add this new token to the TPS tokendb.

The behavior will be configurable for the the external reg and not external reg scenarios
as follows:

op.enroll.nonExternalReg.allowMultiActiveTokensUser=false
op.enroll.externalReg.allowMultiActiveTokensUser=false
---
 base/tps/shared/conf/CS.cfg|  2 +
 .../org/dogtagpki/server/tps/engine/TPSEngine.java |  2 +
 .../server/tps/processor/TPSEnrollProcessor.java   | 80 --
 3 files changed, 78 insertions(+), 6 deletions(-)

diff --git a/base/tps/shared/conf/CS.cfg b/base/tps/shared/conf/CS.cfg
index f552a54..0fbffc2 100644
--- a/base/tps/shared/conf/CS.cfg
+++ b/base/tps/shared/conf/CS.cfg
@@ -773,6 +773,8 @@ op.format.externalRegAddToToken.update.symmetricKeys.requiredVersion=1
 op.format.externalRegAddToToken.revokeCert=false
 op.format.externalRegAddToToken.revokeCert.reason=0
 op.enroll.allowUnknownToken=true
+op.enroll.nonExternalReg.allowMultiActiveTokensUser=false
+op.enroll.externalReg.allowMultiActiveTokensUser=false
 op.enroll.mappingResolver=enrollProfileMappingResolver
 op.enroll.soKey.cuidMustMatchKDD=false
 op.enroll.soKey.enableBoundedGPKeyVersion=true
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 a5fbc3b..a34be7c 100644
--- a/base/tps/src/org/dogtagpki/server/tps/engine/TPSEngine.java
+++ b/base/tps/src/org/dogtagpki/server/tps/engine/TPSEngine.java
@@ -153,6 +153,7 @@ public class TPSEngine {
 
 public static final String CFG_EXTERNAL_REG = "externalReg";
 public static final String CFG_ER_DELEGATION = "delegation";
+public static final String CFG_NON_EXTERNAL_REG = "nonExternalReg";
 
 /* misc values */
 
@@ -192,6 +193,7 @@ public class TPSEngine {
 public static final String ENROLL_MODE_ENROLLMENT = ENROLL_OP;
 public static final String ENROLL_MODE_RECOVERY = RECOVERY_OP;
 public static final String ERNOLL_MODE_RENEWAL = RENEWAL_OP;
+public static final String CFG_ALLOW_MULTI_TOKENS_USER = "allowMultiActiveTokensUser";
 
 public void init() {
 //ToDo
diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
index 6240ea6..3b8cdf3 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
@@ -14,6 +14,11 @@ import java.util.Map;
 import java.util.Random;
 import java.util.zip.DataFormatException;
 
+import netscape.security.provider.RSAPublicKey;
+//import org.mozilla.jss.pkcs11.PK11ECPublicKey;
+import netscape.security.util.BigInt;
+import netscape.security.x509.X509CertImpl;
+
 import org.dogtagpki.server.tps.TPSSession;
 import org.dogtagpki.server.tps.TPSSubsystem;
 import org.dogtagpki.server.tps.TPSTokenPolicy;
@@ -53,6 +58,8 @@ import org.mozilla.jss.pkcs11.PK11PubKey;
 import org.mozilla.jss.pkcs11.PK11RSAPublicKey;
 import org.mozilla.jss.pkix.primitive.SubjectPublicKeyInfo;
 
+import sun.security.pkcs11.wrapper.PKCS11Constants;
+
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.base.EBaseException;
 import com.netscape.certsrv.base.EPropertyNotFound;
@@ -60,12 +67,6 @@ import com.netscape.certsrv.base.IConfigStore;
 import com.netscape.certsrv.tps.token.TokenStatus;
 import com.netscape.cmsutil.util.Utils;
 
-import netscape.security.provider.RSAPublicKey;
-//import org.mozilla.jss.pkcs11.PK11ECPublicKey;
-import netscape.security.util.BigInt;
-import netscape.security.x509.X509CertImpl;
-import sun.security.pkcs11.wrapper.PKCS11Constants;
-
 public

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

2016-06-23 Thread 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 ---
- package com.netscape.cms.servlet.csadmin

Re: [Pki-devel] [PATCH] pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch

2016-06-17 Thread John Magne
Looked over.

Pretty straightforward additions.
As long as the stated successful test worked.

ACK

- Original Message -
From: "Christina Fu" 
To: pki-devel@redhat.com
Sent: Friday, June 17, 2016 5:08:17 PM
Subject: Re: [Pki-devel] [PATCH] 
pki-cfu-0140-Ticket-2346-support-SHA384withRSA.patch

forgot to attach patch... here you go.

On 06/17/2016 04:48 PM, Christina Fu wrote:
> This patch adds support for SHA384withRSA signing algorithm.
> It addresses ticket: https://fedorahosted.org/pki/ticket/2346 
> java.security.NoSuchAlgorithmException: no such algorithm: 
> OID.1.2.840.113549.1.1.12 for provider Mozilla-JSS when signing a CSR 
> using SHA384withRSA
>
> Tested to work with
> 1. the CSR provided by bug reporter in ticket against caServerCert 
> enrollment profile
> 2. few selected profiles
>
> sample result:
>
> Signature Algorithm: SHA384withRSA - 1.2.840.113549.1.1.12
>
> 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] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch

2016-06-17 Thread John Magne
If tested to work and no offending logs remain:

ACK

- Original Message -
From: "Christina Fu" 
To: "pki-devel" 
Sent: Friday, June 17, 2016 2:54:33 PM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch

This is the last patch for
ttps://fedorahosted.org/pki/ticket/2298 [non-TMS] for key 
archival/recovery, not to record certain data in ldap and logs

It mainly trims down the debug log and rids off CRMF requests.  it also 
gets rid of some excessive debugging in exercised areas.
In the last patch, CS.cfg is introduced a new profile, which 
accidentally got copied in a hard coded path, which is fixed too.

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] 0070-Fix-coverity-warnings-for-tkstool.patch

2016-06-17 Thread John Magne
ACK'ed by mharmsen, pushed to master:

Closing ticket #1199




- Original Message -
From: "John Magne" 
To: "pki-devel" 
Sent: Monday, June 6, 2016 4:39:43 PM
Subject: [pki-devel][PATCH] 0070-Fix-coverity-warnings-for-tkstool.patch


Fix attached.

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


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

2016-06-17 Thread John Magne
ACK'd by cfu:

Pushed to master, closing ticket #2340

   
- Original Message -
From: "John Magne" 
To: "pki-devel" 
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

2016-06-16 Thread 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


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

2016-06-14 Thread John Magne
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.
From cecb728768166c9dc252b4c9fe25e38b9cbb72db Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Tue, 14 Jun 2016 16:00:39 -0700
Subject: [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.
---
 base/ca/src/com/netscape/ca/CAService.java | 172 ++---
 1 file changed, 81 insertions(+), 91 deletions(-)

diff --git a/base/ca/src/com/netscape/ca/CAService.java b/base/ca/src/com/netscape/ca/CAService.java
index 485acc6..9bf237f 100644
--- a/base/ca/src/com/netscape/ca/CAService.java
+++ b/base/ca/src/com/netscape/ca/CAService.java
@@ -31,6 +31,33 @@ import java.util.Enumeration;
 import java.util.Hashtable;
 import java.util.Vector;
 
+import netscape.security.extensions.CertInfo;
+import netscape.security.util.BigInt;
+import netscape.security.util.DerValue;
+import netscape.security.x509.AlgorithmId;
+import netscape.security.x509.BasicConstraintsExtension;
+import netscape.security.x509.CRLExtensions;
+import netscape.security.x509.CRLReasonExtension;
+import netscape.security.x509.CertificateAlgorithmId;
+import netscape.security.x509.CertificateChain;
+import netscape.security.x509.CertificateExtensions;
+import netscape.security.x509.CertificateIssuerName;
+import netscape.security.x509.CertificateSerialNumber;
+import netscape.security.x509.CertificateSubjectName;
+import netscape.security.x509.CertificateValidity;
+import netscape.security.x509.Extension;
+import netscape.security.x509.LdapV3DNStrConverter;
+import netscape.security.x509.PKIXExtensions;
+import netscape.security.x509.RevocationReason;
+import netscape.security.x509.RevokedCertImpl;
+import netscape.security.x509.SerialNumber;
+import netscape.security.x509.X500Name;
+import netscape.security.x509.X500NameAttrMap;
+import netscape.security.x509.X509CRLImpl;
+import netscape.security.x509.X509CertImpl;
+import netscape.security.x509.X509CertInfo;
+import netscape.security.x509.X509ExtensionException;
+
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.authority.IAuthority;
 import com.netscape.certsrv.authority.ICertAuthority;
@@ -68,33 +95,6 @@ import com.netscape.cmscore.dbs.RevocationInfo;
 import com.netscape.cmscore.util.Debug;
 import com.netscape.cmsutil.util.Utils;
 
-import netscape.security.extensions.CertInfo;
-import netscape.security.util.BigInt;
-import netscape.security.util.DerValue;
-import netscape.security.x509.AlgorithmId;
-import netscape.security.x509.BasicConstraintsExtension;
-import netscape.security.x509.CRLExtensions;
-import netscape.security.x509.CRLReasonExtension;
-import netscape.security.x509.CertificateAlgorithmId;
-import netscape.security.x509.CertificateChain;
-import netscape.security.x509.CertificateExtensions;
-import netscape.security.x509.CertificateIssuerName;
-import netscape.security.x509.CertificateSerialNumber;
-import netscape.security.x509.CertificateSubjectName;
-import netscape.security.x509.CertificateValidity;
-import netscape.security.x509.Extension;
-import netscape.security.x509.LdapV3DNStrConverter;
-import netscape.security.x509.PKIXExtensions;
-import netscape.security.x509.RevocationReason;
-import netscape.security.x509.RevokedCertImpl;
-import netscape.security.x509.SerialNumber;
-import netscape.security.x509.X500Name;
-import netscape.security.x509.X500NameAttrMap;
-import netscape.security.x509.X509CRLImpl;
-import netscape.security.x509.X509CertImpl;
-import netscape.security.x509.X509CertInfo;
-import netscape.security.x509.X509ExtensionException;
-
 /**
  * Request Service for CertificateAuthority.
  */
@@ -192,7 +192,7 @@ public class CAService implements ICAService, IService {
 
 if (kraConfig != null) {
 mArchivalRequired = kraConfig.getBoolean(
-"archivalRequired", true);
+"archivalRequired", true);
 mKRAConnector = getConnector(kraConfig);
 if (mKRAConnector != null) {
 if (Debug.ON) {
@@ -293,10 +293,12 @@ public class CAService implements ICAService, IService {
 
 String clientCiphers = config.getString("clientCiphers", null);
 if (timeout == 0)
-connector = new HttpConnector((IAuthority) mCA, nickname, clientCiphers, remauthority, resendInterval, config);
+connector = new HttpConnector((IAuthority) mCA, nickname, clientCiphers, remauthority, rese

[Pki-devel] [pki-devel][PATCH] 0071-UdnPwdDirAuth-authentication-plugin-instance-is-not-.patch

2016-06-08 Thread John Magne

UdnPwdDirAuth authentication plugin instance is not working.

Ticket #1579 : UdnPwdDirAuth authentication plugin instance is not working.

Since this class no longer works, we felt it best to just remove it from 
the server.

This patch removes the references and files associated with this auth 
method,including the plugin
itself, so intrepid individuals will not be tempted to manually configure 
this auth method.

QE has nicely decided to independently remove the tests associated with this 
plugin already.
From b471e0d8e260e01833343c35557488be711ddf1f Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Tue, 7 Jun 2016 16:39:40 -0700
Subject: [PATCH] UdnPwdDirAuth authentication plugin instance is not working.

Ticket #1579 : UdnPwdDirAuth authentication plugin instance is not working.

Since this class no longer works, we felt it best to just remove it from the server.

This patch removes the references and files associated with this auth method.
---
 base/ca/shared/conf/CS.cfg |   1 -
 base/ca/shared/webapps/ca/ee/ca/UserDnEnroll.html  | 472 -
 .../netscape/admin/certsrv/ug/AuthBaseDialog.java  |   2 -
 .../admin/certsrv/ug/AuthConfigDialog.java |   3 -
 base/kra/shared/conf/CS.cfg|   1 -
 base/ocsp/shared/conf/CS.cfg   |   1 -
 .../authentication/UdnPwdDirAuthentication.java| 201 -
 .../src/com/netscape/cmscore/apps/Setup.java   |   1 -
 .../cmscore/connector/RequestTransfer.java |   1 -
 base/tks/shared/conf/CS.cfg|   1 -
 base/tps/shared/conf/CS.cfg|   1 -
 11 files changed, 685 deletions(-)
 delete mode 100644 base/ca/shared/webapps/ca/ee/ca/UserDnEnroll.html
 delete mode 100644 base/server/cms/src/com/netscape/cms/authentication/UdnPwdDirAuthentication.java

diff --git a/base/ca/shared/conf/CS.cfg b/base/ca/shared/conf/CS.cfg
index 989a322..c896251 100644
--- a/base/ca/shared/conf/CS.cfg
+++ b/base/ca/shared/conf/CS.cfg
@@ -169,7 +169,6 @@ auths.impl._002=##
 auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication
 auths.impl.CMCAuth.class=com.netscape.cms.authentication.CMCAuth
 auths.impl.SSLclientCertAuth.class=com.netscape.cms.authentication.SSLclientCertAuthentication
-auths.impl.UdnPwdDirAuth.class=com.netscape.cms.authentication.UdnPwdDirAuthentication
 auths.impl.UidPwdDirAuth.class=com.netscape.cms.authentication.UidPwdDirAuthentication
 auths.impl.UidPwdPinDirAuth.class=com.netscape.cms.authentication.UidPwdPinDirAuthentication
 auths.impl.UidPwdGroupDirAuth.class=com.netscape.cms.authentication.UidPwdGroupDirAuthentication
diff --git a/base/ca/shared/webapps/ca/ee/ca/UserDnEnroll.html b/base/ca/shared/webapps/ca/ee/ca/UserDnEnroll.html
deleted file mode 100644
index f4798d4..000
--- a/base/ca/shared/webapps/ca/ee/ca/UserDnEnroll.html
+++ /dev/null
@@ -1,472 +0,0 @@
-
-http://www.w3.org/TR/html4/loose.dtd";>
-
-
-Directory Based User Enrollment Form
-
-
- 
- 
- 
-
-