From edewata at redhat.com  Wed Aug  1 04:39:21 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 31 Jul 2012 23:39:21 -0500
Subject: [Pki-devel] [PATCH] 85 Added SSL authenticator with fallback.
In-Reply-To: <5017DB1D.7020600@redhat.com>
References: <50119E06.8040603@redhat.com> <5017DB1D.7020600@redhat.com>
Message-ID: <5018B2F9.90105@redhat.com>

On 7/31/2012 8:18 AM, Endi Sukma Dewata wrote:
> New patch attached. This patch contains the authenticator only. The SSL
> configuration will be modified in a later patch.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug  1 04:39:32 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 31 Jul 2012 23:39:32 -0500
Subject: [Pki-devel] [PATCH] 87 Refactored PKI JNDI realm.
In-Reply-To: <5017DB27.2010403@redhat.com>
References: <5017DB27.2010403@redhat.com>
Message-ID: <5018B304.2040707@redhat.com>

On 7/31/2012 8:18 AM, Endi Sukma Dewata wrote:
> The PKI JNDI realm has been modified to utilize the authentication
> and authorization subsystems in PKI engine directly. It's no longer
> necessary to define the LDAP connection settings in Tomcat's
> configuration files.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug  1 04:39:55 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 31 Jul 2012 23:39:55 -0500
Subject: [Pki-devel] [PATCH] 88 Merged pki-jndi-realm.jar into
	pki-cmscore.jar.
In-Reply-To: <5017DB2C.8000709@redhat.com>
References: <5017DB2C.8000709@redhat.com>
Message-ID: <5018B31B.4020902@redhat.com>

On 7/31/2012 8:18 AM, Endi Sukma Dewata wrote:
> On Tomcat 7 it's no longer necessary to have a separate package
> for the authenticator and realm classes. They are now packaged
> in pki-cmscore.jar which is deployed in Tomcat's common/lib.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug  1 22:44:18 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 01 Aug 2012 17:44:18 -0500
Subject: [Pki-devel] [PATCH] 27 Dogtag 10 Beta - Ticket 150 . Implement
 Cert search/list request in CLI
In-Reply-To: <1343749603.9474.1.camel@akoneru.redhat.com>
References: <1343749603.9474.1.camel@akoneru.redhat.com>
Message-ID: <5019B142.1020209@redhat.com>

On 7/31/2012 10:46 AM, Abhishek Koneru wrote:
> Please review the attached patch, which has the fix for Ticket 150. Implementing interface for all the UI search - request functionality in CLI.
> Also attached the sample cert request xml form file.
>
> --Abhishek Koneru

The patch needs rebasing and there's a conflict. As discussed, go ahead 
and override my recent changes to cert-find because it doesn't seem to 
be needed anymore. Some comments:

1. The CertFindCLI.printHelp() generates the following help message:

   usage: cert-find<filename>(Optional) [OPTIONS...]

I think we can use the [...] to indicate the optional filename, so it 
will look like this (also note the spacing):

   usage: cert-find [filename] [OPTIONS...]

2. Optional: We don't have this yet, but we might want to reserve the 
command line argument for search keyword which can be used to search all 
fields:

   pki cert-find abhishek

It would match 'abhishek' in username, email, subject DN, etc. If we 
decide to do this, we would use an option to specify the file name:

   usage: cert-find [keyword] [OPTIONS...]

     --input <filename>        File containing the search constraints.

3. The code in CertFindCLI.java:68 needs formatting.

4. The if-then condition in line 75 can be simplified as follows:

   if (<filename specified>) {
       // load searchData from file
   } else {
       // create default searchData
   }

   // modify searchData based on the options

The code in line 99-101 is no longer needed.

5. In line 104 it's not necessary to use a loop to iterate through all 
options.

   // modify searchData based on the options
   applyOptions(cmd, searchData)

In applyOptions() it can go through all possible options sequentially:

   if (!cmd.hasOption("minSerialNumber")) {
       searchData.setSerialNumberRangeInUse(true);
       searchData.setSerialFrom(cmd.getOptionValue("minSerialNumber"));
   }

   if (!cmd.hasOption("maxSerialNumber")) {
       searchData.setSerialNumberRangeInUse(true);
       searchData.setSerialTo(cmd.getOptionValue("maxSerialNumber"));
   }

It's not necessary to trim() the value because they are are already 
trimmed unless they are quoted.

6. In line 111 it should show the exception message.

7. In line 114 it should check the certInfos size too:

   if (certs.getCertInfos() == null || certs.getCertInfos().isEmpty()) {
       // no matches found
   }

8. In addOptions() the option descriptions are not consistent. Let's 
capitalize the first word only, e.g. "Minimum serial number", and use no 
space before colon, one space after that.

9. If an option has an argument (the third param is true) we should 
specify the argument name, for example:

   option = new Option(null, "validNotBeforeFrom", true,
       "Valid not before start date");
   option.setArgName("date")
   options.addOption(option);

It will appear as:

   --validNotBeforeFrom <date>    Valid not before start date

10. The option description should include the default value (if any) and 
acceptable values (if not obvious from the description) or example, for 
example the date format. This might require investigating the server 
code. Feel free to file a ticket for this.

11. The CertSearchData.valueOf() should take a more generic input, e.g. 
Reader, so it can be used to read other inputs, not just files.

-- 
Endi S. Dewata



From awnuk at redhat.com  Thu Aug  2 01:02:50 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Wed, 01 Aug 2012 18:02:50 -0700
Subject: [Pki-devel] ECC enrollments for IE
Message-ID: <5019D1BA.5090203@redhat.com>

This patch enables ECC enrollments for IE.

Bug: 748514.


-------------- next part --------------
Index: pki/redhat/ca-ui/shared/webapps/ca/ee/ca/ProfileSelect.template
===================================================================
--- pki/redhat/ca-ui/shared/webapps/ca/ee/ca/ProfileSelect.template	(revision 16023)
+++ pki/redhat/ca-ui/shared/webapps/ca/ee/ca/ProfileSelect.template	(working copy)
@@ -75,13 +75,39 @@
   if (keyFound == 0) {
     keyType = "RSA";
   }
-  if (navigator.appName == "Microsoft Internet Explorer") {
+  if ((navigator.appName == "Microsoft Internet Explorer") &&
+      ((navigator.appVersion).indexOf("NT 6.") == -1)) {
     keyType = "RSA";
   }
 
   return keyType;
 }
 
+function translateCurveName (name)
+{
+  var translated = "";
+  if (navigator.appName == "Microsoft Internet Explorer") {
+    if (name == "nistp256" || name == "ECDSA_P256") {
+      translated = "ECDSA_P256";
+    } else if (name == "nistp384" || name == "ECDSA_P384") {
+      translated = "ECDSA_P384";
+    } else if (name == "nistp521" || name == "ECDSA_P521") {
+      translated = "ECDSA_P521";
+    }
+  } else {
+    if (name == "ECDSA_P256") {
+      translated = "nistp256";
+    } else if (name == "ECDSA_P384") {
+      translated = "nistp384";
+    } else if (name == "ECDSA_P521") {
+      translated = "nistp521";
+    } else {
+      translated = name;
+    }
+  }
+  return translated;
+}
+
 function keyLengthsCurvesOptions (keyPurpose)
 {
   var keyType = "RSA";
@@ -111,23 +137,33 @@
       }
     }
   }
-  if (navigator.appName == "Microsoft Internet Explorer") {
+  if ((navigator.appName == "Microsoft Internet Explorer") &&
+      ((navigator.appVersion).indexOf("NT 6.") == -1)) {
     keyType = "RSA";
   }
 
   var value = 0;
-  var included = true;
   var l = 0;
   for (l = 0 ; l < lengthsOrCurves.length; l++) {
+      var included = true;
 
       value = lengthsOrCurves[l];
 
       if (keyType != "EC" && !isNumeric(value)) {
           included = false;
+      } else if (keyType == "EC" &&
+                 navigator.appName == "Microsoft Internet Explorer" &&
+                 value != "nistp256" && value != "nistp384" && value != "nistp521" &
+                 value != "ECDSA_P256" && value != "ECDSA_P384" && value != "ECDSA_P521") {
+          included = false;
       }
 
       if (included) {
-          options += '<OPTION VALUE="' + value + '"';
+          if (keyType == "EC") {
+              options += '<OPTION VALUE="' + translateCurveName(value) + '"';
+          } else {
+              options += '<OPTION VALUE="' + value + '"';
+          }
           if (i == 0) {
               options += ' SELECTED';
           }
@@ -139,9 +175,14 @@
      if (keyType != "EC") {
          options = '<OPTION VALUE=1024 SELECTED>1024';
      } else {
-         options = '<OPTION VALUE="nistp256">nistp256';
+         if (navigator.appName == "Microsoft Internet Explorer") {
+             options = '<OPTION VALUE="ECDSA_P256">nistp256';
+         } else {
+             options = '<OPTION VALUE="nistp256">nistp256';
+         }
      }
   }
+  //alert("options="+options);
 
   return options;
 }
@@ -355,13 +396,20 @@
   Dim osVersion
   Dim result
   Dim keyLen
+  Dim keyParameter
   Dim keyIndex
   Set TheForm = Document.ReqForm
 
   checkRequest = False
 
   keyIndex = TheForm.all.keyLength.options.selectedIndex
-  keyLen = CInt (TheForm.all.keyLength.options(keyIndex).value)
+  If (IsNumeric(TheForm.all.keyLength.options(keyIndex).value)) Then
+    keyLen = CInt (TheForm.all.keyLength.options(keyIndex).value)
+    keyParameter = ""
+  Else
+    keyLen = 0
+    keyParameter = TheForm.all.keyLength.options(keyIndex).value
+  End If
 
   osVersion = GetOSVersion()
 
@@ -451,6 +499,15 @@
       Exit Function
     End If
 
+    Set algobj = g_objClassFactory.CreateObject( "X509Enrollment.CObjectId" )
+    If IsObject(algobj) = False Then
+      result = MsgBox("Can't create OID Object. ! " & " Error: " & Err.number & " :" & Err.description,0,"")
+      Exit Function
+    End If
+    algobj.InitializeFromAlgorithmName XCN_CRYPT_ANY_GROUP_ID, XCN_CRYPT_OID_INFO_PUBKEY_ANY, AlgorithmFlagsNone, keyParameter
+    privateKey.Algorithm = algobj
+
+
     privateKey.KeySpec= "1" 
 
   ' Pick the provider that is selected
@@ -458,7 +515,9 @@
     index = options.selectedIndex
     privateKey.ProviderType = index
     privateKey.ProviderName = options(index).text
-    privateKey.Length = keyLen
+    If keyLen > 0 Then
+      privateKey.Length = keyLen
+    End If
 
     szName = "0.9.2342.19200300.100.1.1=" & TheForm.uid.Value & ",E=" & TheForm.email.Value & ",CN=" & TheForm.cn.Value
 
@@ -757,9 +816,11 @@
             Dim selected 
             Dim selectedS 
             Dim selectedE 
-            selected = 0
-            selectedS = 0
-            selectedE = 0
+            Dim selectedEC 
+            selected = -1
+            selectedS = -1
+            selectedE = -1
+            selectedEC = -1
             For i = 0 to csps.Count-1
                
                 curName = csps.ItemByIndex(i).Name
@@ -778,15 +839,22 @@
                   If curName = "Microsoft Enhanced Cryptographic Provider v1.0" Then
                     selectedE = i
                   End If
+                  If curName = "Microsoft Software Key Storage Provider" Then
+                    selectedEC = i
+                  End If
                   'result = MsgBox(curName,0,"")
                 End If 
             Next
-            If selectedE > 0  Then
+            If selectedEC >= 0  Then
+              TheForm.cryptprovider.selectedIndex = selectedEC
+            ElseIf selectedE >= 0  Then
               TheForm.cryptprovider.selectedIndex = selectedE
-            ElseIf selectedS > 0  Then
+            ElseIf selectedS >= 0  Then
               TheForm.cryptprovider.selectedIndex = selectedS
+            ElseIf selected >= 0  Then
+              TheForm.cryptprovider.selectedIndex = selected
             Else
-              TheForm.cryptprovider.selectedIndex = selected
+              TheForm.cryptprovider.selectedIndex = 0
             End If
         End If
 End Function

From mharmsen at redhat.com  Thu Aug  2 01:04:16 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 01 Aug 2012 18:04:16 -0700
Subject: [Pki-devel] ECC enrollments for IE
In-Reply-To: <5019D1BA.5090203@redhat.com>
References: <5019D1BA.5090203@redhat.com>
Message-ID: <5019D210.7090602@redhat.com>

On 08/01/12 18:02, Andrew Wnuk wrote:
> This patch enables ECC enrollments for IE.
>
> Bug: 748514.
>
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK.

I was presented a demo which proved that this code works correctly.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120801/08ccd27a/attachment.htm>

From mharmsen at redhat.com  Thu Aug  2 05:09:14 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 01 Aug 2012 22:09:14 -0700
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
	(08/01/2012)
Message-ID: <501A0B7A.3040408@redhat.com>

This patch documents continued implementation of the PKI Deployment 
Framework based upon the revised filesystem layout documented here:

  * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS

This patch addresses the following issues:

  * PKI TRAC Ticket #279 - Dogtag 10: Fix remaining 'cloning' issues in
    'pkispawn' . . .
  * PKI TRAC Ticket #280 - Dogtag 10: Fix remaining issues in
    'pkidestroy' related to deletion of more than one instance . . .
  * PKI TRAC Ticket #281 - Dogtag 10: Fix 'pkidaemon'/'operations' issue
    to handle individual instance . . .

It has been tested and proven to work successfully on a 64-bit Fedora 17 
machine (using the appropriate 'tomcatjss.jar').

P. S. -- Ade, as you are the most probable reviewer of this patch, 
please feel free to 'push' it to 'master' if you find it in order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120801/d28ffbd5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120801-PKI-Deployment-Scriptlets-Clone.patch
Type: text/x-patch
Size: 60730 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120801/d28ffbd5/attachment.bin>

From edewata at redhat.com  Thu Aug  2 20:24:52 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 02 Aug 2012 15:24:52 -0500
Subject: [Pki-devel] [PATCH] 86 Moved REST services into separate URLs.
In-Reply-To: <5017DB35.2000208@redhat.com>
References: <50120CBF.50002@redhat.com> <5017DB35.2000208@redhat.com>
Message-ID: <501AE214.3050603@redhat.com>

On 7/31/2012 8:18 AM, Endi Sukma Dewata wrote:
> On 7/26/2012 10:36 PM, Endi Sukma Dewata wrote:
>> To support different access control configurations the
>> REST services have been moved out of /pki into several
>> URLs.
>>
>> The certificate request submission service is now located
>> under /ee and it does not require authentication. The
>> configuration service is located under /installer and
>> it requires service-level authentication using PIN. The
>> remaining services are located under /agent and /admin.
>> They require realm authentication using client cert or
>> basic authentication and also require administrator or
>> agent access rights. Existing servlets are not affected
>> by this change.
>>
>> Ticket #107, #259
>
> New patch attached. The search/list operations for certificate and
> certificate request are now accessible without authentication under /ee.
>

New patch attached. The /ee and /admin methods have been moved back into 
the original class, but each method now will use absolute @Path.

Please apply in this order: 86-2, 89.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0086-2-Moved-REST-services-into-separate-URLs.patch
Type: text/x-patch
Size: 44177 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120802/366b6eb9/attachment.bin>

From awnuk at redhat.com  Thu Aug  2 20:49:51 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Thu, 02 Aug 2012 13:49:51 -0700
Subject: [Pki-devel] [PATCH] ECC directory enrollment profile
Message-ID: <501AE7EF.1080609@redhat.com>

This patch adds ECC directory enrollment profile.

Bug: 748514.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120802/ba5b7a37/attachment.htm>
-------------- next part --------------
Index: pki/base/ca/shared/profiles/ca/caECDirUserCert.cfg
===================================================================
--- pki/base/ca/shared/profiles/ca/caECDirUserCert.cfg	(revision 0)
+++ pki/base/ca/shared/profiles/ca/caECDirUserCert.cfg	(revision 0)
@@ -0,0 +1,99 @@
+desc=This certificate profile is for enrolling user certificates with directory-based authentication.
+visible=true
+enable=true
+enableBy=admin
+name=Directory-Authenticated User Dual-Use ECC Certificate Enrollment
+auth.instance_id=UserDirEnrollment
+input.list=i1
+input.i1.class_id=keyGenInputImpl
+output.list=o1
+output.o1.class_id=certOutputImpl
+policyset.list=userCertSet
+policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9
+policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl
+policyset.userCertSet.1.constraint.name=Subject Name Constraint
+policyset.userCertSet.1.constraint.params.pattern=UID=.*
+policyset.userCertSet.1.constraint.params.accept=true
+policyset.userCertSet.1.default.class_id=authTokenSubjectNameDefaultImpl
+policyset.userCertSet.1.default.name=Subject Name Default
+policyset.userCertSet.1.default.params.name=
+policyset.userCertSet.10.constraint.class_id=renewGracePeriodConstraintImpl
+policyset.userCertSet.10.constraint.name=Renewal Grace Period Constraint
+policyset.userCertSet.10.constraint.params.renewal.graceBefore=30
+policyset.userCertSet.10.constraint.params.renewal.graceAfter=30
+policyset.userCertSet.10.default.class_id=noDefaultImpl
+policyset.userCertSet.10.default.name=No Default
+policyset.userCertSet.2.constraint.class_id=validityConstraintImpl
+policyset.userCertSet.2.constraint.name=Validity Constraint
+policyset.userCertSet.2.constraint.params.range=365
+policyset.userCertSet.2.constraint.params.notBeforeCheck=false
+policyset.userCertSet.2.constraint.params.notAfterCheck=false
+policyset.userCertSet.2.default.class_id=validityDefaultImpl
+policyset.userCertSet.2.default.name=Validity Default
+policyset.userCertSet.2.default.params.range=180
+policyset.userCertSet.2.default.params.startTime=0
+policyset.userCertSet.3.constraint.class_id=keyConstraintImpl
+policyset.userCertSet.3.constraint.name=Key Constraint
+policyset.userCertSet.3.constraint.params.keyType=EC
+policyset.userCertSet.3.constraint.params.keyParameters=nistp256,nistp384,nistp521
+policyset.userCertSet.3.default.class_id=userKeyDefaultImpl
+policyset.userCertSet.3.default.name=Key Default
+policyset.userCertSet.4.constraint.class_id=noConstraintImpl
+policyset.userCertSet.4.constraint.name=No Constraint
+policyset.userCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl
+policyset.userCertSet.4.default.name=Authority Key Identifier Default
+policyset.userCertSet.5.constraint.class_id=noConstraintImpl
+policyset.userCertSet.5.constraint.name=No Constraint
+policyset.userCertSet.5.default.class_id=authInfoAccessExtDefaultImpl
+policyset.userCertSet.5.default.name=AIA Extension Default
+policyset.userCertSet.5.default.params.authInfoAccessADEnable_0=true
+policyset.userCertSet.5.default.params.authInfoAccessADLocationType_0=URIName
+policyset.userCertSet.5.default.params.authInfoAccessADLocation_0=
+policyset.userCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1
+policyset.userCertSet.5.default.params.authInfoAccessCritical=false
+policyset.userCertSet.5.default.params.authInfoAccessNumADs=1
+policyset.userCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
+policyset.userCertSet.6.constraint.name=Key Usage Extension Constraint
+policyset.userCertSet.6.constraint.params.keyUsageCritical=true
+policyset.userCertSet.6.constraint.params.keyUsageDigitalSignature=true
+policyset.userCertSet.6.constraint.params.keyUsageNonRepudiation=true
+policyset.userCertSet.6.constraint.params.keyUsageDataEncipherment=false
+policyset.userCertSet.6.constraint.params.keyUsageKeyEncipherment=true
+policyset.userCertSet.6.constraint.params.keyUsageKeyAgreement=false
+policyset.userCertSet.6.constraint.params.keyUsageKeyCertSign=false
+policyset.userCertSet.6.constraint.params.keyUsageCrlSign=false
+policyset.userCertSet.6.constraint.params.keyUsageEncipherOnly=false
+policyset.userCertSet.6.constraint.params.keyUsageDecipherOnly=false
+policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl
+policyset.userCertSet.6.default.name=Key Usage Default
+policyset.userCertSet.6.default.params.keyUsageCritical=true
+policyset.userCertSet.6.default.params.keyUsageDigitalSignature=true
+policyset.userCertSet.6.default.params.keyUsageNonRepudiation=true
+policyset.userCertSet.6.default.params.keyUsageDataEncipherment=false
+policyset.userCertSet.6.default.params.keyUsageKeyEncipherment=true
+policyset.userCertSet.6.default.params.keyUsageKeyAgreement=false
+policyset.userCertSet.6.default.params.keyUsageKeyCertSign=false
+policyset.userCertSet.6.default.params.keyUsageCrlSign=false
+policyset.userCertSet.6.default.params.keyUsageEncipherOnly=false
+policyset.userCertSet.6.default.params.keyUsageDecipherOnly=false
+policyset.userCertSet.7.constraint.class_id=noConstraintImpl
+policyset.userCertSet.7.constraint.name=No Constraint
+policyset.userCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl
+policyset.userCertSet.7.default.name=Extended Key Usage Extension Default
+policyset.userCertSet.7.default.params.exKeyUsageCritical=false
+policyset.userCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.4
+policyset.userCertSet.8.constraint.class_id=noConstraintImpl
+policyset.userCertSet.8.constraint.name=No Constraint
+policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
+policyset.userCertSet.8.default.name=Subject Alt Name Constraint
+policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
+policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
+policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
+policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
+policyset.userCertSet.8.default.params.subjAltNameNumGNs=1
+policyset.userCertSet.9.constraint.class_id=signingAlgConstraintImpl
+policyset.userCertSet.9.constraint.name=No Constraint
+policyset.userCertSet.9.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC
+policyset.userCertSet.9.default.class_id=signingAlgDefaultImpl
+policyset.userCertSet.9.default.name=Signing Alg
+policyset.userCertSet.9.default.params.signingAlg=-
Index: pki/base/ca/shared/conf/CS.cfg
===================================================================
--- pki/base/ca/shared/conf/CS.cfg	(revision 2394)
+++ pki/base/ca/shared/conf/CS.cfg	(working copy)
@@ -949,7 +949,7 @@
 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,caECDualCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caOtherCert,caCACert,caInstallCACert,caRACert,caOCSPCert,caTransportCert,caDirUserCert,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,caJarSigningCert,caIPAserviceCert,caEncUserCert,caEncECUserCert
+profile.list=caUserCert,caECUserCert,caUserSMIMEcapCert,caDualCert,caECDualCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caOtherCert,caCACert,caInstallCACert,caRACert,caOCSPCert,caTransportCert,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,caJarSigningCert,caIPAserviceCert,caEncUserCert,caEncECUserCert
 profile.caUUIDdeviceCert.class_id=caEnrollImpl
 profile.caUUIDdeviceCert.config=[PKI_INSTANCE_PATH]/profiles/ca/caUUIDdeviceCert.cfg
 profile.caManualRenewal.class_id=caEnrollImpl
@@ -974,6 +974,8 @@
 profile.caCMCUserCert.config=[PKI_INSTANCE_PATH]/profiles/ca/caCMCUserCert.cfg
 profile.caDirUserCert.class_id=caEnrollImpl
 profile.caDirUserCert.config=[PKI_INSTANCE_PATH]/profiles/ca/caDirUserCert.cfg
+profile.caECDirUserCert.class_id=caEnrollImpl
+profile.caECDirUserCert.config=[PKI_INSTANCE_PATH]/profiles/ca/caECDirUserCert.cfg
 profile.caDualCert.class_id=caEnrollImpl
 profile.caDualCert.config=[PKI_INSTANCE_PATH]/profiles/ca/caDualCert.cfg
 profile.caECDualCert.class_id=caEnrollImpl

From mharmsen at redhat.com  Thu Aug  2 21:23:56 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Thu, 02 Aug 2012 14:23:56 -0700
Subject: [Pki-devel] [PATCH] ECC directory enrollment profile
In-Reply-To: <501AE7EF.1080609@redhat.com>
References: <501AE7EF.1080609@redhat.com>
Message-ID: <501AEFEC.4080601@redhat.com>

On 08/02/12 13:49, Andrew Wnuk wrote:
> This patch adds ECC directory enrollment profile.
>
> Bug: 748514.
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK

I was given a demo to prove that this worked (including a dumpasn1 of 
the certificate).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120802/63803840/attachment.htm>

From akoneru at redhat.com  Thu Aug  2 23:23:22 2012
From: akoneru at redhat.com (Abhishek Koneru)
Date: Thu, 02 Aug 2012 19:23:22 -0400
Subject: [Pki-devel] [PATCH] 27-2 Fixes for review comments on [PATCH] 27
In-Reply-To: <5019B142.1020209@redhat.com>
References: <1343749603.9474.1.camel@akoneru.redhat.com>
	<5019B142.1020209@redhat.com>
Message-ID: <1343949802.32305.3.camel@akoneru.redhat.com>

Please review the attached patch with fixes for comments given on Patch
27.

--Abhishek

On Wed, 2012-08-01 at 17:44 -0500, Endi Sukma Dewata wrote:
> On 7/31/2012 10:46 AM, Abhishek Koneru wrote:
> > Please review the attached patch, which has the fix for Ticket 150. Implementing interface for all the UI search - request functionality in CLI.
> > Also attached the sample cert request xml form file.
> >
> > --Abhishek Koneru
> 
> The patch needs rebasing and there's a conflict. As discussed, go ahead 
> and override my recent changes to cert-find because it doesn't seem to 
> be needed anymore. Some comments:
> 
> 1. The CertFindCLI.printHelp() generates the following help message:
> 
>    usage: cert-find<filename>(Optional) [OPTIONS...]
> 
> I think we can use the [...] to indicate the optional filename, so it 
> will look like this (also note the spacing):
> 
>    usage: cert-find [filename] [OPTIONS...]
> 
> 2. Optional: We don't have this yet, but we might want to reserve the 
> command line argument for search keyword which can be used to search all 
> fields:
> 
>    pki cert-find abhishek
> 
> It would match 'abhishek' in username, email, subject DN, etc. If we 
> decide to do this, we would use an option to specify the file name:
> 
>    usage: cert-find [keyword] [OPTIONS...]
> 
>      --input <filename>        File containing the search constraints.
> 
> 3. The code in CertFindCLI.java:68 needs formatting.
> 
> 4. The if-then condition in line 75 can be simplified as follows:
> 
>    if (<filename specified>) {
>        // load searchData from file
>    } else {
>        // create default searchData
>    }
> 
>    // modify searchData based on the options
> 
> The code in line 99-101 is no longer needed.
> 
> 5. In line 104 it's not necessary to use a loop to iterate through all 
> options.
> 
>    // modify searchData based on the options
>    applyOptions(cmd, searchData)
> 
> In applyOptions() it can go through all possible options sequentially:
> 
>    if (!cmd.hasOption("minSerialNumber")) {
>        searchData.setSerialNumberRangeInUse(true);
>        searchData.setSerialFrom(cmd.getOptionValue("minSerialNumber"));
>    }
> 
>    if (!cmd.hasOption("maxSerialNumber")) {
>        searchData.setSerialNumberRangeInUse(true);
>        searchData.setSerialTo(cmd.getOptionValue("maxSerialNumber"));
>    }
> 
> It's not necessary to trim() the value because they are are already 
> trimmed unless they are quoted.
> 
> 6. In line 111 it should show the exception message.
> 
> 7. In line 114 it should check the certInfos size too:
> 
>    if (certs.getCertInfos() == null || certs.getCertInfos().isEmpty()) {
>        // no matches found
>    }
> 
> 8. In addOptions() the option descriptions are not consistent. Let's 
> capitalize the first word only, e.g. "Minimum serial number", and use no 
> space before colon, one space after that.
> 
> 9. If an option has an argument (the third param is true) we should 
> specify the argument name, for example:
> 
>    option = new Option(null, "validNotBeforeFrom", true,
>        "Valid not before start date");
>    option.setArgName("date")
>    options.addOption(option);
> 
> It will appear as:
> 
>    --validNotBeforeFrom <date>    Valid not before start date
> 
> 10. The option description should include the default value (if any) and 
> acceptable values (if not obvious from the description) or example, for 
> example the date format. This might require investigating the server 
> code. Feel free to file a ticket for this.
> 
> 11. The CertSearchData.valueOf() should take a more generic input, e.g. 
> Reader, so it can be used to read other inputs, not just files.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-akoneru-0027-2-Feature-Search-certificate-request-interface-in-CLI..patch
Type: text/x-patch
Size: 18607 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120802/6a38eb50/attachment.bin>

From alee at redhat.com  Fri Aug  3 15:37:32 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 03 Aug 2012 11:37:32 -0400
Subject: [Pki-devel] [PATCH] 44 - Fixed operations to operate on correct
 number of instances
Message-ID: <1344008252.5590.84.camel@aleeredhat.laptop>

Reverted previous fix to pkidaemon and operations.  Now, as
expected, systemctl start/stop pki-tomcatd at foo.service will stop
instance foo, whereas pki-tomcatd.target will affect all tomcatd
instances.

Please review.
Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0044-Fixed-operations-to-operate-on-correct-number-of-ins.patch
Type: text/x-patch
Size: 5415 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120803/6bd97ac9/attachment.bin>

From edewata at redhat.com  Fri Aug  3 19:24:37 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 03 Aug 2012 14:24:37 -0500
Subject: [Pki-devel] [PATCH] 86 Moved REST services into separate URLs.
In-Reply-To: <501AE214.3050603@redhat.com>
References: <50120CBF.50002@redhat.com> <5017DB35.2000208@redhat.com>
	<501AE214.3050603@redhat.com>
Message-ID: <501C2575.109@redhat.com>

New patch attached. The services are now split based on roles into 
/rest, /rest/admin, and /rest/agent.

Please apply in this order: 86-3, 89-1.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0086-3-Moved-REST-services-into-separate-URLs.patch
Type: text/x-patch
Size: 42086 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120803/1f6b4c6a/attachment.bin>

From edewata at redhat.com  Fri Aug  3 19:24:42 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 03 Aug 2012 14:24:42 -0500
Subject: [Pki-devel] [PATCH] 89 Enabled SSL authenticator and PKI realm.
In-Reply-To: <5017EB52.4050401@redhat.com>
References: <5017EB52.4050401@redhat.com>
Message-ID: <501C257A.2080609@redhat.com>

On 7/31/2012 9:27 AM, Endi Sukma Dewata wrote:
> The SSL connection has been configured with clientAuth="want" so
> users can choose whether to provide a client certificate or username
> and password. The authentication and authorization will be handled
> by the SSL authenticator with fallback and PKI realm. New access
> control rules have been added for users, groups, and certs REST
> services.
>
> Ticket #107
>

New patch attached. Fixed the ACLs and the paths to use /rest prefix.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0089-1-Enabled-SSL-authenticator-and-PKI-realm.patch
Type: text/x-patch
Size: 14238 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120803/5f967452/attachment.bin>

From edewata at redhat.com  Fri Aug  3 22:09:03 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 03 Aug 2012 17:09:03 -0500
Subject: [Pki-devel] [PATCH] 86 Moved REST services into separate URLs.
In-Reply-To: <501C2575.109@redhat.com>
References: <50120CBF.50002@redhat.com> <5017DB35.2000208@redhat.com>
	<501AE214.3050603@redhat.com> <501C2575.109@redhat.com>
Message-ID: <501C4BFF.9050801@redhat.com>

On 8/3/2012 2:24 PM, Endi Sukma Dewata wrote:
> New patch attached. The services are now split based on roles into
> /rest, /rest/admin, and /rest/agent.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Fri Aug  3 22:09:09 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 03 Aug 2012 17:09:09 -0500
Subject: [Pki-devel] [PATCH] 89 Enabled SSL authenticator and PKI realm.
In-Reply-To: <501C257A.2080609@redhat.com>
References: <5017EB52.4050401@redhat.com> <501C257A.2080609@redhat.com>
Message-ID: <501C4C05.80900@redhat.com>

On 8/3/2012 2:24 PM, Endi Sukma Dewata wrote:
> New patch attached. Fixed the ACLs and the paths to use /rest prefix.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From awnuk at redhat.com  Sat Aug  4 00:49:18 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Fri, 03 Aug 2012 17:49:18 -0700
Subject: [Pki-devel] certificate import for IE
Message-ID: <501C718E.6030208@redhat.com>

This patch corrects certificate import for IE

Bug: 845387.
-------------- next part --------------
Index: pki/redhat/ca-ui/shared/webapps/ca/ee/ca/ImportCert.template
===================================================================
--- pki/redhat/ca-ui/shared/webapps/ca/ee/ca/ImportCert.template	(revision 15995)
+++ pki/redhat/ca-ui/shared/webapps/ca/ee/ca/ImportCert.template	(working copy)
@@ -134,6 +134,7 @@
 //-->
 </SCRIPT>
 
+<!--
 <OBJECT
 	classid="clsid:127698e4-e730-4e5c-a2b1-21490a70c8a1"
 	CODEBASE="/xenroll.dll"
@@ -142,7 +143,20 @@
 
 <OBJECT id='g_objClassFactory' CLASSID='clsid:884e2049-217d-11da-b2a4-000e7bbb2b09'>
 </OBJECT>
+-->
 
+<SCRIPT LANGUAGE="JavaScript">
+//<!--
+if (navigator.appName == "Microsoft Internet Explorer") {
+  if ((navigator.appVersion).indexOf("NT 6.") > -1) {
+    document.writeln("<OBJECT id='g_objClassFactory' CLASSID='clsid:884e2049-217d-11da-b2a4-000e7bbb2b09'></OBJECT>");
+  } else {
+    document.writeln("<OBJECT classid='clsid:127698e4-e730-4e5c-a2b1-21490a70c8a1' CODEBASE='/xenroll.dll' id='Enroll'></OBJECT>");
+  }
+}
+//-->
+</SCRIPT>
+
 <SCRIPT LANGUAGE=VBS>
 <!--
 '========================================================
@@ -178,8 +192,9 @@
                GetOSVersion = 5
         End Function
 
-	Sub ImportCertificate
-		Dim pkcs7
+	'Sub ImportCertificate
+	Sub ImportCertificate (pkcs7)
+		'Dim pkcs7
                 Dim res
                 Dim osVersion
 
@@ -187,7 +202,8 @@
                 osVersion = GetOSVersion()
                  
 		'Convert the cert to PKCS7 format
-		pkcs7 = result.header.pkcs7ChainBase64
+		'pkcs7 = result.header.pkcs7ChainBase64
+		'ret = MsgBox(pkcs7, 0, "Import PKCS7 Cert")
 		If (IsEmpty(pkcs7) OR theError <> 0) Then
 			ret = MsgBox("Could not convert certificate to PKCS7 format", 0, "Import Cert")
 			Exit Sub
@@ -232,10 +248,20 @@
                 End If
 	End Sub
 
-	ImportCertificate()
+	'ImportCertificate()
 -->
 </SCRIPT>
 
+<SCRIPT LANGUAGE="JavaScript">
+//<!--
+if (navigator.appName == "Microsoft Internet Explorer") {
+  var pkcs7 = result.header.pkcs7ChainBase64;
+  //alert("pkcs7="+pkcs7);
+  ImportCertificate(pkcs7);
+}
+//-->
+</SCRIPT>
+
 </font>
 </BODY>
 </HTML>

From jmagne at redhat.com  Sat Aug  4 00:54:22 2012
From: jmagne at redhat.com (John Magne)
Date: Fri, 3 Aug 2012 20:54:22 -0400 (EDT)
Subject: [Pki-devel] certificate import for IE
In-Reply-To: <501C718E.6030208@redhat.com>
Message-ID: <15004625.16567540.1344041662357.JavaMail.root@redhat.com>


Solution looks good.

Grab the pkcs7 value and javascript and pass it down to the vb script function.

ACK

----- Original Message -----
From: "Andrew Wnuk" <awnuk at redhat.com>
To: pki-devel at redhat.com
Sent: Friday, August 3, 2012 5:49:18 PM
Subject: [Pki-devel] certificate import for IE

This patch corrects certificate import for IE

Bug: 845387.

_______________________________________________
Pki-devel mailing list
Pki-devel at redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel



From alee at redhat.com  Sat Aug  4 02:29:30 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 03 Aug 2012 22:29:30 -0400
Subject: [Pki-devel] [PATCH] 44 - Fixed operations to operate on correct
 number of instances
In-Reply-To: <1344008252.5590.84.camel@aleeredhat.laptop>
References: <1344008252.5590.84.camel@aleeredhat.laptop>
Message-ID: <1344047371.5590.111.camel@aleeredhat.laptop>

acked by Endi.  pushed to master.

On Fri, 2012-08-03 at 11:37 -0400, Ade Lee wrote:
> Reverted previous fix to pkidaemon and operations.  Now, as
> expected, systemctl start/stop pki-tomcatd at foo.service will stop
> instance foo, whereas pki-tomcatd.target will affect all tomcatd
> instances.
> 
> Please review.
> Ade
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Mon Aug  6 14:30:35 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 06 Aug 2012 10:30:35 -0400
Subject: [Pki-devel] [PATCH] 45 - Change selinux context for legacy instances
Message-ID: <1344263436.5590.113.camel@aleeredhat.laptop>


    In the new selinux policy, pki_ca_t etc. are all replaced by
    pki_tomcat_t.  To allow old instances to work under dogtag 10, the
    context in the run scripts needs to change.
    Also added a rule needed by selinux policy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0045-Changed-selinux-context-for-legacy-instances.patch
Type: text/x-patch
Size: 1731 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120806/bcdd28bd/attachment.bin>

From alee at redhat.com  Mon Aug  6 14:43:13 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 06 Aug 2012 10:43:13 -0400
Subject: [Pki-devel] [PATCH] 45 - Change selinux context for legacy
 instances
In-Reply-To: <1344263436.5590.113.camel@aleeredhat.laptop>
References: <1344263436.5590.113.camel@aleeredhat.laptop>
Message-ID: <1344264193.21651.4.camel@aleeredhat.laptop>

pushed to master.
On Mon, 2012-08-06 at 10:30 -0400, Ade Lee wrote:
> In the new selinux policy, pki_ca_t etc. are all replaced by
>     pki_tomcat_t.  To allow old instances to work under dogtag 10, the
>     context in the run scripts needs to change.
>     Also added a rule needed by selinux policy.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From akoneru at redhat.com  Mon Aug  6 17:35:57 2012
From: akoneru at redhat.com (Abhishek Koneru)
Date: Mon, 06 Aug 2012 13:35:57 -0400
Subject: [Pki-devel] [PATCH] 28 Ticket 149 - Enhancement - Dogtag 10 -
 Implementation of search/list functionalities.
Message-ID: <1344274557.6842.3.camel@akoneru.redhat.com>

Please review the patch with implementation for Ticket 149 for DogTag
10. The search filter creation is already present. 

Changed the ds calling function and added pagination.

--Abhishek Koneru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-akoneru-0028-Ticket-149-Implementing-the-search-functionality-ser.patch
Type: text/x-patch
Size: 10510 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120806/6085ca86/attachment.bin>

From edewata at redhat.com  Mon Aug  6 18:01:43 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 06 Aug 2012 13:01:43 -0500
Subject: [Pki-devel] [PATCH] 27-2 Fixes for review comments on [PATCH] 27
In-Reply-To: <1343949802.32305.3.camel@akoneru.redhat.com>
References: <1343749603.9474.1.camel@akoneru.redhat.com>
	<5019B142.1020209@redhat.com>
	<1343949802.32305.3.camel@akoneru.redhat.com>
Message-ID: <50200687.5030109@redhat.com>

On 8/2/2012 6:23 PM, Abhishek Koneru wrote:
> Please review the attached patch with fixes for comments given on Patch
> 27.

Some more comments:

>> 11. The CertSearchData.valueOf() should take a more generic input, e.g.
>> Reader, so it can be used to read other inputs, not just files.

I think we should use a Reader class instead of InputStream when 
handling text data, the caller can use FileReader instead of 
FileInputStream.

12. In CertFindCLI.java:111 let's add a space after the dot to separate 
the exception message.

13. In CertFindCLI.java:162,265,267 I think we should use "uid" instead 
of "id" as the parameter name to make it clearer.

14. In CertFindCLI.java:162 we should add an argument name "user id".

15. In CertFindCLI.java:187,190,296,298,300,302 the current 
"revokedFrom" and "revokedTill" might be interpreted differently. Let's 
use the same parameter names as the field names in CertSearchData, in 
this case "revokedOnFrom" and "revokedOnTo" (we can revise it again 
later). And the following parameter descriptions might be better.
  * revokedOnFrom: Revoked on or after this date
  * revokedOnTo: Revoked on or before this date

16. In CertFindCLI.java:183 the "revokedBy" takes a "user id" as an 
argument instead of "serial number".

17. Similarly, in CertFindCLI.java:201 the "issuedBy" takes a "user id".

18. In CertFindCLI.java:149,152 let's use "serial number" as the command 
argument instead of just "number".

19. In CertFindCLI.java:210-224 the certType* parameters take either on 
or off value. So the arg names should be "on|off".

You can also go to the Agent's Certificate Manger -> Search for 
Certificates to see how the parameters are used in the UI.

One more thing, I think we don't need those ...InUse fields in the 
CertSearchData because they can be implied from the parameters we 
specify. They can be removed in a separate ticket.

-- 
Endi S. Dewata



From mharmsen at redhat.com  Wed Aug  8 00:24:46 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 07 Aug 2012 17:24:46 -0700
Subject: [Pki-devel] 'pki-tps-9.0.7-4.fc18' built and released
Message-ID: <5021B1CE.4090800@redhat.com>

Nathan and Ade,

I have performed the following release engineering tasks for Nathan's 
API patch change for httpd 2.2 --> httpd 2.4:

  * Dogtag 10 ('master')
      o 'git am' and 'git push' to 'master' branch
  * Dogtag 9 ('DOGTAG_9_BRANCH')
      o 'git add' and 'git commit' of
        'pki/patches/0001-Port-TPS-to-httpd-2.4.patch' and
        'pki/specs/pki-tps.spec'
      o 'git commit' and 'git push' to 'DOGTAG_9_BRANCH' branch
      o published
        'http://pki.fedoraproject.org/pki/sources/pki-tps/0001-Port-TPS-to-httpd-2.4.patch'
      o performed successful Koji build of 'pki-tps-9.0.7-4.fc18'
          + http://koji.fedoraproject.org/koji/buildinfo?buildID=346590

Note that no "Bodhi" tasks are necessary as the only build requested was 
for Fedora 18 (Rawhide).

-- Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120807/b196a5a3/attachment.htm>

From nkinder at redhat.com  Wed Aug  8 04:39:59 2012
From: nkinder at redhat.com (Nathan Kinder)
Date: Tue, 07 Aug 2012 21:39:59 -0700
Subject: [Pki-devel] 'pki-tps-9.0.7-4.fc18' built and released
In-Reply-To: <5021B1CE.4090800@redhat.com>
References: <5021B1CE.4090800@redhat.com>
Message-ID: <5021ED9F.3080305@redhat.com>

On 08/07/2012 05:24 PM, Matthew Harmsen wrote:
> Nathan and Ade,
>
> I have performed the following release engineering tasks for Nathan's 
> API patch change for httpd 2.2 --> httpd 2.4:
>
>   * Dogtag 10 ('master')
>       o 'git am' and 'git push' to 'master' branch
>   * Dogtag 9 ('DOGTAG_9_BRANCH')
>       o 'git add' and 'git commit' of
>         'pki/patches/0001-Port-TPS-to-httpd-2.4.patch' and
>         'pki/specs/pki-tps.spec'
>       o 'git commit' and 'git push' to 'DOGTAG_9_BRANCH' branch
>       o published
>         'http://pki.fedoraproject.org/pki/sources/pki-tps/0001-Port-TPS-to-httpd-2.4.patch'
>       o performed successful Koji build of 'pki-tps-9.0.7-4.fc18'
>           + http://koji.fedoraproject.org/koji/buildinfo?buildID=346590
>
> Note that no "Bodhi" tasks are necessary as the only build requested 
> was for Fedora 18 (Rawhide).
Thanks Matt!
>
> -- Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120807/9b39a6a7/attachment.htm>

From awnuk at redhat.com  Wed Aug  8 23:04:33 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Wed, 08 Aug 2012 16:04:33 -0700
Subject: [Pki-devel] adding subsequent OCSPs
Message-ID: <5022F081.8030808@redhat.com>

This patch corrects process of attaching OCSP subsystem to CA.
It improves handling of adding subsequent OCSP subsystems to CA.

Bugs: 804179 and 804176.
-------------- next part --------------
Index: pki/base/common/src/com/netscape/cms/servlet/csadmin/UpdateOCSPConfig.java
===================================================================
--- pki/base/common/src/com/netscape/cms/servlet/csadmin/UpdateOCSPConfig.java	(revision 2439)
+++ pki/base/common/src/com/netscape/cms/servlet/csadmin/UpdateOCSPConfig.java	(working copy)
@@ -33,6 +33,8 @@
 import com.netscape.certsrv.apps.CMS;
 import com.netscape.certsrv.authentication.*;
 import com.netscape.certsrv.authorization.*;
+import com.netscape.certsrv.publish.*;
+import com.netscape.certsrv.ca.*;
 import com.netscape.cms.servlet.*;
 import com.netscape.cmsutil.xml.*;
 import org.w3c.dom.*;
@@ -115,24 +117,22 @@
 
         String ocsphost = httpReq.getParameter("ocsp_host");
         String ocspport = httpReq.getParameter("ocsp_port");
+        String ocspname = ocsphost.replace('.', '-')+"-"+ocspport;
+        String publisherPrefix = "ca.publish.publisher.instance.OCSPPublisher-"+ocspname;
+        String rulePrefix = "ca.publish.rule.instance.ocsprule-"+ocspname;
         try {
             cs.putString("ca.publish.enable", "true");
-            cs.putString("ca.publish.publisher.instance.OCSPPublisher.host", 
-              ocsphost);
-            cs.putString("ca.publish.publisher.instance.OCSPPublisher.port", 
-              ocspport);
-            cs.putString("ca.publish.publisher.instance.OCSPPublisher.nickName", 
-              nickname);
-            cs.putString("ca.publish.publisher.instance.OCSPPublisher.path",
-              "/ocsp/agent/ocsp/addCRL");
-            cs.putString("ca.publish.publisher.instance.OCSPPublisher.pluginName", "OCSPPublisher");
-            cs.putString("ca.publish.publisher.instance.OCSPPublisher.enableClientAuth", "true");
-            cs.putString("ca.publish.rule.instance.ocsprule.enable", "true");
-            cs.putString("ca.publish.rule.instance.ocsprule.mapper", "NoMap");
-            cs.putString("ca.publish.rule.instance.ocsprule.pluginName", "Rule");
-            cs.putString("ca.publish.rule.instance.ocsprule.publisher", 
-              "OCSPPublisher");
-            cs.putString("ca.publish.rule.instance.ocsprule.type", "crl");
+            cs.putString(publisherPrefix+".host", ocsphost);
+            cs.putString(publisherPrefix+".port", ocspport);
+            cs.putString(publisherPrefix+".nickName", nickname);
+            cs.putString(publisherPrefix+".path", "/ocsp/agent/ocsp/addCRL");
+            cs.putString(publisherPrefix+".pluginName", "OCSPPublisher");
+            cs.putString(publisherPrefix+".enableClientAuth", "true");
+            cs.putString(rulePrefix+".enable", "true");
+            cs.putString(rulePrefix+".mapper", "NoMap");
+            cs.putString(rulePrefix+".pluginName", "Rule");
+            cs.putString(rulePrefix+".publisher", "OCSPPublisher-"+ocspname);
+            cs.putString(rulePrefix+".type", "crl");
             cs.commit(false);
             // insert info
             CMS.debug("UpdateOCSPConfig: Sending response");
@@ -145,6 +145,16 @@
             byte[] cb = xmlObj.toByteArray();
 
             outputResult(httpResp, "application/xml", cb);
+
+            ICertificateAuthority ca = (ICertificateAuthority) CMS.getSubsystem("ca");
+            IPublisherProcessor pp = ca.getPublisherProcessor();
+            IConfigStore c = cs.getSubStore("ca.publish.publisher.instance");
+            CMS.debug("UpdateOCSPConfig process: adding publisher instance: OCSPPublisher-"+ocspname);
+            pp.addPublisherInstance("OCSPPublisher-"+ocspname, c);
+            c = cs.getSubStore("ca.publish.rule.instance");
+            CMS.debug("UpdateOCSPConfig process: adding rule instance: ocsprule-"+ocspname);
+            pp.addRuleInstance("ocsprule-"+ocspname, c);
+            CMS.debug("UpdateOCSPConfig process: publishing processor updated");
         } catch (Exception e) {
             CMS.debug("UpdateOCSPConfig: Failed to update OCSP configuration. Exception: "+e.toString());
             outputError(httpResp, "Error: Failed to update OCSP configuration.");
Index: pki/base/common/src/com/netscape/certsrv/publish/IPublisherProcessor.java
===================================================================
--- pki/base/common/src/com/netscape/certsrv/publish/IPublisherProcessor.java	(revision 2439)
+++ pki/base/common/src/com/netscape/certsrv/publish/IPublisherProcessor.java	(working copy)
@@ -83,6 +83,14 @@
     public Hashtable getRuleInsts();
 
     /**
+     * Adds rule instance to the instance list.
+     * @param insName rule instance name
+     * @param c config store
+     */
+    public void addRuleInstance(String insName, IConfigStore c) throws
+            EBaseException;
+
+    /**
      *
      * Returns Hashtable of mapper plugins.
      */
@@ -108,6 +116,14 @@
     public Hashtable getPublisherInsts();
 
     /**
+     * Adds publisher instance to the instance list.
+     * @param insName publisher instance name
+     * @param c config store
+     */
+    public void addPublisherInstance(String insName, IConfigStore c) throws
+            EBaseException;
+
+    /**
      *
      * Returns list of rules based on publishing type.
      * @param publishingType Type for which to retrieve rule list.
Index: pki/base/common/src/com/netscape/cmscore/ldap/PublisherProcessor.java
===================================================================
--- pki/base/common/src/com/netscape/cmscore/ldap/PublisherProcessor.java	(revision 2439)
+++ pki/base/common/src/com/netscape/cmscore/ldap/PublisherProcessor.java	(working copy)
@@ -91,6 +91,143 @@
         return mConfig;
     }
 
+    public void addPublisherInstance(String insName, IConfigStore c)
+        throws EBaseException {
+
+        String implName = c.getString(insName + "." + 
+                PROP_PLUGIN);
+        PublisherPlugin plugin =
+            (PublisherPlugin) mPublisherPlugins.get(implName);
+
+        if (plugin == null) { 
+            log(ILogger.LL_FAILURE, 
+		CMS.getLogMessage("CMSCORE_LDAP_PLUGIN_NOT_FIND", implName));
+            throw new ELdapException(implName);
+        }
+        String className = plugin.getClassPath();
+
+        // Instantiate and init the publisher.
+        boolean isEnable = false;
+        ILdapPublisher publisherInst = null;
+
+        try {
+            publisherInst = (ILdapPublisher)
+                    Class.forName(className).newInstance();
+            IConfigStore pConfig = 
+                c.getSubStore(insName);
+
+            publisherInst.init(pConfig);
+            isEnable = true;
+
+        } catch (ClassNotFoundException e) {
+            String errMsg = "PublisherProcessor:: init()-" + e.toString();
+
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        } catch (IllegalAccessException e) {
+            String errMsg = "PublisherProcessor:: init()-" + e.toString();
+
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        } catch (InstantiationException e) {
+            String errMsg = "PublisherProcessor: init()-" + e.toString();
+
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        } catch (Throwable e) {
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_SKIP_PUBLISHER", insName, e.toString()));
+            // Let the server continue if it is a
+            // mis-configuration. But the instance
+            // will be skipped. This give another
+            // chance to the user to re-configure
+            // the server via console.
+        }
+
+        if (publisherInst == null) {
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        }
+
+        if (insName == null) {
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", insName));
+        }
+
+        // add publisher instance to list.
+        mPublisherInsts.put(insName, new 
+            PublisherProxy(isEnable, publisherInst));
+        log(ILogger.LL_INFO, "publisher instance " + insName + " added");
+        if (Debug.ON)
+            Debug.trace("loaded publisher instance " + insName + " impl " + implName);
+
+    }
+
+    public void addRuleInstance(String insName, IConfigStore c)
+        throws EBaseException {
+
+        String implName = c.getString(insName + "." + 
+                PROP_PLUGIN);
+        RulePlugin plugin =
+            (RulePlugin) mRulePlugins.get(implName);
+
+        if (plugin == null) { 
+            log(ILogger.LL_FAILURE, 
+		CMS.getLogMessage("CMSCORE_LDAP_RULE_NOT_FIND", implName));
+            throw new ELdapException(implName);
+        }
+        String className = plugin.getClassPath();
+
+        if (Debug.ON)
+            Debug.trace("loaded rule className=" + className);
+
+            // Instantiate and init the rule
+        IConfigStore mConfig = null;
+
+        try {
+            ILdapRule ruleInst = null;
+
+            ruleInst = (ILdapRule)
+                    Class.forName(className).newInstance();
+            mConfig = c.getSubStore(insName);
+            ruleInst.init(this, mConfig);
+            ruleInst.setInstanceName(insName);
+
+            // add manager instance to list.
+            if (Debug.ON)
+                Debug.trace("ADDING RULE " + insName + "  " + ruleInst);
+            mRuleInsts.put(insName, ruleInst);
+            log(ILogger.LL_INFO, "rule instance " + 
+                insName + " added");
+        } catch (ClassNotFoundException e) {
+            String errMsg = "PublisherProcessor:: init()-" + e.toString();
+
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        } catch (IllegalAccessException e) {
+            String errMsg = "PublisherProcessor:: init()-" + e.toString();
+
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        } catch (InstantiationException e) {
+            String errMsg = "PublisherProcessor: init()-" + e.toString();
+
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
+            throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+        } catch (Throwable e) {
+            if (mConfig == null) {
+                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
+            }
+            mConfig.putString(ILdapRule.PROP_ENABLE, 
+                "false");
+            log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_SKIP_RULE", insName, e.toString()));
+            // Let the server continue if it is a
+            // mis-configuration. But the instance
+            // will be skipped. This give another
+            // chance to the user to re-configure
+            // the server via console.
+        }
+        if (Debug.ON)
+            Debug.trace("loaded rule instance " + insName + " impl " + implName);
+    }
+
     public void init(ISubsystem authority, IConfigStore config)
         throws EBaseException {
         mConfig = config;
@@ -118,69 +255,7 @@
 
         while (instances.hasMoreElements()) {
             String insName = (String) instances.nextElement();
-            String implName = c.getString(insName + "." + 
-                    PROP_PLUGIN);
-            PublisherPlugin plugin =
-                (PublisherPlugin) mPublisherPlugins.get(implName);
-
-            if (plugin == null) { 
-                log(ILogger.LL_FAILURE, 
-			CMS.getLogMessage("CMSCORE_LDAP_PLUGIN_NOT_FIND", implName));
-                throw new ELdapException(implName);
-            }
-            String className = plugin.getClassPath();
-
-            // Instantiate and init the publisher.
-            boolean isEnable = false;
-            ILdapPublisher publisherInst = null;
-
-            try {
-                publisherInst = (ILdapPublisher)
-                        Class.forName(className).newInstance();
-                IConfigStore pConfig = 
-                    c.getSubStore(insName);
-
-                publisherInst.init(pConfig);
-                isEnable = true;
-
-            } catch (ClassNotFoundException e) {
-                String errMsg = "PublisherProcessor:: init()-" + e.toString();
-
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            } catch (IllegalAccessException e) {
-                String errMsg = "PublisherProcessor:: init()-" + e.toString();
-
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            } catch (InstantiationException e) {
-                String errMsg = "PublisherProcessor: init()-" + e.toString();
-
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            } catch (Throwable e) {
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_SKIP_PUBLISHER", insName, e.toString()));
-                // Let the server continue if it is a
-                // mis-configuration. But the instance
-                // will be skipped. This give another
-                // chance to the user to re-configure
-                // the server via console.
-            }
-
-            if (publisherInst == null) {
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            }
-
-            if (insName == null) {
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", insName));
-            }
-
-            // add publisher instance to list.
-            mPublisherInsts.put(insName, new 
-                PublisherProxy(isEnable, publisherInst));
-            log(ILogger.LL_INFO, "publisher instance " + insName + " added");
-            if (Debug.ON)
-                Debug.trace("loaded publisher instance " + insName + " impl " + implName);
+            addPublisherInstance(insName, c);
         }
 
         // load mapper implementation
@@ -287,69 +362,7 @@
         instances = c.getSubStoreNames();
         while (instances.hasMoreElements()) {
             String insName = (String) instances.nextElement();
-            String implName = c.getString(insName + "." + 
-                    PROP_PLUGIN);
-            RulePlugin plugin =
-                (RulePlugin) mRulePlugins.get(implName);
-
-            if (plugin == null) { 
-                log(ILogger.LL_FAILURE, 
-			CMS.getLogMessage("CMSCORE_LDAP_RULE_NOT_FIND", implName));
-                throw new ELdapException(implName);
-            }
-            String className = plugin.getClassPath();
-
-            if (Debug.ON)
-                Debug.trace("loaded rule className=" + className);
-
-                // Instantiate and init the rule
-            IConfigStore mConfig = null;
-
-            try {
-                ILdapRule ruleInst = null;
-
-                ruleInst = (ILdapRule)
-                        Class.forName(className).newInstance();
-                mConfig = c.getSubStore(insName);
-                ruleInst.init(this, mConfig);
-                ruleInst.setInstanceName(insName);
-
-                // add manager instance to list.
-                if (Debug.ON)
-                    Debug.trace("ADDING RULE " + insName + "  " + ruleInst);
-                mRuleInsts.put(insName, ruleInst);
-                log(ILogger.LL_INFO, "rule instance " + 
-                    insName + " added");
-            } catch (ClassNotFoundException e) {
-                String errMsg = "PublisherProcessor:: init()-" + e.toString();
-
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            } catch (IllegalAccessException e) {
-                String errMsg = "PublisherProcessor:: init()-" + e.toString();
-
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            } catch (InstantiationException e) {
-                String errMsg = "PublisherProcessor: init()-" + e.toString();
-
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_PUBLISHER_INIT_FAILED", e.toString()));
-                throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-            } catch (Throwable e) {
-                if (mConfig == null) {
-                    throw new ELdapException(CMS.getUserMessage("CMS_LDAP_FAIL_LOAD_CLASS", className));
-                }
-                mConfig.putString(ILdapRule.PROP_ENABLE, 
-                    "false");
-                log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_LDAP_SKIP_RULE", insName, e.toString()));
-                // Let the server continue if it is a
-                // mis-configuration. But the instance
-                // will be skipped. This give another
-                // chance to the user to re-configure
-                // the server via console.
-            }
-            if (Debug.ON)
-                Debug.trace("loaded rule instance " + insName + " impl " + implName);
+            addRuleInstance(insName, c);
         }
 
         startup();

From mharmsen at redhat.com  Wed Aug  8 23:35:39 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 08 Aug 2012 16:35:39 -0700
Subject: [Pki-devel] adding subsequent OCSPs
In-Reply-To: <5022F081.8030808@redhat.com>
References: <5022F081.8030808@redhat.com>
Message-ID: <5022F7CB.9050408@redhat.com>

On 08/08/12 16:04, Andrew Wnuk wrote:
> This patch corrects process of attaching OCSP subsystem to CA.
> It improves handling of adding subsequent OCSP subsystems to CA.
>
> Bugs: 804179 and 804176.
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK

I was shown a working demo of this patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120808/d6483d7f/attachment.htm>

From edewata at redhat.com  Thu Aug  9 20:27:55 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 09 Aug 2012 15:27:55 -0500
Subject: [Pki-devel] [PATCH] 28 Ticket 149 - Enhancement - Dogtag 10 -
 Implementation of search/list functionalities.
In-Reply-To: <1344274557.6842.3.camel@akoneru.redhat.com>
References: <1344274557.6842.3.camel@akoneru.redhat.com>
Message-ID: <50241D4B.9030204@redhat.com>

On 8/6/2012 12:35 PM, Abhishek Koneru wrote:
> Please review the patch with implementation for Ticket 149 for DogTag
> 10. The search filter creation is already present.
>
> Changed the ds calling function and added pagination.

The patch needs a minor rebase, but it's ACKed. It can be pushed after 
patch #27-3 is fixed.

We still need to do the same for the listCerts() operation. I think we 
can add "status" into CertSearchData, then the listCerts() can use it to 
call searchCerts():

   public CertDataInfos listCerts(...) {
       CertSearchData csd = new CertSearchData();
       csd.setStatus(status);
       return searchCerts(csd, start, size);
   }

The createSearchFilter() methods will need to be combined.

-- 
Endi S. Dewata



From mharmsen at redhat.com  Fri Aug 10 00:29:57 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Thu, 09 Aug 2012 17:29:57 -0700
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
	(08/09/2012)
Message-ID: <50245605.4040209@redhat.com>

This patch documents continued implementation of the PKI Deployment 
Framework based upon the revised filesystem layout documented here:

  * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS

This patch addresses the following issues:

  * TRAC Ticket #184 - Dogtag 10: Update PKI Deployment to handle
    cloning CA/KRA/OCSP/TKS . . .
  * TRAC Ticket #285 - Dogtag 10: Fix installation issues for KRA, OCSP,
    and TKS

It has been tested and proven to work successfully to deploy a KRA as a 
separate instance on a 64-bit Fedora 17 machine (using the appropriate 
'tomcatjss.jar').

P. S. -- Ade, as you are the most probable reviewer of this patch, 
please feel free to 'push' it to 'master' if you find it in order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120809/7429cab2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120809-PKI-Deployment-Scriptlets-KRA-Errata.patch
Type: text/x-patch
Size: 8086 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120809/7429cab2/attachment.bin>

From alee at redhat.com  Fri Aug 10 14:50:11 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 10 Aug 2012 10:50:11 -0400
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
 (08/09/2012)
In-Reply-To: <50245605.4040209@redhat.com>
References: <50245605.4040209@redhat.com>
Message-ID: <1344610211.21349.83.camel@aleeredhat.laptop>

The patch works.  I was able to get a KRA installed.

Comments:
1. The logic in pkijython for determining whether to send the issuing CA
information is incorrect.  Specifically, all clones still need to
contact a CA to generate their server cert.

2.  The same logic applies to the code in pkiparser.py.  In fact, I
think we can simplify the logic there significantly.  There is no need
to distinguish in the subsystem name whether the server is a clone or
subordinate or external.  Just use "{subsystem_type} {hostname} {port}"
for all subsystems (apache and tomcat).

Its very difficult to follow the logic in that section. For the
parameters in that section the logic should be:

# for all subsystems
set_default(subsystem_name, "{subsystem_type} {hostname} {port}") 

if (root ca) {
   security_domain_type = "new"
   set_default(security_domain_name, "{dnsname} Security Domain")    
} else {
   security_domain_type = "existing"
   set_default(security_domain_host, "{pki_hostname}")
   set_default(security_domain_uri, "https:// {security_domain_host}:{security)_domain_port}")
}

where set_default() is defined as :

set_default(x, y) {
   if not len (master_dict[x]) {
       master_dict[x] = y
   }
}

I need to think about the conditional a bit to decide when we can say we
need a new vs. existing security domain.

Ade

On Thu, 2012-08-09 at 17:29 -0700, Matthew Harmsen wrote:
> This patch documents continued implementation of the PKI Deployment
> Framework based upon the revised filesystem layout documented here:
>       * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
> This patch addresses the following issues:
>       * TRAC Ticket #184 - Dogtag 10: Update PKI Deployment to handle
>         cloning CA/KRA/OCSP/TKS . . .
>       * TRAC Ticket #285 - Dogtag 10: Fix installation issues for KRA,
>         OCSP, and TKS
> It has been tested and proven to work successfully to deploy a KRA as
> a separate instance on a 64-bit Fedora 17 machine (using the
> appropriate 'tomcatjss.jar').
> 
> P. S. -- Ade, as you are the most probable reviewer of this patch,
> please feel free to 'push' it to 'master' if you find it in order.
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From edewata at redhat.com  Fri Aug 10 17:29:33 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 10 Aug 2012 12:29:33 -0500
Subject: [Pki-devel] [PATCH] 90 Updated test build scripts.
Message-ID: <502544FD.4000807@redhat.com>

The build scripts for test, util test, and common test
components have been updated to automatically find the
source codes and not create unnecessary test jar files.

Ticket #62

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0090-Updated-test-build-scripts.patch
Type: text/x-patch
Size: 9004 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120810/8f5598f6/attachment.bin>

From edewata at redhat.com  Fri Aug 10 17:29:45 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 10 Aug 2012 12:29:45 -0500
Subject: [Pki-devel] [PATCH] 91 Updated the remaining build scripts.
Message-ID: <50254509.6080902@redhat.com>

The remaining build scripts have been updated to automatically
find the source codes.

Ticket #62

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0091-Updated-the-remaining-build-scripts.patch
Type: text/x-patch
Size: 23550 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120810/26cad383/attachment.bin>

From alee at redhat.com  Fri Aug 10 18:00:35 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 10 Aug 2012 14:00:35 -0400
Subject: [Pki-devel] [PATCH] patch to allow installation of ocsp and tks
	using pkispawn.
Message-ID: <1344621636.21349.86.camel@aleeredhat.laptop>

Just needed to add a couple of missing files, and reset the resteasy
prefix.  Will applied on top of Matt's last patch, will allow OCSP and
TKS to install.  Pushed to master.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0046-Changes-to-allow-installation-of-ocsp-and-tks.patch
Type: text/x-patch
Size: 3438 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120810/c51baddb/attachment.bin>

From mharmsen at redhat.com  Fri Aug 10 21:52:09 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Fri, 10 Aug 2012 14:52:09 -0700
Subject: [Pki-devel] Proposed solution for the "pkideployment.cfg" template
	file . . .
Message-ID: <50258289.7010701@redhat.com>

Everyone,

It has been brought to my attention (and rightly so) that the 
'pkideployment.cfg' file required by the 'pkispawn' executable is 
confusing to use.

One suggestion was simply to rename the file from 'pkideployment.cfg' to 
something like 'pkideployment.cfg.template' to denote that this is 
actually a template, and not an actual final configuration file, and 
rely solely upon a well-written man page (see TRAC Ticket #227 - Dogtag 
10: Document 'pkideployment.cfg 
<https://fedorahosted.org/pki/ticket/227>') which is not slated to be 
finished until the final phase of the Dogtag 10 release.  Not everyone 
likes this suggestion.

Another suggestion was to create separate template files for all the 
various "flavors"/"configurations", but I am not in favor of this 
approach as it leads to a problem of keeping too much identical 
information in sync across the various template files.  A slight 
alternative to this would be to create separate sectional files that are 
pasted together to create a single configuration file (which in my 
opinion is way too complicated for what should be a relatively simple 
configuration file).

Therefore, I would like to suggest another alternative -- rather than 
creating one or more "static" templates, I would like to suggest the 
creation of a simple python script which generates a configuration file 
suitable for the user's subsystem choice.  For example, this simple 
script could be used to generate a suitable configuration file which 
could easily be edited by an end-user to produce a 'pkideployment.cfg' 
configuration file to any one of the following:

  * CA
  * KRA
  * OCSP
  * TKS
  * RA
  * TPS
  * CA Clone
  * KRA Clone
  * OCSP Clone
  * TKS Clone
  * External CA (stage 1)
  * External CA (stage 2)
  * Subordinate CA

'TRAC Ticket #227 - Dogtag 10: Document 'pkideployment.cfg 
<https://fedorahosted.org/pki/ticket/227>' will still be utilized to 
provide details on what all of the various name/value pairs are used for 
(along with both their resident default values as well as the computed 
default values of keys which are purposefully left unassigned), as well 
as provide detailed examples.

Please fill free to comment in response to this email and suggest any 
other alternatives.  If the alternative that I suggest here is approved 
of, I am willing to writeup a brief design document for such a 'pkispawn 
pkideployment.cfg' configuration file generator.

-- Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120810/9cf20c51/attachment.htm>

From mharmsen at redhat.com  Sat Aug 11 05:15:28 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Fri, 10 Aug 2012 22:15:28 -0700
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
 (08/09/2012)
In-Reply-To: <1344610211.21349.83.camel@aleeredhat.laptop>
References: <50245605.4040209@redhat.com>
	<1344610211.21349.83.camel@aleeredhat.laptop>
Message-ID: <5025EA70.8060506@redhat.com>

The attached patch (new code which has been combined with the previous 
patch) addresses Comments 1 and 2 below.

This code has been successfully tested on a 64-bit Fedora 17 machine for 
a CA, a Cloned CA, and a KRA.

NOTE:  While the logic in comment 2 is correct from a "configuration" 
viewpoint, the "security_domain_name" is also required by other sections 
of the "installation" code in
        generating various certificate subject DNs for non-root CA 
subsystems and will generate a "java.io.IOException: Bad AVA format: 
Missing attribute value" exception
        during "configuration" if it is not defined, thus why the 
altered code in 'pkiparser.py' does not match the proposed logic verbatim.

-- Matt

P. S. -- Ade, once again, as you are the most probable reviewer of this patch, please feel free to 'push' it to 'master' if you find it in order.

On 08/10/12 07:50, Ade Lee wrote:
> The patch works.  I was able to get a KRA installed.
>
> Comments:
> 1. The logic in pkijython for determining whether to send the issuing CA
> information is incorrect.  Specifically, all clones still need to
> contact a CA to generate their server cert.
>
> 2.  The same logic applies to the code in pkiparser.py.  In fact, I
> think we can simplify the logic there significantly.  There is no need
> to distinguish in the subsystem name whether the server is a clone or
> subordinate or external.  Just use "{subsystem_type} {hostname} {port}"
> for all subsystems (apache and tomcat).
>
> Its very difficult to follow the logic in that section. For the
> parameters in that section the logic should be:
>
> # for all subsystems
> set_default(subsystem_name, "{subsystem_type} {hostname} {port}")
>
> if (root ca) {
>     security_domain_type = "new"
>     set_default(security_domain_name, "{dnsname} Security Domain")
> } else {
>     security_domain_type = "existing"
>     set_default(security_domain_host, "{pki_hostname}")
>     set_default(security_domain_uri, "https:// {security_domain_host}:{security)_domain_port}")
> }
>
> where set_default() is defined as :
>
> set_default(x, y) {
>     if not len (master_dict[x]) {
>         master_dict[x] = y
>     }
> }
>
> I need to think about the conditional a bit to decide when we can say we
> need a new vs. existing security domain.
>
> Ade
>
> On Thu, 2012-08-09 at 17:29 -0700, Matthew Harmsen wrote:
>> This patch documents continued implementation of the PKI Deployment
>> Framework based upon the revised filesystem layout documented here:
>>        * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
>> This patch addresses the following issues:
>>        * TRAC Ticket #184 - Dogtag 10: Update PKI Deployment to handle
>>          cloning CA/KRA/OCSP/TKS . . .
>>        * TRAC Ticket #285 - Dogtag 10: Fix installation issues for KRA,
>>          OCSP, and TKS
>> It has been tested and proven to work successfully to deploy a KRA as
>> a separate instance on a 64-bit Fedora 17 machine (using the
>> appropriate 'tomcatjss.jar').
>>
>> P. S. -- Ade, as you are the most probable reviewer of this patch,
>> please feel free to 'push' it to 'master' if you find it in order.
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120810-PKI-Deployment-Scriptlets-KRA-Errata.patch
Type: text/x-patch
Size: 17635 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120810/c294ac6a/attachment.bin>

From edewata at redhat.com  Mon Aug 13 14:19:03 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 09:19:03 -0500
Subject: [Pki-devel] [PATCH] 28 Ticket 149 - Enhancement - Dogtag 10 -
 Implementation of search/list functionalities.
In-Reply-To: <1344629443.1985.3.camel@akoneru.redhat.com>
References: <1344274557.6842.3.camel@akoneru.redhat.com>
	<50241D4B.9030204@redhat.com>
	<1344629443.1985.3.camel@akoneru.redhat.com>
Message-ID: <50290CD7.8060505@redhat.com>

On 8/10/2012 3:10 PM, Abhishek Koneru wrote:
> Patch rebased over 27-4.
> Please review and commit.

ACK. Pushed to master.

-- 
Endi S. Dewata



From alee at redhat.com  Mon Aug 13 15:47:09 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 13 Aug 2012 11:47:09 -0400
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
 (08/09/2012)
In-Reply-To: <5025EA70.8060506@redhat.com>
References: <50245605.4040209@redhat.com>
	<1344610211.21349.83.camel@aleeredhat.laptop>
	<5025EA70.8060506@redhat.com>
Message-ID: <1344872830.21349.109.camel@aleeredhat.laptop>

I'm not sure where the idea that you do not need a security domain for
an external CA came from.  You always need a security domain - either
new or existing.  I'm going to push the patch as-is for now, but this
will be one of the things that needs to be fixed for external installs.

I would have hoped that you would define the set_default() function or
similar.  Without it, the code is still very difficult to parse and that
slows down reviews and makes it likely for errors to creep in.  Also, to
make it more concise, we can replace pki_master_dict with just master.
We can leave this for a future patch, but I would like to see it soon.

Compare: 
if not len(config.pki_master_dict['pki_subsystem_name']):
            config.pki_master_dict['pki_subsystem_name'] =\
                config.pki_subsystem + " " +\
                config.pki_master_dict['pki_hostname'] + " " +\
                config.pki_master_dict['pki_https_port']

to

set_default('pki_subsystem_name', str.format("{} {} {}",\
    (config.pki_subsystem, master['pki_hostname'], master['pki_https_port']))

Pushed to master.

On Fri, 2012-08-10 at 22:15 -0700, Matthew Harmsen wrote:
> The attached patch (new code which has been combined with the previous 
> patch) addresses Comments 1 and 2 below.
> 
> This code has been successfully tested on a 64-bit Fedora 17 machine for 
> a CA, a Cloned CA, and a KRA.
> 
> NOTE:  While the logic in comment 2 is correct from a "configuration" 
> viewpoint, the "security_domain_name" is also required by other sections 
> of the "installation" code in
>         generating various certificate subject DNs for non-root CA 
> subsystems and will generate a "java.io.IOException: Bad AVA format: 
> Missing attribute value" exception
>         during "configuration" if it is not defined, thus why the 
> altered code in 'pkiparser.py' does not match the proposed logic verbatim.
> 
> -- Matt
> 
> P. S. -- Ade, once again, as you are the most probable reviewer of this patch, please feel free to 'push' it to 'master' if you find it in order.
> 
> On 08/10/12 07:50, Ade Lee wrote:
> > The patch works.  I was able to get a KRA installed.
> >
> > Comments:
> > 1. The logic in pkijython for determining whether to send the issuing CA
> > information is incorrect.  Specifically, all clones still need to
> > contact a CA to generate their server cert.
> >
> > 2.  The same logic applies to the code in pkiparser.py.  In fact, I
> > think we can simplify the logic there significantly.  There is no need
> > to distinguish in the subsystem name whether the server is a clone or
> > subordinate or external.  Just use "{subsystem_type} {hostname} {port}"
> > for all subsystems (apache and tomcat).
> >
> > Its very difficult to follow the logic in that section. For the
> > parameters in that section the logic should be:
> >
> > # for all subsystems
> > set_default(subsystem_name, "{subsystem_type} {hostname} {port}")
> >
> > if (root ca) {
> >     security_domain_type = "new"
> >     set_default(security_domain_name, "{dnsname} Security Domain")
> > } else {
> >     security_domain_type = "existing"
> >     set_default(security_domain_host, "{pki_hostname}")
> >     set_default(security_domain_uri, "https:// {security_domain_host}:{security)_domain_port}")
> > }
> >
> > where set_default() is defined as :
> >
> > set_default(x, y) {
> >     if not len (master_dict[x]) {
> >         master_dict[x] = y
> >     }
> > }
> >
> > I need to think about the conditional a bit to decide when we can say we
> > need a new vs. existing security domain.
> >
> > Ade
> >
> > On Thu, 2012-08-09 at 17:29 -0700, Matthew Harmsen wrote:
> >> This patch documents continued implementation of the PKI Deployment
> >> Framework based upon the revised filesystem layout documented here:
> >>        * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
> >> This patch addresses the following issues:
> >>        * TRAC Ticket #184 - Dogtag 10: Update PKI Deployment to handle
> >>          cloning CA/KRA/OCSP/TKS . . .
> >>        * TRAC Ticket #285 - Dogtag 10: Fix installation issues for KRA,
> >>          OCSP, and TKS
> >> It has been tested and proven to work successfully to deploy a KRA as
> >> a separate instance on a 64-bit Fedora 17 machine (using the
> >> appropriate 'tomcatjss.jar').
> >>
> >> P. S. -- Ade, as you are the most probable reviewer of this patch,
> >> please feel free to 'push' it to 'master' if you find it in order.
> >> _______________________________________________
> >> Pki-devel mailing list
> >> Pki-devel at redhat.com
> >> https://www.redhat.com/mailman/listinfo/pki-devel
> >
> 




From edewata at redhat.com  Mon Aug 13 17:27:53 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:27:53 -0500
Subject: [Pki-devel] [PATCH] 92 Cleaned up REST client class names.
Message-ID: <50293919.9040801@redhat.com>

The REST client classes have been renamed for better clarity
and consistency.

Ticket #259

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0092-Cleaned-up-REST-client-class-names.patch
Type: text/x-patch
Size: 25905 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/35bf07b2/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:27:57 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:27:57 -0500
Subject: [Pki-devel] [PATCH] 93 Cleaned up REST server class names.
Message-ID: <5029391D.90601@redhat.com>

The REST server classes have been renamed for better clarity
and consistency.

Ticket #259

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0093-Cleaned-up-REST-server-class-names.patch
Type: text/x-patch
Size: 39283 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/f22fbdeb/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:28:03 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:28:03 -0500
Subject: [Pki-devel] [PATCH] 94 Cleaned up REST common class names.
Message-ID: <50293923.1020909@redhat.com>

The REST common classes have been renamed for better clarity
and consistency.

Ticket #259

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0094-Cleaned-up-REST-common-class-names.patch
Type: text/x-patch
Size: 233734 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/3dedf374/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:30:49 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:30:49 -0500
Subject: [Pki-devel] [PATCH] 95 Reorganized REST client classes.
Message-ID: <502939C9.3040008@redhat.com>

The REST client classes have been moved into the
com.netscape.cms.client.<component> packages.

Ticket #215

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0095-Reorganized-REST-client-classes.patch
Type: text/x-patch
Size: 16847 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/cc4bf0d5/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:30:53 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:30:53 -0500
Subject: [Pki-devel] [PATCH] 96 Reorganized REST server classes.
Message-ID: <502939CD.8090603@redhat.com>

The factory and DAO classes used by REST services have been moved
into the com.netscape.cms.servlet.<component> packages.

Ticket #215

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0096-Reorganized-REST-server-classes.patch
Type: text/x-patch
Size: 23874 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/efd05ce6/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:30:56 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:30:56 -0500
Subject: [Pki-devel] [PATCH] 97 Reorganized REST common classes.
Message-ID: <502939D0.4080304@redhat.com>

The common classes used by REST client and services have been moved
into the com.netscape.certsrv.<component> packages.

Ticket #215

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0097-Reorganized-REST-common-classes.patch
Type: text/x-patch
Size: 137580 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/4864fd02/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:42:18 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:42:18 -0500
Subject: [Pki-devel] [PATCH] 98 Fixed REST common class dependency.
Message-ID: <50293C7A.8050600@redhat.com>

The ConfigurationResponse previously had a method that used a class
that exists on the server only, creating a dependency issue since
the ConfigurationResponse will be used by the client as well. The
method now has been moved into a separate factory class.

Ticket #215

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0098-Fixed-REST-common-class-dependency.patch
Type: text/x-patch
Size: 5763 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/28889ee9/attachment.bin>

From edewata at redhat.com  Mon Aug 13 17:42:21 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 12:42:21 -0500
Subject: [Pki-devel] [PATCH] 99 Added pki-client.jar.
Message-ID: <50293C7D.4020203@redhat.com>

A new pki-client.jar has been created to package the REST client
and CLI classes.

Ticket #215

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0099-Added-pki-client.jar.patch
Type: text/x-patch
Size: 4488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/a4a63d26/attachment.bin>

From akoneru at redhat.com  Mon Aug 13 22:44:33 2012
From: akoneru at redhat.com (Abhishek Koneru)
Date: Mon, 13 Aug 2012 18:44:33 -0400
Subject: [Pki-devel] [PATCH] 29 Fix for ticket 219 - BugZilla issue 816232
Message-ID: <1344897873.2867.2.camel@akoneru.redhat.com>

Please review the patch with fix for ticket 219 in Dog Tag 10 Beta.

--Abhishek Koneru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-akoneru-0029-Ticket-219-Conversion-of-integer-variable-to-BigInte.patch
Type: text/x-patch
Size: 3316 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/88003687/attachment.bin>

From edewata at redhat.com  Tue Aug 14 01:44:13 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 20:44:13 -0500
Subject: [Pki-devel] [PATCH] 94 Cleaned up REST common class names.
In-Reply-To: <50293923.1020909@redhat.com>
References: <50293923.1020909@redhat.com>
Message-ID: <5029AD6D.3090202@redhat.com>

On 8/13/2012 12:28 PM, Endi Sukma Dewata wrote:
> The REST common classes have been renamed for better clarity
> and consistency.
>
> Ticket #259

Rebased on top of master.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0094-1-Cleaned-up-REST-common-class-names.patch
Type: text/x-patch
Size: 233291 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/59479d67/attachment.bin>

From edewata at redhat.com  Tue Aug 14 01:44:26 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 13 Aug 2012 20:44:26 -0500
Subject: [Pki-devel] [PATCH] 95 Reorganized REST client classes.
In-Reply-To: <502939C9.3040008@redhat.com>
References: <502939C9.3040008@redhat.com>
Message-ID: <5029AD7A.3050300@redhat.com>

On 8/13/2012 12:30 PM, Endi Sukma Dewata wrote:
> The REST client classes have been moved into the
> com.netscape.cms.client.<component> packages.
>
> Ticket #215

Fixed incorrect import.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0095-1-Reorganized-REST-client-classes.patch
Type: text/x-patch
Size: 17432 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120813/fdb2fcfd/attachment.bin>

From mharmsen at redhat.com  Wed Aug 15 01:21:17 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 14 Aug 2012 18:21:17 -0700
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
	(08/14/2012)
Message-ID: <502AF98D.5000608@redhat.com>

This patch documents continued implementation of the PKI Deployment 
Framework based upon the revised filesystem layout documented here:

  * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS

This patch addresses the following issues:

  * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy needs to
    contact the security domain to update the domain
  * Made Fedora 17 rely upon tomcatjss 7.0.0 or later

It has been tested and proven to work successfully to 
spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17 
machine (using the appropriate 'tomcatjss.jar').

P. S. - While fixing the parameters passed via "outputError()" in 
'base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java', 
I noticed that several of the other servlets in this directory also 
utilized the "AUTH_FAILURE" error value for the second argument of 
"outputError()" which gets passed as the string "2" --- while this 
string is technically acceptable, I believe that this may be old usage 
of some legacy parent method since "outputError()" is currently defined 
in "base/common/src/com/netscape/cms/servlet/base/CMSServlet.java" as:

  * protected void outputError(HttpServletResponse httpResp, String
    errorString)
  * protected void outputError(HttpServletResponse httpResp, String
    errorString, String requestId)
  * protected void outputError(HttpServletResponse httpResp, String
    status, String errorString, String requestId)

so for all of my changes to "outputError()" in "UpdateDomainXML.java", I 
merely changed these incorrect three parameter call versions to the two 
parameter call version by removing the second parameter 
("AUTH_FAILURE").  If I am correct about this seemingly legacy usage, 
please let me know if I need to file a TRAC ticket for this issue.

Thanks,
-- Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120814/248a0a94/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120814-PKI-Deployment-Scriptlets-Security-Domain.patch
Type: text/x-patch
Size: 18778 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120814/248a0a94/attachment.bin>

From alee at redhat.com  Wed Aug 15 03:00:01 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 14 Aug 2012 23:00:01 -0400
Subject: [Pki-devel] [PATCH] 47 - Changes to get TPS ad RA working on dogtag
	10
Message-ID: <1344999602.21349.111.camel@aleeredhat.laptop>

    Changes to get TPS and RA running on dogtag 10
    
    Added systemd scripts for RA and TPS.  Modified init scripts
    and configuration files to use correct directives for httpd 2.4.
    TPS and RA subsystems are now installable using pkicreate

Please review,
Ade

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0047-Changes-to-get-TPS-and-RA-running-on-dogtag-10.patch
Type: text/x-patch
Size: 26643 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120814/36f3f352/attachment.bin>

From alee at redhat.com  Wed Aug 15 03:38:11 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 14 Aug 2012 23:38:11 -0400
Subject: [Pki-devel] [PATCH] 92 Cleaned up REST client class names.
In-Reply-To: <50293919.9040801@redhat.com>
References: <50293919.9040801@redhat.com>
Message-ID: <1345001892.21349.112.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 12:27 -0500, Endi Sukma Dewata wrote:
> The REST client classes have been renamed for better clarity
> and consistency.
> 
> Ticket #259
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 03:48:04 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 14 Aug 2012 23:48:04 -0400
Subject: [Pki-devel] [PATCH] 93 Cleaned up REST server class names.
In-Reply-To: <5029391D.90601@redhat.com>
References: <5029391D.90601@redhat.com>
Message-ID: <1345002485.21349.113.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 12:27 -0500, Endi Sukma Dewata wrote:
> The REST server classes have been renamed for better clarity
> and consistency.
> 
> Ticket #259
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 04:32:12 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 00:32:12 -0400
Subject: [Pki-devel] [PATCH] 94 Cleaned up REST common class names.
In-Reply-To: <5029AD6D.3090202@redhat.com>
References: <50293923.1020909@redhat.com> <5029AD6D.3090202@redhat.com>
Message-ID: <1345005133.21349.114.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 20:44 -0500, Endi Sukma Dewata wrote:
> On 8/13/2012 12:28 PM, Endi Sukma Dewata wrote:
> > The REST common classes have been renamed for better clarity
> > and consistency.
> >
> > Ticket #259
> 
> Rebased on top of master.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 04:50:51 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 00:50:51 -0400
Subject: [Pki-devel] [PATCH] 95 Reorganized REST client classes.
In-Reply-To: <5029AD7A.3050300@redhat.com>
References: <502939C9.3040008@redhat.com> <5029AD7A.3050300@redhat.com>
Message-ID: <1345006251.21349.115.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 20:44 -0500, Endi Sukma Dewata wrote:
> On 8/13/2012 12:30 PM, Endi Sukma Dewata wrote:
> > The REST client classes have been moved into the
> > com.netscape.cms.client.<component> packages.
> >
> > Ticket #215
> 
> Fixed incorrect import.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 04:51:09 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 00:51:09 -0400
Subject: [Pki-devel] [PATCH] 96 Reorganized REST server classes.
In-Reply-To: <502939CD.8090603@redhat.com>
References: <502939CD.8090603@redhat.com>
Message-ID: <1345006269.21349.116.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 12:30 -0500, Endi Sukma Dewata wrote:
> The factory and DAO classes used by REST services have been moved
> into the com.netscape.cms.servlet.<component> packages.
> 
> Ticket #215
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 05:04:10 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 01:04:10 -0400
Subject: [Pki-devel] [PATCH] 97 Reorganized REST common classes.
In-Reply-To: <502939D0.4080304@redhat.com>
References: <502939D0.4080304@redhat.com>
Message-ID: <1345007050.21349.117.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 12:30 -0500, Endi Sukma Dewata wrote:
> The common classes used by REST client and services have been moved
> into the com.netscape.certsrv.<component> packages.
> 
> Ticket #215
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 14:18:29 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 10:18:29 -0400
Subject: [Pki-devel] [PATCH] 98 Fixed REST common class dependency.
In-Reply-To: <50293C7A.8050600@redhat.com>
References: <50293C7A.8050600@redhat.com>
Message-ID: <1345040310.21349.145.camel@aleeredhat.laptop>

ack
On Mon, 2012-08-13 at 12:42 -0500, Endi Sukma Dewata wrote:
> The ConfigurationResponse previously had a method that used a class
> that exists on the server only, creating a dependency issue since
> the ConfigurationResponse will be used by the client as well. The
> method now has been moved into a separate factory class.
> 
> Ticket #215
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Wed Aug 15 14:39:56 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 10:39:56 -0400
Subject: [Pki-devel] [PATCH] 99 Added pki-client.jar.
In-Reply-To: <50293C7D.4020203@redhat.com>
References: <50293C7D.4020203@redhat.com>
Message-ID: <1345041596.21349.147.camel@aleeredhat.laptop>

A couple of questions:

1. Does it make sense for the new jar to be delivered in its own
package?
2. Why do all of the files indicate that they were built at Tue Jan 01
00:00:00 EST 1980?

Ade

On Mon, 2012-08-13 at 12:42 -0500, Endi Sukma Dewata wrote:
> A new pki-client.jar has been created to package the REST client
> and CLI classes.
> 
> Ticket #215
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From edewata at redhat.com  Wed Aug 15 17:09:35 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:09:35 -0500
Subject: [Pki-devel] [PATCH] 90 Updated test build scripts.
In-Reply-To: <502544FD.4000807@redhat.com>
References: <502544FD.4000807@redhat.com>
Message-ID: <502BD7CF.8040703@redhat.com>

On 8/10/2012 12:29 PM, Endi Sukma Dewata wrote:
> The build scripts for test, util test, and common test
> components have been updated to automatically find the
> source codes and not create unnecessary test jar files.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:09:46 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:09:46 -0500
Subject: [Pki-devel] [PATCH] 91 Updated the remaining build scripts.
In-Reply-To: <50254509.6080902@redhat.com>
References: <50254509.6080902@redhat.com>
Message-ID: <502BD7DA.8090703@redhat.com>

On 8/10/2012 12:29 PM, Endi Sukma Dewata wrote:
> The remaining build scripts have been updated to automatically
> find the source codes.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:10:10 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:10:10 -0500
Subject: [Pki-devel] [PATCH] 92 Cleaned up REST client class names.
In-Reply-To: <1345001892.21349.112.camel@aleeredhat.laptop>
References: <50293919.9040801@redhat.com>
	<1345001892.21349.112.camel@aleeredhat.laptop>
Message-ID: <502BD7F2.1050706@redhat.com>

On 8/14/2012 10:38 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:10:24 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:10:24 -0500
Subject: [Pki-devel] [PATCH] 93 Cleaned up REST server class names.
In-Reply-To: <1345002485.21349.113.camel@aleeredhat.laptop>
References: <5029391D.90601@redhat.com>
	<1345002485.21349.113.camel@aleeredhat.laptop>
Message-ID: <502BD800.5010303@redhat.com>

On 8/14/2012 10:48 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:10:36 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:10:36 -0500
Subject: [Pki-devel] [PATCH] 94 Cleaned up REST common class names.
In-Reply-To: <1345005133.21349.114.camel@aleeredhat.laptop>
References: <50293923.1020909@redhat.com> <5029AD6D.3090202@redhat.com>
	<1345005133.21349.114.camel@aleeredhat.laptop>
Message-ID: <502BD80C.4050201@redhat.com>

On 8/14/2012 11:32 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:10:48 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:10:48 -0500
Subject: [Pki-devel] [PATCH] 95 Reorganized REST client classes.
In-Reply-To: <1345006251.21349.115.camel@aleeredhat.laptop>
References: <502939C9.3040008@redhat.com> <5029AD7A.3050300@redhat.com>
	<1345006251.21349.115.camel@aleeredhat.laptop>
Message-ID: <502BD818.7000704@redhat.com>

On 8/14/2012 11:50 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:10:59 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:10:59 -0500
Subject: [Pki-devel] [PATCH] 96 Reorganized REST server classes.
In-Reply-To: <1345006269.21349.116.camel@aleeredhat.laptop>
References: <502939CD.8090603@redhat.com>
	<1345006269.21349.116.camel@aleeredhat.laptop>
Message-ID: <502BD823.5030803@redhat.com>

On 8/14/2012 11:51 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:11:13 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:11:13 -0500
Subject: [Pki-devel] [PATCH] 97 Reorganized REST common classes.
In-Reply-To: <1345007050.21349.117.camel@aleeredhat.laptop>
References: <502939D0.4080304@redhat.com>
	<1345007050.21349.117.camel@aleeredhat.laptop>
Message-ID: <502BD831.4020500@redhat.com>

On 8/15/2012 12:04 AM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:11:28 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:11:28 -0500
Subject: [Pki-devel] [PATCH] 98 Fixed REST common class dependency.
In-Reply-To: <1345040310.21349.145.camel@aleeredhat.laptop>
References: <50293C7A.8050600@redhat.com>
	<1345040310.21349.145.camel@aleeredhat.laptop>
Message-ID: <502BD840.2070902@redhat.com>

On 8/15/2012 9:18 AM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Wed Aug 15 17:16:04 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 15 Aug 2012 12:16:04 -0500
Subject: [Pki-devel] [PATCH] 99 Added pki-client.jar.
In-Reply-To: <1345041596.21349.147.camel@aleeredhat.laptop>
References: <50293C7D.4020203@redhat.com>
	<1345041596.21349.147.camel@aleeredhat.laptop>
Message-ID: <502BD954.9020002@redhat.com>

On 8/15/2012 9:39 AM, Ade Lee wrote:
> A couple of questions:
>
> 1. Does it make sense for the new jar to be delivered in its own
> package?

Yes, but it depends on this ticket:
https://fedorahosted.org/pki/ticket/295

> 2. Why do all of the files indicate that they were built at Tue Jan 01
> 00:00:00 EST 1980?

It seems to be a global problem, not just PKI:
https://fedorahosted.org/pki/ticket/296

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From mharmsen at redhat.com  Wed Aug 15 19:09:57 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 15 Aug 2012 12:09:57 -0700
Subject: [Pki-devel] [PATCH] 47 - Changes to get TPS ad RA working on
 dogtag 10
In-Reply-To: <1344999602.21349.111.camel@aleeredhat.laptop>
References: <1344999602.21349.111.camel@aleeredhat.laptop>
Message-ID: <502BF405.3080508@redhat.com>

On 08/14/12 20:00, Ade Lee wrote:
>      Changes to get TPS and RA running on dogtag 10
>      
>      Added systemd scripts for RA and TPS.  Modified init scripts
>      and configuration files to use correct directives for httpd 2.4.
>      TPS and RA subsystems are now installable using pkicreate
>
> Please review,
> Ade
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120815/8ebb10f9/attachment.htm>

From alee at redhat.com  Wed Aug 15 19:39:30 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 15:39:30 -0400
Subject: [Pki-devel] [PATCH] 47 - Changes to get TPS ad RA working on
 dogtag 10
In-Reply-To: <502BF405.3080508@redhat.com>
References: <1344999602.21349.111.camel@aleeredhat.laptop>
	<502BF405.3080508@redhat.com>
Message-ID: <1345059571.21349.148.camel@aleeredhat.laptop>

pushed to master
On Wed, 2012-08-15 at 12:09 -0700, Matthew Harmsen wrote:
> On 08/14/12 20:00, Ade Lee wrote:
> 
> > Changes to get TPS and RA running on dogtag 10
> >     
> >     Added systemd scripts for RA and TPS.  Modified init scripts
> >     and configuration files to use correct directives for httpd 2.4.
> >     TPS and RA subsystems are now installable using pkicreate
> > 
> > Please review,
> > Ade
> > 
> > 
> > 
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> ACK




From alee at redhat.com  Wed Aug 15 19:50:56 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 15 Aug 2012 15:50:56 -0400
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
 (08/14/2012)
In-Reply-To: <502AF98D.5000608@redhat.com>
References: <502AF98D.5000608@redhat.com>
Message-ID: <1345060256.21349.158.camel@aleeredhat.laptop>

1. As discussed on #irc, the correct fix is to add null as the last
argument for the outputError() function calls when status is sent in.
Please fix this for all of these calls.

2. Use dict function get(foo, default) rather than setdefault(foo,
default)

3. The line : nick = subsystemnick.split(' ', 2) is confusing and not
necessary.  Its better to use code like this:

if ':' in subsystemnick: 
    token_name = subsystemnick.split(':')[0]
else: 
    token_name = "internal"

4. Please use str.format() when constructing big strings like the sslget
command.

5. In the case where you check if the security domain is defined, you
should log that it does not and then return (NOT exit).

6. We should not exit in any cases here except if the sslget call has an
invocation error.  If there is an error, it should be prominently logged
but it should not stop the pkidestroy.

7. Check what happens if sslget fails to reach the server.  In this
case, it is likely that status will be set to None (along with error).
If this is the case, right now your code will throw an exception.

Ade


On Tue, 2012-08-14 at 18:21 -0700, Matthew Harmsen wrote:
> This patch documents continued implementation of the PKI Deployment
> Framework based upon the revised filesystem layout documented here:
>       * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
> This patch addresses the following issues:
>       * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy
>         needs to contact the security domain to update the domain
>       * Made Fedora 17 rely upon tomcatjss 7.0.0 or later
> It has been tested and proven to work successfully to
> spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17
> machine (using the appropriate 'tomcatjss.jar').
> 
> P. S. - While fixing the parameters passed via "outputError()" in
> 'base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java', I noticed that several of the other servlets in this directory also utilized the "AUTH_FAILURE" error value for the second argument of "outputError()" which gets passed as the string "2" --- while this string is technically acceptable, I believe that this may be old usage of some legacy parent method since "outputError()" is currently defined in "base/common/src/com/netscape/cms/servlet/base/CMSServlet.java" as:
>       * protected void outputError(HttpServletResponse httpResp,
>         String errorString)
>       * protected void outputError(HttpServletResponse httpResp,
>         String errorString, String requestId)
>       * protected void outputError(HttpServletResponse httpResp,
>         String status, String errorString, String requestId)
> so for all of my changes to "outputError()" in "UpdateDomainXML.java",
> I merely changed these incorrect three parameter call versions to the
> two parameter call version by removing the second parameter
> ("AUTH_FAILURE").  If I am correct about this seemingly legacy usage,
> please let me know if I need to file a TRAC ticket for this issue.
> 
> Thanks,
> -- Matt 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From cfu at redhat.com  Thu Aug 16 00:46:52 2012
From: cfu at redhat.com (Christina Fu)
Date: Wed, 15 Aug 2012 17:46:52 -0700
Subject: [Pki-devel] task 241 ready for review
Message-ID: <502C42FC.9040705@redhat.com>

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

thanks,
Christina



From akoneru at redhat.com  Thu Aug 16 17:29:05 2012
From: akoneru at redhat.com (Abhishek Koneru)
Date: Thu, 16 Aug 2012 13:29:05 -0400
Subject: [Pki-devel] [PATCH] 29 Fix for ticket 219 - BugZilla issue
 816232
In-Reply-To: <1344897873.2867.2.camel@akoneru.redhat.com>
References: <1344897873.2867.2.camel@akoneru.redhat.com>
Message-ID: <1345138145.7677.17.camel@akoneru.redhat.com>

Please review the patch for ticket 219 - fix BZ 816232 - incorrect
casting from BigInt to Int in installation wizard. This patch is for the
DogTag 9 branch. The previous one was for DogTag 10 branch.

Defect description:
  The serial number generated for certificates is wrong when the number
is large. Problem is due to the conversion of BigInteger to integer
while generating a new serial number, which truncates the most
significant bits in the serial number and therefore a large number (eg.
10fff0001) becomes a smaller number (eg. fff0001). This conversion in
turn leads to a collision if a certificate with the smaller number
exists in the database.

Steps to reproduce the defect:
 
 - Create a CA. - (1)
 - Edit the fields minSerialNumber and maxSerialNumber in the
<CA-Installation Path>/conf.CS.cfg to large values like 100000000 and
110000000.
 - Restart the CA.
 - Configure the CA.
 - Create a new CA.
 - Configure this as a clone to (1)CA
 - After the Certificates are generated, view the serial number by
clicking on "View Certificate in PrettyPrint".

Results:
Before the patch is applied: The serial number is truncated.(Wrong)
After the patch is applied: The serial number is found as expected.

--Abhishek Koneru
On Mon, 2012-08-13 at 18:44 -0400, Abhishek Koneru wrote:
> Please review the patch with fix for ticket 219 in Dog Tag 10 Beta.
> 
> --Abhishek Koneru
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-akoneru-0030-Fix-for-BugZilla-ticket-219-DogTag 9	branch.patch
Type: text/x-patch
Size: 2971 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/ae2337be/attachment.bin>

From edewata at redhat.com  Thu Aug 16 18:49:50 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 16 Aug 2012 13:49:50 -0500
Subject: [Pki-devel] SSL handshake problem
Message-ID: <502D40CE.8080107@redhat.com>

Hi,

I'm having a problem running a CLI operation on Dogtag 10 which seems to 
be caused by SSL handshake issue. Here are the steps to reproduce:

1. Get the latest Dogtag 10 source code.
2. Apply the attached pki-certrequest.patch.
3. Get the pki-dev tools (see http://pki.fedoraproject.org/wiki/Testing).
4. Execute these commands in pki-dev/scripts to build and install CA:

  % ./theme-build.sh
  % ./theme-install.sh
  % ./core-build.sh
  % ./core-install.sh
  % ./ds-create.sh
  % ./ca-create.sh

5. Then execute these test commands in pki-dev/scripts:

  % ./cert-request-submit.sh cert-request.xml (note the Request ID)
  % ./cert-request-review.sh <Request ID> review.xml
  % ./cert-request-approve.sh review.xml

Both review and approve operations are done via SSL and they require 
client certificate authentication. However, the review works, but the 
approve operation fails with HTTP code 401 (Unauthorized). This is 
because the review is a GET operation which doesn't send any data, but 
the approve is a POST operation which sends a relatively large data.

These commands use Apache HTTP Client library which has a parameter 
called MIN_CHUNK_LIMIT (see 
http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html). 
The parameter is set to 512 bytes by default, so any request longer than 
that (such as the approve request) may be sent in multiple chunks.

It seems that the current Tomcat JSS doesn't properly handle a request 
sent in multiple chunks. Currently the JSSSocketFactory.handshake() is 
not doing the handshake. The initial handshake is actually done when the 
server starts reading the data stream, without asking for the client 
certificate. Then when the server needs to get the client certificate it 
will do an SSL renegotiation in JSSSupport.getPeerCertificateChain(). 
For some reason the renegotiation fails if the request is sent in 
multiple chunks.

One possible solution is to fix either Tomcat JSS, JSS, or NSS to handle 
multiple request chunks properly. We'll need an expert in this area to 
investigate and fix it.

Another solution is to raise the MIN_CHUNK_LIMIT on the client, but 
there's a hard limit of 8 KB and there might be 3rd party clients which 
we can't control.

Another possibility is we might be able to remove the requirement for 
renegotiation (still to be confirmed). Originally the renegotiation is 
needed to access some pages in Dogtag Web UI so it will prompt for 
client certificate. In Dogtag 10 we're doing some reorganization so 
renegotiation might not be needed anymore. In general unprotected UI 
pages would be accessed via unsecured port, but when the user tries to 
access a protected page he will be redirected to a secured port. Here 
the client certificate will be asked during the initial negotiation. 
Since there is no unauthenticated SSL connection, there is no need for 
renegotiation.

Assuming we don't need renegotiation anymore, I attached a patch for 
Tomcat JSS (tomcatjss-handshake.patch) to do the initial negotiation in 
JSSSocketFactory.handshake() that will also ask for the client 
certificate. With this patch the approve operation will work properly. 
Is this the right solution? Are there other solutions?

Thanks.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-certrequest.patch
Type: text/x-patch
Size: 3461 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/3e8c3443/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tomcatjss-handshake.patch
Type: text/x-patch
Size: 1576 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/3e8c3443/attachment-0001.bin>

From mharmsen at redhat.com  Fri Aug 17 03:13:44 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Thu, 16 Aug 2012 20:13:44 -0700
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
 (08/16/2012)
In-Reply-To: <1345060256.21349.158.camel@aleeredhat.laptop>
References: <502AF98D.5000608@redhat.com>
	<1345060256.21349.158.camel@aleeredhat.laptop>
Message-ID: <502DB6E8.6020904@redhat.com>

This patch documents continued implementation of the PKI Deployment 
Framework based upon the revised filesystem layout documented here:

  * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS

This patch addresses the issues listed below as well as the following 
issues:

  * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy needs to
    contact the security domain to update the domain
  * Made Fedora 17 rely upon tomcatjss 7.0.0 or later
  * Changed Dogtag 10 build-time and runtime requirements for 'pki-deploy'
  * Altered PKI Package Dependency Chain (top-to-bottom): pki-ca,
    pki-kra, pki-ocsp, pki-tks --> pki-deploy --> pki-common
  * Changed TPS to require a build-time dependency of 'httpd-devel >= 2.4.2'

It has been tested and proven to work successfully to 
spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17 
machine (using the appropriate 'tomcatjss.jar').

On 08/15/12 12:50, Ade Lee wrote:
> 1. As discussed on #irc, the correct fix is to add null as the last
> argument for the outputError() function calls when status is sent in.
> Please fix this for all of these calls.
>
> 2. Use dict function get(foo, default) rather than setdefault(foo,
> default)
>
> 3. The line : nick = subsystemnick.split(' ', 2) is confusing and not
> necessary.  Its better to use code like this:
>
> if ':' in subsystemnick:
>      token_name = subsystemnick.split(':')[0]
> else:
>      token_name = "internal"
>
> 4. Please use str.format() when constructing big strings like the sslget
> command.
>
> 5. In the case where you check if the security domain is defined, you
> should log that it does not and then return (NOT exit).
>
> 6. We should not exit in any cases here except if the sslget call has an
> invocation error.  If there is an error, it should be prominently logged
> but it should not stop the pkidestroy.
>
> 7. Check what happens if sslget fails to reach the server.  In this
> case, it is likely that status will be set to None (along with error).
> If this is the case, right now your code will throw an exception.
>
> Ade
>
>
> On Tue, 2012-08-14 at 18:21 -0700, Matthew Harmsen wrote:
>> This patch documents continued implementation of the PKI Deployment
>> Framework based upon the revised filesystem layout documented here:
>>        * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
>> This patch addresses the following issues:
>>        * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy
>>          needs to contact the security domain to update the domain
>>        * Made Fedora 17 rely upon tomcatjss 7.0.0 or later
>> It has been tested and proven to work successfully to
>> spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17
>> machine (using the appropriate 'tomcatjss.jar').
>>
>> P. S. - While fixing the parameters passed via "outputError()" in
>> 'base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java', I noticed that several of the other servlets in this directory also utilized the "AUTH_FAILURE" error value for the second argument of "outputError()" which gets passed as the string "2" --- while this string is technically acceptable, I believe that this may be old usage of some legacy parent method since "outputError()" is currently defined in "base/common/src/com/netscape/cms/servlet/base/CMSServlet.java" as:
>>        * protected void outputError(HttpServletResponse httpResp,
>>          String errorString)
>>        * protected void outputError(HttpServletResponse httpResp,
>>          String errorString, String requestId)
>>        * protected void outputError(HttpServletResponse httpResp,
>>          String status, String errorString, String requestId)
>> so for all of my changes to "outputError()" in "UpdateDomainXML.java",
>> I merely changed these incorrect three parameter call versions to the
>> two parameter call version by removing the second parameter
>> ("AUTH_FAILURE").  If I am correct about this seemingly legacy usage,
>> please let me know if I need to file a TRAC ticket for this issue.
>>
>> Thanks,
>> -- Matt
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/ac0c799a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120816-PKI-Deployment-Scriptlets-Security-Domain.patch
Type: text/x-patch
Size: 44314 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/ac0c799a/attachment.bin>

From cfu at redhat.com  Fri Aug 17 04:10:02 2012
From: cfu at redhat.com (Christina Fu)
Date: Thu, 16 Aug 2012 21:10:02 -0700
Subject: [Pki-devel] request for review - patch for Bug 820695 - Tracker -
 TPS (ECC with nethsm) configuration failed at key generation
Message-ID: <502DC41A.8020602@redhat.com>

Please review the following patch:
https://bugzilla.redhat.com/attachment.cgi?id=605068&action=diff&context=patch&collapsed=&headers=1&format=raw

This patch allows ECC keys to be generated on certain HSM's.

  It requires

the new (working) fix from
https://bugzilla.redhat.com/show_bug.cgi?id=820684
certutil support for EC on HSMs - need to call PK11_GenerateKeyPairWithOpFlags()

The official fix for 820684 is in process.  I have tested this patch against a preliminary developer build.

thanks,
Christina



From edewata at redhat.com  Fri Aug 17 16:04:12 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 17 Aug 2012 11:04:12 -0500
Subject: [Pki-devel] [PATCH] 100 Fixed default port number in CLI help
	message.
Message-ID: <502E6B7C.1090202@redhat.com>

The CLI help message has been fixed to show the correct default
port number.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0100-Fixed-default-port-number-in-CLI-help-message.patch
Type: text/x-patch
Size: 1114 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/864708a8/attachment.bin>

From edewata at redhat.com  Fri Aug 17 16:04:22 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 17 Aug 2012 11:04:22 -0500
Subject: [Pki-devel] [PATCH] 101 Fixed exceptions during shutdown.
Message-ID: <502E6B86.7090505@redhat.com>

The shutdown() methods in several classes have been fixed to allow
more graceful shutdown. Null pointers are checked to avoid exception.
It's not necessary to empty container objects since they might still
be used by other threads and will be garbage collected eventually.

Ticket #247

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0101-Fixed-exceptions-during-shutdown.patch
Type: text/x-patch
Size: 15181 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/22866be2/attachment.bin>

From edewata at redhat.com  Fri Aug 17 16:10:55 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 17 Aug 2012 11:10:55 -0500
Subject: [Pki-devel] [PATCH] 100 Fixed default port number in CLI help
 message.
In-Reply-To: <502E6B7C.1090202@redhat.com>
References: <502E6B7C.1090202@redhat.com>
Message-ID: <502E6D0F.6010201@redhat.com>

On 8/17/2012 11:04 AM, Endi Sukma Dewata wrote:
> The CLI help message has been fixed to show the correct default
> port number.

ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From alee at redhat.com  Fri Aug 17 16:45:29 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 17 Aug 2012 12:45:29 -0400
Subject: [Pki-devel] [PATCH] 48 - add default for pidDir for dogtag 9
	instances
Message-ID: <1345221930.21349.195.camel@aleeredhat.laptop>

This parameter was defined in dogtag 10 and is needed on startup.
Causes conniptions if not present on dogtag 9 instances that have been
migrated to dogtag 10.

Please review.
Ade

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0048-Added-default-for-pidDir-for-dogtag-9-instances.patch
Type: text/x-patch
Size: 1210 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/dbd40b74/attachment.bin>

From alee at redhat.com  Fri Aug 17 17:17:38 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 17 Aug 2012 13:17:38 -0400
Subject: [Pki-devel] [PATCH] 29 Fix for ticket 219 - BugZilla issue
 816232
In-Reply-To: <1344897873.2867.2.camel@akoneru.redhat.com>
References: <1344897873.2867.2.camel@akoneru.redhat.com>
Message-ID: <1345223858.21349.196.camel@aleeredhat.laptop>

ack  - pushed to master

On Mon, 2012-08-13 at 18:44 -0400, Abhishek Koneru wrote:
> Please review the patch with fix for ticket 219 in Dog Tag 10 Beta.
> 
> --Abhishek Koneru
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Fri Aug 17 17:26:33 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 17 Aug 2012 13:26:33 -0400
Subject: [Pki-devel] [PATCH] 29 Fix for ticket 219 - BugZilla issue
 816232
In-Reply-To: <1345138145.7677.17.camel@akoneru.redhat.com>
References: <1344897873.2867.2.camel@akoneru.redhat.com>
	<1345138145.7677.17.camel@akoneru.redhat.com>
Message-ID: <1345224394.21349.198.camel@aleeredhat.laptop>

ack - pushed to dogtag 9

On Thu, 2012-08-16 at 13:29 -0400, Abhishek Koneru wrote:
> Please review the patch for ticket 219 - fix BZ 816232 - incorrect
> casting from BigInt to Int in installation wizard. This patch is for the
> DogTag 9 branch. The previous one was for DogTag 10 branch.
> 
> Defect description:
>   The serial number generated for certificates is wrong when the number
> is large. Problem is due to the conversion of BigInteger to integer
> while generating a new serial number, which truncates the most
> significant bits in the serial number and therefore a large number (eg.
> 10fff0001) becomes a smaller number (eg. fff0001). This conversion in
> turn leads to a collision if a certificate with the smaller number
> exists in the database.
> 
> Steps to reproduce the defect:
>  
>  - Create a CA. - (1)
>  - Edit the fields minSerialNumber and maxSerialNumber in the
> <CA-Installation Path>/conf.CS.cfg to large values like 100000000 and
> 110000000.
>  - Restart the CA.
>  - Configure the CA.
>  - Create a new CA.
>  - Configure this as a clone to (1)CA
>  - After the Certificates are generated, view the serial number by
> clicking on "View Certificate in PrettyPrint".
> 
> Results:
> Before the patch is applied: The serial number is truncated.(Wrong)
> After the patch is applied: The serial number is found as expected.
> 
> --Abhishek Koneru
> On Mon, 2012-08-13 at 18:44 -0400, Abhishek Koneru wrote:
> > Please review the patch with fix for ticket 219 in Dog Tag 10 Beta.
> > 
> > --Abhishek Koneru
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Fri Aug 17 20:06:53 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 17 Aug 2012 16:06:53 -0400
Subject: [Pki-devel] [PATCH] 48 - add default for pidDir for dogtag 9
 instances
In-Reply-To: <1345221930.21349.195.camel@aleeredhat.laptop>
References: <1345221930.21349.195.camel@aleeredhat.laptop>
Message-ID: <1345234013.21349.199.camel@aleeredhat.laptop>

acked by Endi. Pushed to master.

On Fri, 2012-08-17 at 12:45 -0400, Ade Lee wrote:
> This parameter was defined in dogtag 10 and is needed on startup.
> Causes conniptions if not present on dogtag 9 instances that have been
> migrated to dogtag 10.
> 
> Please review.
> Ade
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From nkinder at redhat.com  Fri Aug 17 21:07:36 2012
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 17 Aug 2012 14:07:36 -0700
Subject: [Pki-devel] SSL handshake problem
In-Reply-To: <502D40CE.8080107@redhat.com>
References: <502D40CE.8080107@redhat.com>
Message-ID: <502EB298.6040505@redhat.com>

Adding Elio to the thread in case he has any thoughts on this...

On 08/16/2012 11:49 AM, Endi Sukma Dewata wrote:
> Hi,
>
> I'm having a problem running a CLI operation on Dogtag 10 which seems 
> to be caused by SSL handshake issue. Here are the steps to reproduce:
>
> 1. Get the latest Dogtag 10 source code.
> 2. Apply the attached pki-certrequest.patch.
> 3. Get the pki-dev tools (see http://pki.fedoraproject.org/wiki/Testing).
> 4. Execute these commands in pki-dev/scripts to build and install CA:
>
>  % ./theme-build.sh
>  % ./theme-install.sh
>  % ./core-build.sh
>  % ./core-install.sh
>  % ./ds-create.sh
>  % ./ca-create.sh
>
> 5. Then execute these test commands in pki-dev/scripts:
>
>  % ./cert-request-submit.sh cert-request.xml (note the Request ID)
>  % ./cert-request-review.sh <Request ID> review.xml
>  % ./cert-request-approve.sh review.xml
>
> Both review and approve operations are done via SSL and they require 
> client certificate authentication. However, the review works, but the 
> approve operation fails with HTTP code 401 (Unauthorized). This is 
> because the review is a GET operation which doesn't send any data, but 
> the approve is a POST operation which sends a relatively large data.
>
> These commands use Apache HTTP Client library which has a parameter 
> called MIN_CHUNK_LIMIT (see 
> http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html). 
> The parameter is set to 512 bytes by default, so any request longer 
> than that (such as the approve request) may be sent in multiple chunks.
>
> It seems that the current Tomcat JSS doesn't properly handle a request 
> sent in multiple chunks. Currently the JSSSocketFactory.handshake() is 
> not doing the handshake. The initial handshake is actually done when 
> the server starts reading the data stream, without asking for the 
> client certificate. Then when the server needs to get the client 
> certificate it will do an SSL renegotiation in 
> JSSSupport.getPeerCertificateChain(). For some reason the 
> renegotiation fails if the request is sent in multiple chunks.
>
> One possible solution is to fix either Tomcat JSS, JSS, or NSS to 
> handle multiple request chunks properly. We'll need an expert in this 
> area to investigate and fix it.
>
> Another solution is to raise the MIN_CHUNK_LIMIT on the client, but 
> there's a hard limit of 8 KB and there might be 3rd party clients 
> which we can't control.
>
> Another possibility is we might be able to remove the requirement for 
> renegotiation (still to be confirmed). Originally the renegotiation is 
> needed to access some pages in Dogtag Web UI so it will prompt for 
> client certificate. In Dogtag 10 we're doing some reorganization so 
> renegotiation might not be needed anymore. In general unprotected UI 
> pages would be accessed via unsecured port, but when the user tries to 
> access a protected page he will be redirected to a secured port. Here 
> the client certificate will be asked during the initial negotiation. 
> Since there is no unauthenticated SSL connection, there is no need for 
> renegotiation.
>
> Assuming we don't need renegotiation anymore, I attached a patch for 
> Tomcat JSS (tomcatjss-handshake.patch) to do the initial negotiation 
> in JSSSocketFactory.handshake() that will also ask for the client 
> certificate. With this patch the approve operation will work properly. 
> Is this the right solution? Are there other solutions?
>
> Thanks.
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/dad281ce/attachment.htm>

From jmagne at redhat.com  Fri Aug 17 21:23:19 2012
From: jmagne at redhat.com (John Magne)
Date: Fri, 17 Aug 2012 17:23:19 -0400 (EDT)
Subject: [Pki-devel] SSL handshake problem
In-Reply-To: <502EB298.6040505@redhat.com>
Message-ID: <1823298313.16078487.1345238599634.JavaMail.root@redhat.com>



----- Original Message -----
From: "Nathan Kinder" <nkinder at redhat.com>
To: "Endi Sukma Dewata" <edewata at redhat.com>
Cc: "Bob Relyea" <rrelyea at redhat.com>, "pki-devel" <pki-devel at redhat.com>
Sent: Friday, August 17, 2012 2:07:36 PM
Subject: Re: [Pki-devel] SSL handshake problem



Adding Elio to the thread in case he has any thoughts on this... 

On 08/16/2012 11:49 AM, Endi Sukma Dewata wrote: 


Hi, 

I'm having a problem running a CLI operation on Dogtag 10 which seems to be caused by SSL handshake issue. Here are the steps to reproduce: 

1. Get the latest Dogtag 10 source code. 
2. Apply the attached pki-certrequest.patch. 
3. Get the pki-dev tools (see http://pki.fedoraproject.org/wiki/Testing ). 
4. Execute these commands in pki-dev/scripts to build and install CA: 

% ./theme-build.sh 
% ./theme-install.sh 
% ./core-build.sh 
% ./core-install.sh 
% ./ds-create.sh 
% ./ca-create.sh 

5. Then execute these test commands in pki-dev/scripts: 

% ./cert-request-submit.sh cert-request.xml (note the Request ID) 
% ./cert-request-review.sh <Request ID> review.xml 
% ./cert-request-approve.sh review.xml 

Both review and approve operations are done via SSL and they require client certificate authentication. However, the review works, but the approve operation fails with HTTP code 401 (Unauthorized). This is because the review is a GET operation which doesn't send any data, but the approve is a POST operation which sends a relatively large data. 

These commands use Apache HTTP Client library which has a parameter called MIN_CHUNK_LIMIT (see http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html ). The parameter is set to 512 bytes by default, so any request longer than that (such as the approve request) may be sent in multiple chunks. 

It seems that the current Tomcat JSS doesn't properly handle a request sent in multiple chunks. Currently the JSSSocketFactory.handshake() is not doing the handshake. The initial handshake is actually done when the server starts reading the data stream, without asking for the client certificate. Then when the server needs to get the client certificate it will do an SSL renegotiation in JSSSupport.getPeerCertificateChain(). For some reason the renegotiation fails if the request is sent in multiple chunks. 

One possible solution is to fix either Tomcat JSS, JSS, or NSS to handle multiple request chunks properly. We'll need an expert in this area to investigate and fix it. 

Another solution is to raise the MIN_CHUNK_LIMIT on the client, but there's a hard limit of 8 KB and there might be 3rd party clients which we can't control. 

Another possibility is we might be able to remove the requirement for renegotiation (still to be confirmed). Originally the renegotiation is needed to access some pages in Dogtag Web UI so it will prompt for client certificate. In Dogtag 10 we're doing some reorganization so renegotiation might not be needed anymore. In general unprotected UI pages would be accessed via unsecured port, but when the user tries to access a protected page he will be redirected to a secured port. Here the client certificate will be asked during the initial negotiation. Since there is no unauthenticated SSL connection, there is no need for renegotiation. 

Assuming we don't need renegotiation anymore, I attached a patch for Tomcat JSS (tomcatjss-handshake.patch) to do the initial negotiation in JSSSocketFactory.handshake() that will also ask for the client certificate. With this patch the approve operation will work properly. Is this the right solution? Are there other solutions? 

Thanks. 

Endi:

If we do the tomcatjss-handshake thing, does this still leave us with the Apache proxy ssl client cert issue? Or was that a consequence of renegotiation? I don't remember. Perhaps alee knows off the top of his head.



_______________________________________________
Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel 

_______________________________________________
Pki-devel mailing list
Pki-devel at redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel



From nkinder at redhat.com  Fri Aug 17 21:26:56 2012
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 17 Aug 2012 14:26:56 -0700
Subject: [Pki-devel] SSL handshake problem
In-Reply-To: <502EB298.6040505@redhat.com>
References: <502D40CE.8080107@redhat.com> <502EB298.6040505@redhat.com>
Message-ID: <502EB720.8070509@redhat.com>

Adding Elio for real this time...

On 08/17/2012 02:07 PM, Nathan Kinder wrote:
> Adding Elio to the thread in case he has any thoughts on this...
>
> On 08/16/2012 11:49 AM, Endi Sukma Dewata wrote:
>> Hi,
>>
>> I'm having a problem running a CLI operation on Dogtag 10 which seems 
>> to be caused by SSL handshake issue. Here are the steps to reproduce:
>>
>> 1. Get the latest Dogtag 10 source code.
>> 2. Apply the attached pki-certrequest.patch.
>> 3. Get the pki-dev tools (see 
>> http://pki.fedoraproject.org/wiki/Testing).
>> 4. Execute these commands in pki-dev/scripts to build and install CA:
>>
>>  % ./theme-build.sh
>>  % ./theme-install.sh
>>  % ./core-build.sh
>>  % ./core-install.sh
>>  % ./ds-create.sh
>>  % ./ca-create.sh
>>
>> 5. Then execute these test commands in pki-dev/scripts:
>>
>>  % ./cert-request-submit.sh cert-request.xml (note the Request ID)
>>  % ./cert-request-review.sh <Request ID> review.xml
>>  % ./cert-request-approve.sh review.xml
>>
>> Both review and approve operations are done via SSL and they require 
>> client certificate authentication. However, the review works, but the 
>> approve operation fails with HTTP code 401 (Unauthorized). This is 
>> because the review is a GET operation which doesn't send any data, 
>> but the approve is a POST operation which sends a relatively large data.
>>
>> These commands use Apache HTTP Client library which has a parameter 
>> called MIN_CHUNK_LIMIT (see 
>> http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html). 
>> The parameter is set to 512 bytes by default, so any request longer 
>> than that (such as the approve request) may be sent in multiple chunks.
>>
>> It seems that the current Tomcat JSS doesn't properly handle a 
>> request sent in multiple chunks. Currently the 
>> JSSSocketFactory.handshake() is not doing the handshake. The initial 
>> handshake is actually done when the server starts reading the data 
>> stream, without asking for the client certificate. Then when the 
>> server needs to get the client certificate it will do an SSL 
>> renegotiation in JSSSupport.getPeerCertificateChain(). For some 
>> reason the renegotiation fails if the request is sent in multiple 
>> chunks.
>>
>> One possible solution is to fix either Tomcat JSS, JSS, or NSS to 
>> handle multiple request chunks properly. We'll need an expert in this 
>> area to investigate and fix it.
>>
>> Another solution is to raise the MIN_CHUNK_LIMIT on the client, but 
>> there's a hard limit of 8 KB and there might be 3rd party clients 
>> which we can't control.
>>
>> Another possibility is we might be able to remove the requirement for 
>> renegotiation (still to be confirmed). Originally the renegotiation 
>> is needed to access some pages in Dogtag Web UI so it will prompt for 
>> client certificate. In Dogtag 10 we're doing some reorganization so 
>> renegotiation might not be needed anymore. In general unprotected UI 
>> pages would be accessed via unsecured port, but when the user tries 
>> to access a protected page he will be redirected to a secured port. 
>> Here the client certificate will be asked during the initial 
>> negotiation. Since there is no unauthenticated SSL connection, there 
>> is no need for renegotiation.
>>
>> Assuming we don't need renegotiation anymore, I attached a patch for 
>> Tomcat JSS (tomcatjss-handshake.patch) to do the initial negotiation 
>> in JSSSocketFactory.handshake() that will also ask for the client 
>> certificate. With this patch the approve operation will work 
>> properly. Is this the right solution? Are there other solutions?
>>
>> Thanks.
>>
>>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/21fd2c44/attachment.htm>

From alee at redhat.com  Fri Aug 17 21:40:19 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 17 Aug 2012 17:40:19 -0400
Subject: [Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues
 (08/16/2012)
In-Reply-To: <502DB6E8.6020904@redhat.com>
References: <502AF98D.5000608@redhat.com>
	<1345060256.21349.158.camel@aleeredhat.laptop>
	<502DB6E8.6020904@redhat.com>
Message-ID: <1345239620.21349.201.camel@aleeredhat.laptop>

ACK.

Only caveat - the commit message is badly formatted -- shows up in one
long line.

Ade

On Thu, 2012-08-16 at 20:13 -0700, Matthew Harmsen wrote:
> This patch documents continued implementation of the PKI Deployment
> Framework based upon the revised filesystem layout documented here:
>       * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
> This patch addresses the issues listed below as well as the following
> issues:
>       * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy
>         needs to contact the security domain to update the domain
>       * Made Fedora 17 rely upon tomcatjss 7.0.0 or later
>       * Changed Dogtag 10 build-time and runtime requirements for
>         'pki-deploy'
>       * Altered PKI Package Dependency Chain (top-to-bottom):  pki-ca,
>         pki-kra, pki-ocsp, pki-tks --> pki-deploy --> pki-common
>       * Changed TPS to require a build-time dependency of 'httpd-devel
>         >= 2.4.2'
>         
> It has been tested and proven to work successfully to
> spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17
> machine (using the appropriate 'tomcatjss.jar').
> 
> On 08/15/12 12:50, Ade Lee wrote:
> 
> > 1. As discussed on #irc, the correct fix is to add null as the last
> > argument for the outputError() function calls when status is sent in.
> > Please fix this for all of these calls.
> > 
> > 2. Use dict function get(foo, default) rather than setdefault(foo,
> > default)
> > 
> > 3. The line : nick = subsystemnick.split(' ', 2) is confusing and not
> > necessary.  Its better to use code like this:
> > 
> > if ':' in subsystemnick: 
> >     token_name = subsystemnick.split(':')[0]
> > else: 
> >     token_name = "internal"
> > 
> > 4. Please use str.format() when constructing big strings like the sslget
> > command.
> > 
> > 5. In the case where you check if the security domain is defined, you
> > should log that it does not and then return (NOT exit).
> > 
> > 6. We should not exit in any cases here except if the sslget call has an
> > invocation error.  If there is an error, it should be prominently logged
> > but it should not stop the pkidestroy.
> > 
> > 7. Check what happens if sslget fails to reach the server.  In this
> > case, it is likely that status will be set to None (along with error).
> > If this is the case, right now your code will throw an exception.
> > 
> > Ade
> > 
> > 
> > On Tue, 2012-08-14 at 18:21 -0700, Matthew Harmsen wrote:
> > > This patch documents continued implementation of the PKI Deployment
> > > Framework based upon the revised filesystem layout documented here:
> > >       * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
> > > This patch addresses the following issues:
> > >       * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy
> > >         needs to contact the security domain to update the domain
> > >       * Made Fedora 17 rely upon tomcatjss 7.0.0 or later
> > > It has been tested and proven to work successfully to
> > > spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17
> > > machine (using the appropriate 'tomcatjss.jar').
> > > 
> > > P. S. - While fixing the parameters passed via "outputError()" in
> > > 'base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java', I noticed that several of the other servlets in this directory also utilized the "AUTH_FAILURE" error value for the second argument of "outputError()" which gets passed as the string "2" --- while this string is technically acceptable, I believe that this may be old usage of some legacy parent method since "outputError()" is currently defined in "base/common/src/com/netscape/cms/servlet/base/CMSServlet.java" as:
> > >       * protected void outputError(HttpServletResponse httpResp,
> > >         String errorString)
> > >       * protected void outputError(HttpServletResponse httpResp,
> > >         String errorString, String requestId)
> > >       * protected void outputError(HttpServletResponse httpResp,
> > >         String status, String errorString, String requestId)
> > > so for all of my changes to "outputError()" in "UpdateDomainXML.java",
> > > I merely changed these incorrect three parameter call versions to the
> > > two parameter call version by removing the second parameter
> > > ("AUTH_FAILURE").  If I am correct about this seemingly legacy usage,
> > > please let me know if I need to file a TRAC ticket for this issue.
> > > 
> > > Thanks,
> > > -- Matt 
> > > _______________________________________________
> > > Pki-devel mailing list
> > > Pki-devel at redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> > 
> 




From awnuk at redhat.com  Fri Aug 17 23:23:20 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Fri, 17 Aug 2012 16:23:20 -0700
Subject: [Pki-devel] DRM connector protection
Message-ID: <502ED268.7010904@redhat.com>

This patch prevents DRM connector to be overwritten by subsequent DRM 
installations.

Bug 804179.
-------------- next part --------------
Index: pki/redhat/common-ui/shared/admin/console/config/donepanel.vm
===================================================================
--- pki/redhat/common-ui/shared/admin/console/config/donepanel.vm	(revision 16021)
+++ pki/redhat/common-ui/shared/admin/console/config/donepanel.vm	(working copy)
@@ -58,7 +58,17 @@
 #end
 <br/>
 To create additional instances, type "/usr/bin/pkicreate" on the command line.
+#if ($systemType != "tps")
 <br>
-#if ($systemType != "tps")
 To start the administration console, type "/usr/bin/pkiconsole" on the command line.
+<br/>
 #end
+#if (($systemType == "kra") && ($info != ""))
+<hr>
+<br>
+<b>Important warning</b> reported by Certificate Authority:<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>$info</b>
+<br/>
+<br>
+This instance of Data Recovery Manager (DRM) is not connected to any Certificate Authority (CA).  Please consult the product documentation for the manual procedure of connecting a DRM to a CA.
+<br/>
+#end
Index: pki/base/common/src/com/netscape/cms/servlet/csadmin/DonePanel.java
===================================================================
--- pki/base/common/src/com/netscape/cms/servlet/csadmin/DonePanel.java	(revision 2439)
+++ pki/base/common/src/com/netscape/cms/servlet/csadmin/DonePanel.java	(working copy)
@@ -417,13 +417,18 @@
 
         // need to push connector information to the CA
         if (type.equals("KRA") && !ca_host.equals("")) {
+            boolean connectorUpdated = true;
             try {
                 updateConnectorInfo(ownagenthost, ownagentsport);
+                CMS.debug("DonePanel: connector information updated.");
             } catch (IOException e) {
                 context.put("errorString", "Failed to update connector information.");
-                return;
+                context.put("info", "Failed to update connector information. "+e.getMessage());
+                connectorUpdated = false;
+                CMS.debug("DonePanel: exception in updating connector information. "+e.getMessage());
+                //return;
             }
-            setupClientAuthUser();
+            if (connectorUpdated) setupClientAuthUser();
         } // if KRA
 
         // import the CA certificate into the OCSP
Index: pki/base/common/src/com/netscape/cms/servlet/csadmin/UpdateConnector.java
===================================================================
--- pki/base/common/src/com/netscape/cms/servlet/csadmin/UpdateConnector.java	(revision 2439)
+++ pki/base/common/src/com/netscape/cms/servlet/csadmin/UpdateConnector.java	(working copy)
@@ -122,41 +122,46 @@
             return;
         }
 
-        IConfigStore cs = CMS.getConfigStore();
+        // check if connector exists
+        ICertificateAuthority ca = (ICertificateAuthority)CMS.getSubsystem("ca");
+        ICAService caService = (ICAService)ca.getCAService();
+        boolean connectorExists = (caService.getKRAConnector() != null)? true:false;
+        if (connectorExists) {
+            CMS.debug("UpdateConnector: KRA connector already exists");
+        } else {
+            IConfigStore cs = CMS.getConfigStore();
 
-        Enumeration list = httpReq.getParameterNames();
-        while (list.hasMoreElements()) {
-            String name = (String)list.nextElement();
-            String val = httpReq.getParameter(name);
-            if (name != null && name.startsWith("ca.connector")) {
-                CMS.debug("Adding connector update name=" + name + " val=" + val);
-                cs.putString(name, val);
-            } else {
-                CMS.debug("Skipping connector update name=" + name + " val=" + val);
+            Enumeration list = httpReq.getParameterNames();
+            while (list.hasMoreElements()) {
+                String name = (String)list.nextElement();
+                String val = httpReq.getParameter(name);
+                if (name != null && name.startsWith("ca.connector")) {
+                    CMS.debug("Adding connector update name=" + name + " val=" + val);
+                    cs.putString(name, val);
+                } else {
+                    CMS.debug("Skipping connector update name=" + name + " val=" + val);
+                }
             }
-        }
  
-        try { 
-            String nickname = cs.getString("ca.subsystem.nickname", "");
-            String tokenname = cs.getString("ca.subsystem.tokenname", "");
-            if (!tokenname.equals("Internal Key Storage Token"))
-                nickname = tokenname+":"+nickname;
-            cs.putString("ca.connector.KRA.nickName", nickname);
-            cs.commit(false);
-        } catch (Exception e) {
-        }
+            try { 
+                String nickname = cs.getString("ca.subsystem.nickname", "");
+                String tokenname = cs.getString("ca.subsystem.tokenname", "");
+                if (!tokenname.equals("Internal Key Storage Token"))
+                    nickname = tokenname+":"+nickname;
+                cs.putString("ca.connector.KRA.nickName", nickname);
+                cs.commit(false);
+            } catch (Exception e) {
+            }
 
-        // start the connector
-        try { 
-            ICertificateAuthority ca = (ICertificateAuthority)
-                CMS.getSubsystem("ca");
-            ICAService caService = (ICAService)ca.getCAService();
-            IConnector kraConnector = caService.getConnector(
-                cs.getSubStore("ca.connector.KRA"));
-            caService.setKRAConnector(kraConnector);
-            kraConnector.start();
-        } catch (Exception e) {
-            CMS.debug("Failed to start connector " + e);
+            // start the connector
+            try { 
+                IConnector kraConnector = caService.getConnector(
+                    cs.getSubStore("ca.connector.KRA"));
+                caService.setKRAConnector(kraConnector);
+                kraConnector.start();
+            } catch (Exception e) {
+                CMS.debug("Failed to start connector " + e);
+            }
         }
 
         // send success status back to the requestor
@@ -165,7 +170,12 @@
             XMLObject xmlObj = new XMLObject();
             Node root = xmlObj.createRoot("XMLResponse");
 
-            xmlObj.addItemToContainer(root, "Status", SUCCESS);
+            if (connectorExists) {
+                xmlObj.addItemToContainer(root, "Status", FAILED);
+                xmlObj.addItemToContainer(root, "Error", "DRM connector already exists.");
+            } else {
+                xmlObj.addItemToContainer(root, "Status", SUCCESS);
+            }
             byte[] cb = xmlObj.toByteArray();
 
             outputResult(httpResp, "application/xml", cb);

From mharmsen at redhat.com  Fri Aug 17 23:45:51 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Fri, 17 Aug 2012 16:45:51 -0700
Subject: [Pki-devel] DRM connector protection
In-Reply-To: <502ED268.7010904@redhat.com>
References: <502ED268.7010904@redhat.com>
Message-ID: <502ED7AF.5000209@redhat.com>

Andrew Wnuk wrote:
> This patch prevents DRM connector to be overwritten by subsequent DRM 
> installations.
>
> Bug 804179.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK

Screen shots attached in bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/a74df1df/attachment.htm>

From edewata at redhat.com  Mon Aug 20 17:50:44 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 20 Aug 2012 12:50:44 -0500
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM packages.
Message-ID: <503278F4.4050105@redhat.com>

The pki-common package has been split such that the common and
client binaries are packaged in pki-base and server binaries are
packaged in pki-server. The pki-util has been merged into pki-base
and the pki-deploy package has been merged into pki-server.

Ticket #295

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0102-Added-pki-base-and-pki-server-RPM-packages.patch
Type: text/x-patch
Size: 19964 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120820/14bdb2f0/attachment.bin>

From edewata at redhat.com  Mon Aug 20 20:41:31 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 20 Aug 2012 15:41:31 -0500
Subject: [Pki-devel] [PATCH] 103 Merged pki-native-tools and pki-java-tools.
Message-ID: <5032A0FB.1070601@redhat.com>

The pki-native-tools and pki-java-tools have been merged into
pki-tools and pki-server will depend on it. Since pki-ra and
pki-tps depends on pki-server they automatically depends on
pki-tools as well.

Ticket #295

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0103-Merged-pki-native-tools-and-pki-java-tools.patch
Type: text/x-patch
Size: 12619 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120820/e6dd5fa2/attachment.bin>

From edewata at redhat.com  Mon Aug 20 23:48:31 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 20 Aug 2012 18:48:31 -0500
Subject: [Pki-devel] [PATCH] 104 Moved REST CLI into pki-tools.
Message-ID: <5032CCCF.9030204@redhat.com>

The pki-client.jar has been split and merged into pki-certsrv.jar
and pki-tools.jar. The REST client classes are now packaged in
com.netscape.certsrv.<component> packages. The REST CLI classes
are now packaged in com.netscape.cmstools.<component> packages.
The "pki" script has been moved into pki-tools RPM package.

Ticket #215

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0104-Moved-REST-CLI-into-pki-tools.patch
Type: text/x-patch
Size: 73031 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120820/e4c31773/attachment.bin>

From edewata at redhat.com  Tue Aug 21 19:02:48 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 21 Aug 2012 14:02:48 -0500
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM
	packages.
In-Reply-To: <503278F4.4050105@redhat.com>
References: <503278F4.4050105@redhat.com>
Message-ID: <5033DB58.8090801@redhat.com>

On 8/20/2012 12:50 PM, Endi Sukma Dewata wrote:
> The pki-common package has been split such that the common and
> client binaries are packaged in pki-base and server binaries are
> packaged in pki-server. The pki-util has been merged into pki-base
> and the pki-deploy package has been merged into pki-server.
>
> Ticket #295

New patch attached. The old package definition wasn't removed properly.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0102-1-Added-pki-base-and-pki-server-RPM-packages.patch
Type: text/x-patch
Size: 20850 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120821/c471a28d/attachment.bin>

From cfu at redhat.com  Wed Aug 22 01:38:35 2012
From: cfu at redhat.com (Christina Fu)
Date: Tue, 21 Aug 2012 18:38:35 -0700
Subject: [Pki-devel] request for review - patch for Bug 820695 - Tracker
 - TPS (ECC with nethsm) configuration failed at key generation
In-Reply-To: <502DC41A.8020602@redhat.com>
References: <502DC41A.8020602@redhat.com>
Message-ID: <5034381B.6090301@redhat.com>

new patch to review.  It now loops through a few known crypto token's 
required option combos.

https://bugzilla.redhat.com/attachment.cgi?id=606088&action=diff&context=patch&collapsed=&headers=1&format=raw

please review,
thanks,
Christina

On 08/16/2012 09:10 PM, Christina Fu wrote:
> Please review the following patch:
> https://bugzilla.redhat.com/attachment.cgi?id=605068&action=diff&context=patch&collapsed=&headers=1&format=raw 
>
>
> This patch allows ECC keys to be generated on certain HSM's.
>
>  It requires
>
> the new (working) fix from
> https://bugzilla.redhat.com/show_bug.cgi?id=820684
> certutil support for EC on HSMs - need to call 
> PK11_GenerateKeyPairWithOpFlags()
>
> The official fix for 820684 is in process.  I have tested this patch 
> against a preliminary developer build.
>
> thanks,
> Christina
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel



From edewata at redhat.com  Thu Aug 23 00:04:31 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 22 Aug 2012 19:04:31 -0500
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM
	packages.
In-Reply-To: <5033DB58.8090801@redhat.com>
References: <503278F4.4050105@redhat.com> <5033DB58.8090801@redhat.com>
Message-ID: <5035738F.8010003@redhat.com>

On 8/21/2012 2:02 PM, Endi Sukma Dewata wrote:
> On 8/20/2012 12:50 PM, Endi Sukma Dewata wrote:
>> The pki-common package has been split such that the common and
>> client binaries are packaged in pki-base and server binaries are
>> packaged in pki-server. The pki-util has been merged into pki-base
>> and the pki-deploy package has been merged into pki-server.
>>
>> Ticket #295
>
> New patch attached. The old package definition wasn't removed properly.

New patch attached. Updated pki-console.spec, dogtag-pki.spec, and some 
other files.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0102-2-Added-pki-base-and-pki-server-RPM-packages.patch
Type: text/x-patch
Size: 26435 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/974261ec/attachment.bin>

From edewata at redhat.com  Thu Aug 23 00:04:35 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 22 Aug 2012 19:04:35 -0500
Subject: [Pki-devel] [PATCH] 103 Merged pki-native-tools and
	pki-java-tools.
In-Reply-To: <5032A0FB.1070601@redhat.com>
References: <5032A0FB.1070601@redhat.com>
Message-ID: <50357393.3000405@redhat.com>

On 8/20/2012 3:41 PM, Endi Sukma Dewata wrote:
> The pki-native-tools and pki-java-tools have been merged into
> pki-tools and pki-server will depend on it. Since pki-ra and
> pki-tps depends on pki-server they automatically depends on
> pki-tools as well.
>
> Ticket #295

New patch attached. Updated dogtag-pki.spec and some other files.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0103-1-Merged-pki-native-tools-and-pki-java-tools.patch
Type: text/x-patch
Size: 17023 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/35d4af2c/attachment.bin>

From edewata at redhat.com  Thu Aug 23 00:04:44 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 22 Aug 2012 19:04:44 -0500
Subject: [Pki-devel] [PATCH] 105 Updated CMake jar() function.
Message-ID: <5035739C.1040501@redhat.com>

The jar() function has been modified to support multiple input dirs
in a single command. This way it's not necessary to define multiple
jar targets for the same jar file. The pki-console build script has
been updated to utilize this functionality.

Ticket #89

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0105-Updated-CMake-jar-function.patch
Type: text/x-patch
Size: 5879 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/59f6a03c/attachment.bin>

From edewata at redhat.com  Thu Aug 23 00:05:42 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 22 Aug 2012 19:05:42 -0500
Subject: [Pki-devel] [PATCH] 106 Moved WAR creation code into CMake scripts.
Message-ID: <503573D6.30006@redhat.com>

The code to generate the WAR files has been moved from the RPM
spec file into the CMake scripts for each subsystem to allow better
control.

Ticket #89

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0106-Moved-WAR-creation-code-into-CMake-scripts.patch
Type: text/x-patch
Size: 8014 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/f140cc45/attachment.bin>

From edewata at redhat.com  Thu Aug 23 00:05:52 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 22 Aug 2012 19:05:52 -0500
Subject: [Pki-devel] [PATCH] 107 Added proxy realm.
Message-ID: <503573E0.7030007@redhat.com>

CMS engine is a singleton and it's used by PKI realm to authenticate
users accessing the subsystem. Since a Tomcat instance may contain
multiple subsystems, each having separate realm, the PKI JAR files
need to be moved into WEB-INF/lib so that they will run inside
separate class loaders. Note that Tomcat requires that the JAR files
be copied into this folder, they cannot be linked.

Tomcat also requires that the authenticator and realm classes be
available in common/lib. To address this a new package pki-tomcat.jar
has been added. The package contains the authenticator and a proxy
realm. When the subsystems start running, they will register their
own realms into the proxy realms such that the authentications will
be forwarded to the appropriate subsystems.

Ticket #89

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0107-Added-proxy-realm.patch
Type: text/x-patch
Size: 29985 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/fb32a3bf/attachment.bin>

From jmagne at redhat.com  Thu Aug 23 00:30:13 2012
From: jmagne at redhat.com (John Magne)
Date: Wed, 22 Aug 2012 20:30:13 -0400 (EDT)
Subject: [Pki-devel] request for review - patch for Bug 820695 - Tracker
 - TPS (ECC with nethsm) configuration failed at key generation
In-Reply-To: <5034381B.6090301@redhat.com>
Message-ID: <984106771.19527094.1345681813495.JavaMail.root@redhat.com>

ACK:

Good addition to try different flags for our supported hsm.s

Should probably remove the check for $hw="" when trying the vanilla flags first.
Might as well just let it go and try them.

----- Original Message -----
From: "Christina Fu" <cfu at redhat.com>
To: pki-devel at redhat.com
Sent: Tuesday, August 21, 2012 6:38:35 PM
Subject: Re: [Pki-devel] request for review - patch for Bug 820695 - Tracker - TPS (ECC with nethsm) configuration failed at key generation

new patch to review.  It now loops through a few known crypto token's 
required option combos.

https://bugzilla.redhat.com/attachment.cgi?id=606088&action=diff&context=patch&collapsed=&headers=1&format=raw

please review,
thanks,
Christina

On 08/16/2012 09:10 PM, Christina Fu wrote:
> Please review the following patch:
> https://bugzilla.redhat.com/attachment.cgi?id=605068&action=diff&context=patch&collapsed=&headers=1&format=raw 
>
>
> This patch allows ECC keys to be generated on certain HSM's.
>
>  It requires
>
> the new (working) fix from
> https://bugzilla.redhat.com/show_bug.cgi?id=820684
> certutil support for EC on HSMs - need to call 
> PK11_GenerateKeyPairWithOpFlags()
>
> The official fix for 820684 is in process.  I have tested this patch 
> against a preliminary developer build.
>
> thanks,
> Christina
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

_______________________________________________
Pki-devel mailing list
Pki-devel at redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel



From alee at redhat.com  Thu Aug 23 02:51:38 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 22 Aug 2012 22:51:38 -0400
Subject: [Pki-devel] [PATCH] 49, 50,
	52 - fix broken selinux on f16 (dogtag 9)
Message-ID: <1345690298.2539.17.camel@aleeredhat.laptop>

The last selinux changes checked into dogtag 9 resolved the following
bug for f17:
    BZ 841966 : latest selinux policy fix breaks dogtag

Unfortunately, it also broke the pki-selinux policy in f16.

The following patches address this.  They should be applied in order
(49,50,52)  Basically, 49 reverts the previous change. 50 and 52 adds a
new patch that will be applied to the pki-selinux code for f17 only.

The new patch has already been uploaded, so you should be able to build.

Please review,
Thanks, 
Ade


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0049-Revert-BZ-841966-latest-selinux-policy-fix-breaks-do.patch
Type: text/x-patch
Size: 2365 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/c2353dbc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0050-Modified-selinux-policy-patch-for-f17.patch
Type: text/x-patch
Size: 4295 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/c2353dbc/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0052-spec-file-changes-for-selinux-patch.patch
Type: text/x-patch
Size: 4106 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/c2353dbc/attachment-0002.bin>

From alee at redhat.com  Thu Aug 23 02:53:57 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 22 Aug 2012 22:53:57 -0400
Subject: [Pki-devel] [PATCH] 51 - add systemd files to dogtag 9 for tps/ra
Message-ID: <1345690437.2539.20.camel@aleeredhat.laptop>

This adds systemd files for tps and ra.  These subsystems now start
correctly on f17.

Please review,
Ade

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0051-Added-systemd-files-for-RA-and-TPS.patch
Type: text/x-patch
Size: 16597 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/ddcfbc68/attachment.bin>

From mharmsen at redhat.com  Thu Aug 23 03:21:16 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 22 Aug 2012 20:21:16 -0700
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 10)
Message-ID: <5035A1AC.8010803@redhat.com>

This patch addresses the issue listed below for Dogtag 10:

  * TRAC Ticket #301 - Need to modify init scripts to verify needed
    symlinks in an instance

This patch has been tested and found to work successfully on 64-bit 
Fedora 17 with SElinux in "Permissive" mode:

  * Built and installed Dogtag 9 Packages on a 64-bit Fedora 17 host
  * Installed and configured Dogtag 9 CA instance
  * Successfully submitted an enrollment request, approved enrollment
    request, issued certificate, and listed certificates
  * Built and installed Dogtag 10 Packages on the same 64-bit Fedora 17 host
  * Restarted Dogtag 9 CA instance (so that it was now running under
    Dogtag 10)
  * Successfully submitted an enrollment request and listed certificates
  * Successfully approved the enrollment request and issued a
    certificate AFTER:
      o manually shutting down the CA instance,
      o applying the CS.cfg fixes documented in "TRAC Ticket #303 -
        Dogtag 10: CS.cfg parameters for Dogtag 9 instance running under
        Dogtag 10 packages . . .", and
      o restarting the CA instance)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/cd78f530/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120822-Verify-symbolic-links-Dogtag-10.patch
Type: text/x-patch
Size: 30193 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/cd78f530/attachment.bin>

From mharmsen at redhat.com  Thu Aug 23 03:26:03 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 22 Aug 2012 20:26:03 -0700
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 9)
Message-ID: <5035A2CB.10207@redhat.com>

This patch addresses the issue listed below for Dogtag 9:

  * TRAC Ticket #301 - Need to modify init scripts to verify needed
    symlinks in an instance

This patch has been tested and found to work successfully on 64-bit 
Fedora 16 with SElinux in "Permissive" mode:

  * Built and installed Dogtag 9 Packages on a 64-bit Fedora 16 host
  * Installed and configured Dogtag 9 CA, KRA, OCSP, TKS, RA, and TPS
    instances
  * Tested attached symlinks patch on all subsystems (although I was
    unable to get the configured TPS to restart -- successfully applied
    logic from standalone test program)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/c5472379/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120822-Verify-symbolic-links-Dogtag-9.patch
Type: text/x-patch
Size: 13769 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120822/c5472379/attachment.bin>

From edewata at redhat.com  Thu Aug 23 19:11:28 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 23 Aug 2012 14:11:28 -0500
Subject: [Pki-devel] [PATCH] 101 Fixed exceptions during shutdown.
In-Reply-To: <502E6B86.7090505@redhat.com>
References: <502E6B86.7090505@redhat.com>
Message-ID: <50368060.10004@redhat.com>

On 8/17/2012 11:04 AM, Endi Sukma Dewata wrote:
> The shutdown() methods in several classes have been fixed to allow
> more graceful shutdown. Null pointers are checked to avoid exception.
> It's not necessary to empty container objects since they might still
> be used by other threads and will be garbage collected eventually.
>
> Ticket #247

Revised the patch to handle the attributes more consistently. See the 
updated patch description.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0101-1-Fixed-exceptions-during-shutdown.patch
Type: text/x-patch
Size: 17321 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120823/d6283ab9/attachment.bin>

From mharmsen at redhat.com  Thu Aug 23 22:58:45 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Thu, 23 Aug 2012 15:58:45 -0700
Subject: [Pki-devel] [PATCH] 49, 50,
 52 - fix broken selinux on f16 (dogtag 9)
In-Reply-To: <1345690298.2539.17.camel@aleeredhat.laptop>
References: <1345690298.2539.17.camel@aleeredhat.laptop>
Message-ID: <5036B5A5.7090109@redhat.com>

On 08/22/12 19:51, Ade Lee wrote:
> The last selinux changes checked into dogtag 9 resolved the following
> bug for f17:
>      BZ 841966 : latest selinux policy fix breaks dogtag
>
> Unfortunately, it also broke the pki-selinux policy in f16.
>
> The following patches address this.  They should be applied in order
> (49,50,52)  Basically, 49 reverts the previous change. 50 and 52 adds a
> new patch that will be applied to the pki-selinux code for f17 only.
>
> The new patch has already been uploaded, so you should be able to build.
>
> Please review,
> Thanks,
> Ade
>
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK - because Failures alluded to below were deemed as to not be caused 
by these patches.

Tested pre-installed/pre-configured CA, KRA, OCSP, TKS, RA, and TPS 
instances on 64-bit Fedora 16 running SELinux in Enforcing mode:

  * Successfully restarted CA
      o Successfully requested, approved, and issued a certificate on the CA
  * Successfully restarted KRA
      o Successfully archived a certificate's keys on the KRA
  * Successfully restarted OCSP
  * Successfully restarted RA
  * Successfully restarted TKS
  * Successfully restarted TPS after changing
    '/var/lib/pki-tps/conf/CS.cfg' from:
      o selftests.container.order.startup=TPSPresence:critical,
        TPSSystemCertsVerification:critical to
      o selftests.container.order.startup=TPSPresence:critical
      o Failure was believed to NOT be related to these patches as this
        appears to crash TKS as well
  * Successfully restarted TKS after changing
    '/var/lib/pki-tks/conf/CS.cfg' from:
      o selftests.container.order.startup=TKSKnownSessionKey:critical,
        SystemCertsVerification:critical to
      o selftests.container.order.startup=SystemCertsVerification:critical
      o Failure was believed to NOT be related to these patches


Built/Installed/Configured/Tested CA, KRA, OCSP, TKS, RA, and TPS 
instances on 64-bit Fedora 17 running SELinux in Enforcing mode:

  * Successfully restarted KRA
      o Successfully archived a certificate's keys on the KRA
  * Successfully restarted OCSP
      o Successfully restarted RA
  * Successfully restarted TKS
  * Successfully restarted TPS after changing
    '/var/lib/pki-tps/conf/CS.cfg' from:
      o selftests.container.order.startup=TPSPresence:critical,
        TPSSystemCertsVerification:critical to
      o selftests.container.order.startup=TPSPresence:critical
      o Failure was believed to NOT be related to these patches as this
        appears to crash TKS as well
  * Successfully restarted TKS after changing
    '/var/lib/pki-tks/conf/CS.cfg' from:
      o selftests.container.order.startup=TKSKnownSessionKey:critical,
        SystemCertsVerification:critical to
      o selftests.container.order.startup=SystemCertsVerification:critical
      o Failure was believed to NOT be related to these patches


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120823/a05860a2/attachment.htm>

From mharmsen at redhat.com  Thu Aug 23 22:58:48 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Thu, 23 Aug 2012 15:58:48 -0700
Subject: [Pki-devel] [PATCH] 51 - add systemd files to dogtag 9 for
	tps/ra
In-Reply-To: <1345690437.2539.20.camel@aleeredhat.laptop>
References: <1345690437.2539.20.camel@aleeredhat.laptop>
Message-ID: <5036B5A8.8070404@redhat.com>

On 08/22/12 19:53, Ade Lee wrote:
> This adds systemd files for tps and ra.  These subsystems now start
> correctly on f17.
>
> Please review,
> Ade
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK - because Failures alluded to below were deemed as to not be caused 
by this patch.

Tested pre-installed/pre-configured CA, KRA, OCSP, TKS, RA, and TPS 
instances on 64-bit Fedora 16 running SELinux in Enforcing mode:

  * Successfully restarted CA
      o Successfully requested, approved, and issued a certificate on the CA
  * Successfully restarted KRA
      o Successfully archived a certificate's keys on the KRA
  * Successfully restarted OCSP
  * Successfully restarted RA
  * Successfully restarted TKS
  * Successfully restarted TPS after changing
    '/var/lib/pki-tps/conf/CS.cfg' from:
      o selftests.container.order.startup=TPSPresence:critical,
        TPSSystemCertsVerification:critical to
      o selftests.container.order.startup=TPSPresence:critical
      o Failure was believed to NOT be related to these patches as this
        appears to crash TKS as well
  * Successfully restarted TKS after changing
    '/var/lib/pki-tks/conf/CS.cfg' from:
      o selftests.container.order.startup=TKSKnownSessionKey:critical,
        SystemCertsVerification:critical to
      o selftests.container.order.startup=SystemCertsVerification:critical
      o Failure was believed to NOT be related to these patches


Built/Installed/Configured/Tested CA, KRA, OCSP, TKS, RA, and TPS 
instances on 64-bit Fedora 17 running SELinux in Enforcing mode:

  * Successfully restarted KRA
      o Successfully archived a certificate's keys on the KRA
  * Successfully restarted OCSP
      o Successfully restarted RA
  * Successfully restarted TKS
  * Successfully restarted TPS after changing
    '/var/lib/pki-tps/conf/CS.cfg' from:
      o selftests.container.order.startup=TPSPresence:critical,
        TPSSystemCertsVerification:critical to
      o selftests.container.order.startup=TPSPresence:critical
      o Failure was believed to NOT be related to these patches as this
        appears to crash TKS as well
  * Successfully restarted TKS after changing
    '/var/lib/pki-tks/conf/CS.cfg' from:
      o selftests.container.order.startup=TKSKnownSessionKey:critical,
        SystemCertsVerification:critical to
      o selftests.container.order.startup=SystemCertsVerification:critical
      o Failure was believed to NOT be related to these patches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120823/6fa3ecef/attachment.htm>

From alee at redhat.com  Fri Aug 24 03:04:01 2012
From: alee at redhat.com (Ade Lee)
Date: Thu, 23 Aug 2012 23:04:01 -0400
Subject: [Pki-devel] [PATCH] 49, 50,
 52 - fix broken selinux on f16 (dogtag 9)
In-Reply-To: <5036B5A5.7090109@redhat.com>
References: <1345690298.2539.17.camel@aleeredhat.laptop>
	<5036B5A5.7090109@redhat.com>
Message-ID: <1345777442.2539.21.camel@aleeredhat.laptop>

pushed to dogtag 9
On Thu, 2012-08-23 at 15:58 -0700, Matthew Harmsen wrote:
> On 08/22/12 19:51, Ade Lee wrote:
> 
> > The last selinux changes checked into dogtag 9 resolved the following
> > bug for f17:
> >     BZ 841966 : latest selinux policy fix breaks dogtag
> > 
> > Unfortunately, it also broke the pki-selinux policy in f16.
> > 
> > The following patches address this.  They should be applied in order
> > (49,50,52)  Basically, 49 reverts the previous change. 50 and 52 adds a
> > new patch that will be applied to the pki-selinux code for f17 only.
> > 
> > The new patch has already been uploaded, so you should be able to build.
> > 
> > Please review,
> > Thanks, 
> > Ade
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> ACK - because Failures alluded to below were deemed as to not be
> caused by these patches.
> 
> Tested pre-installed/pre-configured CA, KRA, OCSP, TKS, RA, and TPS
> instances on 64-bit Fedora 16 running SELinux in Enforcing mode:
> 
>       * Successfully restarted CA
>               * Successfully requested, approved, and issued a
>                 certificate on the CA
>       * Successfully restarted KRA
>               * Successfully archived a certificate's keys on the KRA
>       * Successfully restarted OCSP
>       * Successfully restarted RA
>       * Successfully restarted TKS
>       * Successfully restarted TPS after changing
>         '/var/lib/pki-tps/conf/CS.cfg' from:
>               * selftests.container.order.startup=TPSPresence:critical, TPSSystemCertsVerification:critical to
>               * selftests.container.order.startup=TPSPresence:critical
>               * Failure was believed to NOT be related to these
>                 patches as this appears to crash TKS as well
>       * Successfully restarted TKS after changing
>         '/var/lib/pki-tks/conf/CS.cfg' from:
>               * selftests.container.order.startup=TKSKnownSessionKey:critical, SystemCertsVerification:critical to
>               * selftests.container.order.startup=SystemCertsVerification:critical
>               * Failure was believed to NOT be related to these
>                 patches
> 
> Built/Installed/Configured/Tested CA, KRA, OCSP, TKS, RA, and TPS
> instances on 64-bit Fedora 17 running SELinux in Enforcing mode:
> 
>       * Successfully restarted KRA
>               * Successfully archived a certificate's keys on the KRA
>       * Successfully restarted OCSP
>               * Successfully restarted RA
>       * Successfully restarted TKS
>       * Successfully restarted TPS after changing
>         '/var/lib/pki-tps/conf/CS.cfg' from:
>               * selftests.container.order.startup=TPSPresence:critical, TPSSystemCertsVerification:critical to
>               * selftests.container.order.startup=TPSPresence:critical
>               * Failure was believed to NOT be related to these
>                 patches as this appears to crash TKS as well
>       * Successfully restarted TKS after changing
>         '/var/lib/pki-tks/conf/CS.cfg' from:
>               * selftests.container.order.startup=TKSKnownSessionKey:critical, SystemCertsVerification:critical to
>               * selftests.container.order.startup=SystemCertsVerification:critical
>               * Failure was believed to NOT be related to these
>                 patches
> 




From alee at redhat.com  Fri Aug 24 03:04:36 2012
From: alee at redhat.com (Ade Lee)
Date: Thu, 23 Aug 2012 23:04:36 -0400
Subject: [Pki-devel] [PATCH] 51 - add systemd files to dogtag 9 for
 tps/ra
In-Reply-To: <5036B5A8.8070404@redhat.com>
References: <1345690437.2539.20.camel@aleeredhat.laptop>
	<5036B5A8.8070404@redhat.com>
Message-ID: <1345777477.2539.22.camel@aleeredhat.laptop>

pushed to dogtag 9
On Thu, 2012-08-23 at 15:58 -0700, Matthew Harmsen wrote:
> On 08/22/12 19:53, Ade Lee wrote:
> 
> > This adds systemd files for tps and ra.  These subsystems now start
> > correctly on f17.
> > 
> > Please review,
> > Ade
> > 
> > 
> > 
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> ACK - because Failures alluded to below were deemed as to not be
> caused by this patch.
> 
> Tested pre-installed/pre-configured CA, KRA, OCSP, TKS, RA, and TPS
> instances on 64-bit Fedora 16 running SELinux in Enforcing mode:
> 
>       * Successfully restarted CA
>               * Successfully requested, approved, and issued a
>                 certificate on the CA
>       * Successfully restarted KRA
>               * Successfully archived a certificate's keys on the KRA
>       * Successfully restarted OCSP
>       * Successfully restarted RA
>       * Successfully restarted TKS
>       * Successfully restarted TPS after changing
>         '/var/lib/pki-tps/conf/CS.cfg' from:
>               * selftests.container.order.startup=TPSPresence:critical, TPSSystemCertsVerification:critical to
>               * selftests.container.order.startup=TPSPresence:critical
>               * Failure was believed to NOT be related to these
>                 patches as this appears to crash TKS as well
>       * Successfully restarted TKS after changing
>         '/var/lib/pki-tks/conf/CS.cfg' from:
>               * selftests.container.order.startup=TKSKnownSessionKey:critical, SystemCertsVerification:critical to
>               * selftests.container.order.startup=SystemCertsVerification:critical
>               * Failure was believed to NOT be related to these
>                 patches
> 
> Built/Installed/Configured/Tested CA, KRA, OCSP, TKS, RA, and TPS
> instances on 64-bit Fedora 17 running SELinux in Enforcing mode:
> 
>       * Successfully restarted KRA
>               * Successfully archived a certificate's keys on the KRA
>       * Successfully restarted OCSP
>               * Successfully restarted RA
>       * Successfully restarted TKS
>       * Successfully restarted TPS after changing
>         '/var/lib/pki-tps/conf/CS.cfg' from:
>               * selftests.container.order.startup=TPSPresence:critical, TPSSystemCertsVerification:critical to
>               * selftests.container.order.startup=TPSPresence:critical
>               * Failure was believed to NOT be related to these
>                 patches as this appears to crash TKS as well
>       * Successfully restarted TKS after changing
>         '/var/lib/pki-tks/conf/CS.cfg' from:
>               * selftests.container.order.startup=TKSKnownSessionKey:critical, SystemCertsVerification:critical to
>               * selftests.container.order.startup=SystemCertsVerification:critical
>               * Failure was believed to NOT be related to these
>                 patches




From alee at redhat.com  Fri Aug 24 14:54:20 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 24 Aug 2012 10:54:20 -0400
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 10)
In-Reply-To: <5035A1AC.8010803@redhat.com>
References: <5035A1AC.8010803@redhat.com>
Message-ID: <1345820060.2539.63.camel@aleeredhat.laptop>

Couple of comments:

1. We need to think about how to handle each of the cases you have
encountered.  There are a number of cases where you simply warn and exit
rather than fixing the link.  I think these are open for debate, but I
suggest the following:

missing link -> (currently) add the link (suggested) add the link
link pointing to wrong place --> (currently) error (suggested) fix the link
link pointing to non-existent target --> (currently) error (suggested) fix the link
link is actually a file -> (currently) warn (suggested) warn
link is a directory or otherwise -> (currently) error (suggested) error
   
2. This is perhaps a stylistic comment.  You spend a large number of
lines defining variables that specify paths that ultimately only ever
get used within the same function.  To me, this just makes the code
harder to read.  Its a lot simpler (and has no loss in generality) to
see:

[jaxrs-api.jar]=/usr/share/java/resteasy/jaxrs-api.jar

instead of:
[jaxrs-api.jar]=${resteasy_java_dir}/jaxrs-api.jar

If I need to understand what a particular link is, I can see it directly
rather than having to hunt through figuring out what {resteasy_java_dir}
is, which in turn is defined in terms of {java_dir} ...

The only reason you might want to declare variables here would be for
arch dependent links.
  
Ade

On Wed, 2012-08-22 at 20:21 -0700, Matthew Harmsen wrote:
> This patch addresses the issue listed below for Dogtag 10:
>       * TRAC Ticket #301 - Need to modify init scripts to verify
>         needed symlinks in an instance
> This patch has been tested and found to work successfully on 64-bit
> Fedora 17 with SElinux in "Permissive" mode:
>       * Built and installed Dogtag 9 Packages on a 64-bit Fedora 17
>         host
>       * Installed and configured Dogtag 9 CA instance
>       * Successfully submitted an enrollment request, approved
>         enrollment request, issued certificate, and listed
>         certificates
>       * Built and installed Dogtag 10 Packages on the same 64-bit
>         Fedora 17 host
>       * Restarted Dogtag 9 CA instance (so that it was now running
>         under Dogtag 10)
>       * Successfully submitted an enrollment request and listed
>         certificates 
>       * Successfully approved the enrollment request and issued a
>         certificate AFTER:
>               * manually shutting down the CA instance,
>               * applying the CS.cfg fixes documented in "TRAC Ticket
>                 #303 - Dogtag 10: CS.cfg parameters for Dogtag 9
>                 instance running under Dogtag 10 packages . . .", and
>               * restarting the CA instance)
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Fri Aug 24 14:54:48 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 24 Aug 2012 10:54:48 -0400
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 9)
In-Reply-To: <5035A2CB.10207@redhat.com>
References: <5035A2CB.10207@redhat.com>
Message-ID: <1345820089.2539.64.camel@aleeredhat.laptop>

same comments as on the dogtag 10 patch.

On Wed, 2012-08-22 at 20:26 -0700, Matthew Harmsen wrote:
> This patch addresses the issue listed below for Dogtag 9:
>       * TRAC Ticket #301 - Need to modify init scripts to verify
>         needed symlinks in an instance
> This patch has been tested and found to work successfully on 64-bit
> Fedora 16 with SElinux in "Permissive" mode:
>       * Built and installed Dogtag 9 Packages on a 64-bit Fedora 16
>         host
>       * Installed and configured Dogtag 9 CA, KRA, OCSP, TKS, RA, and
>         TPS instances
>       * Tested attached symlinks patch on all subsystems (although I
>         was unable to get the configured TPS to restart --
>         successfully applied logic from standalone test program)
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From akoneru at redhat.com  Fri Aug 24 20:14:30 2012
From: akoneru at redhat.com (Abhishek Koneru)
Date: Fri, 24 Aug 2012 16:14:30 -0400
Subject: [Pki-devel] [PATCH] 30 Continued - Fix for ticket 219 for DogTag
 branches : 8.1_Errata and 8.2
Message-ID: <1345839270.11778.4.camel@akoneru.redhat.com>

Please review the patches attached with fix ticket 219 for DogTag
branches - 8.1_Errata and 8.2.
The description about the ticket is attached below.

--Abhishek Koneru

Defect description:
  The serial number generated for certificates is wrong when the number
is large. Problem is due to the conversion of BigInteger to integer
while generating a new serial number, which truncates the most
significant bits in the serial number and therefore a large number (eg.
10fff0001) becomes a smaller number (eg. fff0001). This conversion in
turn leads to a collision if a certificate with the smaller number
exists in the database.

Steps to reproduce the defect:
 
 - Create a CA. - (1)
 - Edit the fields minSerialNumber and maxSerialNumber in the
<CA-Installation Path>/conf.CS.cfg to large values like 100000000 and
110000000.
 - Restart the CA.
 - Configure the CA.
 - Create a new CA.
 - Configure this as a clone to (1)CA
 - After the Certificates are generated, view the serial number by
clicking on "View Certificate in PrettyPrint".

Results:
Before the patch is applied: The serial number is truncated.(Wrong)
After the patch is applied: The serial number is found as expected.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ticket219-fix-Dogtag8.2-branch.patch
Type: text/x-patch
Size: 5192 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120824/26bdf110/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ticket_219-fix-Dogtag_8.1_Errata_Branch.patch
Type: text/x-patch
Size: 5080 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120824/26bdf110/attachment-0001.bin>

From alee at redhat.com  Tue Aug 28 02:29:56 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 27 Aug 2012 22:29:56 -0400
Subject: [Pki-devel] [PATCH] 101 Fixed exceptions during shutdown.
In-Reply-To: <50368060.10004@redhat.com>
References: <502E6B86.7090505@redhat.com> <50368060.10004@redhat.com>
Message-ID: <1346120997.2539.78.camel@aleeredhat.laptop>

ack

On Thu, 2012-08-23 at 14:11 -0500, Endi Sukma Dewata wrote:
> On 8/17/2012 11:04 AM, Endi Sukma Dewata wrote:
> > The shutdown() methods in several classes have been fixed to allow
> > more graceful shutdown. Null pointers are checked to avoid exception.
> > It's not necessary to empty container objects since they might still
> > be used by other threads and will be garbage collected eventually.
> >
> > Ticket #247
> 
> Revised the patch to handle the attributes more consistently. See the 
> updated patch description.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 03:26:03 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 27 Aug 2012 23:26:03 -0400
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM
 packages.
In-Reply-To: <5035738F.8010003@redhat.com>
References: <503278F4.4050105@redhat.com> <5033DB58.8090801@redhat.com>
	<5035738F.8010003@redhat.com>
Message-ID: <1346124363.2539.94.camel@aleeredhat.laptop>

1. As discussed on #irc, please add a patch to handle the javadoc
packages.

2.  How did you determine the Requires for pki-base?  We do not want to
install more than is necessary on a client.  For example, it isn't clear
to me that jython should be a requirement for pki-base.  Rather it
should have been a requirement for pki-deploy - which becomes part of
pki-server.  

Similarly the following seem to be requirements for pki-server rather
than pki-base:  pki-common-theme, velocity, tomcatjss, pki-symkey,
(jss?)

3.  The following should probably be replaced by packages (if possible):
Requires:         %{_javadir}/velocity.jar
Requires:         %{_javadir}/xalan-j2.jar
Requires:         %{_javadir}/xalan-j2-serializer.jar
Requires:         %{_javadir}/xerces-j2.jar
Requires:         %{_javadir}/xml-commons-apis.jar
Requires:         %{_javadir}/xml-commons-resolver.jar

And then we should ask whether they are requirements for pki-base or
pki-server.

4. pki-symkey: I know we said this will likely eventually be folded into
jss.  But this is only used by the tks.  So it should be a requirement
for either pki-server or pki-tks.

5.  Its also an interesting question as to whether velocity is in fact a
requirement for the *-theme packages, rather than pki-server.
 
Ade
On Wed, 2012-08-22 at 19:04 -0500, Endi Sukma Dewata wrote:
> On 8/21/2012 2:02 PM, Endi Sukma Dewata wrote:
> > On 8/20/2012 12:50 PM, Endi Sukma Dewata wrote:
> >> The pki-common package has been split such that the common and
> >> client binaries are packaged in pki-base and server binaries are
> >> packaged in pki-server. The pki-util has been merged into pki-base
> >> and the pki-deploy package has been merged into pki-server.
> >>
> >> Ticket #295
> >
> > New patch attached. The old package definition wasn't removed properly.
> 
> New patch attached. Updated pki-console.spec, dogtag-pki.spec, and some 
> other files.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 03:31:21 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 27 Aug 2012 23:31:21 -0400
Subject: [Pki-devel] [PATCH] 104 Moved REST CLI into pki-tools.
In-Reply-To: <5032CCCF.9030204@redhat.com>
References: <5032CCCF.9030204@redhat.com>
Message-ID: <1346124681.2539.95.camel@aleeredhat.laptop>

ack

On Mon, 2012-08-20 at 18:48 -0500, Endi Sukma Dewata wrote:
> The pki-client.jar has been split and merged into pki-certsrv.jar
> and pki-tools.jar. The REST client classes are now packaged in
> com.netscape.certsrv.<component> packages. The REST CLI classes
> are now packaged in com.netscape.cmstools.<component> packages.
> The "pki" script has been moved into pki-tools RPM package.
> 
> Ticket #215
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 03:31:50 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 27 Aug 2012 23:31:50 -0400
Subject: [Pki-devel] [PATCH] 103 Merged pki-native-tools and
 pki-java-tools.
In-Reply-To: <50357393.3000405@redhat.com>
References: <5032A0FB.1070601@redhat.com> <50357393.3000405@redhat.com>
Message-ID: <1346124710.2539.96.camel@aleeredhat.laptop>

ack

On Wed, 2012-08-22 at 19:04 -0500, Endi Sukma Dewata wrote:
> On 8/20/2012 3:41 PM, Endi Sukma Dewata wrote:
> > The pki-native-tools and pki-java-tools have been merged into
> > pki-tools and pki-server will depend on it. Since pki-ra and
> > pki-tps depends on pki-server they automatically depends on
> > pki-tools as well.
> >
> > Ticket #295
> 
> New patch attached. Updated dogtag-pki.spec and some other files.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 03:52:31 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 27 Aug 2012 23:52:31 -0400
Subject: [Pki-devel] [PATCH] 105 Updated CMake jar() function.
In-Reply-To: <5035739C.1040501@redhat.com>
References: <5035739C.1040501@redhat.com>
Message-ID: <1346125952.2539.97.camel@aleeredhat.laptop>

ack
On Wed, 2012-08-22 at 19:04 -0500, Endi Sukma Dewata wrote:
> The jar() function has been modified to support multiple input dirs
> in a single command. This way it's not necessary to define multiple
> jar targets for the same jar file. The pki-console build script has
> been updated to utilize this functionality.
> 
> Ticket #89
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 03:52:45 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 27 Aug 2012 23:52:45 -0400
Subject: [Pki-devel] [PATCH] 106 Moved WAR creation code into CMake
 scripts.
In-Reply-To: <503573D6.30006@redhat.com>
References: <503573D6.30006@redhat.com>
Message-ID: <1346125966.2539.98.camel@aleeredhat.laptop>

ack
On Wed, 2012-08-22 at 19:05 -0500, Endi Sukma Dewata wrote:
> The code to generate the WAR files has been moved from the RPM
> spec file into the CMake scripts for each subsystem to allow better
> control.
> 
> Ticket #89
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From mharmsen at redhat.com  Tue Aug 28 03:57:11 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Mon, 27 Aug 2012 20:57:11 -0700
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 9)
In-Reply-To: <1345820089.2539.64.camel@aleeredhat.laptop>
References: <5035A2CB.10207@redhat.com>
	<1345820089.2539.64.camel@aleeredhat.laptop>
Message-ID: <503C4197.3050309@redhat.com>

This patch attempts to address these issues.

On 08/24/12 07:54, Ade Lee wrote:
> same comments as on the dogtag 10 patch.
>
> On Wed, 2012-08-22 at 20:26 -0700, Matthew Harmsen wrote:
>> This patch addresses the issue listed below for Dogtag 9:
>>        * TRAC Ticket #301 - Need to modify init scripts to verify
>>          needed symlinks in an instance
>> This patch has been tested and found to work successfully on 64-bit
>> Fedora 16 with SElinux in "Permissive" mode:
>>        * Built and installed Dogtag 9 Packages on a 64-bit Fedora 16
>>          host
>>        * Installed and configured Dogtag 9 CA, KRA, OCSP, TKS, RA, and
>>          TPS instances
>>        * Tested attached symlinks patch on all subsystems (although I
>>          was unable to get the configured TPS to restart --
>>          successfully applied logic from standalone test program)
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120827-Verify-symbolic-links-Dogtag-9.patch
Type: text/x-patch
Size: 20155 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120827/13269133/attachment.bin>

From mharmsen at redhat.com  Tue Aug 28 04:01:27 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Mon, 27 Aug 2012 21:01:27 -0700
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 10)
In-Reply-To: <1345820060.2539.63.camel@aleeredhat.laptop>
References: <5035A1AC.8010803@redhat.com>
	<1345820060.2539.63.camel@aleeredhat.laptop>
Message-ID: <503C4297.4090601@redhat.com>

The attached patch attempts to address these issues and adds a patch for:

  * TRAC Ticket #303 - Dogtag 10: CS.cfg parameters for Dogtag 9
    instance running under Dogtag 10 packages . . .

With the addition of the patch above, I was able to simply restart the 
server and it successfully started a Dogtag 9 CA instance running under 
the Dogtag 10 packages.

On 08/24/12 07:54, Ade Lee wrote:
> Couple of comments:
>
> 1. We need to think about how to handle each of the cases you have
> encountered.  There are a number of cases where you simply warn and exit
> rather than fixing the link.  I think these are open for debate, but I
> suggest the following:
>
> missing link -> (currently) add the link (suggested) add the link
> link pointing to wrong place --> (currently) error (suggested) fix the link
> link pointing to non-existent target --> (currently) error (suggested) fix the link
> link is actually a file -> (currently) warn (suggested) warn
> link is a directory or otherwise -> (currently) error (suggested) error
>     
> 2. This is perhaps a stylistic comment.  You spend a large number of
> lines defining variables that specify paths that ultimately only ever
> get used within the same function.  To me, this just makes the code
> harder to read.  Its a lot simpler (and has no loss in generality) to
> see:
>
> [jaxrs-api.jar]=/usr/share/java/resteasy/jaxrs-api.jar
>
> instead of:
> [jaxrs-api.jar]=${resteasy_java_dir}/jaxrs-api.jar
>
> If I need to understand what a particular link is, I can see it directly
> rather than having to hunt through figuring out what {resteasy_java_dir}
> is, which in turn is defined in terms of {java_dir} ...
>
> The only reason you might want to declare variables here would be for
> arch dependent links.
>    
> Ade
>
> On Wed, 2012-08-22 at 20:21 -0700, Matthew Harmsen wrote:
>> This patch addresses the issue listed below for Dogtag 10:
>>        * TRAC Ticket #301 - Need to modify init scripts to verify
>>          needed symlinks in an instance
>> This patch has been tested and found to work successfully on 64-bit
>> Fedora 17 with SElinux in "Permissive" mode:
>>        * Built and installed Dogtag 9 Packages on a 64-bit Fedora 17
>>          host
>>        * Installed and configured Dogtag 9 CA instance
>>        * Successfully submitted an enrollment request, approved
>>          enrollment request, issued certificate, and listed
>>          certificates
>>        * Built and installed Dogtag 10 Packages on the same 64-bit
>>          Fedora 17 host
>>        * Restarted Dogtag 9 CA instance (so that it was now running
>>          under Dogtag 10)
>>        * Successfully submitted an enrollment request and listed
>>          certificates
>>        * Successfully approved the enrollment request and issued a
>>          certificate AFTER:
>>                * manually shutting down the CA instance,
>>                * applying the CS.cfg fixes documented in "TRAC Ticket
>>                  #303 - Dogtag 10: CS.cfg parameters for Dogtag 9
>>                  instance running under Dogtag 10 packages . . .", and
>>                * restarting the CA instance)
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120827/f696cc9e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120827-Verify-symbolic-links-Dogtag-10.patch
Type: text/x-patch
Size: 44584 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120827/f696cc9e/attachment.bin>

From alee at redhat.com  Tue Aug 28 04:05:29 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 28 Aug 2012 00:05:29 -0400
Subject: [Pki-devel] [PATCH] 104 Moved REST CLI into pki-tools.
In-Reply-To: <1346124681.2539.95.camel@aleeredhat.laptop>
References: <5032CCCF.9030204@redhat.com>
	<1346124681.2539.95.camel@aleeredhat.laptop>
Message-ID: <1346126729.2539.99.camel@aleeredhat.laptop>

Actually - not quite ack.  The eclipse build works, but the cmake build
fails.

On Mon, 2012-08-27 at 23:31 -0400, Ade Lee wrote:
> ack
> 
> On Mon, 2012-08-20 at 18:48 -0500, Endi Sukma Dewata wrote:
> > The pki-client.jar has been split and merged into pki-certsrv.jar
> > and pki-tools.jar. The REST client classes are now packaged in
> > com.netscape.certsrv.<component> packages. The REST CLI classes
> > are now packaged in com.netscape.cmstools.<component> packages.
> > The "pki" script has been moved into pki-tools RPM package.
> > 
> > Ticket #215
> > 
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 13:33:31 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 28 Aug 2012 09:33:31 -0400
Subject: [Pki-devel] [PATCH] 107 Added proxy realm.
In-Reply-To: <503573E0.7030007@redhat.com>
References: <503573E0.7030007@redhat.com>
Message-ID: <1346160812.2539.135.camel@aleeredhat.laptop>

The changes look ok, although due to the issue in one of the previous
patches, I cannot build yet using the compose scripts.

What effect does this patch have on the patch that mharmsen is currently
working on?  At the very least, you will need to modify where it is
checking for links for the dogtag 10 instance.

And how does this affect a dogtag 9 instance running under dogtag 10
code?

On Wed, 2012-08-22 at 19:05 -0500, Endi Sukma Dewata wrote:
> CMS engine is a singleton and it's used by PKI realm to authenticate
> users accessing the subsystem. Since a Tomcat instance may contain
> multiple subsystems, each having separate realm, the PKI JAR files
> need to be moved into WEB-INF/lib so that they will run inside
> separate class loaders. Note that Tomcat requires that the JAR files
> be copied into this folder, they cannot be linked.
> 
> Tomcat also requires that the authenticator and realm classes be
> available in common/lib. To address this a new package pki-tomcat.jar
> has been added. The package contains the authenticator and a proxy
> realm. When the subsystems start running, they will register their
> own realms into the proxy realms such that the authentications will
> be forwarded to the appropriate subsystems.
> 
> Ticket #89
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Tue Aug 28 14:25:10 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 28 Aug 2012 10:25:10 -0400
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 9)
In-Reply-To: <503C4197.3050309@redhat.com>
References: <5035A2CB.10207@redhat.com>
	<1345820089.2539.64.camel@aleeredhat.laptop>
	<503C4197.3050309@redhat.com>
Message-ID: <1346163910.2539.159.camel@aleeredhat.laptop>

The CS.cfg logic looks fine.

The check_symlinks() code is still a little confusing.

You do the following check:

target=${symlinks[${key}]}
# Check to make certain that the expected target exists.
if [ -e ${target} ]; then
    ....
else
    # Attempt to remove this dangling symbolic link and
    # issue an ERROR that the target to which the
    # symbolic link is expected to point does NOT exist.
    rm ${symlink}
    ....

This is not correct.  Its not necessarily a danglng link.  The link that
is there may in fact point to another (wrong) target.  All you know is
that you cannot correct this link because the expected target does not
exist.

To simplify check_links(), I suggest that you move the check for whether
or not the target exists and is fully resolvable into make_symlink().
If either fails, then error out.

then the logic in check_symlinks() becomes simpler.

if [ -e symlink]; then
    if [-h symlink]; then
        target = symlinks[key]
        current_target = `readlink symlink`
        if [target == current_target]; then 
            check if exists and resolvable and chown
        else
            rm symlink
            make_link()
    elif [-f symlink]
        warn about debugging
    else
        error "directory or some such"
else
    make_link()

On Mon, 2012-08-27 at 20:57 -0700, Matthew Harmsen wrote:
> This patch attempts to address these issues.
> 
> On 08/24/12 07:54, Ade Lee wrote:
> > same comments as on the dogtag 10 patch.
> >
> > On Wed, 2012-08-22 at 20:26 -0700, Matthew Harmsen wrote:
> >> This patch addresses the issue listed below for Dogtag 9:
> >>        * TRAC Ticket #301 - Need to modify init scripts to verify
> >>          needed symlinks in an instance
> >> This patch has been tested and found to work successfully on 64-bit
> >> Fedora 16 with SElinux in "Permissive" mode:
> >>        * Built and installed Dogtag 9 Packages on a 64-bit Fedora 16
> >>          host
> >>        * Installed and configured Dogtag 9 CA, KRA, OCSP, TKS, RA, and
> >>          TPS instances
> >>        * Tested attached symlinks patch on all subsystems (although I
> >>          was unable to get the configured TPS to restart --
> >>          successfully applied logic from standalone test program)
> >> _______________________________________________
> >> Pki-devel mailing list
> >> Pki-devel at redhat.com
> >> https://www.redhat.com/mailman/listinfo/pki-devel
> >
> 




From edewata at redhat.com  Tue Aug 28 20:02:08 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 28 Aug 2012 15:02:08 -0500
Subject: [Pki-devel] [PATCH] 101 Fixed exceptions during shutdown.
In-Reply-To: <1346120997.2539.78.camel@aleeredhat.laptop>
References: <502E6B86.7090505@redhat.com> <50368060.10004@redhat.com>
	<1346120997.2539.78.camel@aleeredhat.laptop>
Message-ID: <503D23C0.7030902@redhat.com>

On 8/27/2012 9:29 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Tue Aug 28 20:02:42 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 28 Aug 2012 15:02:42 -0500
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM
	packages.
In-Reply-To: <1346124363.2539.94.camel@aleeredhat.laptop>
References: <503278F4.4050105@redhat.com> <5033DB58.8090801@redhat.com>
	<5035738F.8010003@redhat.com>
	<1346124363.2539.94.camel@aleeredhat.laptop>
Message-ID: <503D23E2.4060209@redhat.com>

On 8/27/2012 10:26 PM, Ade Lee wrote:
> 1. As discussed on #irc, please add a patch to handle the javadoc
> packages.

I opened a ticket for this:
https://fedorahosted.org/pki/ticket/305

> 2.  How did you determine the Requires for pki-base?  We do not want to
> install more than is necessary on a client.  For example, it isn't clear
> to me that jython should be a requirement for pki-base.  Rather it
> should have been a requirement for pki-deploy - which becomes part of
> pki-server.

The original pki-common's Requires were split for pki-base (combined 
with pki-util) and pki-server. Ideally all server-specific Requires 
should go to pki-server. But it's difficult to make a clean split 
without inspecting the code and running tests. So this patch contains a 
pretty safe split, the pki-base may contain more than required, but it 
wouldn't hurt and can be refined again.

> Similarly the following seem to be requirements for pki-server rather
> than pki-base:  pki-common-theme, velocity, tomcatjss, pki-symkey,
> (jss?)

OK, I'll move the Requires as follows:
  * pki-common-theme, velocity, & tomcatjss ==> pki-server
  * pki-symkey ==> pki-tks

Should we rename pki-common-theme to pki-server-theme?
The jss will stay in pki-base because it's required by the clients.

> 3.  The following should probably be replaced by packages (if possible):
> Requires:         %{_javadir}/velocity.jar
> Requires:         %{_javadir}/xalan-j2.jar
> Requires:         %{_javadir}/xalan-j2-serializer.jar
> Requires:         %{_javadir}/xerces-j2.jar
> Requires:         %{_javadir}/xml-commons-apis.jar
> Requires:         %{_javadir}/xml-commons-resolver.jar

This is an existing issue, it should be addressed separately: 
https://fedorahosted.org/pki/ticket/306

> And then we should ask whether they are requirements for pki-base or
> pki-server.

I'll move the velocity.jar to pki-server, but the rest might have to 
wait. Those XML libraries could be needed indirectly by pki-base.

> 4. pki-symkey: I know we said this will likely eventually be folded into
> jss.  But this is only used by the tks.  So it should be a requirement
> for either pki-server or pki-tks.

Yes, this goes to pki-tks and we'll remove it once it's merged into jss.

> 5.  Its also an interesting question as to whether velocity is in fact a
> requirement for the *-theme packages, rather than pki-server.

To my understanding the themes only contain velocity scripts and we only 
need the velocity.jar when the server runs it.

I'll post a revised patch with these changes.

-- 
Endi S. Dewata



From mharmsen at redhat.com  Wed Aug 29 00:07:58 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 28 Aug 2012 17:07:58 -0700
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 9)
In-Reply-To: <1346163910.2539.159.camel@aleeredhat.laptop>
References: <5035A2CB.10207@redhat.com>
	<1345820089.2539.64.camel@aleeredhat.laptop>
	<503C4197.3050309@redhat.com>
	<1346163910.2539.159.camel@aleeredhat.laptop>
Message-ID: <503D5D5E.40407@redhat.com>

The following patch attempts to address these issues.

It should be understood that this has NOT been tested with any package 
renames/location changes that may have been checked-in this morning, and 
as such, the data may need to be changed and tested to comply with these 
changes.

-- Matt

On 08/28/12 07:25, Ade Lee wrote:
> The CS.cfg logic looks fine.
>
> The check_symlinks() code is still a little confusing.
>
> You do the following check:
>
> target=${symlinks[${key}]}
> # Check to make certain that the expected target exists.
> if [ -e ${target} ]; then
>      ....
> else
>      # Attempt to remove this dangling symbolic link and
>      # issue an ERROR that the target to which the
>      # symbolic link is expected to point does NOT exist.
>      rm ${symlink}
>      ....
>
> This is not correct.  Its not necessarily a danglng link.  The link that
> is there may in fact point to another (wrong) target.  All you know is
> that you cannot correct this link because the expected target does not
> exist.
>
> To simplify check_links(), I suggest that you move the check for whether
> or not the target exists and is fully resolvable into make_symlink().
> If either fails, then error out.
>
> then the logic in check_symlinks() becomes simpler.
>
> if [ -e symlink]; then
>      if [-h symlink]; then
>          target = symlinks[key]
>          current_target = `readlink symlink`
>          if [target == current_target]; then
>              check if exists and resolvable and chown
>          else
>              rm symlink
>              make_link()
>      elif [-f symlink]
>          warn about debugging
>      else
>          error "directory or some such"
> else
>      make_link()
>
> On Mon, 2012-08-27 at 20:57 -0700, Matthew Harmsen wrote:
>> This patch attempts to address these issues.
>>
>> On 08/24/12 07:54, Ade Lee wrote:
>>> same comments as on the dogtag 10 patch.
>>>
>>> On Wed, 2012-08-22 at 20:26 -0700, Matthew Harmsen wrote:
>>>> This patch addresses the issue listed below for Dogtag 9:
>>>>         * TRAC Ticket #301 - Need to modify init scripts to verify
>>>>           needed symlinks in an instance
>>>> This patch has been tested and found to work successfully on 64-bit
>>>> Fedora 16 with SElinux in "Permissive" mode:
>>>>         * Built and installed Dogtag 9 Packages on a 64-bit Fedora 16
>>>>           host
>>>>         * Installed and configured Dogtag 9 CA, KRA, OCSP, TKS, RA, and
>>>>           TPS instances
>>>>         * Tested attached symlinks patch on all subsystems (although I
>>>>           was unable to get the configured TPS to restart --
>>>>           successfully applied logic from standalone test program)
>>>> _______________________________________________
>>>> Pki-devel mailing list
>>>> Pki-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120828-Verify-symbolic-links-Dogtag-9.patch
Type: text/x-patch
Size: 16711 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120828/064757b3/attachment.bin>

From mharmsen at redhat.com  Wed Aug 29 00:10:50 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 28 Aug 2012 17:10:50 -0700
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 10)
Message-ID: <503D5E0A.5090909@redhat.com>

The following patch attempts to address the issues expressed for the 
complementary Dogtag 9 patch.

It should be understood that this has NOT been tested with any package 
renames/location changes that may have been checked-in this morning, and 
as such, the data may need to be changed and tested to comply with these 
changes.

-- Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20120828-Verify-symbolic-links-Dogtag-10.patch
Type: text/x-patch
Size: 37696 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120828/c2276cb5/attachment.bin>

From rcritten at redhat.com  Wed Aug 29 13:04:14 2012
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 29 Aug 2012 09:04:14 -0400
Subject: [Pki-devel] What if I lose my IPA CA?
Message-ID: <503E134E.6000604@redhat.com>

I can't find any documentation how we'd handle this in IPA, so before a 
customer runs into it...

What happens if someone sets up multiple IPA servers and only has a CA 
installed on one of them, and that server goes away forever for some 
reason (they deleted the replica, horrific failure, etc)?

Let's also assume they saved the original CA PKCS#12 file.

Is there some mechanism to either stand up a new dogtag instance with 
this CA's key? Would it be better to stand up a new server as a 
subordinate of this CA?

I'm not entirely sure of the mechanics we'd use for either of these, but 
its a start.

thanks

rob



From alee at redhat.com  Wed Aug 29 15:14:05 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 29 Aug 2012 11:14:05 -0400
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 10)
In-Reply-To: <503D5E0A.5090909@redhat.com>
References: <503D5E0A.5090909@redhat.com>
Message-ID: <1346253246.2539.178.camel@aleeredhat.laptop>

ack

On Tue, 2012-08-28 at 17:10 -0700, Matthew Harmsen wrote:
> The following patch attempts to address the issues expressed for the 
> complementary Dogtag 9 patch.
> 
> It should be understood that this has NOT been tested with any package 
> renames/location changes that may have been checked-in this morning, and 
> as such, the data may need to be changed and tested to comply with these 
> changes.
> 
> -- Matt




From alee at redhat.com  Wed Aug 29 15:14:20 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 29 Aug 2012 11:14:20 -0400
Subject: [Pki-devel] [PATCH] Verify Symbolic Links (Dogtag 9)
In-Reply-To: <503D5D5E.40407@redhat.com>
References: <5035A2CB.10207@redhat.com>
	<1345820089.2539.64.camel@aleeredhat.laptop>
	<503C4197.3050309@redhat.com>
	<1346163910.2539.159.camel@aleeredhat.laptop>
	<503D5D5E.40407@redhat.com>
Message-ID: <1346253261.2539.179.camel@aleeredhat.laptop>

ack

On Tue, 2012-08-28 at 17:07 -0700, Matthew Harmsen wrote:
> The following patch attempts to address these issues.
> 
> It should be understood that this has NOT been tested with any package 
> renames/location changes that may have been checked-in this morning, and 
> as such, the data may need to be changed and tested to comply with these 
> changes.
> 
> -- Matt
> 
> On 08/28/12 07:25, Ade Lee wrote:
> > The CS.cfg logic looks fine.
> >
> > The check_symlinks() code is still a little confusing.
> >
> > You do the following check:
> >
> > target=${symlinks[${key}]}
> > # Check to make certain that the expected target exists.
> > if [ -e ${target} ]; then
> >      ....
> > else
> >      # Attempt to remove this dangling symbolic link and
> >      # issue an ERROR that the target to which the
> >      # symbolic link is expected to point does NOT exist.
> >      rm ${symlink}
> >      ....
> >
> > This is not correct.  Its not necessarily a danglng link.  The link that
> > is there may in fact point to another (wrong) target.  All you know is
> > that you cannot correct this link because the expected target does not
> > exist.
> >
> > To simplify check_links(), I suggest that you move the check for whether
> > or not the target exists and is fully resolvable into make_symlink().
> > If either fails, then error out.
> >
> > then the logic in check_symlinks() becomes simpler.
> >
> > if [ -e symlink]; then
> >      if [-h symlink]; then
> >          target = symlinks[key]
> >          current_target = `readlink symlink`
> >          if [target == current_target]; then
> >              check if exists and resolvable and chown
> >          else
> >              rm symlink
> >              make_link()
> >      elif [-f symlink]
> >          warn about debugging
> >      else
> >          error "directory or some such"
> > else
> >      make_link()
> >
> > On Mon, 2012-08-27 at 20:57 -0700, Matthew Harmsen wrote:
> >> This patch attempts to address these issues.
> >>
> >> On 08/24/12 07:54, Ade Lee wrote:
> >>> same comments as on the dogtag 10 patch.
> >>>
> >>> On Wed, 2012-08-22 at 20:26 -0700, Matthew Harmsen wrote:
> >>>> This patch addresses the issue listed below for Dogtag 9:
> >>>>         * TRAC Ticket #301 - Need to modify init scripts to verify
> >>>>           needed symlinks in an instance
> >>>> This patch has been tested and found to work successfully on 64-bit
> >>>> Fedora 16 with SElinux in "Permissive" mode:
> >>>>         * Built and installed Dogtag 9 Packages on a 64-bit Fedora 16
> >>>>           host
> >>>>         * Installed and configured Dogtag 9 CA, KRA, OCSP, TKS, RA, and
> >>>>           TPS instances
> >>>>         * Tested attached symlinks patch on all subsystems (although I
> >>>>           was unable to get the configured TPS to restart --
> >>>>           successfully applied logic from standalone test program)
> >>>> _______________________________________________
> >>>> Pki-devel mailing list
> >>>> Pki-devel at redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/pki-devel
> >
> 




From awnuk at redhat.com  Wed Aug 29 15:18:50 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Wed, 29 Aug 2012 08:18:50 -0700
Subject: [Pki-devel] What if I lose my IPA CA?
In-Reply-To: <503E134E.6000604@redhat.com>
References: <503E134E.6000604@redhat.com>
Message-ID: <503E32DA.1000502@redhat.com>

On 08/29/2012 06:04 AM, Rob Crittenden wrote:
> I can't find any documentation how we'd handle this in IPA, so before 
> a customer runs into it...
>
> What happens if someone sets up multiple IPA servers and only has a CA 
> installed on one of them, and that server goes away forever for some 
> reason (they deleted the replica, horrific failure, etc)?
>
> Let's also assume they saved the original CA PKCS#12 file.

You may need to save more than the original CA PKCS#12 file.
You should save also CA's internal database and remember how it was 
customize.

>
> Is there some mechanism to either stand up a new dogtag instance with 
> this CA's key? Would it be better to stand up a new server as a 
> subordinate of this CA?
>
> I'm not entirely sure of the mechanics we'd use for either of these, 
> but its a start.
>
> thanks
>
> rob
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel



From jmagne at redhat.com  Wed Aug 29 19:04:42 2012
From: jmagne at redhat.com (John Magne)
Date: Wed, 29 Aug 2012 15:04:42 -0400 (EDT)
Subject: [Pki-devel] Review Request - Bug 849027 - rhcs81 tks failed start
 in selftest sharedsessionkey - symkey PK11_Derive
In-Reply-To: <941452654.23255437.1346267045095.JavaMail.root@redhat.com>
Message-ID: <2084932884.23255477.1346267082798.JavaMail.root@redhat.com>


Patch to simply allow TKS to come up as normal when doing its initial self tests.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=849027

Attachment: https://bugzilla.redhat.com/attachment.cgi?id=607970&action=diff



From jmagne at redhat.com  Wed Aug 29 19:09:20 2012
From: jmagne at redhat.com (John Magne)
Date: Wed, 29 Aug 2012 15:09:20 -0400 (EDT)
Subject: [Pki-devel] Reivew Request - Bug 844800 - TPS should provide the
 ability to not allow tokens marked as 'Terminated' to be formatted and
 reused
Message-ID: <64340166.23256824.1346267360184.JavaMail.root@redhat.com>


Patch to allow independent transition states for both the TPS UI and TPS operations such as Format and Enrollment.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=844800

Attachment: https://bugzilla.redhat.com/attachment.cgi?id=607976&action=diff



From edewata at redhat.com  Wed Aug 29 22:04:53 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 17:04:53 -0500
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM
	packages.
In-Reply-To: <503D23E2.4060209@redhat.com>
References: <503278F4.4050105@redhat.com> <5033DB58.8090801@redhat.com>
	<5035738F.8010003@redhat.com>
	<1346124363.2539.94.camel@aleeredhat.laptop>
	<503D23E2.4060209@redhat.com>
Message-ID: <503E9205.8030504@redhat.com>

On 8/28/2012 3:02 PM, Endi Sukma Dewata wrote:
> I'll post a revised patch with these changes.

New patch attached.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0102-3-Added-pki-base-and-pki-server-RPM-packages.patch
Type: text/x-patch
Size: 26625 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120829/b0ff4aa9/attachment.bin>

From edewata at redhat.com  Wed Aug 29 22:04:57 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 17:04:57 -0500
Subject: [Pki-devel] [PATCH] 103 Merged pki-native-tools and
	pki-java-tools.
In-Reply-To: <1346124710.2539.96.camel@aleeredhat.laptop>
References: <5032A0FB.1070601@redhat.com> <50357393.3000405@redhat.com>
	<1346124710.2539.96.camel@aleeredhat.laptop>
Message-ID: <503E9209.9020102@redhat.com>

On 8/27/2012 10:31 PM, Ade Lee wrote:
> ack

Rebased, no code change.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0103-2-Merged-pki-native-tools-and-pki-java-tools.patch
Type: text/x-patch
Size: 17101 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120829/b6d0948c/attachment.bin>

From edewata at redhat.com  Wed Aug 29 22:05:57 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 17:05:57 -0500
Subject: [Pki-devel] [PATCH] 107 Added proxy realm.
In-Reply-To: <1346160812.2539.135.camel@aleeredhat.laptop>
References: <503573E0.7030007@redhat.com>
	<1346160812.2539.135.camel@aleeredhat.laptop>
Message-ID: <503E9245.8050403@redhat.com>

On 8/28/2012 8:33 AM, Ade Lee wrote:
> The changes look ok, although due to the issue in one of the previous
> patches, I cannot build yet using the compose scripts.

New patch attached. I added allowLinking=true so now it can use links in 
the WEB-INF/lib.

> What effect does this patch have on the patch that mharmsen is currently
> working on?  At the very least, you will need to modify where it is
> checking for links for the dogtag 10 instance.

I modified the operations and functions to check the pki-*.jars at the 
new location.

> And how does this affect a dogtag 9 instance running under dogtag 10
> code?

I tried upgrading Dogtag 9 instance and it seems to be working fine. The 
pki-tomcat.jar link will be added into common/lib so the code in 
CMSStartServlet will still work although it's not used.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0107-1-Added-proxy-realm.patch
Type: text/x-patch
Size: 34866 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120829/afa0d653/attachment.bin>

From edewata at redhat.com  Wed Aug 29 22:06:05 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 17:06:05 -0500
Subject: [Pki-devel] [PATCH] 104 Moved REST CLI into pki-tools.
In-Reply-To: <1346126729.2539.99.camel@aleeredhat.laptop>
References: <5032CCCF.9030204@redhat.com>
	<1346124681.2539.95.camel@aleeredhat.laptop>
	<1346126729.2539.99.camel@aleeredhat.laptop>
Message-ID: <503E924D.7060206@redhat.com>

On 8/27/2012 11:05 PM, Ade Lee wrote:
> Actually - not quite ack.  The eclipse build works, but the cmake build
> fails.

I couldn't reproduce the problem. Could you try again with the new 
patches? They should be applied in this order: 102-3, 103-2, 104, 105, 
106, 107-1.

-- 
Endi S. Dewata



From cfu at redhat.com  Wed Aug 29 22:24:06 2012
From: cfu at redhat.com (Christina Fu)
Date: Wed, 29 Aug 2012 15:24:06 -0700
Subject: [Pki-devel] Review Request - Bug 849027 - rhcs81 tks failed
 start in selftest sharedsessionkey - symkey PK11_Derive
In-Reply-To: <2084932884.23255477.1346267082798.JavaMail.root@redhat.com>
References: <2084932884.23255477.1346267082798.JavaMail.root@redhat.com>
Message-ID: <503E9686.7070603@redhat.com>

On 08/29/2012 12:04 PM, John Magne wrote:
> Patch to simply allow TKS to come up as normal when doing its initial self tests.
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=849027
>
> Attachment: https://bugzilla.redhat.com/attachment.cgi?id=607970&action=diff

ACK.



From edewata at redhat.com  Thu Aug 30 04:44:05 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 23:44:05 -0500
Subject: [Pki-devel] [PATCH] 102 Added pki-base and pki-server RPM
	packages.
In-Reply-To: <503E9205.8030504@redhat.com>
References: <503278F4.4050105@redhat.com> <5033DB58.8090801@redhat.com>
	<5035738F.8010003@redhat.com>
	<1346124363.2539.94.camel@aleeredhat.laptop>
	<503D23E2.4060209@redhat.com> <503E9205.8030504@redhat.com>
Message-ID: <503EEF95.9080606@redhat.com>

On 8/29/2012 5:04 PM, Endi Sukma Dewata wrote:
> On 8/28/2012 3:02 PM, Endi Sukma Dewata wrote:
>> I'll post a revised patch with these changes.
>
> New patch attached.

Fixed velocity dependency. ACKed by Ade. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Thu Aug 30 04:44:24 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 23:44:24 -0500
Subject: [Pki-devel] [PATCH] 103 Merged pki-native-tools and
	pki-java-tools.
In-Reply-To: <503E9209.9020102@redhat.com>
References: <5032A0FB.1070601@redhat.com> <50357393.3000405@redhat.com>
	<1346124710.2539.96.camel@aleeredhat.laptop>
	<503E9209.9020102@redhat.com>
Message-ID: <503EEFA8.10606@redhat.com>

On 8/29/2012 5:04 PM, Endi Sukma Dewata wrote:
> On 8/27/2012 10:31 PM, Ade Lee wrote:
>> ack
>
> Rebased, no code change.

Rebased again. Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Thu Aug 30 04:44:47 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Wed, 29 Aug 2012 23:44:47 -0500
Subject: [Pki-devel] [PATCH] 104 Moved REST CLI into pki-tools.
In-Reply-To: <503E924D.7060206@redhat.com>
References: <5032CCCF.9030204@redhat.com>
	<1346124681.2539.95.camel@aleeredhat.laptop>
	<1346126729.2539.99.camel@aleeredhat.laptop>
	<503E924D.7060206@redhat.com>
Message-ID: <503EEFBF.8000204@redhat.com>

On 8/29/2012 5:06 PM, Endi Sukma Dewata wrote:
> On 8/27/2012 11:05 PM, Ade Lee wrote:
>> Actually - not quite ack.  The eclipse build works, but the cmake build
>> fails.
>
> I couldn't reproduce the problem. Could you try again with the new
> patches? They should be applied in this order: 102-3, 103-2, 104, 105,
> 106, 107-1.

Fixed missing dependency. ACKed by Ade. Pushed to master.
I verified installing pki-tools on another machine and run pki client to 
connect to CA remotely.

-- 
Endi S. Dewata



From edewata at redhat.com  Thu Aug 30 18:36:24 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 30 Aug 2012 13:36:24 -0500
Subject: [Pki-devel] [PATCH] 105 Updated CMake jar() function.
In-Reply-To: <1346125952.2539.97.camel@aleeredhat.laptop>
References: <5035739C.1040501@redhat.com>
	<1346125952.2539.97.camel@aleeredhat.laptop>
Message-ID: <503FB2A8.2000705@redhat.com>

On 8/27/2012 10:52 PM, Ade Lee wrote:
> ack

Pushed to master.

-- 
Endi S. Dewata



From edewata at redhat.com  Thu Aug 30 18:36:50 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 30 Aug 2012 13:36:50 -0500
Subject: [Pki-devel] [PATCH] 106 Moved WAR creation code into CMake
	scripts.
In-Reply-To: <1346125966.2539.98.camel@aleeredhat.laptop>
References: <503573D6.30006@redhat.com>
	<1346125966.2539.98.camel@aleeredhat.laptop>
Message-ID: <503FB2C2.6000306@redhat.com>

On 8/27/2012 10:52 PM, Ade Lee wrote:
> ack

New patch attached. The code is now moved into pkispawn so it will use 
the correct theme files.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0106-1-Moved-webapp-creation-code-into-pkispawn.patch
Type: text/x-patch
Size: 11199 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120830/b766df31/attachment.bin>

From edewata at redhat.com  Thu Aug 30 18:37:02 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 30 Aug 2012 13:37:02 -0500
Subject: [Pki-devel] [PATCH] 107 Added proxy realm.
In-Reply-To: <503E9245.8050403@redhat.com>
References: <503573E0.7030007@redhat.com>
	<1346160812.2539.135.camel@aleeredhat.laptop>
	<503E9245.8050403@redhat.com>
Message-ID: <503FB2CE.4070703@redhat.com>

On 8/29/2012 5:05 PM, Endi Sukma Dewata wrote:
> On 8/28/2012 8:33 AM, Ade Lee wrote:
>> The changes look ok, although due to the issue in one of the previous
>> patches, I cannot build yet using the compose scripts.
>
> New patch attached. I added allowLinking=true so now it can use links in
> the WEB-INF/lib.
>
>> What effect does this patch have on the patch that mharmsen is currently
>> working on?  At the very least, you will need to modify where it is
>> checking for links for the dogtag 10 instance.
>
> I modified the operations and functions to check the pki-*.jars at the
> new location.
>
>> And how does this affect a dogtag 9 instance running under dogtag 10
>> code?
>
> I tried upgrading Dogtag 9 instance and it seems to be working fine. The
> pki-tomcat.jar link will be added into common/lib so the code in
> CMSStartServlet will still work although it's not used.

Rebased. No code change.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0107-2-Added-proxy-realm.patch
Type: text/x-patch
Size: 34864 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120830/2cc3b0f0/attachment.bin>

From edewata at redhat.com  Thu Aug 30 18:37:13 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 30 Aug 2012 13:37:13 -0500
Subject: [Pki-devel] [PATCH] 108 Fixed conflicting LDIF files.
Message-ID: <503FB2D9.3040505@redhat.com>

During subsystem configuration the ConfigurationUtils.importLDIFS()
would generate LDIF files in <instance>/conf folder which may conflict
with files belonging to other subsystems. The code has been modified
to generate the files in <instance>/<subsystem>/conf folder.

Ticket #89

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0108-Fixed-conflicting-LDIF-files.patch
Type: text/x-patch
Size: 2265 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120830/c91752ae/attachment.bin>

From cfu at redhat.com  Thu Aug 30 18:40:43 2012
From: cfu at redhat.com (Christina Fu)
Date: Thu, 30 Aug 2012 11:40:43 -0700
Subject: [Pki-devel] Reivew Request - Bug 844800 - TPS should provide
 the ability to not allow tokens marked as 'Terminated' to be formatted and
 reused
In-Reply-To: <64340166.23256824.1346267360184.JavaMail.root@redhat.com>
References: <64340166.23256824.1346267360184.JavaMail.root@redhat.com>
Message-ID: <503FB3AB.10708@redhat.com>

On 08/29/2012 12:09 PM, John Magne wrote:
> Patch to allow independent transition states for both the TPS UI and TPS operations such as Format and Enrollment.
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=844800
>
> Attachment: https://bugzilla.redhat.com/attachment.cgi?id=607976&action=diff

ACK.  I just suggest to remove the existing confusing log message 
regarding the "disabled" status which seems to be not used/set at all, 
and you have removed the call to check for disabled status anyway.

Christina



From edewata at redhat.com  Thu Aug 30 21:11:00 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 30 Aug 2012 16:11:00 -0500
Subject: [Pki-devel] [PATCH] 109 Merged Javadoc packages.
Message-ID: <503FD6E4.5090309@redhat.com>

The Javadocs for pki-util, pki-java-tools and pki-common have been
merged and packaged into pki-javadoc RPM.

Ticket #295

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0109-Merged-Javadoc-packages.patch
Type: text/x-patch
Size: 14044 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120830/8ea70e61/attachment.bin>

From edewata at redhat.com  Thu Aug 30 23:42:27 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 30 Aug 2012 18:42:27 -0500
Subject: [Pki-devel] [PATCH] 110 Removed duplicate common classes in
	pki-console.jar.
Message-ID: <503FFA63.60601@redhat.com>

The pki-console has been modified to depend on pki-base. This way
it's no longer necessary to include duplicate common classes in
pki-console.

Ticket #113

I verified installing pki-base, dogtag-pki-console-theme, and 
pki-console and running pkiconsole to connect to a remote CA.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0110-Removed-duplicate-common-classes-in-pki-console.jar.patch
Type: text/x-patch
Size: 5283 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120830/92df94b1/attachment.bin>

From alee at redhat.com  Fri Aug 31 20:12:26 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 31 Aug 2012 16:12:26 -0400
Subject: [Pki-devel] [PATCH] 30 Continued - Fix for ticket 219 for
 DogTag branches : 8.1_Errata and 8.2
In-Reply-To: <1345839270.11778.4.camel@akoneru.redhat.com>
References: <1345839270.11778.4.camel@akoneru.redhat.com>
Message-ID: <1346443947.26671.43.camel@aleeredhat.laptop>

pushed to 8.1 errata and 8.2 branches.

On Fri, 2012-08-24 at 16:14 -0400, Abhishek Koneru wrote:
> Please review the patches attached with fix ticket 219 for DogTag
> branches - 8.1_Errata and 8.2.
> The description about the ticket is attached below.
> 
> --Abhishek Koneru
> 
> Defect description:
>   The serial number generated for certificates is wrong when the number
> is large. Problem is due to the conversion of BigInteger to integer
> while generating a new serial number, which truncates the most
> significant bits in the serial number and therefore a large number (eg.
> 10fff0001) becomes a smaller number (eg. fff0001). This conversion in
> turn leads to a collision if a certificate with the smaller number
> exists in the database.
> 
> Steps to reproduce the defect:
>  
>  - Create a CA. - (1)
>  - Edit the fields minSerialNumber and maxSerialNumber in the
> <CA-Installation Path>/conf.CS.cfg to large values like 100000000 and
> 110000000.
>  - Restart the CA.
>  - Configure the CA.
>  - Create a new CA.
>  - Configure this as a clone to (1)CA
>  - After the Certificates are generated, view the serial number by
> clicking on "View Certificate in PrettyPrint".
> 
> Results:
> Before the patch is applied: The serial number is truncated.(Wrong)
> After the patch is applied: The serial number is found as expected.
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




From alee at redhat.com  Fri Aug 31 20:43:14 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 31 Aug 2012 16:43:14 -0400
Subject: [Pki-devel] [PATCH] fix anon connections to DB
Message-ID: <1346445795.26671.45.camel@aleeredhat.laptop>

Patched acked by Jack and pushed to master and dogtag 9.

Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0053-Fixed-anon-connection-factory-to-make-no-anonymous-b.patch
Type: text/x-patch
Size: 4063 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120831/5bb3e68a/attachment.bin>