Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Christina Fu]

Hi Fraser,
That sounds good!  I just added the following page to document my "quick
test" procedure which I use during development:
https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency
btw, the verifySCT is currently enabled, but the failure is ignored.
However, you could look in the debug log for "verifySCT" to see relevant
debug messages.

I'll ask Dinesh to add his more comprehensive testing procedure to the page.
thanks!!
Christina

On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale  wrote:

> Hi Christina,
>
> I will find a day next week to have a close look.  Probably Tuesday
> or Wednesday.  It will help to have test environment setup
> documentation, i.e. how to set up a log server to test with, how to
> configure Dogtag, etc.  If this stuff is already written then you
> just need to tell me where to look :)
>
> Cheers,
> Fraser
>
> On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote:
> > HI Fraser,
> > verifySCT still fails.  I still think the fact the rfc does not require
> the
> > signed object to accompany the signature presents undue challenge to the
> > party that needs to verify the signature.  Although I understand that
> this
> > is v1, and the issue would not be present in v2 since there will not be
> > poison extension ;-/.
> > I'd appreciate it if you could find time to take a closer look.
> >
> > Here is my latest attempt:
> > https://github.com/dogtagpki/pki/pull/440
> > Since it's a patch against the latest code, for a full view, it would be
> > easier if you just apply the patch and read from "(Certificate
> > Transparency)" in
> > base/ca/src/com/netscape/ca/CAService.java
> > This patch would require JSS change at:
> > https://github.com/dogtagpki/jss/pull/575
> >
> > Code still requires some refinement but I wish to address the
> verification
> > issue before cleaning things up.  Of course I still let verifySCT returns
> > success for now just so people could still play with CT.
> > Much appreciated!
> > Christina
> >
> > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu  wrote:
> >
> > > Hi Fraser,
> > > Thanks for the response!
> > > Regarding the poison extension, yes I was aware that it needed to be
> > > removed so the code already had it removed.  It was the order of things
> > > left inside tbsCert that I was concerned about since I used the
> existing
> > > delete method provided for the Extension class, which I wasn't sure if
> it'd
> > > preserve the order of the remaining extensions.  Thanks for confirming
> my
> > > suspicion.  I will double-check the order.
> > >
> > > Also thanks for the input on how to handle failed CT log communication
> > > v.s. response verification failure.   I will address them separately as
> > > suggested.
> > > Finally, nice catch with the missing data length!!  I'll add that and
> go
> > > from there.
> > >
> > > thanks again!
> > > Christina
> > >
> > > On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale 
> > > wrote:
> > >
> > >> Hi Christina,
> > >>
> > >> Adding pki-devel@ for wider audience.  Comments below.
> > >>
> > >> On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> > >> > Hi Fraser,
> > >> > Do you know how the signature returned in the SCT response could be
> > >> > verified by the CA?
> > >> > My thought is that the CA should somehow verify the CT response
> after
> > >> > sending the add-pre-chain request and before signing the cert.
> Since
> > >> log
> > >> > inclusion verification would not be feasible right after the request
> > >> (the
> > >> > SCT response is supposed to be just a "promise, according to the
> rfc),
> > >> I
> > >> > ruled that out and intend to stay with just the following two
> > >> verifications
> > >> > on the response itself:
> > >> >
> > >> >- checking if log id (CT log signer public key hash) returned in
> the
> > >> CT
> > >> >response is correct
> > >> >- this I have no problem verifying
> > >> >   - Verifying if the signature returned in the CT response is
> > >> correct
> > >> >   - this I can't seem to get it working.
> > >> >
> > >> > I put the verification work above in the method "verifySCT".
> > >&

Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Christina Fu]

HI Fraser,
verifySCT still fails.  I still think the fact the rfc does not require the
signed object to accompany the signature presents undue challenge to the
party that needs to verify the signature.  Although I understand that this
is v1, and the issue would not be present in v2 since there will not be
poison extension ;-/.
I'd appreciate it if you could find time to take a closer look.

Here is my latest attempt:
https://github.com/dogtagpki/pki/pull/440
Since it's a patch against the latest code, for a full view, it would be
easier if you just apply the patch and read from "(Certificate
Transparency)" in
base/ca/src/com/netscape/ca/CAService.java
This patch would require JSS change at:
https://github.com/dogtagpki/jss/pull/575

Code still requires some refinement but I wish to address the verification
issue before cleaning things up.  Of course I still let verifySCT returns
success for now just so people could still play with CT.
Much appreciated!
Christina

On Tue, Jun 2, 2020 at 3:05 PM Christina Fu  wrote:

> Hi Fraser,
> Thanks for the response!
> Regarding the poison extension, yes I was aware that it needed to be
> removed so the code already had it removed.  It was the order of things
> left inside tbsCert that I was concerned about since I used the existing
> delete method provided for the Extension class, which I wasn't sure if it'd
> preserve the order of the remaining extensions.  Thanks for confirming my
> suspicion.  I will double-check the order.
>
> Also thanks for the input on how to handle failed CT log communication
> v.s. response verification failure.   I will address them separately as
> suggested.
> Finally, nice catch with the missing data length!!  I'll add that and go
> from there.
>
> thanks again!
> Christina
>
> On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale 
> wrote:
>
>> Hi Christina,
>>
>> Adding pki-devel@ for wider audience.  Comments below.
>>
>> On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
>> > Hi Fraser,
>> > Do you know how the signature returned in the SCT response could be
>> > verified by the CA?
>> > My thought is that the CA should somehow verify the CT response after
>> > sending the add-pre-chain request and before signing the cert.  Since
>> log
>> > inclusion verification would not be feasible right after the request
>> (the
>> > SCT response is supposed to be just a "promise, according to the rfc),
>> I
>> > ruled that out and intend to stay with just the following two
>> verifications
>> > on the response itself:
>> >
>> >- checking if log id (CT log signer public key hash) returned in the
>> CT
>> >response is correct
>> >- this I have no problem verifying
>> >   - Verifying if the signature returned in the CT response is
>> correct
>> >   - this I can't seem to get it working.
>> >
>> > I put the verification work above in the method "verifySCT".
>> >
>> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209
>> > What I am wondering is how this can be done properly.  Since the
>> tbsCert is
>> > not to contain the poison extension, the poison extension needs to be
>> > removed by the CT server before it signs.  What if the order of the
>> > extensions contained in the tbsCert gets changed in the process?
>> >
>> The poison extension must be removed, and care must be taken to keep
>> everything else in the same order, and reserialise the parts in
>> exactly the same way.
>>
>> > It seems that the response should contain the tbsCert that it signs
>> (which
>> > isn't per the rfc) or I am not sure how the CA could verify the
>> signature.
>> >
>> The response does not contain the TBCCertificate.  Both sides (log
>> and client) remove the poison extension (and change nothing else),
>> then both sides can sign the same data.
>>
>> > So the question now is if I should just leave out the check, unless you
>> > have other suggestions.
>> >
>> I do think we should verify the signature, to ensure the message was
>> actually received by the log server we wanted and not an impostor.
>>
>> > Of course, I also could have missed something in my code.
>> >
>> The binary format is complex and it's easy to miss something.  After
>> you implement removal of the poison extension, if it is still not
>> working I will go over the code with a fine-tooth comb.
>>
>> I copied some of the code and left comments below, too.  Comments
>> begin with

Re: [Pki-devel] Certificate Transparency SCT signature verification?

[Christina Fu]

Hi Fraser,
Thanks for the response!
Regarding the poison extension, yes I was aware that it needed to be
removed so the code already had it removed.  It was the order of things
left inside tbsCert that I was concerned about since I used the existing
delete method provided for the Extension class, which I wasn't sure if it'd
preserve the order of the remaining extensions.  Thanks for confirming my
suspicion.  I will double-check the order.

Also thanks for the input on how to handle failed CT log communication v.s.
response verification failure.   I will address them separately as
suggested.
Finally, nice catch with the missing data length!!  I'll add that and go
from there.

thanks again!
Christina

On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale  wrote:

> Hi Christina,
>
> Adding pki-devel@ for wider audience.  Comments below.
>
> On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> > Hi Fraser,
> > Do you know how the signature returned in the SCT response could be
> > verified by the CA?
> > My thought is that the CA should somehow verify the CT response after
> > sending the add-pre-chain request and before signing the cert.  Since log
> > inclusion verification would not be feasible right after the request (the
> > SCT response is supposed to be just a "promise, according to the rfc),  I
> > ruled that out and intend to stay with just the following two
> verifications
> > on the response itself:
> >
> >- checking if log id (CT log signer public key hash) returned in the
> CT
> >response is correct
> >- this I have no problem verifying
> >   - Verifying if the signature returned in the CT response is correct
> >   - this I can't seem to get it working.
> >
> > I put the verification work above in the method "verifySCT".
> >
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209
> > What I am wondering is how this can be done properly.  Since the tbsCert
> is
> > not to contain the poison extension, the poison extension needs to be
> > removed by the CT server before it signs.  What if the order of the
> > extensions contained in the tbsCert gets changed in the process?
> >
> The poison extension must be removed, and care must be taken to keep
> everything else in the same order, and reserialise the parts in
> exactly the same way.
>
> > It seems that the response should contain the tbsCert that it signs
> (which
> > isn't per the rfc) or I am not sure how the CA could verify the
> signature.
> >
> The response does not contain the TBCCertificate.  Both sides (log
> and client) remove the poison extension (and change nothing else),
> then both sides can sign the same data.
>
> > So the question now is if I should just leave out the check, unless you
> > have other suggestions.
> >
> I do think we should verify the signature, to ensure the message was
> actually received by the log server we wanted and not an impostor.
>
> > Of course, I also could have missed something in my code.
> >
> The binary format is complex and it's easy to miss something.  After
> you implement removal of the poison extension, if it is still not
> working I will go over the code with a fine-tooth comb.
>
> I copied some of the code and left comments below, too.  Comments
> begin with `!!'.  I think I found one bug and a couple of possible
> improvements.
>
> > One last question, currently in the code, if verifySCT fails, I just
> > "continue" to process for next CT log.  Should this just bail out all
> > together or it's fine to continue? Or could this be a choice by the
> admin.
> > What do you think and why?
> >
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L951
> >
> My line of thinking is this:
>
> - we should tolerate communication errors with log (perhaps
>   enqueuing the cert for a retry later)
>
> - but (assuming we implement it correctly) verifySCT failure is
>   indicative of something wrong with the log (e.g. key changed); it
>   is not a communication error and can be treated differently.
>
> - I think it's OK to fail hard.  Admins will likely want to know if
>   something is wrong with CT logging.
>
> - But in case we make a mistake, or an org needs issuance to
>   continue despite CT log misbehaviour, there should be a config
>   knob to allow this condition to be ignored.  "In case of
>   emergency..."
>
>
> >
> > thanks,
> > Christina
>
> boolean verifySCT(CTResponse response, byte[] tbsCert, String
> logPublicKey)
> throws Exception {
>
>

Re: [Pki-devel] KRA Admin certificate

[Christina Fu]

After running pkispawn to install KRA, you should see an "Installation
Summary" displayed where it shows where to locate the PKCS #12 file.  the
p12 file is a package consisted of the your admin cert and its keys.
Password is what you specified in your pkispawn config file.
For more detail, check out
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/planning_installation_and_deployment_guide/index#Installation_and_Configuration
If not sufficient please report the issue.

thanks,
Christina



On Thu, Dec 5, 2019 at 11:48 PM Sharath 
wrote:

> Hello Team,
>
> Can you please tell, where shall I get the KRA Admin Certificate ?
>
> Thanks,
>
> Sharath
>
>
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] [PATCH] Ticket-2757-CMC-enrollment-profiles-for-system-certi.patch (First Part - non-TMS)

[Christina Fu]

This is the first part for ticket https://pagure.io/dogtagpki/issue/2757 
need CMC enrollment profiles for system certificates


This first part supports non-TMS (CA, KRA, and OCSP) cmc requests for 
system certs.


Please see comments and code in patch for details.

Usage examples can be found here:

http://pki.fedoraproject.org/wiki/PKI_10.4_CMC_Feature_Update_(RFC5272)#Examples_.28System_Certificates.29

The 2nd part (TMS) will be submitted soon.

thanks,

Christina

From e471035822a5447fddc67c8abf8a1a0ffb9a5bcf Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Mon, 26 Jun 2017 18:09:55 -0700
Subject: [PATCH] Ticket #2757 CMC enrollment profiles for system certificates

First part patch to support non-TMS CMC-based installation.

This patch contains the following:
* The code in CMCAuth (agent-based) to check ssl client auth cert against the CMC signing cert
* The non-TMS system enrollment profiles:
caCMCauditSigningCert.cfg
caCMCcaCert.cfg
caCMCkraStorageCert.cfg
caCMCkraTransportCert.cfg
caCMCocspCert.cfg
caCMCserverCert.cfg
caCMCsubsystemCert.cfg
* new URI's in web.xml as new access points
---
 base/ca/shared/conf/CS.cfg |  20 ++-
 .../shared/profiles/ca/caCMCauditSigningCert.cfg   |  80 +
 base/ca/shared/profiles/ca/caCMCcaCert.cfg |  96 ++
 base/ca/shared/profiles/ca/caCMCkraStorageCert.cfg |  86 +
 .../shared/profiles/ca/caCMCkraTransportCert.cfg   |  86 +
 base/ca/shared/profiles/ca/caCMCocspCert.cfg   |  71 
 base/ca/shared/profiles/ca/caCMCserverCert.cfg |  90 ++
 base/ca/shared/profiles/ca/caCMCsubsystemCert.cfg  |  86 +
 base/ca/shared/profiles/ca/caFullCMCUserCert.cfg   |   4 +-
 .../shared/profiles/ca/caFullCMCUserSignedCert.cfg |   2 +-
 base/ca/shared/webapps/ca/WEB-INF/web.xml  | 196 +
 .../src/com/netscape/cmstools/CMCRequest.java  |   2 +-
 .../com/netscape/cms/authentication/CMCAuth.java   |  44 -
 .../cms/authentication/CMCUserSignedAuth.java  |   2 +
 .../netscape/cms/profile/common/EnrollProfile.java |  12 ++
 .../servlet/profile/ProfileSubmitCMCServlet.java   |   2 +-
 16 files changed, 868 insertions(+), 11 deletions(-)
 create mode 100644 base/ca/shared/profiles/ca/caCMCauditSigningCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caCMCcaCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caCMCkraStorageCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caCMCkraTransportCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caCMCocspCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caCMCserverCert.cfg
 create mode 100644 base/ca/shared/profiles/ca/caCMCsubsystemCert.cfg

diff --git a/base/ca/shared/conf/CS.cfg b/base/ca/shared/conf/CS.cfg
index 4da7429..9c136a8 100644
--- a/base/ca/shared/conf/CS.cfg
+++ b/base/ca/shared/conf/CS.cfg
@@ -969,7 +969,7 @@ oidmap.pse.oid=2.16.840.1.113730.1.18
 oidmap.subject_info_access.class=netscape.security.extensions.SubjectInfoAccessExtension
 oidmap.subject_info_access.oid=1.3.6.1.5.5.7.1.11
 os.userid=nobody
-profile.list=caUserCert,caECUserCert,caUserSMIMEcapCert,caDualCert,caDirBasedDualCert,caECDualCert,AdminCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caSubsystemCert,caOtherCert,caCACert,caCrossSignedCACert,caInstallCACert,caRACert,caOCSPCert,caStorageCert,caTransportCert,caDirPinUserCert,caDirUserCert,caECDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caFullCMCUserSignedCert,caFullCMCSelfSignedCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthDRMstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,caInternalAuthAuditSigningCert,DomainController,caDualRAuserCert,caRAagentCert,caRAserverCert,caUUIDdeviceCert,caSSLClientSelfRenewal,caDirUserRenewal,caManualRenewal,caTokenMSLoginEnrollment,caTokenUserSigningKeyRenewal,caTokenUserEncryptionKeyRenewal,caTokenUserAuthKeyRenewal,caJarSigningCert,caIPAserviceCert,caEncUserCert,caSigningUserCert,caSigningECUserCert,caEncECUserCert,caTokenUserDelegateAuthKeyEnrollment,caTokenUserDelegateSigningKeyEnrollment
+profile.list=caCMCserverCert,caCMCsubsystemCert,caCMCauditSigningCert,caCMCcaCert,caCMCocspCert,caCMCkraTransportCert,caCMCkraStorageCert,caUserCert,caECUserCert,caUserSMIMEcapCert,caDualCert,caDirBasedDualCert,caECDualCert,AdminCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caSubsystemCert,caOtherCert,caCACert,caCMCcaCert,caCrossSignedCACert,caInstallCACert,caRACert,caOCSPCert,caStorageCert,caTransportCert,caDirPinUserCert,caDirUserCert,caECDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caFullCMCUserSignedCert,caFullCMCSelfSign

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

[Christina Fu]

looks good. ACK.

Christina


On 06/29/2017 03:43 PM, John Magne wrote:

[PATCH] SCP03 support: fix Key Changeover with HSM (RHCS)

Ticket #2764.

This relatively simple fix involves making sure the correct crypto token is 
being used to search for the master key int the case of symmetric key changover 
where the master key resides on an HSM.


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


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

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

[Christina Fu]

and here is the patch...


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


This patch addresses:

https://pagure.io/dogtagpki/issue/2616 CMC: replace id-cmc-statusInfo 
with id-cmc-statusInfoV2


See patch comment for detail.

thanks,

Christina



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


>From 9966c8ad9a2418f18f5ef7169d4ccd7d13e16fc9 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 16 Jun 2017 18:20:38 -0700
Subject: [PATCH] Ticket #2616 CMC: replace id-cmc-statusInfo with
 id-cmc-statusInfoV2

This patch contains the following update:
* Structurely, CMCStatusInfo to CMCStatusInfoV2 update; no extendedFailInfo has been added at this point
* In case of EncryptedPOP, instead of returning with CMCStatus pending where
  PendInfo contains the requestID, it now returns CMCStatus failed whith
  responseInfo control contains the requestID. On the client side, CMCRequest
  now processes the responseInfo and returns the DecryptedPOP with requestID in
  the regInfo control. CMCResponse has been updated to handle the new controls
  as well.
* A number of fail info codes are now being supported by the server to add
  clarity to CMC failed status, including:
  badMessageCheck, badRequest, unsuportedExt, badIdentity, popRequired, and popFailed.
---
 .../certsrv/profile/ECMCBadIdentityException.java  |  54 ++
 .../profile/ECMCBadMessageCheckException.java  |  54 ++
 .../certsrv/profile/ECMCBadRequestException.java   |  53 +
 .../certsrv/profile/ECMCPopFailedException.java|  53 +
 .../certsrv/profile/ECMCPopRequiredException.java  |  59 ++
 .../profile/ECMCUnsupportedExtException.java   |  53 +
 .../src/com/netscape/cmstools/CMCRequest.java  |  69 +--
 .../src/com/netscape/cmstools/CMCResponse.java |  36 +++-
 .../netscape/cms/profile/common/EnrollProfile.java | 195 ---
 .../cms/servlet/common/CMCOutputTemplate.java  | 216 -
 .../servlet/common/GenPendingTemplateFiller.java   |  10 +-
 .../servlet/profile/ProfileSubmitCMCServlet.java   |  96 -
 .../netscape/cms/servlet/request/CheckRequest.java |   8 +-
 base/server/cmsbundle/src/UserMessages.properties  |   1 +
 14 files changed, 747 insertions(+), 210 deletions(-)
 create mode 100644 base/common/src/com/netscape/certsrv/profile/ECMCBadIdentityException.java
 create mode 100644 base/common/src/com/netscape/certsrv/profile/ECMCBadMessageCheckException.java
 create mode 100644 base/common/src/com/netscape/certsrv/profile/ECMCBadRequestException.java
 create mode 100644 base/common/src/com/netscape/certsrv/profile/ECMCPopFailedException.java
 create mode 100644 base/common/src/com/netscape/certsrv/profile/ECMCPopRequiredException.java
 create mode 100644 base/common/src/com/netscape/certsrv/profile/ECMCUnsupportedExtException.java

diff --git a/base/common/src/com/netscape/certsrv/profile/ECMCBadIdentityException.java b/base/common/src/com/netscape/certsrv/profile/ECMCBadIdentityException.java
new file mode 100644
index 000..801f433
--- /dev/null
+++ b/base/common/src/com/netscape/certsrv/profile/ECMCBadIdentityException.java
@@ -0,0 +1,54 @@
+// --- BEGIN COPYRIGHT BLOCK ---
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of the GNU General Public License as published by
+// the Free Software Foundation; version 2 of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+//
+// (C) 2007 Red Hat, Inc.
+// All rights reserved.
+// --- END COPYRIGHT BLOCK ---
+package com.netscape.certsrv.profile;
+
+/**
+ * This represents a profile specific exception for handling
+ * CMC badIdentity condition.
+ * The framework raises this exception when a request fails identity
+ * checks
+ * 
+ *
+ * @version $Revision$, $Date$
+ */
+public class ECMCBadIdentityException extends EProfileException {
+
+/**
+ *
+ */
+private static final long serialVersionUID = -89147145684990870L;
+
+/**
+ * Creates an exception.
+ *
+ * @param msg localized message that will be
+ *displayed to end user.
+ */
+public ECMCBadIdentityException(String msg) {
+super(msg);
+}
+
+public ECMCBadIdentityException(Throwable cause) {
+super(cause.getMessage(), cause);
+}
+
+public ECMCBadIdentityException(String msg, Throwable cause) {
+super(msg, cause);
+}
+
+}
diff --git a/base/common/src/com/netscape/certsr

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

[Christina Fu]

This patch addresses:

https://pagure.io/dogtagpki/issue/2616 CMC: replace id-cmc-statusInfo 
with id-cmc-statusInfoV2


See patch comment for detail.

thanks,

Christina

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

[Pki-devel] [PATCH] Ticket-2619-Allow-CA-to-process-user-signed-CMC-revo.patch

[Christina Fu]

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


Patch description in patch comment area.

please review.

thanks,

Christina

>From c6a7a2024cddfb47a17e2c0f0309b93b656e8f53 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Tue, 30 May 2017 14:12:06 -0700
Subject: [PATCH] Ticket #2619 Allow CA to process user-signed CMC revocation
 requests First of all, the original CMC revocation only supports agent-signed
 CMC revocation requests from the UI where CMCRevReqServlet handles it with
 CMCAuth.  It is in violation with https://tools.ietf.org/html/rfc5273 CMC
 Transport Protocols, as for HTTP/HTTPS, the body of the message is the binary
 value of the BER encoding of the PKI Request or Response,so HTML is not an
 approved method.The other way is through profileSubmitCMCFullServlet (or
 maybe not, as it was completely broken).

One thing that's much less crucial, but goes along with rfc update is the name of the revocation request ASN1 structure. In the new rfc5272, it is now called RevokeRequest insead of RevRequest.

This patch revamped the CMC revocation provision and fixing what's broken and adding what's missing.

On the client side:

CMCRequest

- Commented out the code where it made an assumption to use OtherMsg for the signer information. This makes no sense as the outer layer SignedData would have the same information when signing happens.

- removed the revRequest.nickname parameter from the configuration.  From the code it seems like it expects the certificate to be revoked to exist in the user database, and it uses the same certificate to sign the revocation request.  The RFC does allow for self-signed revocation, but it also allows for signing with another certificate provided that it has same subject.  By removing the revRequest.nickname parameter, I am using the "nickname" parameter as the signer cert, which may or may not be the same certificate specified in revRequest.serial.  It is less confusing. The change also eliminate the need for the cert to be revoked to be present in the db.  In addition, revRequest.issuer only needs to be specified if revRequest.sharedSecret is used. The code will extract the issuer info from the signing cert.

- added support for unsigned data in support of shared secret in both CMCRequest and server;  The original code assumed that a cmc revocation request that relies on shared secret still requires agent signing.

CMCRevoke

- The original code assumed that the nss db password is the same as Shared Secret (!!).  This patch added a "-t" to accept shred secret, and keep the -p for the nss db password.

- The original code printed out b64 encoded request to the screen output as well as the file CMCRevoke.out.  Both are unusable directly.  This patch fixes it so that the output to the screen can be directly copied and pasted into the CMC revocate ui at ee (processed by CMCRevReqServlet);  Again, this is not RFC conforming, but I fixed it anyways;

- The output to the file CMCRevoke.out has been fixed so that it is the BER encoding of the request, which can be fed directly into the updated server that now conforms to the RFC (see below)

- This code still requires the signer certificate nickname to run, making the shared secret method moot.  Since CMCRequest has been updated to work properly, we can leave this for now.

On the server side.

CMCUserSignedAuth has been updated to handle unsigned DATA;  Recall that the original CMC revocation only handled SIGNED_DATA (making assumption that agent always signs the requests).  This addition is important to support shared secrets properly.

Another thing that's important change on the server side is that it now checks the revoking cert's subject against the signer's subject, if authenticated by CMCUserSignedAuth.  The original code did not do that, I think it is because it always checks if it's an agent or not.

Something that could be improved on is to have its own servlet.  However, due to the time restriction, I only updated existing EnrollProfile, ProfileSubmitCMCServlet, and CMCOutputTemplate to handle the rfc conforming cmc revocation requests.

The shared secret handling is left in the CMCOutputTemplate for now.  Logically it would make sense to go into CMCUserSignedAuth. This could be left as a possible later ticket for improvement.   Shared Token plugin implementation will be added in later ticket as well.

Previously missed signing cert validation is also added for more complete check.
Some SHA1 are turned into SHA2

Finally, some auditing are added, but it is not finalized.  It will be done in the next ticket(s).
---
 base/common/src/com/netscape/certsrv/apps/CMS.java |  10 +
 .../src/com/netscape/certsrv/apps/ICMSEngine.java  |   8 +
 .../com/netscape/certsrv/base/SessionContext.java  |   5 +
 .../src/com/netscape/cmstools/CMCRequest.java  | 245 ++

Re: [Pki-devel] [PATCH] Ticket-2617-part2-add-revocation-check-to-signing-ce.patch

[Christina Fu]

Received verbal ack from jmagne.

pushed to master:

commit 380f7fda040cc5d394e34eead45ebb921532cc07

thanks,

Christina


On 06/05/2017 09:03 AM, Christina Fu wrote:


This patch adds the missing revocation check (and possibly validity 
check) to


https://pagure.io/dogtagpki/issue/2617 Allow CA to process pre-signed 
CMC non-signing certificate requests


The code that CMCUserSignedAuth originated from, CMCAuth, has a 
confusing comment where it states:


// verify signer's certificate using the revocator
right above the CryptoManager.isCertValid() call.  Which mislead me 
into believing that the call checks for revocation status.


During work for CMC revocation (upcoming patch), I found out that is 
not entirely the case.  The call does not check for revocation status 
when I used a revoked cert to sign the cmc request.  I am adding 
revocation and validity checks to make sure that the check is more 
complete.


thanks,

Christina



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

[Pki-devel] [PATCH] Ticket-2617-part2-add-revocation-check-to-signing-ce.patch

[Christina Fu]

This patch adds the missing revocation check (and possibly validity 
check) to


https://pagure.io/dogtagpki/issue/2617 Allow CA to process pre-signed 
CMC non-signing certificate requests


The code that CMCUserSignedAuth originated from, CMCAuth, has a 
confusing comment where it states:


// verify signer's certificate using the revocator
right above the CryptoManager.isCertValid() call.  Which mislead me into 
believing that the call checks for revocation status.


During work for CMC revocation (upcoming patch), I found out that is not 
entirely the case.  The call does not check for revocation status when I 
used a revoked cert to sign the cmc request.  I am adding revocation and 
validity checks to make sure that the check is more complete.


thanks,

Christina

>From 380f7fda040cc5d394e34eead45ebb921532cc07 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Mon, 5 Jun 2017 08:50:25 -0700
Subject: [PATCH] Ticket #2617 part2: add revocation check to signing cert

---
 .../cms/authentication/CMCUserSignedAuth.java | 19 +++
 .../authentication/CertUserDBAuthentication.java  |  2 +-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/base/server/cms/src/com/netscape/cms/authentication/CMCUserSignedAuth.java b/base/server/cms/src/com/netscape/cms/authentication/CMCUserSignedAuth.java
index 2128c1e..a18c25e 100644
--- a/base/server/cms/src/com/netscape/cms/authentication/CMCUserSignedAuth.java
+++ b/base/server/cms/src/com/netscape/cms/authentication/CMCUserSignedAuth.java
@@ -29,6 +29,7 @@ import java.io.ByteArrayInputStream;
 import java.io.ByteArrayOutputStream;
 import java.io.IOException;
 import java.math.BigInteger;
+import java.security.cert.CertificateExpiredException;
 import java.security.MessageDigest;
 import java.security.PublicKey;
 import java.util.Enumeration;
@@ -1076,7 +1077,10 @@ public class CMCUserSignedAuth implements IAuthManager, IExtendedPluginInfo,
 si.verify(digest, id, pubK);
 }
 CMS.debug(method + "finished checking signature");
+
 // verify signer's certificate using the revocator
+// ...or not;  I think it just checks usage and
+// validity, but not revocation status
 if (!cm.isCertValid(certByteArray, true, CryptoManager.CertUsage.SSLClient)) {
 CMS.debug(method + "CMC signature failed to be verified");
 s.close();
@@ -1086,6 +1090,21 @@ public class CMCUserSignedAuth implements IAuthManager, IExtendedPluginInfo,
 }
 // At this point, the signature has been verified;
 
+// now check revocation status of the cert
+if (CMS.isRevoked(x509Certs)) {
+CMS.debug(method + "CMC signing cert is a revoked certificate");
+throw new EInvalidCredentials(CMS.getUserMessage("CMS_AUTHENTICATION_INVALID_CREDENTIAL"));
+}
+try { //do this again anyways
+cert.checkValidity();
+} catch (CertificateExpiredException e) {
+CMS.debug(method + "CMC signing cert is an expired certificate");
+throw new EInvalidCredentials(CMS.getUserMessage("CMS_AUTHENTICATION_INVALID_CREDENTIAL"));
+} catch (Exception e) {
+CMS.debug(method + e.toString());
+throw new EInvalidCredentials(CMS.getUserMessage("CMS_AUTHENTICATION_INVALID_CREDENTIAL"));
+}
+
 IAuthToken tempToken = new AuthToken(null);
 /*
 netscape.security.x509.X500Name tempPrincipal = (X500Name) x509Certs[0].getSubjectDN();
diff --git a/base/server/cmscore/src/com/netscape/cmscore/authentication/CertUserDBAuthentication.java b/base/server/cmscore/src/com/netscape/cmscore/authentication/CertUserDBAuthentication.java
index 998d7e2..ae450fa 100644
--- a/base/server/cmscore/src/com/netscape/cmscore/authentication/CertUserDBAuthentication.java
+++ b/base/server/cmscore/src/com/netscape/cmscore/authentication/CertUserDBAuthentication.java
@@ -168,7 +168,7 @@ public class CertUserDBAuthentication implements IAuthManager, ICertUserDBAuthen
 try {
 user = (User) mCULocator.locateUser(certs);
 } catch (EUsrGrpException e) {
-CMS.debug("CertUserDBAuthentication: cannot map certificate to any user");
+CMS.debug("CertUserDBAuthentication: cannot map certificate to any user" + e);
 log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_AUTH_AGENT_AUTH_FAILED&q

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

[Christina Fu]

pushed to master:

commit 8aafe1d4345f8b8d20b2f87c68b2e6be4eee18eb

thanks,

Christina


On 05/19/2017 06:36 PM, John Magne wrote:

ACK:

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

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



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

Ticket#2618 feature: pre-signed CMC renewal request

This patch provides the feature implementation to allow CA to process 
pre-signed CMC renewal requests. In the world of CMC, renewal request are full 
CMC requests that are signed by previously issued signing certificate.
The implementation approach is to use the caFullCMCUserSignedCert with the 
enhanced profile constraint: UniqueKeyConstraint.
UniqueKeyConstraint has been updated to disallow renewal of same key shared by 
a revoked certificate. It also saves the origNotAfter of the newest certificate 
sharing the same key in the request to be used by the 
RenewGracePeriodConstraint.
The profile caFullCMCUserSignedCert.cfg has been updated to have both 
UniqueKeyConstraint and RenewGracePeriodConstraint. They must be placed in the 
correct order. By default in the UniqueKeyConstraint the constraint parameter 
allowSameKeyRenewal=true.


Thanks,

Christina

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


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

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

[Christina Fu]

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


Ticket#2618 feature: pre-signed CMC renewal request

This patch provides the feature implementation to allow CA to 
process pre-signed CMC renewal requests. In the world of CMC, renewal 
request are full CMC requests that are signed by previously issued 
signing certificate.
The implementation approach is to use the caFullCMCUserSignedCert 
with the enhanced profile constraint: UniqueKeyConstraint.
UniqueKeyConstraint has been updated to disallow renewal of same 
key shared by a revoked certificate.  It also saves the origNotAfter of 
the newest certificate sharing the same key in the request to be used by 
the RenewGracePeriodConstraint.
The profile caFullCMCUserSignedCert.cfg has been updated to have 
both UniqueKeyConstraint and RenewGracePeriodConstraint.  They must be 
placed in the correct order. By default in the UniqueKeyConstraint the 
constraint parameter allowSameKeyRenewal=true.


Thanks,

Christina

>From 63af93d4b7ba2bdda405bb585ed1e4c096e7ceb2 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 19 May 2017 11:55:14 -0700
Subject: [PATCH] Ticket#2618 feature: pre-signed CMC renewal request

This patch provides the feature implementation to allow CA to process pre-signed CMC renewal requests. In the world of CMC, renewal request are full CMC requests that are signed by previously issued signing certificate.
The implementation approach is to use the caFullCMCUserSignedCert with the enhanced profile constraint: UniqueKeyConstraint.
UniqueKeyConstraint has been updated to disallow renewal of same key shared by a revoked certificate.  It also saves the origNotAfter of the newest certificate sharing the same key in the request to be used by the RenewGracePeriodConstraint.
The profile caFullCMCUserSignedCert.cfg has been updated to have both UniqueKeyConstraint and RenewGracePeriodConstraint.  They must be placed in the correct order. By default in the UniqueKeyConstraint the constraint parameter allowSameKeyRenewal=true.
---
 .../shared/profiles/ca/caFullCMCUserSignedCert.cfg |  13 ++-
 .../src/com/netscape/cmstools/CMCRequest.java  |  14 +--
 .../constraint/RenewGracePeriodConstraint.java |  23 ++--
 .../profile/constraint/UniqueKeyConstraint.java| 116 -
 4 files changed, 124 insertions(+), 42 deletions(-)

diff --git a/base/ca/shared/profiles/ca/caFullCMCUserSignedCert.cfg b/base/ca/shared/profiles/ca/caFullCMCUserSignedCert.cfg
index 229a3cd..63a4bca 100644
--- a/base/ca/shared/profiles/ca/caFullCMCUserSignedCert.cfg
+++ b/base/ca/shared/profiles/ca/caFullCMCUserSignedCert.cfg
@@ -10,12 +10,23 @@ input.i2.class_id=submitterInfoInputImpl
 output.list=o1
 output.o1.class_id=certOutputImpl
 policyset.list=cmcUserCertSet
-policyset.cmcUserCertSet.list=1,2,3,4,5,6,7,8
+policyset.cmcUserCertSet.list=1,9,10,2,3,4,5,6,7,8
 policyset.cmcUserCertSet.1.constraint.class_id=cmcUserSignedSubjectNameConstraintImpl
 policyset.cmcUserCertSet.1.constraint.name=CMC User Signed Subject Name Constraint
 policyset.cmcUserCertSet.1.default.class_id=cmcUserSignedSubjectNameDefaultImpl
 policyset.cmcUserCertSet.1.default.name=User Signed Subject Name Default
 policyset.cmcUserCertSet.1.default.params.name=
+policyset.cmcUserCertSet.9.constraint.class_id=uniqueKeyConstraintImpl
+policyset.cmcUserCertSet.9.constraint.name=Unique Key Constraint
+policyset.cmcUserCertSet.9.constraint.params.allowSameKeyRenewal=true
+policyset.cmcUserCertSet.9.default.class_id=noDefaultImpl
+policyset.cmcUserCertSet.9.default.name=No Default
+policyset.cmcUserCertSet.10.constraint.class_id=renewGracePeriodConstraintImpl
+policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint
+policyset.cmcUserCertSet.10.constraint.params.renewal.graceBefore=30
+policyset.cmcUserCertSet.10.constraint.params.renewal.graceAfter=30
+policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl
+policyset.cmcUserCertSet.10.default.name=No Default
 policyset.cmcUserCertSet.2.constraint.class_id=validityConstraintImpl
 policyset.cmcUserCertSet.2.constraint.name=Validity Constraint
 policyset.cmcUserCertSet.2.constraint.params.notAfterCheck=false
diff --git a/base/java-tools/src/com/netscape/cmstools/CMCRequest.java b/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
index 6e27cb1..9c41403 100644
--- a/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
+++ b/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
@@ -2014,10 +2014,12 @@ public class CMCRequest {
 certname.append(tokenName);
 certname.append(":");
 }
-certname.append(nickname);
-signerCert = cm.findCertByNickname(certname.toString());
-if (signerCert != null) {
-System.out.println("got signerCert: "+ certname.toString());
+if (!selfSign.equal

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

[Christina Fu]

pushed to master:

commit c95cff5899e2975b16db61b811b626742e5e7114

thanks!

Christina


On 05/02/2017 11:43 AM, John Magne wrote:

Makes sense.

ACK if tested to work.


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

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

popLinkWitnessRequired=false.

Workaround was to always set it to true.

This patch fixes it.

It also adds a missing authenticator CMCUserSignedAuth in CS.cfg for ca.

thanks,

Christina


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


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

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

[Christina Fu]

thanks.

Pushed to master:

commit b04739d364e7e220da29ce8d47654377999ad881

Christina


On 04/13/2017 05:44 PM, John Magne wrote:

Cond ACK.


Looks good.

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


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

Please review.

thanks!

Christina


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


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

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

[Christina Fu]

Please review.

thanks!

Christina

>From 23f532da661f2528c47df67c8663a0f4f96401ea Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Thu, 13 Apr 2017 16:53:58 -0700
Subject: [PATCH] Ticket #2614 CMC: id-cmc-popLinkWitnessV2 feature
 implementation This patch provides the feature for CMC on handling
 id-cmc-popLinkWitnessV2

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

diff --git a/base/java-tools/src/com/netscape/cmstools/CMCRequest.java b/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
index a2aca8a..004b81d 100644
--- a/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
+++ b/base/java-tools/src/com/netscape/cmstools/CMCRequest.java
@@ -34,6 +34,7 @@ import java.security.NoSuchAlgorithmException;
 import java.text.SimpleDateFormat;
 import java.util.Arrays;
 import java.util.Date;
+import java.util.Random;
 import java.util.StringTokenizer;
 
 import org.mozilla.jss.CryptoManager;
@@ -53,10 +54,12 @@ import org.mozilla.jss.crypto.CryptoToken;
 import org.mozilla.jss.crypto.DigestAlgorithm;
 import org.mozilla.jss.crypto.ObjectNotFoundException;
 import org.mozilla.jss.crypto.PrivateKey;
+import org.mozilla.jss.crypto.Signature;
 import org.mozilla.jss.crypto.SignatureAlgorithm;
 import org.mozilla.jss.crypto.SymmetricKey;
 import org.mozilla.jss.crypto.X509Certificate;
 import org.mozilla.jss.pkcs10.CertificationRequest;
+import org.mozilla.jss.pkcs10.CertificationRequestInfo;
 import org.mozilla.jss.pkix.cmc.CMCCertId;
 import org.mozilla.jss.pkix.cmc.CMCStatusInfo;
 import org.mozilla.jss.pkix.cmc.DecryptedPOP;
@@ -68,6 +71,7 @@ import org.mozilla.jss.pkix.cmc.OtherInfo;
 import org.mozilla.jss.pkix.cmc.OtherMsg;
 import org.mozilla.jss.pkix.cmc.PKIData;
 import org.mozilla.jss.pkix.cmc.PendInfo;
+import org.mozilla.jss.pkix.cmc.PopLinkWitnessV2;
 import org.mozilla.jss.pkix.cmc.ResponseBody;
 import org.mozilla.jss.pkix.cmc.TaggedAttribute;
 import org.mozilla.jss.pkix.cmc.TaggedCertificationRequest;
@@ -85,7 +89,11 @@ import org.mozilla.jss.pkix.cms.SignerInfo;
 import org.mozilla.jss.pkix.crmf.CertReqMsg;
 import org.mozilla.jss.pkix.crmf.CertRequest;
 import org.mozilla.jss.pkix.crmf.CertTemplate;
+import org.mozilla.jss.pkix.crmf.POPOSigningKey;
+import org.mozilla.jss.pkix.crmf.ProofOfPossession;
+import org.mozilla.jss.pkix.primitive.AVA;
 import org.mozilla.jss.pkix.primitive.AlgorithmIdentifier;
+import org.mozilla.jss.pkix.primitive.Attribute;
 import org.mozilla.jss.pkix.primitive.Name;
 import org.mozilla.jss.pkix.primitive.SubjectPublicKeyInfo;
 import org.mozilla.jss.util.Password;
@@ -148,6 +156,37 @@ public class CMCRequest {
 }
 
 /**
+ * getSigningAlgFromPrivate
+ *
+ */
+static SignatureAlgorithm getSigningAlgFromPrivate (java.security.PrivateKey privKey) {
+String method = "getSigningAlgFromPrivate: ";
+System.out.println(method + "begins.");
+SignatureAlgorithm signAlg = null;
+/*
+org.mozilla.jss.crypto.PrivateKey.Type signingKeyType =
+((org.mozilla.jss.crypto.PrivateKey) privKey)
+.getType();
+*/
+// TODO: allow more options later
+String signingKeyType = privKey.getAlgorithm();
+System.out.println(method + "found signingKeyType=" + signingKeyType);
+if (signingKeyType.equalsIgnoreCase("RSA")) {
+signAlg = SignatureAlgorithm.RSASignatureWithSHA256Digest;
+} else if (signingKeyType.equalsIgnoreCase("EC")) {
+signAlg = SignatureAlgorithm.ECSignatureWithSHA256Digest;
+} else {
+System.out.println(method + "Algorithm not supported:" +
+signingKeyType);
+return null;
+}
+System.out.println(method + "using SignatureAlgorithm: " +
+signAlg.toString());
+
+return signAlg;
+}
+
+/**
  * signData signs the request PKIData
  *
  * @param signerCert the certificate of the authorized signer of the CMC revocation request.
@@ -190,17 +229,9 @@ public class CMCRequest {
 
 EncapsulatedContentInfo ci = new EncapsulatedContentInfo(OBJECT_IDENTIFIER.id_cct_PKIData, pkidata);
 DigestAlgorithm digestAlg = null;
-SignatureAlgorithm signAlg = null;
-org.mozilla.jss.crypto.PrivateKey.Type signingKeyType = ((org.mozilla.jss.crypto.PrivateKey) privKey)
-.getType();
-if (signingKeyType

Re: [Pki-devel] [PATCH] pki-0178, jss-0000..0002 - PKCS #12 key bag AES encryption

[Christina Fu]

Thank you. Please see review comments:

https://bugzilla.mozilla.org/show_bug.cgi?id=1355358#c6

I will review PKCS12Util later.

Christina


On 04/10/2017 11:30 PM, Fraser Tweedale wrote:

On Thu, Apr 06, 2017 at 03:45:55PM -0700, Christina Fu wrote:

Hi Fraser,

Could you please do the following first?

1.  file a Mozilla bugzilla bug for this against Product JSS Release 4.4.1,
then assign to yourself:
https://bugzilla.mozilla.org/
2. After making sure your patch compiles well with the 4.4.1 base, attach
the patch to that ticket, and mark reviewers

thanks!

Christina


Thanks Christina, I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1355358

I was unable to assign myself to the bug ('Assignee' field is not
active when I go to Edit Bug.

Also not sure how to "mark reviewers".  I added you and Elio to Cc
though.

Thanks,
Fraser


On 04/04/2017 02:56 AM, Fraser Tweedale wrote:

Hi team,

Please review attached patches for JSS and Dogtag that:

- add some new EncryptedPrivateKeyInfo export and import functions
to JSS

- update Dogtag's `pki pkcs12' command to use the new functions to
achieve AES encryption of the key bags, with wrapping/unwrapping
occurring on the token.

PKCS #12 files produced by current releases continue to import
properly (of course, this is an important test vector).

These patches do not address the PKCS #12 KRA recovery export; This
is my next task and separate patches will be produced.

Thanks,
Fraser


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

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

[Christina Fu]

looks fine.

ack.

Christina


On 03/29/2017 11:22 AM, John Magne wrote:

[PATCH] SCP03 support for g sc 7 card.

Ticket:

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


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

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

Ex:

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

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

Ex:

tks.defKeySet._005=## tks.prot3   , protocol 3 specific settings
tks.defKeySet._006=## divers= emv,visa2 : Values for the master key case, or > 
version one.
tks.defKeySet._007=## diversVer1 = emv,visa2, or none. This is for developer or 
version one keyset
tks.defKeySet._008=## devKeyType = DES3or AES. This is for the key type of 
developer or version one keys.
tks.defKeySet._009=## masterKeyType = DES3 or AES. This is for the type of key 
for the master key.
tks.defKeySet._010=##
tks.defKeySet._011=## Only supports two tokens now: G Smart Cafe 6 and Smart 
Cafe 7, use these exact settings
tks.defKeySet._013=## Smart Cafe 6 settings:
tks.defKeySet._014=##tks.defKeySet.prot3.divers=emv
tks.defKeySet._015=##tks.defKeySet.prot3.diversVer1Keys=emv
tks.defKeySet._016=##tks.defKeySet.prot3.devKeyType=DES3
tks.defKeySet._017=##tks.defKeySet.prot3.masterKeyType=DES3
tks.defKeySet._018=##Smart Cafe 7 settings:
tks.defKeySet._019=##tks.defKeySet.prot3.divers=none
tks.defKeySet._020=##tks.defKeySet.prot3.diversVer1Keys=none
tks.defKeySet._021=##tks.defKeySet.prot3.devKeyType=AES
tks.defKeySet._022=##tks.defKeySet.prot3.masterKeyType=AES
tks.defKeySet._023=##
tks.defKeySet._024=##


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


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

Re: [Pki-devel] [PATCH] pki-0178, jss-0000..0002 - PKCS #12 key bag AES encryption

[Christina Fu]

Hi Fraser,

Could you please do the following first?

1.  file a Mozilla bugzilla bug for this against Product JSS Release 
4.4.1, then assign to yourself:

https://bugzilla.mozilla.org/
2. After making sure your patch compiles well with the 4.4.1 base, 
attach the patch to that ticket, and mark reviewers


thanks!

Christina


On 04/04/2017 02:56 AM, Fraser Tweedale wrote:

Hi team,

Please review attached patches for JSS and Dogtag that:

- add some new EncryptedPrivateKeyInfo export and import functions
   to JSS

- update Dogtag's `pki pkcs12' command to use the new functions to
   achieve AES encryption of the key bags, with wrapping/unwrapping
   occurring on the token.

PKCS #12 files produced by current releases continue to import
properly (of course, this is an important test vector).

These patches do not address the PKCS #12 KRA recovery export; This
is my next task and separate patches will be produced.

Thanks,
Fraser


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

[Pki-devel] [PATCH] Bug-2615-CMC-cleanup-code-for-Encrypted-Decrypted-PO.patch

[Christina Fu]

This is the cleanup patch that I promised.  It contains as much error-checking 
code as I can muster for now.

It is tested to work.

This is again an incremental patch from the previous CMC patch.

thanks,
ChristinaFrom 9cbc97194ed793229681b1f1b27569674855e617 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Sun, 26 Mar 2017 17:34:51 -0400
Subject: [PATCH] Bug #2615 CMC: cleanup code for Encrypted Decrypted POP This
 patch adds more error checking and debugging

---
 .../netscape/cms/profile/common/EnrollProfile.java | 190 -
 .../cms/servlet/common/CMCOutputTemplate.java  |  75 +++-
 .../com/netscape/cmsutil/crypto/CryptoUtil.java|  18 ++
 3 files changed, 240 insertions(+), 43 deletions(-)

diff --git a/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java b/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java
index 5c07ecb..f4a59d2 100644
--- a/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java
+++ b/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java
@@ -352,8 +352,13 @@ public abstract class EnrollProfile extends BasicProfile
  */
 public void setPOPchallenge(IRequest req) throws EBaseException {
 String method = "EnrollProfile: setPOPchallenge: ";
+String msg = "";
 
 CMS.debug(method + " getting user public key in request");
+if (req == null) {
+CMS.debug(method + "method parameters cannot be null");
+throw new EBaseException(method + msg);
+}
 byte[] req_key_data = req.getExtDataInByteArray(IEnrollProfile.REQUEST_KEY);
 netscape.security.x509.CertificateX509Key pubKey = null;
 if (req_key_data != null) {
@@ -368,16 +373,23 @@ public abstract class EnrollProfile extends BasicProfile
 PublicKey issuanceProtPubKey = authority.getIssuanceProtPubKey();
 if (issuanceProtPubKey != null)
 CMS.debug(method + "issuanceProtPubKey not null");
-else
-CMS.debug(method + "issuanceProtPubKey null");
+else {
+msg = method + "issuanceProtPubKey null";
+CMS.debug(msg);
+throw new EBaseException(method + msg);
+}
 
-String msg = "";
 try {
 CryptoToken token = null;
 String tokenName = CMS.getConfigStore().getString("cmc.token", CryptoUtil.INTERNAL_TOKEN_NAME);
 token = CryptoUtil.getCryptoToken(tokenName);
 
 PublicKey userPubKey = X509Key.parsePublicKey(new DerValue(req_key_data));
+if (userPubKey == null) {
+msg = method + "userPubKey null after X509Key.parsePublicKey";
+CMS.debug(msg);
+throw new EBaseException(msg);
+}
 
 SymmetricKey symKey = CryptoUtil.generateKey(token);
 byte[] pop_encreyptedData = CryptoUtil.encryptUsingSymmetricKey(
@@ -385,7 +397,7 @@ public abstract class EnrollProfile extends BasicProfile
 if (pop_encreyptedData == null) {
 msg = method + "pop_encreyptedData null";
 CMS.debug(msg);
-throw new Exception(msg);
+throw new EBaseException(msg);
 }
 
 byte[] pop_sysPubEncreyptedSession = CryptoUtil.wrapUsingPublicKey(
@@ -393,7 +405,7 @@ public abstract class EnrollProfile extends BasicProfile
 if (pop_sysPubEncreyptedSession == null) {
 msg = method + "pop_sysPubEncreyptedSession null";
 CMS.debug(msg);
-throw new Exception(msg);
+throw new EBaseException(msg);
 }
 
 byte[] pop_userPubEncreyptedSession = CryptoUtil.wrapUsingPublicKey(
@@ -401,7 +413,7 @@ public abstract class EnrollProfile extends BasicProfile
 if (pop_userPubEncreyptedSession == null) {
 msg = method + "pop_userPubEncreyptedSession null";
 CMS.debug(msg);
-throw new Exception(msg);
+throw new EBaseException(msg);
 }
 CMS.debug(method + "POP challenge fields generated successfully...setting request extData");
 
@@ -507,11 +519,15 @@ public abstract class EnrollProfile extends BasicProfile
 throws EProfileException {
 
 String method = "EnrollProfile: parseCMC: ";
+String msg = ""; // for capturing debug and throw info
+
 /* cert request must not be null */
 if (certreq == null) {
-CMS.debug(method + "certreq null");
+ms

[Pki-devel] [PATCH] Issuance Protection Cert establishment and convenience crypto routines

[Christina Fu]

This patch provides routines that can be shared between

https://pagure.io/dogtagpki/issue/2605 CMC feature:
id-cmc-identityProofV2 per rfc5272

and

https://pagure.io/dogtagpki/issue/2604 RFE: shared secret storage and
retrieval mechanism

Note: symkey algorithm remains at DES3 until cmc feature materializes.

thanks,

Christina

>From db2a9326ed3c93e0463444900875021d269f27ae Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 17 Mar 2017 11:49:41 -0700
Subject: [PATCH] pagure#2605 CMC feature: id-cmc-identityProofV2 per rfc5272
 (part 1) This patch provides methods that can be shared between the CA and
 the ISharedToken plugins:  1. the convenience routines for quick encryption,
 decryption, hashing methods that take default algorithms.  2. The
 establishment of Issuance Protection Certificate

---
 .../src/com/netscape/ca/CertificateAuthority.java  |  57 +++-
 .../netscape/certsrv/ca/ICertificateAuthority.java |  10 ++
 .../com/netscape/cmsutil/crypto/CryptoUtil.java| 145 +
 3 files changed, 211 insertions(+), 1 deletion(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 7ad40a9f6e436d4d3c4c947165a2c7ae18dc960a..a6d56ac6b576371a3f2454b2faf5f90b43b51d29 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -305,6 +305,10 @@ public class CertificateAuthority
 
 protected Hashtable<String, ListenerPlugin> mListenerPlugins = null;
 
+// for CMC shared secret operations
+protected PublicKey mSysEncKey = null;
+protected PrivateKey mSysDecKey = null;
+
 /**
  * Internal constants
  */
@@ -606,16 +610,67 @@ public class CertificateAuthority
 
 CMS.debug("CertificateAuthority: finished init of host authority");
 }
+
+// set up CA Issuance Protection Cert
+if (initSigUnitSucceeded)
+initIssuanceProtectionCert();
 } catch (EBaseException e) {
 CMS.debug(e);
 if (CMS.isPreOpMode()) {
-CMS.debug("CertificateAuthority.init(): Swallow exception in pre-op mode");
+CMS.debug("CertificateAuthority: Swallow exception in pre-op mode");
 return;
 }
 throw e;
 }
 }
 
+/**
+ * initIssuanceProtectionCert sets the CA Issuance Protection cert
+ */
+private void initIssuanceProtectionCert()
+   throws EBaseException {
+String method = "CertificateAuthority: initIssuanceProtectionCert: ";
+CryptoManager cManager = null;
+
+String name = null;
+String defaultName = "cert.subsystem.nickname";
+String certNickName = null;
+try {
+cManager = CryptoManager.getInstance();
+name = "cert.issuance_protection.nickname";
+CMS.debug(method + " about to look for CA Issuance Protection cert: "+
+name);
+certNickName = mConfig.getString(name);
+} catch (EBaseException e) {
+CMS.debug(method + name + " not found; use defaultName : " + defaultName );
+name = defaultName ;
+certNickName = mConfig.getString(name);
+} catch (Exception e) {
+throw new EBaseException(method + e);
+}
+CMS.debug(method + "found nickname: "+ certNickName);
+
+try {
+org.mozilla.jss.crypto.X509Certificate cert = null;
+cert = cManager.findCertByNickname(certNickName);
+if (cert != null) {
+CMS.debug(method + " found CA Issuance Protection cert:" + certNickName);
+mSysEncKey = cert.getPublicKey();
+mSysDecKey = cManager.getInstance().findPrivKeyByCert(cert);
+}
+} catch (Exception e) {
+throw new EBaseException(method + e);
+}
+}
+
+public PublicKey getIssuanceProtPubKey() {
+return mSysEncKey;
+}
+
+public PrivateKey getIssuanceProtPrivKey() {
+return mSysDecKey;
+}
+
 private void checkForNewerCert() throws EBaseException {
 if (authoritySerial == null)
 return;
diff --git a/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java b/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java
index 8ddc601e565f0b3ca901266cfe10928b3f9e4438..8e34880e512e0f59f9d3850961ec42ad72628567 100644
--- a/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java
+++ b/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java
@@ -607,4 +607,14 @@ public interface ICertificateAuthority extends ISubsystem {
  */
 public void deleteAuthority(HttpServletRequest httpReq)
 throws EBaseException;
+
+  

[Pki-devel] [PATCH] Issuance Protection Cert establishment and convenience encrypt/decrypt/hash routines

[Christina Fu]

This patch provides code that can be shared between:

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

and

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

Note: default is DES3 for now; will switch over to AES when the cmc
feature further materializes.

thanks,

Christina

>From db2a9326ed3c93e0463444900875021d269f27ae Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 17 Mar 2017 11:49:41 -0700
Subject: [PATCH] pagure#2605 CMC feature: id-cmc-identityProofV2 per rfc5272
 (part 1) This patch provides methods that can be shared between the CA and
 the ISharedToken plugins:  1. the convenience routines for quick encryption,
 decryption, hashing methods that take default algorithms.  2. The
 establishment of Issuance Protection Certificate

---
 .../src/com/netscape/ca/CertificateAuthority.java  |  57 +++-
 .../netscape/certsrv/ca/ICertificateAuthority.java |  10 ++
 .../com/netscape/cmsutil/crypto/CryptoUtil.java| 145 +
 3 files changed, 211 insertions(+), 1 deletion(-)

diff --git a/base/ca/src/com/netscape/ca/CertificateAuthority.java b/base/ca/src/com/netscape/ca/CertificateAuthority.java
index 7ad40a9f6e436d4d3c4c947165a2c7ae18dc960a..a6d56ac6b576371a3f2454b2faf5f90b43b51d29 100644
--- a/base/ca/src/com/netscape/ca/CertificateAuthority.java
+++ b/base/ca/src/com/netscape/ca/CertificateAuthority.java
@@ -305,6 +305,10 @@ public class CertificateAuthority
 
 protected Hashtable<String, ListenerPlugin> mListenerPlugins = null;
 
+// for CMC shared secret operations
+protected PublicKey mSysEncKey = null;
+protected PrivateKey mSysDecKey = null;
+
 /**
  * Internal constants
  */
@@ -606,16 +610,67 @@ public class CertificateAuthority
 
 CMS.debug("CertificateAuthority: finished init of host authority");
 }
+
+// set up CA Issuance Protection Cert
+if (initSigUnitSucceeded)
+initIssuanceProtectionCert();
 } catch (EBaseException e) {
 CMS.debug(e);
 if (CMS.isPreOpMode()) {
-CMS.debug("CertificateAuthority.init(): Swallow exception in pre-op mode");
+CMS.debug("CertificateAuthority: Swallow exception in pre-op mode");
 return;
 }
 throw e;
 }
 }
 
+/**
+ * initIssuanceProtectionCert sets the CA Issuance Protection cert
+ */
+private void initIssuanceProtectionCert()
+   throws EBaseException {
+String method = "CertificateAuthority: initIssuanceProtectionCert: ";
+CryptoManager cManager = null;
+
+String name = null;
+String defaultName = "cert.subsystem.nickname";
+String certNickName = null;
+try {
+cManager = CryptoManager.getInstance();
+name = "cert.issuance_protection.nickname";
+CMS.debug(method + " about to look for CA Issuance Protection cert: "+
+name);
+certNickName = mConfig.getString(name);
+} catch (EBaseException e) {
+CMS.debug(method + name + " not found; use defaultName : " + defaultName );
+name = defaultName ;
+certNickName = mConfig.getString(name);
+} catch (Exception e) {
+throw new EBaseException(method + e);
+}
+CMS.debug(method + "found nickname: "+ certNickName);
+
+try {
+org.mozilla.jss.crypto.X509Certificate cert = null;
+cert = cManager.findCertByNickname(certNickName);
+if (cert != null) {
+CMS.debug(method + " found CA Issuance Protection cert:" + certNickName);
+mSysEncKey = cert.getPublicKey();
+mSysDecKey = cManager.getInstance().findPrivKeyByCert(cert);
+}
+} catch (Exception e) {
+throw new EBaseException(method + e);
+}
+}
+
+public PublicKey getIssuanceProtPubKey() {
+return mSysEncKey;
+}
+
+public PrivateKey getIssuanceProtPrivKey() {
+return mSysDecKey;
+}
+
 private void checkForNewerCert() throws EBaseException {
 if (authoritySerial == null)
 return;
diff --git a/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java b/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java
index 8ddc601e565f0b3ca901266cfe10928b3f9e4438..8e34880e512e0f59f9d3850961ec42ad72628567 100644
--- a/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java
+++ b/base/common/src/com/netscape/certsrv/ca/ICertificateAuthority.java
@@ -607,4 +607,14 @@ public interface ICertificateAuthority extends ISubsystem {
  */
 public void deleteAuthority(HttpServletRequest httpReq)
 throws EBaseException;
+
+/**
+ * get Issuance Protection Public Key
+ */
+public java.secu

Re: [Pki-devel] [PATCH] 957 Added access banner for PKI UI.

[Christina Fu]

I only have time to play with it. So this review is not based on code 
reading.  I was able to trigger a session timeout and the banner appears 
again as expected.  So from that point of view, as long as the patches 
don't break existing banner-ignorant clients, ack.


And again, please make sure it works with IE.

Christina


On 02/23/2017 01:47 PM, Endi Sukma Dewata wrote:

On 2/22/2017 1:57 PM, Endi Sukma Dewata wrote:

The PKI UI main page has been modified to retrieve access banner
and display it once at the beginning of the SSL connection.

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


New patch #957-1 attached. It's now using the two REST services added 
in patch #956-1.




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


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

Re: [Pki-devel] [PATCH] 957 Added access banner for PKI UI.

[Christina Fu]

On 02/22/2017 04:51 PM, Christina Fu wrote:


First, as discussed over irc, the banner should be re-displayed when 
an ssl session ends.  Sounds like sessonStorage might not do what is 
expected.


correction.  I meant to say "the banner should be re-displayed when an 
ssl session ends and a new session begins"


Please also make sure the resulting code works with IE.

thanks!

Christina


On 02/22/2017 11:57 AM, Endi Sukma Dewata wrote:

The PKI UI main page has been modified to retrieve access banner
and display it once at the beginning of the SSL connection.

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



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




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


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

Re: [Pki-devel] [PATCH] 957 Added access banner for PKI UI.

[Christina Fu]

First, as discussed over irc, the banner should be re-displayed when an 
ssl session ends.  Sounds like sessonStorage might not do what is expected.


Please also make sure the resulting code works with IE.

thanks!

Christina


On 02/22/2017 11:57 AM, Endi Sukma Dewata wrote:

The PKI UI main page has been modified to retrieve access banner
and display it once at the beginning of the SSL connection.

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



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


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

Re: [Pki-devel] [PATCH] 918 Replaced CryptoManager.getTokenByName().

[Christina Fu]

A lot of areas (both on server and on various tools) have been touched, 
although the changes are simple in nature and are all similar.  Please 
make sure everything that's touched by this patch are still working.


ACK if all tested to work.

thanks,

Christina


On 01/25/2017 06:41 AM, Endi Sukma Dewata wrote:

Direct invocations of CryptoManager.getTokenByName() have been
replaced with CryptoUtil.getCryptoToken() and getKeyStorageToken()
to ensure that internal token names are handled consistently both
in normal mode and FIPS mode.

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



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


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

Re: [Pki-devel] [PATCH] 916 Updated CryptoUtil.

[Christina Fu]

looks good.  Only requesting to have comment for isInternalToken() to 
explain why if name is empty its considered true.


conditional ACK if tested to work.

thanks,

Christina


On 01/25/2017 06:41 AM, Endi Sukma Dewata wrote:

The CryptoUtil has been modified to provide separate methods to
obtain crypto tokens and key store tokens. If the provided token
name matches the internal token name the methods will return the
corresponding internal token.

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



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


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

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

[Christina Fu]

This patch addresses:

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


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


thanks!

Christina

>From 5e914a3855d95a0bbca5fc565757fea5e40f16a1 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@dhcp-16-189.sjc.redhat.com>
Date: Fri, 20 Jan 2017 16:01:17 -0800
Subject: [PATCH] Ticket #1741 ECDSA certs Alg IDs contian parameter field Per
 rfc5758, When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, or
 ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an
 AlgorithmIdentifier, the encoding MUST omit the parameters field. Note: Since
 we do not support DSA, this patch does not attempt to address them. Also,
 while we do not claim to support sha224, the patch adds enough code to
 process the OID just for completeness.  However, it does not attempt to offer
 it as part of the signing algorithms.

---
 .../src/netscape/security/x509/AlgorithmId.java| 41 +-
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/base/util/src/netscape/security/x509/AlgorithmId.java b/base/util/src/netscape/security/x509/AlgorithmId.java
index 08c9c4f46cfadd7e75a3e6c1f61b47b6d6687ec9..a89843e0a1fd5dcd4da299758e615a76625019b0 100644
--- a/base/util/src/netscape/security/x509/AlgorithmId.java
+++ b/base/util/src/netscape/security/x509/AlgorithmId.java
@@ -230,10 +230,18 @@ public class AlgorithmId implements Serializable, DerEncoder {
 try (DerOutputStream tmp = new DerOutputStream()) {
 DerOutputStream bytes = new DerOutputStream();
 bytes.putOID(algid);
-if (params == null)
-bytes.putNull();
-else
-bytes.putDerValue(params);
+
+// omit parameter field for ECDSA
+if (!algid.equals(sha224WithEC_oid) &&
+!algid.equals(sha256WithEC_oid) &&
+!algid.equals(sha384WithEC_oid) &&
+!algid.equals(sha512WithEC_oid)) {
+if (params == null) {
+bytes.putNull();
+} else
+bytes.putDerValue(params);
+}
+
 tmp.write(DerValue.tag_Sequence, bytes);
 out.write(tmp.toByteArray());
 }
@@ -246,12 +254,19 @@ public class AlgorithmId implements Serializable, DerEncoder {
 public final byte[] encode() throws IOException {
 try (DerOutputStream out = new DerOutputStream()) {
 DerOutputStream bytes = new DerOutputStream();
-
 bytes.putOID(algid);
-if (params == null)
-bytes.putNull();
-else
-bytes.putDerValue(params);
+
+// omit parameter field for ECDSA
+if (!algid.equals(sha224WithEC_oid) &&
+!algid.equals(sha256WithEC_oid) &&
+!algid.equals(sha384WithEC_oid) &&
+!algid.equals(sha512WithEC_oid)) {
+if (params == null) {
+bytes.putNull();
+} else
+bytes.putDerValue(params);
+}
+
 out.write(DerValue.tag_Sequence, bytes);
 return out.toByteArray();
 }
@@ -314,6 +329,9 @@ public class AlgorithmId implements Serializable, DerEncoder {
 if (name.equals("SHA1withEC") || name.equals("SHA1/EC")
 || name.equals("1.2.840.10045.4.1"))
 return AlgorithmId.sha1WithEC_oid;
+if (name.equals("SHA224withEC") || name.equals("SHA224/EC")
+|| name.equals("1.2.840.10045.4.3.1"))
+return AlgorithmId.sha224WithEC_oid;
 if (name.equals("SHA256withEC") || name.equals("SHA256/EC")
 || name.equals("1.2.840.10045.4.3.2"))
 return AlgorithmId.sha256WithEC_oid;
@@ -646,6 +664,8 @@ public class AlgorithmId implements Serializable, DerEncoder {
  */
 private static final int sha1WithEC_data[] =
{ 1, 2, 840, 10045, 4, 1 };
+private static final int sha224WithEC_data[] =
+   { 1, 2, 840, 10045, 4, 3, 1 };
 private static final int sha256WithEC_data[] =
{ 1, 2, 840, 10045, 4, 3, 2 };
 private static final int sha384WithEC_data[] =
@@ -676,6 +696,9 @@ public class AlgorithmId implements Serializabl

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

[Christina Fu]

Overall, it looks good.  Just some minor suggestions, mostly for 
clarification purposes.


* SecureChannel.java : clearAppletKeySlotData

  - would appreciate comments describing the content and format 
expected in the input "data"


  - maybe a positive debug message after the successful cleanup (as 
negative result is non-fatal regardless)


* PKCS11Obj.java : getKeyIndexList

 - please add high level comment to tell what this does

 - how about go with the convention and assign a String method for 
debug messages?


 - I couldn't figure out why the code needs to traverse the cert 
objects while it has no interest in them;  I don't think it hurts 
though;  I'm okay with it if you decide to leave it in.


 - One question: if TPSBuffer data ends up not having anything add to 
it, will this reference blow up? data.toHexString()


Conditional ACK.

thanks,

Christina



On 12/16/2016 04:28 PM, John Magne wrote:

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

 Ticket #2569: Token memory not wiped after key deletion
 
 This is the dogtag upstream side of the TPS portion of this ticket.

 This fix also involves an applet fix, handled in another bug.


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


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

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

[Christina Fu]

Thanks!

pushed to master:

commit c1656bd16dfca8bb5eef4436ee64b95daaac70c8

Christina


On 01/04/2017 11:50 AM, John Magne wrote:

Looks good.

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

If tested to work, ACK



- Original Message -

From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Wednesday, January 4, 2017 11:26:14 AM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0157-Ticket-2534-additional-reset-cert-status-after-succe.patch

This patch addresses additional issue found after last fix for

https://fedorahosted.org/pki/ticket/2534 Automatic recovery of
encryption cert - CA and TPS tokendb shows different certificate status

where the cert status still shows revoked_on_hold, even though the cert
was just unrevoked successfully on the CA.

thanks,

Christina


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


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

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

[Christina Fu]

This patch addresses additional issue found after last fix for

https://fedorahosted.org/pki/ticket/2534 Automatic recovery of 
encryption cert - CA and TPS tokendb shows different certificate status


where the cert status still shows revoked_on_hold, even though the cert 
was just unrevoked successfully on the CA.


thanks,

Christina

>From c1656bd16dfca8bb5eef4436ee64b95daaac70c8 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@dhcp-16-189.sjc.redhat.com>
Date: Wed, 4 Jan 2017 11:20:06 -0800
Subject: [PATCH] Ticket #2534 (additional) - reset cert status after
 successful unrevoke

---
 .../tps/src/org/dogtagpki/server/tps/processor/EnrolledCertsInfo.java | 4 
 .../src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java| 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/EnrolledCertsInfo.java b/base/tps/src/org/dogtagpki/server/tps/processor/EnrolledCertsInfo.java
index 35793c71f2da2bb7a0c8e6525f3bcc52e21da87f..9395001b82d320312cfa8df4c7014e3967b9fa0a 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/EnrolledCertsInfo.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/EnrolledCertsInfo.java
@@ -163,6 +163,10 @@ public class EnrolledCertsInfo {
 certStatuses.add(status);
 }
 
+public void setCertStatus(int index, TokenCertStatus status) {
+certStatuses.set(index, status);
+}
+
 public void setStartProgress(int startP) {
 startProgress = startP;
 
diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
index 64cc571e3ce56d1722e197388647e3b65196b79f..aba0e99a361c2b3e99a3e4364d138312cf119d39 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
@@ -1960,7 +1960,8 @@ public class TPSEnrollProcessor extends TPSProcessor {
 auditRevoke(certToRecover.getTokenID(), false /*off-hold*/, -1 /*na*/,
 String.valueOf(response.getStatus()), serialToRecover, caConnId, null);
 // successful unrevoke should mark the cert "active"
-certsInfo.addCertStatus(TokenCertStatus.ACTIVE);
+CMS.debug(method + ": unrevoke successful. Setting cert status to active for actualCertIndex:" + actualCertIndex);
+certsInfo.setCertStatus(actualCertIndex, TokenCertStatus.ACTIVE);
 } catch (EBaseException e) {
 logMsg = "failed getting CARemoteRequestHandler";
 CMS.debug(method + ":" + logMsg);
-- 
2.7.4

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

[Pki-devel] [PATCH] pki-cfu-0156-Ticket-2534-Automatic-recovery-of-encryption-cert-CA.patch

[Christina Fu]

https://fedorahosted.org/pki/ticket/2534 Automatic recovery of 
encryption cert - CA and TPS tokendb shows different certificate status


This patch fixes the reported issue so now the auto-recovered 
certificate will reflect the actual status of the certificate. Also, 
since the externalReg tracks its own recovered certificate status, it is 
consolidated with the certificate status tracking mechanism added in 
this patch so that they can be uniformly managed.


thanks,

Christina

>From d81e2a31181c7d8487171fd7fb7c64bc87296c39 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@dhcp-16-189.sjc.redhat.com>
Date: Fri, 18 Nov 2016 12:13:28 -0800
Subject: [PATCH] Ticket #2534 Automatic recovery of encryption cert - CA and
 TPS tokendb shows different certificate status This patch fixes the reported
 issue so now the auto-recovered certificate will reflect the actual status of
 the certificate.  Also, since the externalReg tracks its own recovered
 certificate status, it is consolidated with the certificate status tracking
 mechanism added in this patch so that they can be uniformly managed.

---
 .../src/org/dogtagpki/server/tps/TPSTokendb.java   |  93 ++---
 .../dogtagpki/server/tps/dbs/TokenCertStatus.java  |  43 
 .../server/tps/main/ExternalRegAttrs.java  |  35 ---
 .../server/tps/main/ExternalRegCertToRecover.java  |  27 -
 .../server/tps/processor/EnrolledCertsInfo.java|  24 -
 .../server/tps/processor/TPSEnrollProcessor.java   | 114 +++--
 .../server/tps/processor/TPSProcessor.java |   7 +-
 7 files changed, 158 insertions(+), 185 deletions(-)
 create mode 100644 base/tps/src/org/dogtagpki/server/tps/dbs/TokenCertStatus.java

diff --git a/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java b/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java
index 729e81e070ba1db7c9d5c84d6c85db1fcc76fda7..ca0a409a7b5c440787eaf6713cf14c7f5e32190e 100644
--- a/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java
+++ b/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java
@@ -25,15 +25,12 @@ import java.util.HashMap;
 import java.util.Iterator;
 import java.util.Map;
 
-import netscape.security.x509.RevocationReason;
-
 import org.dogtagpki.server.tps.cms.CARemoteRequestHandler;
 import org.dogtagpki.server.tps.cms.CARevokeCertResponse;
 import org.dogtagpki.server.tps.dbs.ActivityDatabase;
 import org.dogtagpki.server.tps.dbs.TPSCertRecord;
+import org.dogtagpki.server.tps.dbs.TokenCertStatus;
 import org.dogtagpki.server.tps.dbs.TokenRecord;
-import org.dogtagpki.server.tps.main.ExternalRegAttrs;
-import org.dogtagpki.server.tps.main.ExternalRegCertToRecover;
 import org.dogtagpki.tps.main.TPSException;
 import org.dogtagpki.tps.msg.EndOpMsg.TPSStatus;
 
@@ -43,6 +40,8 @@ import com.netscape.certsrv.base.IConfigStore;
 import com.netscape.certsrv.dbs.EDBRecordNotFoundException;
 import com.netscape.certsrv.tps.token.TokenStatus;
 
+import netscape.security.x509.RevocationReason;
+
 /*
  * TPSTokendb class offers a collection of tokendb management convenience routines
  */
@@ -217,64 +216,24 @@ public class TPSTokendb {
 tps.tokenDatabase.updateRecord(id, tokenRecord);
 }
 
-/*
- * tdbAddCertificatesForCUID adds certificates issued for the token CUID
- * - this instance pre-process the cert records to update the cert statuses
- * @param cuid the cuid of the token
- * @param certs an ArrayList of TPSCertRecord
- * @param erAttrs the ExternalRegAttrs collection
- */
-public void tdbAddCertificatesForCUID(String cuid, ArrayList certs, ExternalRegAttrs erAttrs)
-throws TPSException {
-String method = "TPSTokendb.tdbAddCertificatesForCUID (with erAttrs): ";
-String logMsg = "";
-CMS.debug(method + "begins");
-if (cuid == null || certs== null || certs.isEmpty() || erAttrs == null) {
-logMsg =  "params cuid, certs and erAttrs cannot be null or empty";
-CMS.debug(method + logMsg);
-throw new TPSException(method + logMsg, TPSStatus.STATUS_ERROR_CONTACT_ADMIN);
-}
-CMS.debug("TPSTokendb.tdbAddCertificatesForCUID: number of certs to update:"+ certs.size());
-
-// update cert status first
-for (TPSCertRecord cert : certs) {
-ExternalRegCertToRecover.CertStatus status = ExternalRegCertToRecover.CertStatus.UNINITIALIZED;
-status = erAttrs.getCertStatus(cert.getSerialNumber());
-if (status == ExternalRegCertToRecover.CertStatus.UNINITIALIZED) {
-//cert not found in ExternalReg; don't reset status; don't report
-continue;
-}
-
-//cert is one of the ExternalReg recovered certs, update the status
-CMS.debug(method + "found and set status for:" + cert.getSerialNumber());
-cert.setStatus(status.toString());
-
-}
-
-

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

[Christina Fu]

I compared this patch with the original C patch.  There was a check in C 
that does not exist in your Java patch:


1019

if(data.size() != 3){

1020

lifecycle = 0xf0;

1021

RA::Error(LL_PER_PDU, "RA_Processor::GetLifecycle", "apdu response is the 
wrong size, the size is: %x", data.size());

1022

goto loser;

1023

}


Why does it not apply in Java?

Thanks,
Christina

On 11/15/2016 06:20 PM, John Magne wrote:


Ticket: TPS throws "err=6" when attempting to format and e : 
https://fedorahosted.org/pki/ticket/2544

Fix tested on standard card, it does what it is supposed to do. It checks first 
to make sure the lifecycle
state needs to be changed before attempting to do so. This will prevent any 
cards that return an error when
one tries to over write the value with the same value it had before.



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


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

Re: [Pki-devel] [PATCH] 866 Fixed problem installing subordinate CA with HSM in FIPS mode.

[Christina Fu]

looks good.  if tested to work, ack.

Christina


On 11/15/2016 01:57 PM, Endi Sukma Dewata wrote:

Due to certutil issue (bug #1393668) the installation code has
been modified to import certificates into the NSS database in
two steps. This workaround is needed to install subordinate CA
with HSM in FIPS mode.

First, the certificate will be imported into the HSM using the
HSM password without the trust attributes. Then, the certificate
will be imported into the internal token using the internal token
password with the trust attributes.

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



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


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

[Pki-devel] simple TPS debug messages added

[Christina Fu]

qualifies for "simple checkin that does not affect code".

commit 443dcb1914f010ce8fc7c737dd8163e05a3d71db
Author: Christina Fu <c...@dhcp-16-189.sjc.redhat.com>
Date:   Mon Oct 24 09:59:42 2016 -0700

a few simple debugging messages in TPS that will make debugging easier.


Christina

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

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

[Christina Fu]

Just a minor suggestion.  Endi added in CryptalUtil.java lately to fix 
similar FIPS related issue:


isInternalToken().

You might want to take advantage of that instead as it does ignore case.

It's up to you.

ACK.

Christina


On 10/20/2016 03:24 PM, John Magne wrote:

TPS token enrollment fails to setupSecureChannel when TPS and TKS security db 
is on fips mode.
 
 Ticket #2513.
 
 Simple fix allows the TPS and TKS the ability to obtain the proper internal token, even in FiPS mode.



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


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

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

[Christina Fu]

code looks fine.  If tested to work, ACK.

Christina


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

PIN_RESET policy is not giving expected results when set on a token.
 
 Simple fix to actually honor the PIN_RESET=or policy for a given token.

Minor logging improvements added as well for this error condition.
 
 Ticket #2510.





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


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

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

[Christina Fu]

If tested to work for all cases, ACK.

Christina


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

Cert/Key recovery is successful when the cert serial number and key id on the 
ldap user mismatches
 
  Fixes this bug #1381375.

 The portion this patch fixes involves URL encoding glitch we encountered 
when recovering keys using
 the "by cert" method.
 
 Also this bug addresses:
 
 Bug 1379379 - Unable to read an encrypted email using renewed tokens

 The URL encoding problem was affecting the proper verification of this bug.
 
 and
 
 Bug 1379749 - Automatic recovery of encryption cert is not working when a token is physically damaged and a temporary token is issued
 
 The URI encoding was also making this bug appear to fail more than it should have.

 There is also a minor fix to the feature that makes sure it works.
 
 This small fix is in TPSEngine.java where the constant for GenerateNewAndRecoverLast scheme is declared.



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


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

Re: [Pki-devel] [PATCH] 844 Fixed CryptoUtil.getTokenName().

[Christina Fu]

Code looks good.  ACK if tested to work in both FIPS and non-FIPS, with 
or without HSM.


Might be a future exercise to find out where the string "Internal Key 
Storage Token" comes from.


Christina


On 10/13/2016 06:57 PM, Endi Sukma Dewata wrote:

The CryptoUtil.getTokenName() has been modified to check both the
short name and full name of the internal token.

The ConfigurationUtils.deleteCert() has also been modified to call
CryptoUtil.getTokenName().

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

Pushed to master under one-liner/trivial rule.



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


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

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

[Christina Fu]

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


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


conditional ACK if you do that.

Christina


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

Actually attach the patch.

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

Fix for: Add ability to disallow TPS to enroll a single user on multiple 
tokens. #1664
 
 This bug was previously not completely fixed where we left a loophole to allow a user to

 end up with 2 active tokens. This fix closes that loophole.
 
 Also:
 
 Fix for: Unable to read an encrypted email using renewed tokens. #2483
 
 This fix provides for a new optional renewal based token policy, that

 allows the user to retain or recover old encryption certs for that profile,
 that get overwritten by the renewal process.
 
 An example is:
 
 RENEW=YES;RENEW_KEEP_OLD_ENC_CERTS=YES
 
 The second part of the policy is new.
 
 When this is set to "YES", the system will make sure the old enc cert

 will remain on the token. If it's missing or "NO", no such attempt will be 
made.


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


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

Re: [Pki-devel] [PATCH] pki-cfu-0153-Ticket-2496-Cert-Key-recovery-is-successful-when-the.patch

[Christina Fu]

pushed to master:

commit e00a28fcdc3e8fea920c85563a3ab26b123dda2d 
<https://fedorahosted.org/pki/changeset/e00a28fcdc3e8fea920c85563a3ab26b123dda2d/> 



thanks!

Christina


On 10/07/2016 11:19 AM, John Magne wrote:

ACK


One minor issue:

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

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

false and true for byKeID is switched.


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

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


- Original Message -

From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Thursday, October 6, 2016 2:18:49 PM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0153-Ticket-2496-Cert-Key-recovery-is-successful-when-the.patch

Attached  please find the patch for

https://fedorahosted.org/pki/ticket/2496 Cert/Key recovery is successful
when the cert serial number and key id on the ldap user mismatches

Description is in patch summary.

thanks,

Christina


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


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

Re: [Pki-devel] [PATCH] pki-cfu-0151-Ticket-2446-pkispawn-make-subject_dn-defaults-unique.patch

[Christina Fu]

pushed to master:

commit 1195ee9d6e45783d238edc1799363c21590febce

thanks,

Christina


On 08/31/2016 03:29 PM, Endi Sukma Dewata wrote:

ACK.

--
Endi S. Dewata

- Original Message -

Patch for https://fedorahosted.org/pki/ticket/2446 pkispawn: make
subject_dn defaults unique per instance name (for shared HSM)

Please review.

thanks,

Christina


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


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

[Pki-devel] [PATCH] pki-cfu-0151-Ticket-2446-pkispawn-make-subject_dn-defaults-unique.patch

[Christina Fu]

Patch for https://fedorahosted.org/pki/ticket/2446 pkispawn: make 
subject_dn defaults unique per instance name (for shared HSM)


Please review.

thanks,

Christina

>From 1195ee9d6e45783d238edc1799363c21590febce Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@dhcp-16-189.sjc.redhat.com>
Date: Wed, 31 Aug 2016 14:03:02 -0700
Subject: [PATCH] Ticket #2446 pkispawn: make subject_dn defaults unique per
 instance name (for shared HSM) When installing multiple instances on the same
 host sharing the same HSM, if subject_dn's are not specifically spelled out
 with unique names for each instance, installation will fail with complaints
 that same subject name and serial number already exist. This happens in the
 scenario if you are creating a subordinate CA, for example, that's in the
 same domain name as the root CA. It is very inconvenient that you are
 expected to spell out subject dn's of all system certs in the pkispawn config
 file. This patch changes default.cfg so that the instance name is in the
 default subject dn, e.g. adding it as an "ou" component:
 ou=%(pki_instance_name)s

---
 base/server/etc/default.cfg | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/base/server/etc/default.cfg b/base/server/etc/default.cfg
index f759dbac0df53ee6078027740e0aed5f107b22e7..31267ed88159e36e94e900c5fff103a2f2a2357d 100644
--- a/base/server/etc/default.cfg
+++ b/base/server/etc/default.cfg
@@ -124,13 +124,13 @@ pki_ssl_server_key_algorithm=SHA256withRSA
 pki_ssl_server_key_size=2048
 pki_ssl_server_key_type=rsa
 pki_ssl_server_nickname=Server-Cert cert-%(pki_instance_name)s
-pki_ssl_server_subject_dn=cn=%(pki_hostname)s,o=%(pki_security_domain_name)s
+pki_ssl_server_subject_dn=cn=%(pki_hostname)s,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_ssl_server_token=
 pki_subsystem_key_algorithm=SHA256withRSA
 pki_subsystem_key_size=2048
 pki_subsystem_key_type=rsa
 pki_subsystem_nickname=subsystemCert cert-%(pki_instance_name)s
-pki_subsystem_subject_dn=cn=Subsystem Certificate,o=%(pki_security_domain_name)s
+pki_subsystem_subject_dn=cn=Subsystem Certificate,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_subsystem_token=
 pki_theme_enable=True
 pki_theme_server_dir=/usr/share/pki/common-ui
@@ -292,7 +292,7 @@ pki_ca_signing_key_size=2048
 pki_ca_signing_key_type=rsa
 pki_ca_signing_nickname=caSigningCert cert-%(pki_instance_name)s CA
 pki_ca_signing_signing_algorithm=SHA256withRSA
-pki_ca_signing_subject_dn=cn=CA Signing Certificate,o=%(pki_security_domain_name)s
+pki_ca_signing_subject_dn=cn=CA Signing Certificate,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_ca_signing_token=
 pki_ca_signing_csr_path=
 pki_ca_signing_cert_path=
@@ -316,7 +316,7 @@ pki_ocsp_signing_key_size=2048
 pki_ocsp_signing_key_type=rsa
 pki_ocsp_signing_nickname=ocspSigningCert cert-%(pki_instance_name)s CA
 pki_ocsp_signing_signing_algorithm=SHA256withRSA
-pki_ocsp_signing_subject_dn=cn=CA OCSP Signing Certificate,o=%(pki_security_domain_name)s
+pki_ocsp_signing_subject_dn=cn=CA OCSP Signing Certificate,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_ocsp_signing_token=
 pki_profiles_in_ldap=False
 pki_random_serial_numbers_enable=False
@@ -326,10 +326,10 @@ pki_subordinate_security_domain_name=%(pki_dns_domainname)s Subordinate Security
 pki_admin_email=%(pki_admin_name)s@%(pki_dns_domainname)s
 pki_admin_name=%(pki_admin_uid)s
 pki_admin_nickname=PKI Administrator for %(pki_dns_domainname)s
-pki_admin_subject_dn=cn=PKI Administrator,e=%(pki_admin_email)s,o=%(pki_security_domain_name)s
+pki_admin_subject_dn=cn=PKI Administrator,e=%(pki_admin_email)s,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_admin_uid=caadmin
 pki_audit_signing_nickname=auditSigningCert cert-%(pki_instance_name)s CA
-pki_audit_signing_subject_dn=cn=CA Audit Signing Certificate,o=%(pki_security_domain_name)s
+pki_audit_signing_subject_dn=cn=CA Audit Signing Certificate,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_ds_base_dn=o=%(pki_instance_name)s-CA
 pki_ds_database=%(pki_instance_name)s-CA
 pki_ds_hostname=%(pki_hostname)s
@@ -404,22 +404,22 @@ pki_storage_key_size=2048
 pki_storage_key_type=rsa
 pki_storage_nickname=storageCert cert-%(pki_instance_name)s KRA
 pki_storage_signing_algorithm=SHA256withRSA
-pki_storage_subject_dn=cn=DRM Storage Certificate,o=%(pki_security_domain_name)s
+pki_storage_subject_dn=cn=DRM Storage Certificate,ou=%(pki_instance_name)s,o=%(pki_security_domain_name)s
 pki_storage_token=
 pki_transport_key_algorithm=SHA256withRSA
 pki_transport_key_size=2048
 pki_transport_key_type=rsa
 pki_transport_nickname=transportCert cert-%(pki_instance_name)s KRA
 pki_transport_signing_algorithm=SHA256withRSA
-pki_transport_subject_dn=cn=DRM Transport Certificate,o=%(pki_security_domain_name)s
+pki_transport_subject_dn=cn=DRM Transport Certificate,ou=%(pki_instance_name)s,o=%(pki_sec

Re: [Pki-devel] JSS/NSS

[Christina Fu]

On 08/09/2016 05:34 PM, Christina Fu wrote:



On 08/07/2016 06:17 PM, Fraser Tweedale wrote:

On Fri, Aug 05, 2016 at 10:10:22AM -0700, George Wash wrote:
Are there any plans on the dogtag roadmap to ever migrate away from 
using

JSS/NSS?


Hi George,

I dont't think there are any such plans.  Why do you ask?
Right, there is no such plan to ditch JSS/NSS.  Not sure if this 
information will help, but we are in the early stage of doing upstream 
integration into the Mozilla build.

for JSS, I mean.


Christina



Cheers,
Fraser

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


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


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

[Pki-devel] [PATCH] pki-cfu-0150-Ticket-2428-broken-request-links-for-CA-s-system-cer.patch

[Christina Fu]

Attached please find the patch that fixes the broken link from 
cert->request or just simply visiting request records from agent page on 
CA's system certs.


thanks,

Christina

>From 4f4e08db5034daa63519fa68d766f6d5b37651d6 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@dhcp-16-189.sjc.redhat.com>
Date: Thu, 4 Aug 2016 16:40:06 -0700
Subject: [PATCH] Ticket#2428 broken request links for CA's system certs in
 agent request viewing This patch fixes the issue that when an agent visit one
 of the CA's system cert request records, exception is thrown.

---
 .../src/com/netscape/cms/servlet/profile/ProfileReviewServlet.java| 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileReviewServlet.java b/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileReviewServlet.java
index 3cbf0f96b6ba8e2cac8e967ee796db4df79bc121..dbaf310cf49991d8ab598bedee0ac9e83da2c80f 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileReviewServlet.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/profile/ProfileReviewServlet.java
@@ -425,13 +425,15 @@ public class ProfileReviewServlet extends ProfileServlet {
 defValue = def.getValue(defName, locale, req);
 } catch (EPropertyException ee) {
 CMS.debug("ProfileReviewServlet: " + ee.toString());
+} catch (Exception exp) {
+CMS.debug("ProfileReviewServlet: " + exp.toString());
 }
 
 defset.set(ARG_DEF_ID, defName);
 defset.set(ARG_DEF_SYNTAX, defSyntax);
 defset.set(ARG_DEF_CONSTRAINT, defConstraint);
 defset.set(ARG_DEF_NAME, defValueName);
-defset.set(ARG_DEF_VAL, defValue);
+defset.set(ARG_DEF_VAL, (defValue!=null)? defValue:"");
 deflist.add(defset);
 }
 }
-- 
2.7.4

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

Re: [Pki-devel] [PATCH] Bug 1203407 - tomcatjss: missing ciphers

[Christina Fu]

got verbal ack from Jack.

Pushed to master (the dogtag patch):
commit f0ad71e8a4fbae665a6b4875cce5b82895ad74f0

tomcatjss will be built in the next few days.

Christina


On 06/30/2016 03:04 PM, Christina Fu wrote:

The tomcatjss patch address:
*Bug 1203407* <https://bugzilla.redhat.com/show_bug.cgi?id=1203407> 
-tomcatjss: missing ciphers


2nd patch is the accompanying dogtag change to remove references to 
the unsupported ciphers.  There is no critical dependency of the new 
tomcatjss.


thanks,
Christina


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


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

[Pki-devel] [PATCH] Bug 1203407 - tomcatjss: missing ciphers

[Christina Fu]

The tomcatjss patch address:
*Bug 1203407* <https://bugzilla.redhat.com/show_bug.cgi?id=1203407> 
-tomcatjss: missing ciphers


2nd patch is the accompanying dogtag change to remove references to the 
unsupported ciphers.  There is no critical dependency of the new tomcatjss.


thanks,
Christina
diff -up src/org/apache/tomcat/util/net/jss/JSSSocketFactory.java.cfu src/org/apache/tomcat/util/net/jss/JSSSocketFactory.java
--- src/org/apache/tomcat/util/net/jss/JSSSocketFactory.java.cfu	2016-06-30 15:52:40.536775347 -0600
+++ src/org/apache/tomcat/util/net/jss/JSSSocketFactory.java	2016-06-30 15:54:40.636612569 -0600
@@ -96,8 +96,12 @@ public class JSSSocketFactory implements
 SSLSocket.SSL3_RSA_EXPORT_WITH_DES40_CBC_SHA);
 cipherMap.put("SSL3_RSA_WITH_DES_CBC_SHA",
 SSLSocket.SSL3_RSA_WITH_DES_CBC_SHA);
+
 cipherMap.put("SSL3_RSA_WITH_3DES_EDE_CBC_SHA",
 SSLSocket.SSL3_RSA_WITH_3DES_EDE_CBC_SHA);
+// deprecated SSL3.0 names replaced by IANA-registered TLS names
+cipherMap.put("TLS_RSA_WITH_3DES_EDE_CBC_SHA",
+SSLSocket.SSL3_RSA_WITH_3DES_EDE_CBC_SHA);
 
 cipherMap.put("SSL3_DH_DSS_EXPORT_WITH_DES40_CBC_SHA",
 SSLSocket.SSL3_DH_DSS_EXPORT_WITH_DES40_CBC_SHA);
@@ -116,14 +120,23 @@ public class JSSSocketFactory implements
 SSLSocket.SSL3_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA);
 cipherMap.put("SSL3_DHE_DSS_WITH_DES_CBC_SHA",
 SSLSocket.SSL3_DHE_DSS_WITH_DES_CBC_SHA);
+
 cipherMap.put("SSL3_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
 SSLSocket.SSL3_DHE_DSS_WITH_3DES_EDE_CBC_SHA);
+// deprecated SSL3.0 names replaced by IANA-registered TLS names
+cipherMap.put("TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
+SSLSocket.SSL3_DHE_DSS_WITH_3DES_EDE_CBC_SHA);
+
 cipherMap.put("SSL3_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA",
 SSLSocket.SSL3_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA);
 cipherMap.put("SSL3_DHE_RSA_WITH_DES_CBC_SHA",
 SSLSocket.SSL3_DHE_RSA_WITH_DES_CBC_SHA);
+
 cipherMap.put("SSL3_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
 SSLSocket.SSL3_DHE_RSA_WITH_3DES_EDE_CBC_SHA);
+// deprecated SSL3.0 names replaced by IANA-registered TLS names
+cipherMap.put("TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
+SSLSocket.SSL3_DHE_RSA_WITH_3DES_EDE_CBC_SHA);
 
 cipherMap.put("SSL3_DH_ANON_EXPORT_WITH_RC4_40_MD5",
 SSLSocket.SSL3_DH_ANON_EXPORT_WITH_RC4_40_MD5);
@@ -257,13 +270,21 @@ public class JSSSocketFactory implements
 SSLSocket.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);
 cipherMap.put("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
 SSLSocket.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256);
-cipherMap.put("TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256",
-SSLSocket.TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256);
 cipherMap.put("TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
 SSLSocket.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256);
+/* unsupported by nss
+cipherMap.put("TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256",
+SSLSocket.TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256);
 cipherMap.put("TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
 SSLSocket.TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256);
+*/
 
+cipherMap.put("TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
+SSLSocket.TLS_ECDH_RSA_WITH_AES_256_CBC_SHA);
+cipherMap.put("TLS_ECDH_RSA_WITH_AES_128_CBC_SHA",
+SSLSocket.TLS_ECDH_RSA_WITH_AES_128_CBC_SHA);
+cipherMap.put("TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
+SSLSocket.TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA);
 }
 
 private static HashMap<Integer, String> eccCipherMap = new HashMap<Integer, String>();
@@ -308,6 +329,10 @@ public class JSSSocketFactory implements
 "TLS_ECDH_RSA_WITH_NULL_SHA");
 eccCipherMap.put(SSLSocket.TLS_ECDH_ECDSA_WITH_NULL_SHA,
 "TLS_ECDH_ECDSA_WITH_NULL_SHA");
+/* unsupported by nss
+eccCipherMap.put(SSLSocket.TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
+"TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256");
+*/
 }
 
 private AbstractEndpoint endpoint;
@@ -393,6 +418,7 @@ public class JSSSocketFactory implements
 + ": 0x" + Integer.toHexString(cipherid) + "\n");
 SSLSocket.setCipherPreferenceDefault(cipherid, state);
 } catch (Exception e) {
+System.err.println("SSLSocket.setCipherPreferenceDefault exception:" +e);
 if (eccCipherMap.containsKey(cipherid)) {
 

Re: [Pki-devel] [PATCH] pki-cfu-0144-Ticket-1306-config-params-Add-granularity-to-token-t.patch

[Christina Fu]

got verbal ack from Jack.
Pushed to master:
commit 63a58cf51ef2982e8a35eff1f98dd42453e5681e

thanks,
Christina

On 06/30/2016 02:11 PM, Christina Fu wrote:
This patch is for https://fedorahosted.org/pki/ticket/1306 [RFE] Add 
granularity to token termination in TPS

It
1. adds the missing parameters
2. adds a table for revocation code

thanks,
Christina



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


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

[Pki-devel] [PATCH] pki-cfu-0144-Ticket-1306-config-params-Add-granularity-to-token-t.patch

[Christina Fu]

This patch is for https://fedorahosted.org/pki/ticket/1306 [RFE] Add 
granularity to token termination in TPS

It
1. adds the missing parameters
2. adds a table for revocation code

thanks,
Christina

>From 63a58cf51ef2982e8a35eff1f98dd42453e5681e Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Thu, 30 Jun 2016 14:03:24 -0700
Subject: [PATCH] Ticket #1306 config params: Add granularity to token
 termination in TPS

This patch adds the missing configuration parameters that go with the
original bug.  The code would take on defaults when these parameters are
missing, but putting them in the CS.cfg would make it easier for the
administrators.
---
 base/tps/shared/conf/CS.cfg | 123 ++--
 1 file changed, 119 insertions(+), 4 deletions(-)

diff --git a/base/tps/shared/conf/CS.cfg b/base/tps/shared/conf/CS.cfg
index 258d5a76c5ec8e392634f6075f32ae9baa68b290..4f2b3919cf73610ad1a8c8e8c1baf977fb117f6c 100644
--- a/base/tps/shared/conf/CS.cfg
+++ b/base/tps/shared/conf/CS.cfg
@@ -265,7 +265,20 @@ op.enroll._000=#
 op.enroll._001=# TPS Profiles
 op.enroll._002=#  - Operations
 op.enroll._003=#- operation; enroll,pinReset,format
-op.enroll._004=#
+op.enroll._004=#
+op.enroll._005=# Revocation Reasons (revokeCert.reason) according to RFC 5280
+op.enroll._006=# unspecified (0)
+op.enroll._007=# keyCompromise (1)
+op.enroll._008=# CACompromise (2)
+op.enroll._009=# affiliationChanged (3)
+op.enroll._010=# superseded (4)
+op.enroll._011=# cessationOfOperation (5)
+op.enroll._012=# certificateHold (6)
+op.enroll._013=# removeFromCRL (8)
+op.enroll._014=# privilegeWithdrawn (9)
+op.enroll._015=# AACompromise (10)
+op.enroll._016=#
+op.enroll._017=#
 op.enroll.delegateIEtoken._000=#
 op.enroll.delegateIEtoken._001=# Enrollment for externalReg 
 op.enroll.delegateIEtoken._002=# ID, Encryption
@@ -326,12 +339,23 @@ op.enroll.delegateIEtoken.keyGen.authentication.publicKeyNumber=7
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.destroyed.revokeCert=false
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.destroyed.revokeCert.reason=0
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.destroyed.scheme=GenerateNewKey
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.destroyed.holdRevocationUntilLastCredential=false
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.destroyed.revokeExpiredCerts=false
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.keyCompromise.revokeCert=false
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.keyCompromise.revokeCert.reason=1
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.keyCompromise.scheme=GenerateNewKey
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.keyCompromise.holdRevocationUntilLastCredential=false
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.keyCompromise.revokeExpiredCerts=false
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.terminated.revokeCert=true
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.terminated.revokeCert.reason=1
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.terminated.scheme=GenerateNewKey
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.terminated.holdRevocationUntilLastCredential=false
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.terminated.revokeExpiredCerts=false
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.onHold.revokeCert=false
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.onHold.revokeCert.reason=6
 op.enroll.delegateIEtoken.keyGen.authentication.recovery.onHold.scheme=GenerateNewKey
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.onHold.holdRevocationUntilLastCredential=false
+op.enroll.delegateIEtoken.keyGen.authentication.recovery.onHold.revokeExpiredCerts=false
 op.enroll.delegateIEtoken.keyGen.authentication.serverKeygen.archive=false
 op.enroll.delegateIEtoken.keyGen.authentication.serverKeygen.drm.conn=kra1
 op.enroll.delegateIEtoken.keyGen.authentication.serverKeygen.enable=false
@@ -498,12 +522,23 @@ op.enroll.delegateISEtoken.keyGen.authentication.publicKeyNumber=7
 op.enroll.delegateISEtoken.keyGen.authentication.recovery.destroyed.revokeCert=false
 op.enroll.delegateISEtoken.keyGen.authentication.recovery.destroyed.revokeCert.reason=0
 op.enroll.delegateISEtoken.keyGen.authentication.recovery.destroyed.scheme=GenerateNewKey
+op.enroll.delegateISEtoken.keyGen.authentication.recovery.destroyed.holdRevocationUntilLastCredential=false
+op.enroll.delegateISEtoken.keyGen.authentication.recovery.destroyed.revokeExpiredCerts=false
 op.enroll.delegateISEtoken.keyGen.authentication.recovery.keyCompromise.revokeCert=false
 op.enroll.delegateISEtoken.keyGen.authentication.recovery.keyCompromise.revokeCert

Re: [Pki-devel] [pki-devel] [PATCH] 0074-Add-ability-to-disallow-TPS-to-enroll-a-single-user-.patch

[Christina Fu]

Just a few minor ones.

* configuration parameters referencing token existence in tokendb should 
use names begin with "tokendb".  e.g.

tokendb.allowMultiActiveTokensPerUser.externalReg=false
tokendb.allowMultiActiveTokensPerUser.nonExternalReg=false

* boolean allowMultiCerts  -- I think the name is misleading.  how about 
alowMultiTokens


* existing calls to tps.tdb.tdbHasActiveToken() need to be decided:
 e.g.
   1. TPSEnrollProcessor.java search for tdbHasActiveToken (first 
occurrence) , you will find that it is called with "TODO:" comment. I 
believe that whole try/catch with the tps.tdb.tdbHasActiveToken(userid); 
call can be removed since you already call that earlier in your patch
2. TPSEnrollProcessor.java, the 2nd occurrence is when the 
enrolling token is suspended.  You need to look into what it is doing at 
the point and whether that check can also be eliminated.


thanks,
Christina

On 06/24/2016 11:08 AM, John Magne wrote:

Add ability to disallow TPS to enroll a single user on multiple tokens.
 
 This patch will install a check during the early portion of the enrollment

 process check a configurable policy whether or not a user should be allowed
 to have more that one active token.
 
 This check will take place only for brand new tokens not seen before.

 The check will prevent the enrollment to proceed and will exit before the 
system
 has a chance to add this new token to the TPS tokendb.
 
 The behavior will be configurable for the the external reg and not external reg scenarios

 as follows:
 
 op.enroll.nonExternalReg.allowMultiActiveTokensUser=false

 op.enroll.externalReg.allowMultiActiveTokensUser=false


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


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

Re: [Pki-devel] [PATCH] 779 Fixed problem reading HSM password from password file.

[Christina Fu]

Looks like might do it.  If tested to work (borrow a vm from QE if you 
don't have one), ack.


Christina

On 06/24/2016 03:45 PM, Endi Sukma Dewata wrote:

A new method get_token_password() has been added into PKIInstance
Python class in order to read the token password correctly from
password.conf. If the token is an internal token, it will read the
'internal' password. If it is an HSM it will read the password for
'hardware-'.

The codes that call the get_password() to get token password have
been modified to use get_token_password() instead.

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



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


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

[Pki-devel] [PATCH] pki-cfu-0139-Ticket-2298-Part3-trim-down-debug-log-in-non-TMS-crm.patch

[Christina Fu]

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


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


thanks,
Christina
>From 62d8908d91e74320db647b939c0d9900c09d0608 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 17 Jun 2016 14:48:17 -0700
Subject: [PATCH] Ticket #2298 Part3- trim down debug log in non-TMS crmf
 enrollments

---
 base/ca/shared/conf/CS.cfg |  2 +-
 .../src/com/netscape/kra/EnrollmentService.java|  3 +-
 .../netscape/cms/profile/common/EnrollProfile.java | 16 +++---
 .../com/netscape/cms/servlet/base/CMSServlet.java  |  3 +-
 .../netscape/cms/servlet/cert/CertProcessor.java   | 17 ++
 .../cms/servlet/connector/ConnectorServlet.java|  5 +--
 .../cms/servlet/processors/CAProcessor.java| 37 +++---
 .../src/com/netscape/cmscore/apps/CMSEngine.java   |  4 +--
 .../netscape/cmscore/connector/HttpConnection.java |  6 +++-
 .../cmscore/connector/RequestTransfer.java |  4 +--
 .../com/netscape/cmscore/dbs/DBVirtualList.java|  6 ++--
 11 files changed, 61 insertions(+), 42 deletions(-)

diff --git a/base/ca/shared/conf/CS.cfg b/base/ca/shared/conf/CS.cfg
index 3634ba5b16ca35b0b1482f6d456bad88e18457e3..8f0fb76081fe1edde26b017910b468d82b870283 100644
--- a/base/ca/shared/conf/CS.cfg
+++ b/base/ca/shared/conf/CS.cfg
@@ -995,7 +995,7 @@ profile.caCMCUserCert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/c
 profile.caCrossSignedCACert.class_id=caEnrollImpl
 profile.caCrossSignedCACert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/ca/caCrossSignedCACert.cfg
 profile.caDirBasedDualCert.class_id=caEnrollImpl
-profile.caDirBasedDualCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDirBasedDualCert.cfg
+profile.caDirBasedDualCert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/ca/caDirBasedDualCert.cfg
 profile.caDirPinUserCert.class_id=caEnrollImpl
 profile.caDirPinUserCert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/ca/caDirPinUserCert.cfg
 profile.caDirUserCert.class_id=caEnrollImpl
diff --git a/base/kra/src/com/netscape/kra/EnrollmentService.java b/base/kra/src/com/netscape/kra/EnrollmentService.java
index 35b26a56592cdf0b7b5741f27ad5eb3f83ff01a2..398d1780275f9106271f3c83e958d7e618febaf8 100644
--- a/base/kra/src/com/netscape/kra/EnrollmentService.java
+++ b/base/kra/src/com/netscape/kra/EnrollmentService.java
@@ -175,7 +175,8 @@ public class EnrollmentService implements IService {
 
 String transportCert = request.getExtDataInString(IEnrollProfile.REQUEST_TRANSPORT_CERT);
 if (transportCert != null && transportCert.length() > 0) {
-CMS.debug("EnrollmentService: serviceRequest: transportCert=" + transportCert);
+//CMS.debug("EnrollmentService: serviceRequest: transportCert=" + transportCert);
+CMS.debug("EnrollmentService: serviceRequest: transportCert is in request");
 request.deleteExtData(IEnrollProfile.REQUEST_TRANSPORT_CERT);
 } else {
 CMS.debug("EnrollmentService: serviceRequest: Missing transport certificate");
diff --git a/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java b/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java
index 7d7ce06614d82f2d972c6c83f2e1d0cd11bb1e6b..e828b82f203edfc6e6fb8797c5909c7cdd6a32d9 100644
--- a/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java
+++ b/base/server/cms/src/com/netscape/cms/profile/common/EnrollProfile.java
@@ -378,7 +378,8 @@ public abstract class EnrollProfile extends BasicProfile
 throw new EProfileException(
 CMS.getUserMessage(locale, "CMS_PROFILE_INVALID_REQUEST"));
 }
-CMS.debug("EnrollProfile: Start parseCMC(): " + certreq);
+//CMS.debug("EnrollProfile: Start parseCMC(): " + certreq);
+CMS.debug("EnrollProfile.parseCMC(): start");
 
 TaggedRequest msgs[] = null;
 
@@ -465,6 +466,7 @@ public abstract class EnrollProfile extends BasicProfile
 } else
 return null;
 
+CMS.debug("EnrollProfile.parseCMC: end");
 return msgs;
 } catch (Exception e) {
 CMS.debug("EnrollProfile: Unable to parse CMC request: " + e);
@@ -803,7 +805,7 @@ public abstract class EnrollProfile extends BasicProfile
 throw new EProfileException(
 CMS.getUserMessage(locale, "CMS_PROFILE_INVALID_REQUEST"));
 }
-CMS.debug("EnrollProfile: Start parseCRMF(): " +

Re: [Pki-devel] [PATCH] pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch

[Christina Fu]

received verbal ACK from Endi.

Pushed to master:
commit b4b401589f540b38874680bc313363678d2d8e13

One odd behavior was observed, which I filed a separate bug for:
https://fedorahosted.org/pki/ticket/2354 [TPS] missing activity log 
entries via UI and CLI (while correctly recorded in LDAP)


thanks,
Christina

On 06/06/2016 09:14 AM, Christina Fu wrote:
Hi Endi, first, thanks for the review! Please see my response in-line 
below.


thanks,
Christina

On 06/05/2016 01:39 PM, Endi Sukma Dewata wrote:

On 6/3/2016 7:29 PM, Christina Fu wrote:

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

Ticket #2335 Missing activity logs when formatting/enrolling unknown
token This patch adds activity logs for adding unknown token during
format or enrollment

thanks,
Christina


Some comments:

1. The format, enroll, and pin reset operations now generate an 
additional modify activity log. I think this is unnecessary since 
we're not changing token record's user-editable attributes such as 
user ID and policy. Changing system attributes such as token status 
and key info is part of the operation itself, so it should not 
generate an extra modify log.
my thinking was just to record what happens.  First a token is added, 
then operation (format, enroll, pin_reset) proceed, then if the op 
succeeds, then token status gets modified to formatted, but if it 
failed, the token remains added, but stays at unformatted.
So, in case of failed cases, there is still a record of that the token 
being attempted.


2. Enrolling unknown token fails with this error:

  TPSEnrollProcessor.generateCertsAfterRenewalRecoveryPolicy:No such 
token status for this cuid=...


That's because the new unknown token was added with UNFORMATTED 
status and the above method is expecting a FORMATTED status.
ok, I don't recalling seeing such failure when I tested.  I will look 
into this.


I think to fix this the token record has to be added earlier as 
UNFORMATTED, then the format() will change the status to FORMATTED, 
then the generateCertsAfterRenewalRecoveryPolicy() should work as 
before.


3. Due to issue #2 I was not able to test unknown token enrollment. 
If it works it should generate the add, format, and enroll logs.




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


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

[Pki-devel] [PATCH] pki-cfu-0131-Ticket-2335-Missing-activity-logs-when-formatting-en.patch

[Christina Fu]

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

Ticket #2335 Missing activity logs when formatting/enrolling unknown 
token This patch adds activity logs for adding unknown token during 
format or enrollment


thanks,
Christina
>From 844c5c03d5981f6c881bb82f114c72e335478b44 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 3 Jun 2016 17:26:47 -0700
Subject: [PATCH] Ticket #2335 Missing activity logs when formatting/enrolling
 unknown token This patch adds activity logs for adding unknown token during
 format or enrollment

---
 base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java  | 11 +--
 .../server/tps/processor/TPSEnrollProcessor.java   | 18 ++
 .../server/tps/processor/TPSPinResetProcessor.java |  7 ---
 .../dogtagpki/server/tps/processor/TPSProcessor.java   | 17 ++---
 4 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java b/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java
index ed7e022faf7d85bee8e53ebe37b35a16b713bde5..e9190d09a6fd48e34a15ce761fa0aec201db9c30 100644
--- a/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java
+++ b/base/tps/src/org/dogtagpki/server/tps/TPSTokendb.java
@@ -180,19 +180,18 @@ public class TPSTokendb {
 
 public void tdbUpdateTokenEntry(TokenRecord tokenRecord)
 throws Exception {
+String method = "TPSTokendb.tdbUpdateTokenEntry:";
 String id = tokenRecord.getId();
 TokenRecord existingTokenRecord;
 try {
 existingTokenRecord = tps.tokenDatabase.getRecord(id);
 } catch (EDBRecordNotFoundException e) {
-CMS.debug("TPSTokendb.tdbUpdateTokenEntry: " + e);
-CMS.debug("TPSTokendb.tdbUpdateTokenEntry: Adding token " + id);
-// add and exit
-tdbAddTokenEntry(tokenRecord, TokenStatus.FORMATTED);
-return;
+String logMsg = method + e;
+CMS.debug(logMsg);
+throw new TPSException(logMsg, TPSStatus.STATUS_ERROR_CONTACT_ADMIN);
 }
 // token found; modify
-CMS.debug("TPSTokendb.tdbUpdateTokenEntry: token entry found; Modifying with status: " + tokenRecord.getTokenStatus());
+CMS.debug(method + " token entry found; Modifying with status: " + tokenRecord.getTokenStatus());
 // don't change the create time of an existing token record; put it back
 tokenRecord.setCreateTimestamp(existingTokenRecord.getCreateTimestamp());
 tps.tokenDatabase.updateRecord(id, tokenRecord);
diff --git a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
index 24b2dbf8200ae32dc4627e1fed6e9c5af64b187f..4182cc1c879f69b8200c90586fdd4a13d23ec6c5 100644
--- a/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
+++ b/base/tps/src/org/dogtagpki/server/tps/processor/TPSEnrollProcessor.java
@@ -366,13 +366,14 @@ public class TPSEnrollProcessor extends TPSProcessor {
 
 pkcs11objx.setCUID(appletInfo.getCUID());
 
+logMsg = "add token during enrollment";
 if (!isTokenPresent) {
 try {
-tps.tdb.tdbAddTokenEntry(tokenRecord, TokenStatus.FORMATTED);
+tps.tdb.tdbAddTokenEntry(tokenRecord, TokenStatus.UNFORMATTED);
+tps.tdb.tdbActivity(ActivityDatabase.OP_ADD, tokenRecord, session.getIpAddress(), logMsg, "success");
 } catch (Exception e) {
-String failMsg = "add token failure";
-logMsg = failMsg + ":" + e.toString();
-tps.tdb.tdbActivity(ActivityDatabase.OP_ENROLLMENT, tokenRecord, session.getIpAddress(), logMsg,
+logMsg = logMsg + ":" + e.toString();
+tps.tdb.tdbActivity(ActivityDatabase.OP_ADD, tokenRecord, session.getIpAddress(), logMsg,
 "failure");
 throw new TPSException(logMsg);
 }
@@ -397,6 +398,7 @@ public class TPSEnrollProcessor extends TPSProcessor {
 }
 
 //most failed would have thrown an exception
+logMsg = " generateCertsAfterRenewalRecoveryPolicy returned status=" + status;
 String statusString = "Unknown"; // gives some meaningful debug message
 if (status == TPSStatus.STATUS_NO_ERROR)
 statusString = "Enrollment to follow";
@@ -409,7 +411,6 @@ public class TPSEnrollProcessor extends TPSProcessor {
 renewed = true;
 tps.tdb.tdbActivity(ActivityDatabase.OP_RENEWAL, tokenRecord, session.getIpAddress(), logMsg, "success");
 } else {
-logMsg = " generateCertsAfterRenewalRecoveryPolicy returned status=" + status;
 CMS.debug(method + logMsg);

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

[Christina Fu]

while the patch works, I think the original code logic is somehow flawed 
in a way that it uses the "profile" attribute to determine whether the 
request was non-TMS archival requests, and if null it treats it as TMS.  
It would make better sense if we add a separate case instead of lumping 
the handling of recovery requests inside where the TMS handling is at.


thanks,
Christina

On 06/01/2016 03:13 PM, John Magne wrote:

Show KeyOwner info when viewing recovery requests.
 
 This simple fix will grab the subject info out of the cert

 associated with either pending or complete recovery requests being
 viewed in the KRA UI.
 
 For example:
 
 KeyOwner:  UID=jmagne, O=Token Key User
 
 Will be displayed.

 Have seen this display for both pending and completed recovery requests.

 This simple fix should be good enough for this round, despite the bug
 asking about agent info and such. Those enhancements for later.
 
 Ticket : Ticket #1512 : Key owner info missing from the Search results of Recovery request



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


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

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

[Christina Fu]

The original "Show archival requests" and "Show recovery requests" are 
actually quite misleading, as they do NOT show any archival or recovery 
requests for TMS.

However, for the lack of a better idea, I'll leave them as is.

commit 1c5458150d583481415e2bde4e68d8ab7bbf56d9

thanks,
Christina


On 06/03/2016 10:42 AM, John Magne wrote:

ACK

Does the job with little fuss.

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

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




- Original Message -

From: "Christina Fu" <c...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>
Sent: Friday, June 3, 2016 10:22:07 AM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0129-Ticket-2352-TMS-missing-netkeyKeyRecovery-requests-o.patch

https://fedorahosted.org/pki/ticket/2352
  Ticket #2352 [TMS] missing netkeyKeyRecovery requests option in KRA
agent for "List Request"
  This patch allows KRA agent to list netkeyKeyRecovery requests

thanks,
Christina

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


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

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

[Christina Fu]

https://fedorahosted.org/pki/ticket/1665 Certificate Revocation Reasons 
not being updated in some cases


Ticket 1665 - Cert Revocation
Reasons not being updated when on-hold
This patch fixes the following areas:
* In the CA, when revokeCert is called, make it possible to move 
from on_hold

to revoke.
* In the servlet that handles TPS revoke (DoRevokeTPS), make sure 
it allows

the on_hold cert to be put in the bucket to be revoked.
* there are a few minor fixes such as typos and one have to do with the
populate method in SubjectDNInput.java needs better handling of 
subject in

case it's null.
Note: This patch does not make attempt to allow agents to revoke 
certs that
are on_hold from agent interface.  The search filter needs to be 
modified to

allow that.

thanks,
Christina
>From b3e34f912c7aa5a695710fdbf9ff8faf5f5a47af Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Mon, 23 May 2016 16:22:54 -0700
Subject: [PATCH] Ticket 1665 - Cert Revocation Reasons not being updated when
 on-hold This patch fixes the following areas: * In the CA, when revokeCert is
 called, make it possible to move from on_hold to revoke. * In the servlet
 that handles TPS revoke (DoRevokeTPS), make sure it allows the on_hold cert
 to be put in the bucket to be revoked. * there are a few minor fixes such as
 typos and one have to do with the populate method in SubjectDNInput.java
 needs better handling of subject in case it's null. Note: This patch does not
 make attempt to allow agents to revoke certs that are on_hold from agent
 interface.  The search filter needs to be modified to allow that.

---
 base/ca/src/com/netscape/ca/CAService.java | 17 --
 .../netscape/certsrv/dbs/certdb/ICertRecord.java   |  5 +++
 .../certsrv/dbs/certdb/ICertificateRepository.java |  3 ++
 .../netscape/cms/profile/common/EnrollProfile.java |  4 +--
 .../netscape/cms/profile/input/SubjectDNInput.java |  2 +-
 .../com/netscape/cms/servlet/cert/DoRevokeTPS.java | 12 ---
 .../src/com/netscape/cmscore/dbs/CertRecord.java   | 28 
 .../cmscore/dbs/CertificateRepository.java | 38 ++
 .../src/org/dogtagpki/server/tps/TPSTokendb.java   |  2 ++
 9 files changed, 95 insertions(+), 16 deletions(-)

diff --git a/base/ca/src/com/netscape/ca/CAService.java b/base/ca/src/com/netscape/ca/CAService.java
index 2b5d5f732b36f5cf6e1e5aa54552a5e4dcc5afaa..7fdce06136ba5cd27e65b48aeb3ed3e3cb3566e8 100644
--- a/base/ca/src/com/netscape/ca/CAService.java
+++ b/base/ca/src/com/netscape/ca/CAService.java
@@ -1001,9 +1001,11 @@ public class CAService implements ICAService, IService {
 Date revdate = crlentry.getRevocationDate();
 CRLExtensions crlentryexts = crlentry.getExtensions();
 
+CMS.debug("CAService.revokeCert: revokeCert begins");
 CertRecord certRec = (CertRecord) mCA.getCertificateRepository().readCertificateRecord(serialno);
 
 if (certRec == null) {
+CMS.debug("CAService.revokeCert: cert record not found");
 mCA.log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_CA_CERT_NOT_FOUND", serialno.toString(16)));
 throw new ECAException(
 CMS.getUserMessage("CMS_CA_CANT_FIND_CERT_SERIAL",
@@ -1013,14 +1015,24 @@ public class CAService implements ICAService, IService {
 // allow revoking certs that are on hold.
 String certStatus = certRec.getStatus();
 
-if (certStatus.equals(ICertRecord.STATUS_REVOKED) ||
+if ((certStatus.equals(ICertRecord.STATUS_REVOKED) &&
+!certRec.isCertOnHold()) ||
 certStatus.equals(ICertRecord.STATUS_REVOKED_EXPIRED)) {
+CMS.debug("CAService.revokeCert: cert already revoked:" +
+serialno.toString());
 throw new ECAException(CMS.getUserMessage("CMS_CA_CERT_ALREADY_REVOKED",
 "0x" + Long.toHexString(serialno.longValue(;
 }
 try {
-mCA.getCertificateRepository().markAsRevoked(serialno,
+CMS.debug("CAService.revokeCert: about to call markAsRevoked");
+if (certRec.isCertOnHold()) {
+mCA.getCertificateRepository().markAsRevoked(serialno,
+new RevocationInfo(revdate, crlentryexts), true /*isOnHold*/);
+} else {
+mCA.getCertificateRepository().markAsRevoked(serialno,
 new RevocationInfo(revdate, crlentryexts));
+}
+CMS.debug("CAService.revokeCert: cert revoked");
 mCA.log(ILogger.LL_INFO, CMS.getLogMessage("CMSCORE_CA_CERT_REVOKED",
 serialno.toString(16)));
 // inform all CRLIssuingPoints about revoked certificate
@@ -1052,6 +1064,7 @@ public class CAService implements ICAService, IService {

[Pki-devel] Karma Request for JSS 4.2.6-39 on Fedora 24

[Christina Fu]

The following candidate builds of JSS 4.2.6-39 for Fedora 24 (final) 
consist of the following:
jss-4.2.6-39.fc24 



Please provide Karma for these builds in Bodhi located at:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-d3c8f022c5

Additionally, the following builds have been provided for Fedora 25 
(rawhide):
jss-4.2.6-39.fc25 



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

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

[Christina Fu]

This is the re-review of the patches that addressed my original comments.
Overall I think it's good for this round.  I only have a few comments 
and most have already been communicated to jack.


Conditional ACK upon completion of the following, and of course, tested 
to work:


* Please open the new tickets for tasks you wish to push for later. Feel 
free to combine things in same area into one ticket if it makes sense. 
Please list the ticket(s) at commit response.
* Please write a wrapper function computeKekKey() to call the 
computeSessionKey_SCP01() with null null, so for people who read the 
code it's clear that it's actually getting the kek key handle rather 
than a session key.
* wrapSessionKey() now takes a wrapping key, and if it's null, it takes 
a global transportKey.  Please put this in a top block method comment to 
make it clear what this method does
* you defined cryptogram types (per my earlier comment), but you did not 
replace the 0 and 1 in the calling method.
* the top of method comment convention is usually using /* ...*/ instead 
of a whole bunch of //'s



thanks!
Christina


On 05/17/2016 06:44 PM, John Magne wrote:

Enclosed revised patches:

Thanks to cfu for careful review.

Also enclosed responses to comments ,for convenience.




- Original Message -

From: "Christina Fu" <c...@redhat.com>
To: pki-devel@redhat.com
Sent: Friday, May 13, 2016 11:34:17 AM
Subject: Re: [Pki-devel] [pki-devel][PATCH] 
0064-Port-symkey-JNI-to-Java-classes.patch

Hi,
First of all, I have to say that Jack did a wonderful job on such daunting
task. The sheer amount of code and complexity does make the review more
challenging, but I dug through them with my teeth and claws regardless ;-).

We discussed and think we should postpone the checkin to next release so we
can make sure it gets the kind of attention in details that it deserves.

For the first round of reviews, I sent him two separate sets of review
comments last week. One for JSS, and one for the rest.
The JSS patch was not attached to his original email request for review. It
is attached to the following ticket:
https://fedorahosted.org/pki/ticket/801

You can find my review comments attached to this email.

thanks,
Christina

On 04/15/2016 07:03 PM, John Magne wrote:



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

What is supported:

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

Requires:

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

Still to do:

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


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


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


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

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

[Christina Fu]

Adopted comment and checked in:
commit dc13bd1a2366c71880a59586ebe70f40683afa3c

thanks!
Christina

On 05/17/2016 06:25 PM, John Magne wrote:


Looks good.

If tested to work conditional ACK.

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

- Original Message -

From: "Christina Fu" <c...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>
Sent: Tuesday, May 17, 2016 6:13:01 PM
Subject: [Pki-devel] [PATCH] 
pki-cfu-0122-Ticket-1527-reopened-retrieved-wrong-ca-connector-co.patch

Ticket #1527 (reopened) retrieved wrong ca connector config parameter
  This ticket was reopened due to retrieving wrong ca connector
config param under the situation when format is performed during enrollment.
  The following is attempted:
  op.enroll.userKey.ca.conn
  while the following is intended:
  op.format.userKey.ca.conn
  In addition, this patch also fixes the following issues;
  a. reason param name is not conforming: "reason" instead of
"revokeReason"
  b. adding default reason to format TPS profiles
  c. by default mappingResolver.formatProfileMappingResolver resolves
 to tokenKey, while enroll resolves to userKey.
 -> now changed the userKey
  d. if revocation fails during format, it was forgiving.
 -> now changed so that error is logged in activity log and exception
thrown and bail out

Tested to work.

thanks,
Christina

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


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

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

[Christina Fu]

Ticket #1527 (reopened) retrieved wrong ca connector config parameter
This ticket was reopened due to retrieving wrong ca connector 
config param under the situation when format is performed during enrollment.

The following is attempted:
op.enroll.userKey.ca.conn
while the following is intended:
op.format.userKey.ca.conn
In addition, this patch also fixes the following issues;
a. reason param name is not conforming: "reason" instead of 
"revokeReason"

b. adding default reason to format TPS profiles
c. by default mappingResolver.formatProfileMappingResolver resolves
   to tokenKey, while enroll resolves to userKey.
   -> now changed the userKey
d. if revocation fails during format, it was forgiving.
   -> now changed so that error is logged in activity log and exception
  thrown and bail out

Tested to work.

thanks,
Christina
>From 81a475e7a8fe0ff086047bf3295abea253a7e394 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Tue, 17 May 2016 17:57:11 -0700
Subject: [PATCH] Ticket #1527 (reopened) retrieved wrong ca connector config
 parameter This ticket was reopened due to retrieving wrong ca connector
 config param. The following is attempted: op.enroll.userKey.ca.conn while the
 following is intended: op.format.userKey.ca.conn In addition, this patch also
 fixes the following issues; a. reason param name is not conforming: "reason"
 instead of "revokeReason" b. adding default reason to format TPS profiles c.
 by default mappingResolver.formatProfileMappingResolver resolvesto
 tokenKey, while enroll resolves to userKey.-> now changed the userKey d.
 if revocation fails during format, it was forgiving.-> now changed so
 that error is logged in activity log and exception   thrown and bail out

---
 base/tps/shared/conf/CS.cfg| 12 +++-
 .../org/dogtagpki/server/tps/processor/TPSProcessor.java   | 14 --
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/base/tps/shared/conf/CS.cfg b/base/tps/shared/conf/CS.cfg
index 638787d225ca819f051ad999ca92c75c9d51cb88..90d1747dd4617b097e11207f8c10e0bbd8c5ccee 100644
--- a/base/tps/shared/conf/CS.cfg
+++ b/base/tps/shared/conf/CS.cfg
@@ -428,6 +428,7 @@ op.format.delegateIEtoken.issuerinfo.enable=true
 op.format.delegateIEtoken.issuerinfo.value=http://[PKI_HOSTNAME]:[PKI_UNSECURE_PORT]/tps/phoneHome
 op.format.delegateIEtoken.loginRequest.enable=true
 op.format.delegateIEtoken.revokeCert=false
+op.format.delegateIEtoken.revokeCert.reason=0
 op.format.delegateIEtoken.tks.conn=tks1
 op.format.delegateIEtoken.update.applet.directory=/usr/share/pki/tps/applets
 op.format.delegateIEtoken.update.applet.emptyToken.enable=true
@@ -686,6 +687,7 @@ op.format.delegateISEtoken.issuerinfo.enable=true
 op.format.delegateISEtoken.issuerinfo.value=http://[PKI_HOSTNAME]:[PKI_UNSECURE_PORT]/tps/phoneHome
 op.format.delegateISEtoken.loginRequest.enable=true
 op.format.delegateISEtoken.revokeCert=false
+op.format.delegateISEtoken.revokeCert.reason=0
 op.format.delegateISEtoken.tks.conn=tks1
 op.format.delegateISEtoken.update.applet.directory=/usr/share/pki/tps/applets
 op.format.delegateISEtoken.update.applet.emptyToken.enable=true
@@ -770,6 +772,7 @@ op.format.externalRegAddToToken.update.applet.requiredVersion=1.4.54de790f
 op.format.externalRegAddToToken.update.symmetricKeys.enable=false
 op.format.externalRegAddToToken.update.symmetricKeys.requiredVersion=1
 op.format.externalRegAddToToken.revokeCert=false
+op.format.externalRegAddToToken.revokeCert.reason=0
 op.enroll.allowUnknownToken=true
 op.enroll.mappingResolver=enrollProfileMappingResolver
 op.enroll.soKey.cuidMustMatchKDD=false
@@ -1392,6 +1395,7 @@ op.format.cleanToken.issuerinfo.enable=true
 op.format.cleanToken.issuerinfo.value=
 op.format.cleanToken.loginRequest.enable=true
 op.format.cleanToken.revokeCert=true
+op.format.cleanToken.revokeCert.reason=0
 op.format.cleanToken.tks.conn=tks1
 op.format.cleanToken.update.applet.directory=[TPS_DIR]/applets
 op.format.cleanToken.update.applet.emptyToken.enable=true
@@ -1413,6 +1417,7 @@ op.format.soCleanSOToken.issuerinfo.enable=true
 op.format.soCleanSOToken.issuerinfo.value=
 op.format.soCleanSOToken.loginRequest.enable=false
 op.format.soCleanSOToken.revokeCert=true
+op.format.soCleanSOToken.revokeCert.reason=0
 op.format.soCleanSOToken.tks.conn=tks1
 op.format.soCleanSOToken.update.applet.directory=[TPS_DIR]/applets
 op.format.soCleanSOToken.update.applet.emptyToken.enable=true
@@ -1434,6 +1439,7 @@ op.format.soCleanUserToken.issuerinfo.enable=true
 op.format.soCleanUserToken.issuerinfo.value=
 op.format.soCleanUserToken.loginRequest.enable=false
 op.format.soCleanUserToken.revokeCert=true
+op.format.soCleanUserToken.revokeCert.reason=0
 op.format.soCleanUserToken.tks.conn=tks1
 op.format.soCleanUserToken.update.applet.directory=[TPS_DIR]/applets
 op

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

[Christina Fu]

Hi,
First of all, I have to say that Jack did a wonderful job on such 
daunting task.  The sheer amount of code and complexity does make the 
review more challenging, but I dug through them with my teeth and claws 
regardless ;-).


We discussed and think we should postpone the checkin to next release so 
we can make sure it gets the kind of attention in details that it deserves.


For the first round of reviews, I sent him two separate sets of review 
comments last week.  One for JSS, and one for the rest.
The JSS patch was not attached to his original email request for 
review.  It is attached to the following ticket:

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

You can find my review comments attached to this email.

thanks,
Christina

On 04/15/2016 07:03 PM, John Magne wrote:

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

What is supported:

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

Requires:

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

Still to do:

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


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


--- Begin Message ---

Sending this out to you just to get it off my back...
this is just the JSS part.

Some of these already communicated to you.  I'm just listing them out to 
track for the re-review.


==

JSS
*PK11KeyWrapper.java
  - The original unwrapSymmetric) assumes temporary true, and you want 
to have a function that treats it as false.
  You made a copy of the original and named it unwrapSymmetricPerm() 
and set the temporary to false.
  -  I think it'd be better if you just add a "temporary" param to the 
original function, and add the function with original signature to call 
into the one with temporary true;  Then you call into the new signature 
with temporary false (instead of adding this extra unwrapSymmetricPerm()


* Java_org_mozilla_jss_pkcs11_PK11Store_putSymKeysInVector
This function gets a list of sym keys from a token and put them into a 
vector.  It seems more appropriate to be called
getSymKeysInVector()  ("put" made me think initially that you are 
putting keys into the token)


* PK11SymKey.c: JSS_PK11_wrapSymKey
 - Are we sure that all sym keys have nicknames?
   Should we maintain the original "no nickname" code path by checking 
if nickname is null and call original calls?


* in Java_org_mozilla_jss_pkcs11_PK11SymKey_setNickNameNative
 /* name the key */
status = PK11_SetSymKeyNickname( key, keyname );
if( status != SECSuccess ) {
JSS_throwMsgPrErr(env, TOKEN_EXCEPTION,
"Failed to name symmetric key");
 - is there not an error code that you can get and throw back to make 
it more useful?
 I noticed this applies to many other areas as well.  it's a good idea 
to get errorcode to throw back


* setNickName
 - you might want to check if nickname is null before passing it down to C

* might want to check if new JSS files created should bear the same 
Netscape etc. license


*PK11SymmetricKeyDeriver.c :  bestSlot = 
PK11_GetBestSlot(deriveMechanism, NULL);
 should test it out on hsm (already communicated to jack... item here 
to track)
  - suggest if issues found, revert to old code (or code similar to old 
code) and create a separate ticket to tackle

  - new code should test to work on both nethsm and lunasa

* the test SymKeyDeriving seems to fail at NSS init (Jack found the hard 
coded lib):  tracking here
--- End Message ---
--- Begin Message ---


=
SecureChannelProtocol.java

** diversifyKey()
  - I don't see KDD being checked for null when conext is being 
assigned to it.
  - in the 3 calls you made to standardKDF.getDiversificationData(), 
first param you passed in is "KDD". Could you mean "context"? because
   if nistSP800_108KdfUseCuidAsKdd is true, then your KDD is most 
likely null, isn't it?

 - I got so confused with these standardKDF.getDiversificationData() calls.
   reason being that the getDiversificationData() is really not 
specific to "standardKDF".  It is used and used if you choose 
NistSP800_108KDF too!!!
   How about moving the getDiversificationData() method to the base KDF 
class instead?


*computeSessionKey_SCP02()
note yet implemented, but your debug log says it's SCP01.

**computeMAC_SCP01()
 - are you sure the cipher needs to be initialized inside the loop 
instead of before the loop?

cipher.initEncrypt(symKey);
  - also, oddly, I don't see any 

[Pki-devel] 0119-Ticket-2303-Key-recovery-fails-with-KRA-on-lunaSA.patch

[Christina Fu]

One patch for JSS
one patch for KRA
These patches should address the KRA unwrap issues when the keys are on 
lunaSA.


the KRA patch will required the JSS patch to function.
It is also required for the lunaSA to be of the following model: CKE – 
Key Export Models


Christina
diff -up jss-4.2.6/mozilla/security/jss/org/mozilla/jss/pkcs11/PK11KeyWrapper.c.cfu jss-4.2.6/mozilla/security/jss/org/mozilla/jss/pkcs11/PK11KeyWrapper.c
--- jss-4.2.6/mozilla/security/jss/org/mozilla/jss/pkcs11/PK11KeyWrapper.c.cfu	2016-04-28 16:50:06.0 -0700
+++ jss-4.2.6/mozilla/security/jss/org/mozilla/jss/pkcs11/PK11KeyWrapper.c	2016-04-28 16:50:00.0 -0700
@@ -434,7 +434,7 @@ Java_org_mozilla_jss_pkcs11_PK11KeyWrapp
 isSensitive = PR_FALSE;
 isExtractable = PR_FALSE;
 } else if ( isLunasa) {
-isSensitive = PR_FALSE;
+isSensitive = PR_TRUE;
 isExtractable = PR_TRUE;
 }
 
>From faadd5d9635fcf2c5ab2e02cc09a3f1caca1e0ad Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Fri, 6 May 2016 10:40:55 -0700
Subject: [PATCH] =?UTF-8?q?Ticket=20#2303=20Key=20recovery=20fails=20with?=
 =?UTF-8?q?=20KRA=20on=20lunaSA=20=20This=20patch=20requires=20JSS=20with?=
 =?UTF-8?q?=20the=20jss-lunasaUnwrap.patch=20to=20work=20properly=20on=20t?=
 =?UTF-8?q?he=20lunaSA.=20=20It=20is=20also=20required=20for=20the=20lunaS?=
 =?UTF-8?q?A=20to=20be=20of=20the=20following=20model:=20=20CKE=20?=
 =?UTF-8?q?=E2=80=93=20Key=20Export=20Models?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 base/kra/src/com/netscape/kra/TokenKeyRecoveryService.java | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/base/kra/src/com/netscape/kra/TokenKeyRecoveryService.java b/base/kra/src/com/netscape/kra/TokenKeyRecoveryService.java
index a976169e3f0db92df1a1f3f633a1960a52bc0984..ef141dc66b6ef3a9d1de1c92af996f7694069c54 100644
--- a/base/kra/src/com/netscape/kra/TokenKeyRecoveryService.java
+++ b/base/kra/src/com/netscape/kra/TokenKeyRecoveryService.java
@@ -264,7 +264,7 @@ public class TokenKeyRecoveryService implements IService {
 (wrapped_des_key.length > 0)) {
 
 // unwrap the des key
-sk = (PK11SymKey) mTransportUnit.unwrap_encrypt_sym(wrapped_des_key);
+sk = (PK11SymKey) mTransportUnit.unwrap_sym(wrapped_des_key);
 
 if (sk == null) {
 CMS.debug("TokenKeyRecoveryService: no des key");
@@ -516,6 +516,7 @@ public class TokenKeyRecoveryService implements IService {
 return false;
 }
 
+CMS.debug("TokenKeyRecoveryService: about to wrap...");
 KeyWrapper wrapper = token.getKeyWrapper(
 KeyWrapAlgorithm.DES3_CBC_PAD);
 
@@ -688,6 +689,7 @@ public class TokenKeyRecoveryService implements IService {
 CMS.debug( "TokenKeyRecoveryService: recoverKey() - recovery failure");
 throw new EKRAException(CMS.getUserMessage("CMS_KRA_RECOVERY_FAILED_1", "private key recovery/unwrapping failure"));
 }
+CMS.debug( "TokenKeyRecoveryService: recoverKey() - recovery completed, returning privKey");
 return privKey;
 
 } catch (Exception e) {
-- 
2.4.3

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

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

[Christina Fu]

ACK

On 04/27/2016 01:59 PM, John Magne wrote:

TPS auth special characters fix.
 
 Ticket #1636.

 Smartcard token enroll/format fails when the ldap user has special 
characters in userid or password
 
 Tested with both esc and tpsclient. The problem was when using a real card because the client uri encodes

 the authentication creds and the server needs to decode them.


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


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

Re: [Pki-devel] Dogtags Website Down (Help!)

[Christina Fu]

Also, Mike, it might be a good idea to subscribe to the mailing lists.

Christina

On 04/12/2016 09:30 AM, Christina Fu wrote:

Hi Mike,
It appears that they are still working on it.  Is there anything 
specific that you are looking for?


About whether there are any other resources, I just googled and found 
some Youtube on how to install a Dogtag CA
And here is some guy's link: 
https://joejulian.name/blog/setting-up-dogtag-pki-ca-certificate-manager/
Disclaimer:  I cannot vouch for the validity of any of those 
information, so please use them at your own risk.


Not sure if this helps, but if you want to play with the code...

Here is how to check out the source:
git clone git://git.fedorahosted.org/git/pki.git

Here is how you can create your own branch to work on:
 git checkout -b myBranch

Under pki/scripts you will find various scripts for compilation.

Christina

On 04/12/2016 08:38 AM, Michael Morelli wrote:

Hi everyone,

It appears the Dogtags PKI website is still down. Can anyone please 
help to restore it? We need it for university project. If not, are 
there any other resources we can use in the interim ?


-Mike

On Fri, Apr 8, 2016 at 1:57 PM, Matthew Harmsen <mharm...@redhat.com 
<mailto:mharm...@redhat.com>> wrote:


On 04/08/2016 11:44 AM, MICHAEL JOHN MORELLI wrote:

It appears that http://dogtagpki.org/ is down. Can someone
please help restore it? We are setting this up for a class project

-Mike

Sincerely,

Michael J. Morelli
Pennsylvania State University
mj...@psu.edu <mailto:mj...@psu.edu>
Mobile 814.769.3971 




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

Mike,

Please try again --- it appears to be back up at this time.

-- Matt




--
Sincerely,

Michael J. Morelli
Pennsylvania State University
mj...@psu.edu
Mobile 814.769.3971


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




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


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

Re: [Pki-devel] Dogtags Website Down (Help!)

[Christina Fu]

Hi Mike,
It appears that they are still working on it.  Is there anything 
specific that you are looking for?


About whether there are any other resources, I just googled and found 
some Youtube on how to install a Dogtag CA
And here is some guy's link: 
https://joejulian.name/blog/setting-up-dogtag-pki-ca-certificate-manager/
Disclaimer:  I cannot vouch for the validity of any of those 
information, so please use them at your own risk.


Not sure if this helps, but if you want to play with the code...

Here is how to check out the source:
git clone git://git.fedorahosted.org/git/pki.git

Here is how you can create your own branch to work on:
 git checkout -b myBranch

Under pki/scripts you will find various scripts for compilation.

Christina

On 04/12/2016 08:38 AM, Michael Morelli wrote:

Hi everyone,

It appears the Dogtags PKI website is still down. Can anyone please 
help to restore it? We need it for university project. If not, are 
there any other resources we can use in the interim ?


-Mike

On Fri, Apr 8, 2016 at 1:57 PM, Matthew Harmsen > wrote:


On 04/08/2016 11:44 AM, MICHAEL JOHN MORELLI wrote:

It appears that http://dogtagpki.org/ is down. Can someone please
help restore it? We are setting this up for a class project

-Mike

Sincerely,

Michael J. Morelli
Pennsylvania State University
mj...@psu.edu 
Mobile 814.769.3971 




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

Mike,

Please try again --- it appears to be back up at this time.

-- Matt




--
Sincerely,

Michael J. Morelli
Pennsylvania State University
mj...@psu.edu 
Mobile 814.769.3971


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


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

Re: [Pki-devel] Trouble enrolling with SSCEP

[Christina Fu]

Hi Hayg,
Good to hear.  To answer your previous question, caRouterCert.cfg is the 
default sscep enrollment profile.  You can see the authentication by 
default using flatfile:

auth.instance_id=flatFileAuth
Earlier, I misunderstood you for removing that and rendering a manual 
approval.


Christina

On 04/11/2016 05:14 AM, haygastour...@gmail.com wrote:

Hi Christina,

I got this to work with sscep. It seems the IP in my flatfile was 
wrong. I think the main issue is the lack of a clear error message.


Thanks for your help,
Hayg

On Mon, Apr 11, 2016 at 10:54 AM, haygastour...@gmail.com 
<mailto:haygastour...@gmail.com> <haygastour...@gmail.com 
<mailto:haygastour...@gmail.com>> wrote:


Hi Christina,

Thank you for your help.

I think using SCEP there is no enrollment profile that I touch? I
thought setting up the flatfile.txt with the relevant values and
modifying the config to enable SCEP was all that I needed to do.
My intention was for it to be *automatically* approved because of
the IP/password being present in flatfile.txt

Does that help? Sorry if I'm misunderstanding your questions.

Thanks,
Hayg

On Fri, Apr 8, 2016 at 9:58 PM, Christina Fu <c...@redhat.com
<mailto:c...@redhat.com>> wrote:

Hi Hayg,

I am running Fedora 22 so I'm not sure if there is any
difference at all.

I would like to understand your issue(s) better.
When you said that your request failed because it was "getting
deferred", does that mean you have it in the enrollment
profile for manual approval?  In other words, it was your
intention to have the request manually approved by the CA agents?
You realize that if you require manual agent approval, there
is no option for sscep to "fetch" the already issued cert right?

Or, did you not intend to have the request deferred and
failed?  In which case, you want to know why it failed?  If
so, do you have relevant debug log to give us some clue?

Did I misunderstand your issue?

Christina


On 04/05/2016 02:57 AM, haygastour...@gmail.com
<mailto:haygastour...@gmail.com> wrote:

Hello everyone,

I've been trying to enroll with dogtag via SSCEP for the last
few days to no avail and I've reached the end of my rope, so
I'm reaching out for your help (which I very much would
appreciate).

I am running Ubuntu and my dogtag versions are:
hayg@hayg:~$ dpkg -l | grep dogtag

ii  dogtag-pki   10.2.6-1  all  Dogtag Public
Key Infrastructure (PKI) Suite
ii  dogtag-pki-console-theme 10.2.6-1all
 Certificate System - PKI Console User Interface
ii  dogtag-pki-server-theme  10.2.6-1  all  
   Certificate System - PKI Server User Interface


My SSCEP:
[~/sscep]$ cat VERSION

0.6.1


My flatfile.txt:
hayg@hayg:~$ sudo cat
/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt

#UID:172.16.24.238
#PWD:1212
UID:10.129.25.186
PWD:secret

(I restarted my pki-tomcatd service just in case, to make
sure it took effect)

On the SSCEP side I'm doing: ./sscep enroll -l cert.pem -r
local.csr -k local.key -c astourian.crt -u
'http://hayg.astourian.info:8080/ca/cgi-bin/pkiclient.exe'
<http://hayg.astourian.info:8080/ca/cgi-bin/pkiclient.exe%27>

This fails because the request is getting deferred and I have
fail on defer set to true, per the docs.

The request actually shows up in 'List Certificates' when I
go to the web UI, but when I try to approve it, I get:

The Certificate System has encountered an unrecoverable
error.
Error Message:
/java.lang.NullPointerException
/Please contact your local administrator for assistance.

When I try to resume the enrollment by adding the -R flag to
sscep it fails with the following error in the logs:

CRSEnrollment: No certificate has been found


My CSR:
[~/sscep]$ openssl req -in local.csr -noout -text

Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=10.129.25.186
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:ab:f4:b7:55:bd:26:51:b7:65:b9:51:4e:08:31:
83:ef:d6:b7:97:cc:cb:82:4b:a6:3f:be:ac:1c:9a:
f5:1e:0d:56:7c:6a:be:d3:49:17:b6:ba:42:05:eb:
6c:e2:ff:2b:0f:64:d5:ae:e8:5b:6c:f8:df:74:ef:
1f:a1:94:50:4c:35:90:bc:0

Re: [Pki-devel] Trouble enrolling with SSCEP

[Christina Fu]

Hi Hayg,

I am running Fedora 22 so I'm not sure if there is any difference at all.

I would like to understand your issue(s) better.
When you said that your request failed because it was "getting 
deferred", does that mean you have it in the enrollment profile for 
manual approval?  In other words, it was your intention to have the 
request manually approved by the CA agents?
You realize that if you require manual agent approval, there is no 
option for sscep to "fetch" the already issued cert right?


Or, did you not intend to have the request deferred and failed?  In 
which case, you want to know why it failed?  If so, do you have relevant 
debug log to give us some clue?


Did I misunderstand your issue?

Christina

On 04/05/2016 02:57 AM, haygastour...@gmail.com wrote:

Hello everyone,

I've been trying to enroll with dogtag via SSCEP for the last few days 
to no avail and I've reached the end of my rope, so I'm reaching out 
for your help (which I very much would appreciate).


I am running Ubuntu and my dogtag versions are:
hayg@hayg:~$ dpkg -l | grep dogtag

ii  dogtag-pki   10.2.6-1
 all  Dogtag Public Key Infrastructure (PKI) Suite
ii  dogtag-pki-console-theme 10.2.6-1
 all  Certificate System - PKI Console User Interface
ii  dogtag-pki-server-theme  10.2.6-1
 all  Certificate System - PKI Server User Interface


My SSCEP:
[~/sscep]$ cat VERSION

0.6.1


My flatfile.txt:
hayg@hayg:~$ sudo cat /var/lib/pki/pki-tomcat/conf/ca/flatfile.txt

#UID:172.16.24.238
#PWD:1212
UID:10.129.25.186
PWD:secret

(I restarted my pki-tomcatd service just in case, to make sure it took 
effect)


On the SSCEP side I'm doing: ./sscep enroll -l cert.pem -r local.csr 
-k local.key -c astourian.crt -u 
'http://hayg.astourian.info:8080/ca/cgi-bin/pkiclient.exe' 



This fails because the request is getting deferred and I have fail on 
defer set to true, per the docs.


The request actually shows up in 'List Certificates' when I go to the 
web UI, but when I try to approve it, I get:


The Certificate System has encountered an unrecoverable error.
Error Message:
/java.lang.NullPointerException
/Please contact your local administrator for assistance.

When I try to resume the enrollment by adding the -R flag to sscep it 
fails with the following error in the logs:


CRSEnrollment: No certificate has been found


My CSR:
[~/sscep]$ openssl req -in local.csr -noout -text

Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=10.129.25.186
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:ab:f4:b7:55:bd:26:51:b7:65:b9:51:4e:08:31:
83:ef:d6:b7:97:cc:cb:82:4b:a6:3f:be:ac:1c:9a:
f5:1e:0d:56:7c:6a:be:d3:49:17:b6:ba:42:05:eb:
6c:e2:ff:2b:0f:64:d5:ae:e8:5b:6c:f8:df:74:ef:
1f:a1:94:50:4c:35:90:bc:02:2b:2a:e3:80:b6:e1:
75:a0:34:4d:74:0b:47:2c:f5:2d:87:2a:72:4a:93:
5b:76:a8:cc:96:56:0b:de:62:69:1e:37:30:eb:49:
4a:0a:8c:55:c4:0e:a7:9d:95:88:2d:ed:15:19:c6:
19:93:02:84:40:09:40:44:b1
Exponent: 65537 (0x10001)
Attributes:
challengePassword:secret
Requested Extensions:
X509v3 Subject Alternative Name: critical
IP Address:10.129.25.186
Signature Algorithm: sha1WithRSAEncryption
 7e:85:96:60:54:ed:c7:fd:d4:9d:b9:48:4c:d6:5a:2d:b1:62:
 8f:26:58:04:da:f2:6d:cf:c7:59:dc:b5:b2:a9:69:8d:e0:df:
 4d:26:7b:51:3e:d5:f4:90:21:d9:20:69:6f:6f:e1:58:28:90:
 05:a7:38:1b:04:05:e6:84:03:78:95:90:d6:da:0c:56:c1:e9:
 16:d4:01:15:c5:5e:06:3f:44:48:6e:e5:dd:f6:dc:62:0a:f9:
 af:e7:c5:3d:0a:86:b1:99:40:90:ff:30:02:92:91:fb:dd:50:
 f0:df:bf:73:96:6f:04:3e:73:66:02:86:66:a0:00:fa:a7:58:
 ea:ae 



As you can see, the password is "secret" and the CN is the UID from 
flatfile.txt.


I welcome you all to try enrolling with my server. I can then try 
approving and see if it works.


Again, I very much appreciate all of your help. Please excuse my wall 
of text x_x


Thanks,
Hayg


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


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

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

[Christina Fu]

pushed to master
commit ca8febca42bdb278d5fbfc641333c4bd1fe7a9be

thanks,
Christina

On 04/05/2016 06:05 PM, John Magne wrote:

ACK:

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

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

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

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

thanks,
Christina

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


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

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

[Christina Fu]

Attached please find the patch for ticket 1006:
https://fedorahosted.org/pki/ticket/1006 Audit logging for TPS REST 
operations


Most of the work is on
1. finding the right places to place the audit calls
2. deciding on what should be audited: since all read operations are 
captured by AUTZ, the REST operations audited are only write operations

3. deciding on the audit events that should be provided for the operations
4. making needed information available at the places where auditing is 
happening


thanks
Christina
From b739dd8935499e833655be5d05a8002df07cc8e9 Mon Sep 17 00:00:00 2001
From: Christina Fu <c...@redhat.com>
Date: Thu, 24 Mar 2016 16:23:05 -0700
Subject: [PATCH] Ticket #1006 Audit logging for TPS REST operations

---
 .../src/com/netscape/certsrv/logging/IAuditor.java |   3 +-
 .../com/netscape/cms/servlet/base/PKIService.java  |  15 ++
 .../org/dogtagpki/server/rest/AuditService.java| 117 ++--
 base/server/cmsbundle/src/LogMessages.properties   |  55 +++-
 .../src/com/netscape/cmscore/logging/Auditor.java  |  19 +-
 base/tps/shared/conf/CS.cfg.in |   4 +-
 .../dogtagpki/server/tps/config/ConfigService.java |  30 ++-
 .../server/tps/rest/AuthenticatorService.java  | 187 ++---
 .../server/tps/rest/ConnectorService.java  | 180 ++---
 .../server/tps/rest/ProfileMappingService.java | 157 +--
 .../dogtagpki/server/tps/rest/ProfileService.java  | 171 ++--
 .../dogtagpki/server/tps/rest/TokenService.java| 297 +
 12 files changed, 1028 insertions(+), 207 deletions(-)

diff --git a/base/common/src/com/netscape/certsrv/logging/IAuditor.java b/base/common/src/com/netscape/certsrv/logging/IAuditor.java
index a9362259633e29d33f5ae8fc3efc86628c9ebe35..89c03b838ca2e546224bfd2b3785c6684b59aeed 100644
--- a/base/common/src/com/netscape/certsrv/logging/IAuditor.java
+++ b/base/common/src/com/netscape/certsrv/logging/IAuditor.java
@@ -70,9 +70,10 @@ public interface IAuditor {
  * @return a delimited string of one or more delimited name/value pairs
  */
 public String getParamString(String scope, String type, String id, Map<String, String> params);
+public String getParamString(StringBuilder paramsters, Map<String, String> params);
 
 /**
  * Log audit message.
  */
 public void log(String message);
-}
\ No newline at end of file
+}
diff --git a/base/server/cms/src/com/netscape/cms/servlet/base/PKIService.java b/base/server/cms/src/com/netscape/cms/servlet/base/PKIService.java
index d2e55b5a3c42ee89f5784da12de860fd4e8880bf..7ed9c0dc86b08add5066a9c6df29ce791775e54e 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/base/PKIService.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/base/PKIService.java
@@ -259,6 +259,21 @@ public class PKIService {
 auditor.log(auditMessage);
 }
 
+public void auditConfigTokenGeneral(String status, String service, Map<String, String> params, String info) {
+CMS.debug("PKIService.auditConfigTokenGeneral begins");
+
+String msg = CMS.getLogMessage(
+"LOGGING_SIGNED_AUDIT_CONFIG_TOKEN_GENERAL_5",
+servletRequest.getUserPrincipal().getName(),
+status,
+service,
+auditor.getParamString(null, params),
+info);
+auditor.log(msg);
+
+CMS.debug("PKIService.auditConfigTokenGeneral ends");
+}
+
 /**
  * Get the values of the fields annotated with @FormParam.
  */
diff --git a/base/server/cms/src/org/dogtagpki/server/rest/AuditService.java b/base/server/cms/src/org/dogtagpki/server/rest/AuditService.java
index e32c36c3313e8bbb3ea729245dcd51d5f2fda7a7..273625e81776ab8a8cd024f503f5e45ade94612a 100644
--- a/base/server/cms/src/org/dogtagpki/server/rest/AuditService.java
+++ b/base/server/cms/src/org/dogtagpki/server/rest/AuditService.java
@@ -21,6 +21,7 @@ package org.dogtagpki.server.rest;
 import java.io.UnsupportedEncodingException;
 import java.net.URI;
 import java.util.Collection;
+import java.util.HashMap;
 import java.util.Map;
 import java.util.TreeMap;
 import java.util.TreeSet;
@@ -42,6 +43,7 @@ import com.netscape.certsrv.base.IConfigStore;
 import com.netscape.certsrv.base.PKIException;
 import com.netscape.certsrv.logging.AuditConfig;
 import com.netscape.certsrv.logging.AuditResource;
+import com.netscape.certsrv.logging.ILogger;
 import com.netscape.cms.servlet.base.PKIService;
 
 /**
@@ -66,29 +68,62 @@ public class AuditService extends PKIService implements AuditResource {
 }
 
 public AuditConfig createAuditConfig() throws UnsupportedEncodingException, EBaseException {
+return createAuditConfig(null);
+}
+
+public AuditConfig createAuditConfig(Map<String, String> auditParams)
+throws UnsupportedEncodingException, EBaseException {
 
 IConfigStore cs = CMS.getConfigS

Re: [Pki-devel] [PATCH] pki-cfu-0115-Ticket-1007-TPS-audit.patch

[Christina Fu]

pushed to master:
commit 4e948d6ab69f19f5ee705ca168e7813c14d36f10

thanks,
Christina

On 02/15/2016 02:58 PM, John Magne wrote:

Looks solid:

Conditional ACK until fixing issue in method:



setExternalRegSelectedTokenType(ExternalRegAttrs erAttrs)

Check for null for erAttrs before using.


- Original Message -
From: "Christina Fu" <c...@redhat.com>
To: "pki-devel" <pki-devel@redhat.com>
Sent: Friday, 12 February, 2016 2:31:07 PM
Subject: [Pki-devel] [PATCH] pki-cfu-0115-Ticket-1007-TPS-audit.patch

This patch is for
https://fedorahosted.org/pki/ticket/1007

  Ticket #1007 TPS audit
  This patch implements the TPS operation auditing:
TOKEN_APPLET_UPGRADE_SUCCESS,TOKEN_APPLET_UPGRADE_FAILURE,TOKEN_CERT_ENROLLMENT,TOKEN_CERT_RENEWAL,TOKEN_CERT_RETRIEVAL,TOKEN_KEY_RECOVERY,TOKEN_CERT_STATUS_CHANGE_REQUEST,TOKEN_OP_REQUEST,TOKEN_FORMAT_SUCCESS,TOKEN_FORMAT_FAILURE,TOKEN_KEY_CHANGEOVER,TOKEN_KEY_CHANGEOVER_FAILURE,TOKEN_PIN_RESET_SUCCESS,TOKEN_PIN_RESET_FAILURE,TOKEN_STATE_CHANGE,TOKEN_AUTH_SUCCESS,TOKEN_AUTH_FAILURE

  Administrative auditing (via REST interface) will be covered in a
separate ticket.

thanks,
Christina


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


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

Re: [Pki-devel] [PATCH] 678 Fixed token modify operation.

[Christina Fu]

Looks fine. If tested to work, ACK.

Christina

On 02/05/2016 04:08 PM, Endi Sukma Dewata wrote:

The TPS UI and CLI have been modified to accept only user ID and
policy attributes when modifying a token.

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



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


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

Re: [Pki-devel] [PATCH] 676 Fixed LDAP error handling in TokenService.

[Christina Fu]

looks fine.
If tested to work, ACK.

Christina

On 02/03/2016 08:34 PM, Endi Sukma Dewata wrote:

The DBSSession has been modified to attach the LDAPException
to the EDBException. The TokenService will catch the EDBException
and obtain the orignal LDAPException. This way the TokenService
can obtain the LDAP error code and throw the proper exception
the client.

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



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


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

Re: [Pki-devel] [PATCH] 674 Fixed error handling in TokenService.

[Christina Fu]

looks fine.

If tested to work, ACK.

Christina

On 02/03/2016 08:43 AM, Endi Sukma Dewata wrote:

The TokenService has been modified to re-throw the original
PKIException. This way on invalid token state transition the
client will receive the original BadRequestException. Other
types of exception will be wrapped with PKIException.

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



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


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

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

[Christina Fu]

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


thanks,
Christina

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

Enhance tkstool for capabilities and security

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

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

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

Master key can be tested by using the tool:

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




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


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