From edewata at redhat.com Thu Jan 3 12:58:36 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 03 Jan 2013 19:58:36 +0700 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. Message-ID: <50E5807C.9040701@redhat.com> The pkispawn has been modified such that if there is no configuration file specified it will enter an interactive mode. Ticket #380 The pkidestroy will be modified in a separate patch. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0199-Added-interactive-subsystem-installation.patch Type: text/x-patch Size: 23608 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 3 22:11:53 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 04 Jan 2013 05:11:53 +0700 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <50E5807C.9040701@redhat.com> References: <50E5807C.9040701@redhat.com> Message-ID: <50E60229.8000709@redhat.com> On 1/3/2013 7:58 PM, Endi Sukma Dewata wrote: > The pkispawn has been modified such that if there is no configuration > file specified it will enter an interactive mode. > > Ticket #380 > > The pkidestroy will be modified in a separate patch. Nevermind. The new patch contains cleanups and the pkidestroy changes. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0199-1-Added-interactive-subsystem-installation.patch Type: text/x-patch Size: 26691 bytes Desc: not available URL: From edewata at redhat.com Fri Jan 4 15:17:54 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 04 Jan 2013 22:17:54 +0700 Subject: [Pki-devel] [PATCH] 35 Fix for ticket 214 - Proper error message while adding duplicate user In-Reply-To: <1354892396.32653.3.camel@akoneru.redhat.com> References: <1354892396.32653.3.camel@akoneru.redhat.com> Message-ID: <50E6F2A2.6030908@redhat.com> On 12/7/2012 9:59 PM, Abhishek Koneru wrote: > Please review the patch which fixes the ticket 214. It requires Patch 34 > which is also attached to be applied first. Patch #34 is ACKed and pushed after rebase. I have some comments about patch #35: 1. The patch is adding a new message: CMS_USRGRP_USER_ADD_FAILED_2=An user already exits with the user id \"{0}\". In this project it looks like the convention is that the number at the end of the message name indicates the number of parameters, which in this case should be 1. 2. In UsrGrpAdminServlet.java I'm not sure the failure there is caused by the user already exists. It could be that the user ID is already specified in the request but there's another error. 3. In UGSubsystem.java instead of checking whether the user already exists using getUser(), you could try to check the LDAP return code of the add() operation. This way we don't need to do any extra checking. -- Endi S. Dewata From mharmsen at redhat.com Fri Jan 4 18:14:27 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 04 Jan 2013 10:14:27 -0800 Subject: [Pki-devel] [PATCH] 35 Fix for ticket 214 - Proper error message while adding duplicate user In-Reply-To: <50E6F2A2.6030908@redhat.com> References: <1354892396.32653.3.camel@akoneru.redhat.com> <50E6F2A2.6030908@redhat.com> Message-ID: <50E71C03.1030903@redhat.com> On 01/04/13 07:17, Endi Sukma Dewata wrote: > On 12/7/2012 9:59 PM, Abhishek Koneru wrote: >> Please review the patch which fixes the ticket 214. It requires Patch 34 >> which is also attached to be applied first. > > Patch #34 is ACKed and pushed after rebase. > > I have some comments about patch #35: > > 1. The patch is adding a new message: > > CMS_USRGRP_USER_ADD_FAILED_2=An user already exits with the user id > \"{0}\". > > In this project it looks like the convention is that the number at the > end of the message name indicates the number of parameters, which in > this case should be 1. > Also, fix the typos "An user" --> "A user" and "exits" --> "exists". > 2. In UsrGrpAdminServlet.java I'm not sure the failure there is caused > by the user already exists. It could be that the user ID is already > specified in the request but there's another error. > > 3. In UGSubsystem.java instead of checking whether the user already > exists using getUser(), you could try to check the LDAP return code of > the add() operation. This way we don't need to do any extra checking. > From mharmsen at redhat.com Sat Jan 5 06:10:28 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 04 Jan 2013 22:10:28 -0800 Subject: [Pki-devel] [PATCH] Use tomcatjss 7.1.0 and fix weird errno=0 exception . . . Message-ID: <50E7C3D4.6020509@redhat.com> Please review the attached patch which addresses the following PKI issues: * TRAC Ticket #469 - Dogtag 10: Fix tomcatjss issue in pki-core.spec and dogtag-pki.spec . . . * TRAC Ticket #468 - pkispawn throws exception The patch has been applied and successfully tested on a 64-bit Fedora 18 machine. -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130104-Use-tomcatjss-7.1.0-and-fix-weird-errno-0-exception.patch Type: text/x-patch Size: 9068 bytes Desc: not available URL: From edewata at redhat.com Mon Jan 7 16:08:59 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 07 Jan 2013 23:08:59 +0700 Subject: [Pki-devel] [PATCH] Use tomcatjss 7.1.0 and fix weird errno=0 exception . . . In-Reply-To: <50E7C3D4.6020509@redhat.com> References: <50E7C3D4.6020509@redhat.com> Message-ID: <50EAF31B.9090201@redhat.com> On 1/5/2013 1:10 PM, Matthew Harmsen wrote: > Please review the attached patch which addresses the following PKI issues: > > * TRAC Ticket #469 - Dogtag 10: Fix tomcatjss issue in pki-core.spec > and dogtag-pki.spec . . . > * TRAC Ticket #468 - pkispawn throws exception > > The patch has been applied and successfully tested on a 64-bit Fedora 18 > machine. Works for me. ACK. -- Endi S. Dewata From alee at redhat.com Mon Jan 7 16:41:02 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 07 Jan 2013 11:41:02 -0500 Subject: [Pki-devel] [PATCH] Use tomcatjss 7.1.0 and fix weird errno=0 exception . . . In-Reply-To: <50EAF31B.9090201@redhat.com> References: <50E7C3D4.6020509@redhat.com> <50EAF31B.9090201@redhat.com> Message-ID: <1357576867.16107.5.camel@aleeredhat.laptop> Looks sound to me too. ACK On Mon, 2013-01-07 at 23:08 +0700, Endi Sukma Dewata wrote: > On 1/5/2013 1:10 PM, Matthew Harmsen wrote: > > Please review the attached patch which addresses the following PKI issues: > > > > * TRAC Ticket #469 - Dogtag 10: Fix tomcatjss issue in pki-core.spec > > and dogtag-pki.spec . . . > > * TRAC Ticket #468 - pkispawn throws exception > > > > The patch has been applied and successfully tested on a 64-bit Fedora 18 > > machine. > > Works for me. ACK. > From alee at redhat.com Mon Jan 7 21:44:46 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 07 Jan 2013 16:44:46 -0500 Subject: [Pki-devel] [PATCH] 110 Increase root CA validity to 20 years Message-ID: <1357595087.16107.6.camel@aleeredhat.laptop> Please review. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0110-Increase-root-CA-validity-to-20-years.patch Type: text/x-patch Size: 4039 bytes Desc: not available URL: From mharmsen at redhat.com Mon Jan 7 22:42:04 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 07 Jan 2013 14:42:04 -0800 Subject: [Pki-devel] [PATCH] 110 Increase root CA validity to 20 years In-Reply-To: <1357595087.16107.6.camel@aleeredhat.laptop> References: <1357595087.16107.6.camel@aleeredhat.laptop> Message-ID: <50EB4F3C.7070308@redhat.com> On 01/07/13 13:44, Ade Lee wrote: > Please review. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK Previous CA Signing Certificate validity: Validity: Not Before: Friday, January 4, 2013 9:47:11 PM PST US/Pacific Not After: Monday, January 4, 2021 9:47:11 PM PST US/Pacific CA Signing Certificate validity (post patch): Validity: Not Before: Monday, January 7, 2013 2:31:09 PM PST US/Pacific Not After: Friday, January 7, 2033 2:31:09 PM PST US/Pacific -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Tue Jan 8 02:58:30 2013 From: cfu at redhat.com (Christina Fu) Date: Mon, 07 Jan 2013 18:58:30 -0800 Subject: [Pki-devel] Review Request: ECC CRL support for OCSP Message-ID: <50EB8B56.40102@redhat.com> The following code is ready for review: https://bugzilla.redhat.com/attachment.cgi?id=674480&action=diff&context=patch&collapsed=&headers=1&format=raw It addresses the following *Bug 839426* -[RFE] ECC CRL support for OCSP 1. adding an ECC CRL via OCSP agent interface 2. publishing an ECC CRL from CA to OCSP thanks, Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Jan 8 19:53:00 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 08 Jan 2013 14:53:00 -0500 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <50E60229.8000709@redhat.com> References: <50E5807C.9040701@redhat.com> <50E60229.8000709@redhat.com> Message-ID: <1357674781.16107.24.camel@aleeredhat.laptop> Some immediate feedback. 1. We ought to have some code to ensure that only one invocation of pkispawn or pkidestroy is running at a time. This is important for selinux. Maybe this is a separate ticket. 2. We should prompt for passwords twice and confirm that the passwords match (as they are not displayed). 3. After all inputs are entered, it would be good to output something like "Starting installation ...". It would also be good to print out the choices made, and allow them to go back and change them by typing "back" - just like DS does. 4. Man page for pkispawn and pkidestroy needs to be updated. Similarly for pkispawn -h. 5. For subsystem type - entering something incorrect - like RAT for example, causes an unsightly traceback. 6. When installing a KRA, you are prompted for a security domain admin certificate --why? 7. When installing KRA (and OCSP and TKS), you need to be prompted for connection info to two CA's -- the security domain CA, and the issuing CA. These need not be the same. 8. How do you handle the admin cert ie. whether to create a new admin or reuse the cert of an old admin? I suspect this is related to question 6 above. 9. It would be nice if the interactive script wrong out a config file (maybe with passwords XXX'ed out) after the install. Looking at code next ... On Fri, 2013-01-04 at 05:11 +0700, Endi Sukma Dewata wrote: > On 1/3/2013 7:58 PM, Endi Sukma Dewata wrote: > > The pkispawn has been modified such that if there is no configuration > > file specified it will enter an interactive mode. > > > > Ticket #380 > > > > The pkidestroy will be modified in a separate patch. > > Nevermind. The new patch contains cleanups and the pkidestroy changes. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Jan 8 20:25:42 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 08 Jan 2013 15:25:42 -0500 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <1357674781.16107.24.camel@aleeredhat.laptop> References: <50E5807C.9040701@redhat.com> <50E60229.8000709@redhat.com> <1357674781.16107.24.camel@aleeredhat.laptop> Message-ID: <1357676742.16107.26.camel@aleeredhat.laptop> More feedback: 1. What does python -u do? In general, the code changes look fine. Ade On Tue, 2013-01-08 at 14:53 -0500, Ade Lee wrote: > Some immediate feedback. > > 1. We ought to have some code to ensure that only one invocation of > pkispawn or pkidestroy is running at a time. This is important for > selinux. Maybe this is a separate ticket. > > 2. We should prompt for passwords twice and confirm that the passwords > match (as they are not displayed). > > 3. After all inputs are entered, it would be good to output something > like "Starting installation ...". It would also be good to print out > the choices made, and allow them to go back and change them by typing > "back" - just like DS does. > > 4. Man page for pkispawn and pkidestroy needs to be updated. Similarly > for pkispawn -h. > > 5. For subsystem type - entering something incorrect - like RAT for > example, causes an unsightly traceback. > > 6. When installing a KRA, you are prompted for a security domain admin > certificate --why? > > 7. When installing KRA (and OCSP and TKS), you need to be prompted for > connection info to two CA's -- the security domain CA, and the issuing > CA. These need not be the same. > > 8. How do you handle the admin cert ie. whether to create a new admin or > reuse the cert of an old admin? I suspect this is related to question 6 > above. > > 9. It would be nice if the interactive script wrong out a config file > (maybe with passwords XXX'ed out) after the install. > > Looking at code next ... > > > > > On Fri, 2013-01-04 at 05:11 +0700, Endi Sukma Dewata wrote: > > On 1/3/2013 7:58 PM, Endi Sukma Dewata wrote: > > > The pkispawn has been modified such that if there is no configuration > > > file specified it will enter an interactive mode. > > > > > > Ticket #380 > > > > > > The pkidestroy will be modified in a separate patch. > > > > Nevermind. The new patch contains cleanups and the pkidestroy changes. > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Jan 9 02:12:15 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 09 Jan 2013 09:12:15 +0700 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <1357676742.16107.26.camel@aleeredhat.laptop> References: <50E5807C.9040701@redhat.com> <50E60229.8000709@redhat.com> <1357674781.16107.24.camel@aleeredhat.laptop> <1357676742.16107.26.camel@aleeredhat.laptop> Message-ID: <50ECD1FF.9020802@redhat.com> On 1/9/2013 3:25 AM, Ade Lee wrote: > 1. What does python -u do? We're using different ways to display the messages: python/jython print, python logging, jython javasystem.out. Apparently each of them has separate buffer so the messages would not appear in the proper order unless we disable buffering using -u. >> 1. We ought to have some code to ensure that only one invocation of >> pkispawn or pkidestroy is running at a time. This is important for >> selinux. Maybe this is a separate ticket. I opened this ticket: https://fedorahosted.org/pki/ticket/470 >> 2. We should prompt for passwords twice and confirm that the passwords >> match (as they are not displayed). Agreed, the initial patch was meant to provide the basic functionality. I'm planning to add verifications & error checking in a follow up patch. However, we should only do password verification for passwords that we create. In this case we'll do it for the admin password only. For DS we're only using an existing password, so I don't think we should verify it. The DS password was created and verified during DS installation. I believe the PKI UI also doesn't require DS password verification. Same thing for security domain password, the password is already verified when we create the security domain itself. When we create KRA we're only using the password. >> 3. After all inputs are entered, it would be good to output something >> like "Starting installation ...". It would also be good to print out >> the choices made, and allow them to go back and change them by typing >> "back" - just like DS does. OK, will add in follow up. If you type "back" you'd need to re-enter everything, is that ok? >> 4. Man page for pkispawn and pkidestroy needs to be updated. Similarly >> for pkispawn -h. OK. For the help page (-h) the -f option should be made optional (the -s option is already fixed). Any other changes to the help page? For the man page I opened this ticket: https://fedorahosted.org/pki/ticket/471 >> 5. For subsystem type - entering something incorrect - like RAT for >> example, causes an unsightly traceback. Will do the error checking in follow up. >> 6. When installing a KRA, you are prompted for a security domain admin >> certificate --why? I think the prompt is wrong, it should have been "Import admin certificate" instead of "Security domain certificate". The default pki_admin_cert_file for KRA would point to the CA admin cert in KRA's client dir. This will not work if the CA and KRA are installed on different instances. By prompting for the cert, it will allow you to enter the CA admin cert in the CA's client dir. If they are installed in the same instances you can just accept the default value. What's actually the difference between pki_admin_cert_file and pki_client_admin_cert, is one for import and the other for export? Do they contain the same certificate? >> 7. When installing KRA (and OCSP and TKS), you need to be prompted for >> connection info to two CA's -- the security domain CA, and the issuing >> CA. These need not be the same. What are the parameters for the issuing CA? Do you have an example? How common is it to have different CA's for the security domain and issuing CA? Note that in the interactive mode we can limit ourselves to support the most common scenarios only. >> 8. How do you handle the admin cert ie. whether to create a new admin or >> reuse the cert of an old admin? I suspect this is related to question 6 >> above. The default pki_import_admin_cert for non-CA subsystems is True. So right now it only supports reusing the old admin cert, that's why in #6 you're asked for the cert. I'll fix the logic to use pki_import_admin_cert. There are several ways to handle this: a) Add another prompt asking whether to create or reuse the admin cert. b) Don't support that in the interactive mode. You'd have to use a config file. Which one would you suggest? >> 9. It would be nice if the interactive script wrong out a config file >> (maybe with passwords XXX'ed out) after the install. The user config file will be stored in the registry with the passwords intact just like in the non-interactive mode. Is this sufficient? -- Endi S. Dewata From edewata at redhat.com Wed Jan 9 02:28:40 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 09 Jan 2013 09:28:40 +0700 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <50ECD1FF.9020802@redhat.com> References: <50E5807C.9040701@redhat.com> <50E60229.8000709@redhat.com> <1357674781.16107.24.camel@aleeredhat.laptop> <1357676742.16107.26.camel@aleeredhat.laptop> <50ECD1FF.9020802@redhat.com> Message-ID: <50ECD5D8.8000501@redhat.com> >>> 3. After all inputs are entered, it would be good to output something >>> like "Starting installation ...". It would also be good to print out >>> the choices made, and allow them to go back and change them by typing >>> "back" - just like DS does. > > OK, will add in follow up. If you type "back" you'd need to re-enter > everything, is that ok? I mean not re-enter everything, but you'd have to go through all the prompts again. Most of the time you'll just accept the displayed values, but you'll need to re-enter the values you want to change and all passwords (including the verification) because they aren't displayed. Alternatively we could use a menu system, so we ask the user to select which parameter he wants to change and then prompt for that parameter only. Any suggestions? -- Endi S. Dewata From alee at redhat.com Wed Jan 9 05:23:08 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 09 Jan 2013 00:23:08 -0500 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <50ECD1FF.9020802@redhat.com> References: <50E5807C.9040701@redhat.com> <50E60229.8000709@redhat.com> <1357674781.16107.24.camel@aleeredhat.laptop> <1357676742.16107.26.camel@aleeredhat.laptop> <50ECD1FF.9020802@redhat.com> Message-ID: <1357708989.16107.40.camel@aleeredhat.laptop> On Wed, 2013-01-09 at 09:12 +0700, Endi Sukma Dewata wrote: > On 1/9/2013 3:25 AM, Ade Lee wrote: > > 1. What does python -u do? > > We're using different ways to display the messages: python/jython print, > python logging, jython javasystem.out. Apparently each of them has > separate buffer so the messages would not appear in the proper order > unless we disable buffering using -u. OK > > >> 1. We ought to have some code to ensure that only one invocation of > >> pkispawn or pkidestroy is running at a time. This is important for > >> selinux. Maybe this is a separate ticket. > > I opened this ticket: > https://fedorahosted.org/pki/ticket/470 > > >> 2. We should prompt for passwords twice and confirm that the passwords > >> match (as they are not displayed). > > Agreed, the initial patch was meant to provide the basic functionality. > I'm planning to add verifications & error checking in a follow up patch. > > However, we should only do password verification for passwords that we > create. In this case we'll do it for the admin password only. > > For DS we're only using an existing password, so I don't think we should > verify it. The DS password was created and verified during DS > installation. I believe the PKI UI also doesn't require DS password > verification. > > Same thing for security domain password, the password is already > verified when we create the security domain itself. When we create KRA > we're only using the password. > The password verification is mostly for sanity checking purposes. It is possible that the password that is entered for the DS password is mis-typed. Having ham-fisted fingers, I tend to do that. As the password is not displayed, its unclear until you actually start the installation whether the password was mis-typed. On the other hand, you are unlikely to mistype a password twice. So, I think it should be done for all passwords. > >> 3. After all inputs are entered, it would be good to output something > >> like "Starting installation ...". It would also be good to print out > >> the choices made, and allow them to go back and change them by typing > >> "back" - just like DS does. > > OK, will add in follow up. If you type "back" you'd need to re-enter > everything, is that ok? > Yes - and I understand, re-enter everything meaning that you have to go through the prompts again. > >> 4. Man page for pkispawn and pkidestroy needs to be updated. Similarly > >> for pkispawn -h. > > OK. For the help page (-h) the -f option should be made optional (the -s > option is already fixed). Any other changes to the help page? > Thats probably fine. > For the man page I opened this ticket: > https://fedorahosted.org/pki/ticket/471 > Ok - I am interested in how this is documented. In particular, we want to be careful to explain exactly what type of installation is available using the interactive install. I would suggest writing this first - so that we can decide if we agree on this - and if the options need to change accordingly. > >> 5. For subsystem type - entering something incorrect - like RAT for > >> example, causes an unsightly traceback. > > Will do the error checking in follow up. > OK > >> 6. When installing a KRA, you are prompted for a security domain admin > >> certificate --why? > > I think the prompt is wrong, it should have been "Import admin > certificate" instead of "Security domain certificate". > > The default pki_admin_cert_file for KRA would point to the CA admin cert > in KRA's client dir. This will not work if the CA and KRA are installed > on different instances. By prompting for the cert, it will allow you to > enter the CA admin cert in the CA's client dir. If they are installed in > the same instances you can just accept the default value. > > What's actually the difference between pki_admin_cert_file and > pki_client_admin_cert, is one for import and the other for export? Do > they contain the same certificate? > > >> 7. When installing KRA (and OCSP and TKS), you need to be prompted for > >> connection info to two CA's -- the security domain CA, and the issuing > >> CA. These need not be the same. > > What are the parameters for the issuing CA? Do you have an example? > > How common is it to have different CA's for the security domain and > issuing CA? Note that in the interactive mode we can limit ourselves to > support the most common scenarios only. > This goes back to my statements about the man page. We need to decide exactly what we are supporting in the interactive install. I think its reasonable for the CA to be not the same as the security domain CA. > >> 8. How do you handle the admin cert ie. whether to create a new admin or > >> reuse the cert of an old admin? I suspect this is related to question 6 > >> above. > > The default pki_import_admin_cert for non-CA subsystems is True. So > right now it only supports reusing the old admin cert, that's why in #6 > you're asked for the cert. I'll fix the logic to use pki_import_admin_cert. > > There are several ways to handle this: > a) Add another prompt asking whether to create or reuse the admin cert. > b) Don't support that in the interactive mode. You'd have to use a > config file. > > Which one would you suggest? I like option (a) -- and if the choice is to reuse an admin cert, prompt for its location. > > >> 9. It would be nice if the interactive script wrong out a config file > >> (maybe with passwords XXX'ed out) after the install. > > The user config file will be stored in the registry with the passwords > intact just like in the non-interactive mode. Is this sufficient? > Yes. From cfu at redhat.com Wed Jan 9 18:36:38 2013 From: cfu at redhat.com (Christina Fu) Date: Wed, 09 Jan 2013 10:36:38 -0800 Subject: [Pki-devel] Review Request: CMC ECC support In-Reply-To: <1671068218.50795685.1356130014374.JavaMail.root@redhat.com> References: <1671068218.50795685.1356130014374.JavaMail.root@redhat.com> Message-ID: <50EDB8B6.4000704@redhat.com> Hi Jack, Thank you for your review comments. The following patch should address your comments: https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview2.diff thanks, Christina On 12/21/2012 02:46 PM, John Magne wrote: > Review Comments: > > > PKCS10Client.java > > 1. Typo, I think: > > 50 + System.out.println(" -x\n"); > > 2. When parsing the command line args, it looks like we assume an even number or args, with the first arg being the switch and the second one being the value. > > When you check the switch, there is no code to handle the case when the switch is not in the list. Also, it appears that not every value is checked. For instance, if an ecc curve is specified, I don't see a check for null. > > 3. We have the following piece of code in two places near each other: > > if (dbdir == null) > 141 dbdir = "."; > > > 4. The following block: > > try { > 170 + token.login(pass); > 171 + System.out.println("PKCS10Client: token "+ tokenName + " logged in..."); > 172 + } catch (Exception e) { > 173 + System.out.println("PKCS10Client: login Exception: " + e.toString()); > 174 + if (!token.isLoggedIn()) { > 175 + System.out.println("PKCS10Client: token not logged in, calling initPassword..."); > 176 + token.initPassword(pass, pass); > 177 + } > 178 + } > > > What are we doing here? If the password is wrong, should we not bomb out? > > 5. Code: > > if (alg.equals("rsa")) { > 182 + KeyPairGenerator kg = token.getKeyPairGenerator(KeyPairAlgorithm.RSA); > 183 + kg.initialize(rsa_keylen); > 184 + pair = kg.genKeyPair(); > 185 + } else if (alg.equals("ec")) { > 186 + // used with SSL server cert that doe > > What if the alg is some bogus value? The tool seems to happily skip over the entire block and keep going. Maybe some quick check? > > 6. certRequest = new CertificationRequest(certReqInfo, > > If certRequest is null, we just log the fact to the screen but keep going. > > 7. PublicKey pubk = pair.getPublic(); > > Here , I do not think we ever check to see if "pair" is generated without a null. Maybe that is taken care of with the exceptions. But, also "pubk" is used later without a check for null. > > 8. Same as #6, with the value of "certReq". > > CRMFPopClient.java > > 1. Check for the same argument parsing concerts as in the previous tool. > > 2. This check here: > > try { > 599 + CryptoManager.initialize( DB_DIR ); > 600 + } catch (Exception e) { > 601 + // it is ok if it is already initialized > 602 + System.out.println("CRMFPopClient: INITIALIZATION ERROR: " + e.toString()); > 603 + //return; > 604 + } > > Is it possible this would fail for some other reason besides that it was already initialized? > > > 3. Same concern in the previous tool about what happens when token.login fails. > > > CMCRequest.java > > 1. Same concern here about checking the password. > > HttpClient.java > > 1. This code: > > + X509Certificate cert = > 1803 + cm.findCertByNickname(certname.toString()); > 1804 if (cert == null) > 1805 System.out.println("client cert is null"); > 1806 else > 1807 System.out.println("client cert is not null"); > > > Do we care if there is no client cert? The code proceeds happily from this point on. > > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, 18 December, 2012 8:44:27 PM > Subject: Re: [Pki-devel] Review Request: CMC ECC support > > Please find a newer patch which now also includes support for CMC > revocation within the CMCRequest tool and op flags for EC key generation > in CRMFPopClient and PKCS10Client. > > https://fedorahosted.org/pki/ticket/362 > > You will also find various Examples on how to test different scenarios > in regards to CMC request issuance. > > thanks, > Christina > > > On 12/11/2012 04:51 PM, Christina Fu wrote: >> The following code is ready for review for task >> https://fedorahosted.org/pki/ticket/362 >> Feature: CMC ECC >> which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well >> as CMC Response checking support needed HTTPClient ECC support. >> It should inherently fix the following existing bugs: >> https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC >> CRMF >> https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC >> revoke >> >> attachment: >> https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff >> >> Code changes involve both server and several tools. >> >> I will do some writeup and provide example on how to test in the task >> comment later. >> >> thanks! >> Christina >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From awnuk at redhat.com Wed Jan 9 20:23:04 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 09 Jan 2013 12:23:04 -0800 Subject: [Pki-devel] Review Request: ECC CRL support for OCSP In-Reply-To: <50EB8B56.40102@redhat.com> References: <50EB8B56.40102@redhat.com> Message-ID: <50EDD1A8.2060709@redhat.com> On 01/07/2013 06:58 PM, Christina Fu wrote: > The following code is ready for review: > https://bugzilla.redhat.com/attachment.cgi?id=674480&action=diff&context=patch&collapsed=&headers=1&format=raw > > It addresses the following > *Bug 839426* > -[RFE] ECC CRL support for OCSP > 1. adding an ECC CRL via OCSP agent interface > 2. publishing an ECC CRL from CA to OCSP > > thanks, > Christina > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK Received demo of this patch including manual and automatic CRL updates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Jan 9 23:51:04 2013 From: jmagne at redhat.com (John Magne) Date: Wed, 9 Jan 2013 18:51:04 -0500 (EST) Subject: [Pki-devel] Review Request: CMC ECC support In-Reply-To: <50EDB8B6.4000704@redhat.com> Message-ID: <1948145994.2654582.1357775464455.JavaMail.root@redhat.com> Checked over code again to verify the concerns were taken care of. The were: ACK ----- Original Message ----- From: "Christina Fu" To: "John Magne" Cc: pki-devel at redhat.com Sent: Wednesday, 9 January, 2013 10:36:38 AM Subject: Re: [Pki-devel] Review Request: CMC ECC support Hi Jack, Thank you for your review comments. The following patch should address your comments: https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview2.diff thanks, Christina On 12/21/2012 02:46 PM, John Magne wrote: > Review Comments: > > > PKCS10Client.java > > 1. Typo, I think: > > 50 + System.out.println(" -x\n"); > > 2. When parsing the command line args, it looks like we assume an even number or args, with the first arg being the switch and the second one being the value. > > When you check the switch, there is no code to handle the case when the switch is not in the list. Also, it appears that not every value is checked. For instance, if an ecc curve is specified, I don't see a check for null. > > 3. We have the following piece of code in two places near each other: > > if (dbdir == null) > 141 dbdir = "."; > > > 4. The following block: > > try { > 170 + token.login(pass); > 171 + System.out.println("PKCS10Client: token "+ tokenName + " logged in..."); > 172 + } catch (Exception e) { > 173 + System.out.println("PKCS10Client: login Exception: " + e.toString()); > 174 + if (!token.isLoggedIn()) { > 175 + System.out.println("PKCS10Client: token not logged in, calling initPassword..."); > 176 + token.initPassword(pass, pass); > 177 + } > 178 + } > > > What are we doing here? If the password is wrong, should we not bomb out? > > 5. Code: > > if (alg.equals("rsa")) { > 182 + KeyPairGenerator kg = token.getKeyPairGenerator(KeyPairAlgorithm.RSA); > 183 + kg.initialize(rsa_keylen); > 184 + pair = kg.genKeyPair(); > 185 + } else if (alg.equals("ec")) { > 186 + // used with SSL server cert that doe > > What if the alg is some bogus value? The tool seems to happily skip over the entire block and keep going. Maybe some quick check? > > 6. certRequest = new CertificationRequest(certReqInfo, > > If certRequest is null, we just log the fact to the screen but keep going. > > 7. PublicKey pubk = pair.getPublic(); > > Here , I do not think we ever check to see if "pair" is generated without a null. Maybe that is taken care of with the exceptions. But, also "pubk" is used later without a check for null. > > 8. Same as #6, with the value of "certReq". > > CRMFPopClient.java > > 1. Check for the same argument parsing concerts as in the previous tool. > > 2. This check here: > > try { > 599 + CryptoManager.initialize( DB_DIR ); > 600 + } catch (Exception e) { > 601 + // it is ok if it is already initialized > 602 + System.out.println("CRMFPopClient: INITIALIZATION ERROR: " + e.toString()); > 603 + //return; > 604 + } > > Is it possible this would fail for some other reason besides that it was already initialized? > > > 3. Same concern in the previous tool about what happens when token.login fails. > > > CMCRequest.java > > 1. Same concern here about checking the password. > > HttpClient.java > > 1. This code: > > + X509Certificate cert = > 1803 + cm.findCertByNickname(certname.toString()); > 1804 if (cert == null) > 1805 System.out.println("client cert is null"); > 1806 else > 1807 System.out.println("client cert is not null"); > > > Do we care if there is no client cert? The code proceeds happily from this point on. > > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, 18 December, 2012 8:44:27 PM > Subject: Re: [Pki-devel] Review Request: CMC ECC support > > Please find a newer patch which now also includes support for CMC > revocation within the CMCRequest tool and op flags for EC key generation > in CRMFPopClient and PKCS10Client. > > https://fedorahosted.org/pki/ticket/362 > > You will also find various Examples on how to test different scenarios > in regards to CMC request issuance. > > thanks, > Christina > > > On 12/11/2012 04:51 PM, Christina Fu wrote: >> The following code is ready for review for task >> https://fedorahosted.org/pki/ticket/362 >> Feature: CMC ECC >> which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well >> as CMC Response checking support needed HTTPClient ECC support. >> It should inherently fix the following existing bugs: >> https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC >> CRMF >> https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC >> revoke >> >> attachment: >> https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff >> >> Code changes involve both server and several tools. >> >> I will do some writeup and provide example on how to test in the task >> comment later. >> >> thanks! >> Christina >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Jan 10 00:52:28 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 10 Jan 2013 07:52:28 +0700 Subject: [Pki-devel] [PATCH] 200 Added nonce validation for certificate revocation. Message-ID: <50EE10CC.3030402@redhat.com> The certificate REST service has been modified to validate nonce when revoking a certificate. Ticket #213 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0200-Added-nonce-validation-for-certificate-revocation.patch Type: text/x-patch Size: 25328 bytes Desc: not available URL: From mharmsen at redhat.com Thu Jan 10 02:01:52 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 09 Jan 2013 18:01:52 -0800 Subject: [Pki-devel] [PATCH] Added third-party license file Message-ID: <50EE2110.2040206@redhat.com> Please review the attached patch which addresses the following PKI issue: * TRAC Ticket #430 - License for 3rd party code Comments: * I referenced the header of the 'jquery.i18n.properties' plug-in because the documented license URLs are broken o After searching the inspiration URL contained in this header, although I concluded that the file called 'MIT-LICENSE.txt' most likely pointed to the 'MIT-LICENSE.txt' file used by jquery, I did not place a copy of this license text after the header for 'jquery.i18n.properties' o Also within this header, I was unable to determine the exact GPL version, since I was unable to find the documented file called 'GPL-LICENSE.txt' o The header URL 'www.codingwithcoffee.com' contains a note in the expanded text that the project page for 'jquery.i18n.properties' has been moved to 'http://code.google.com/p/jquery-i18n-properties/', and thus this was used as the 'Project URL'referenced at the top of the 'THIRD_PARTY_LICENSES' file -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130109-Add-third-party-license-file.patch Type: text/x-patch Size: 4297 bytes Desc: not available URL: From alee at redhat.com Thu Jan 10 05:43:20 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 10 Jan 2013 00:43:20 -0500 Subject: [Pki-devel] [PATCH] Added third-party license file In-Reply-To: <50EE2110.2040206@redhat.com> References: <50EE2110.2040206@redhat.com> Message-ID: <1357796601.16107.42.camel@aleeredhat.laptop> ACK On Wed, 2013-01-09 at 18:01 -0800, Matthew Harmsen wrote: > Please review the attached patch which addresses the following PKI > issue: > * TRAC Ticket #430 - License for 3rd party code > Comments: > * I referenced the header of the 'jquery.i18n.properties' > plug-in because the documented license URLs are broken > * After searching the inspiration URL contained in this > header, although I concluded that the file called > 'MIT-LICENSE.txt' most likely pointed to the > 'MIT-LICENSE.txt' file used by jquery, I did not place > a copy of this license text after the header for > 'jquery.i18n.properties' > * Also within this header, I was unable to determine the > exact GPL version, since I was unable to find the > documented file called 'GPL-LICENSE.txt' > * The header URL 'www.codingwithcoffee.com' contains a > note in the expanded text that the project page for > 'jquery.i18n.properties' has been moved to > 'http://code.google.com/p/jquery-i18n-properties/', > and thus this was used as the 'Project URL' referenced > at the top of the 'THIRD_PARTY_LICENSES' file > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Jan 11 04:01:06 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 10 Jan 2013 23:01:06 -0500 Subject: [Pki-devel] [PATCH] 111 - pkidestory does not remove KRA connector Message-ID: <1357876876.16107.48.camel@aleeredhat.laptop> This patch is bigger than I originally planned, but its mostly pretty straightforward. Resolved Trac Ticket 367 - pkidestroy does not remove connector * Added RESTful servlet to add/remove a KRA connector from the CA. * Modified ACL to allow KRA subsystem user to remove connector. * Modified connector code to allow the connector to be replaced without a server restart. * Added functionality to pki CLI to add/remove connector * Added code to pkidestroy to remove the connector (using both pki CLI and sslget) When the issues with pki connection are resolved, we will use that method instead. * Modified sslget to accept HTTP return codes < 300. In this case, we were returning 204 - which is perfectly legitimate. Test this by: 1. Install a CA, KRA 2. pkidestroy the KRA. The KRA connector config should be removed from the CA. 3. Test removing/ adding KRA connector using pki. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0111-Resolved-Trac-Ticket-367-pkidestroy-does-not-remove-.patch Type: text/x-patch Size: 62201 bytes Desc: not available URL: From alee at redhat.com Fri Jan 11 15:52:59 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 11 Jan 2013 10:52:59 -0500 Subject: [Pki-devel] [PATCH] 111 - pkidestory does not remove KRA connector In-Reply-To: <1357876876.16107.48.camel@aleeredhat.laptop> References: <1357876876.16107.48.camel@aleeredhat.laptop> Message-ID: <1357919580.16107.49.camel@aleeredhat.laptop> New patch based on feedback from Endi. This one throws the exceptions from the processor directly. Ade On Thu, 2013-01-10 at 23:01 -0500, Ade Lee wrote: > This patch is bigger than I originally planned, but its mostly pretty > straightforward. > > Resolved Trac Ticket 367 - pkidestroy does not remove connector > > * Added RESTful servlet to add/remove a KRA connector from the CA. > * Modified ACL to allow KRA subsystem user to remove connector. > * Modified connector code to allow the connector to be replaced without > a server restart. > * Added functionality to pki CLI to add/remove connector > * Added code to pkidestroy to remove the connector (using both pki CLI > and sslget) When the issues with pki connection are resolved, we will > use that method instead. > * Modified sslget to accept HTTP return codes < 300. In this case, we > were returning 204 - which is perfectly legitimate. > > Test this by: > 1. Install a CA, KRA > 2. pkidestroy the KRA. The KRA connector config should be removed from > the CA. > 3. Test removing/ adding KRA connector using pki. > > Thanks, > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0111-1-Resolved-Trac-Ticket-367-pkidestroy-does-not-remove-.patch Type: text/x-patch Size: 61994 bytes Desc: not available URL: From nkinder at redhat.com Fri Jan 11 22:19:35 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 11 Jan 2013 14:19:35 -0800 Subject: [Pki-devel] Please Review: (Ticket 209)TPS token enrollment causes DS syntax violations Message-ID: <50F08FF7.3060502@redhat.com> https://fedorahosted.org/pki/ticket/209 https://fedorahosted.org/pki/attachment/ticket/209/0001-Ticket-209-TPS-token-enrollment-causes-DS-syntax-vio.patch From edewata at redhat.com Mon Jan 14 15:36:32 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 14 Jan 2013 22:36:32 +0700 Subject: [Pki-devel] [PATCH] 201 Added LDAP exception converter. Message-ID: <50F42600.5030303@redhat.com> A utility class has been added to convert LDAP exceptions into PKI exceptions. Ticket #191, #214 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0201-Added-LDAP-exception-converter.patch Type: text/x-patch Size: 4772 bytes Desc: not available URL: From alee at redhat.com Tue Jan 15 02:15:08 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 14 Jan 2013 21:15:08 -0500 Subject: [Pki-devel] [PATCH] 111 - pkidestory does not remove KRA connector In-Reply-To: <1357919580.16107.49.camel@aleeredhat.laptop> References: <1357876876.16107.48.camel@aleeredhat.laptop> <1357919580.16107.49.camel@aleeredhat.laptop> Message-ID: <1358216113.16107.58.camel@aleeredhat.laptop> Patch further modified based on feedback from Endi. 1. Fixed the parsing of host:port list in KRAConnectorProcessor code. 2. Changed Resender to use ExecutorService. We need to modify the order in which the Resender hread starts up, so that it occurs after the server is up and accepting connections - just in case the KRA and CA are in the same instance. Please review. Ade On Fri, 2013-01-11 at 10:52 -0500, Ade Lee wrote: > New patch based on feedback from Endi. This one throws the exceptions > from the processor directly. > > Ade > On Thu, 2013-01-10 at 23:01 -0500, Ade Lee wrote: > > This patch is bigger than I originally planned, but its mostly pretty > > straightforward. > > > > Resolved Trac Ticket 367 - pkidestroy does not remove connector > > > > * Added RESTful servlet to add/remove a KRA connector from the CA. > > * Modified ACL to allow KRA subsystem user to remove connector. > > * Modified connector code to allow the connector to be replaced without > > a server restart. > > * Added functionality to pki CLI to add/remove connector > > * Added code to pkidestroy to remove the connector (using both pki CLI > > and sslget) When the issues with pki connection are resolved, we will > > use that method instead. > > * Modified sslget to accept HTTP return codes < 300. In this case, we > > were returning 204 - which is perfectly legitimate. > > > > Test this by: > > 1. Install a CA, KRA > > 2. pkidestroy the KRA. The KRA connector config should be removed from > > the CA. > > 3. Test removing/ adding KRA connector using pki. > > > > Thanks, > > Ade > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0111-2-Resolved-Trac-Ticket-367-pkidestroy-does-not-remove-.patch Type: text/x-patch Size: 67788 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 15 02:52:21 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2013 09:52:21 +0700 Subject: [Pki-devel] [PATCH] 200 Added nonce validation for certificate revocation. In-Reply-To: <50EE10CC.3030402@redhat.com> References: <50EE10CC.3030402@redhat.com> Message-ID: <50F4C465.3040607@redhat.com> On 1/10/2013 7:52 AM, Endi Sukma Dewata wrote: > The certificate REST service has been modified to validate > nonce when revoking a certificate. > > Ticket #213 I retested the patch, it works as expected with nonces enabled & disabled. In most cases you'll get a proper error message (e.g. You did not provide a valid certificate) if you don't provide the required client cert. The only thing is that if you do a cert-request-approve using username & password you'll get an internal error, but this is an existing problem and we don't support that scenario. -- Endi S. Dewata From edewata at redhat.com Tue Jan 15 04:23:42 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2013 11:23:42 +0700 Subject: [Pki-devel] [PATCH] 200 Added nonce validation for certificate revocation. In-Reply-To: <50F4C465.3040607@redhat.com> References: <50EE10CC.3030402@redhat.com> <50F4C465.3040607@redhat.com> Message-ID: <50F4D9CE.90303@redhat.com> On 1/15/2013 9:52 AM, Endi Sukma Dewata wrote: > On 1/10/2013 7:52 AM, Endi Sukma Dewata wrote: >> The certificate REST service has been modified to validate >> nonce when revoking a certificate. >> >> Ticket #213 > > I retested the patch, it works as expected with nonces enabled & disabled. > > In most cases you'll get a proper error message (e.g. You did not > provide a valid certificate) if you don't provide the required client > cert. The only thing is that if you do a cert-request-approve using > username & password you'll get an internal error, but this is an > existing problem and we don't support that scenario. New patch attached. It fixes the problem getting the cert anonymously. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0200-1-Added-nonce-validation-for-certificate-revocation.patch Type: text/x-patch Size: 28155 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 15 15:38:24 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2013 22:38:24 +0700 Subject: [Pki-devel] [PATCH] 200 Added nonce validation for certificate revocation. In-Reply-To: <50F4D9CE.90303@redhat.com> References: <50EE10CC.3030402@redhat.com> <50F4C465.3040607@redhat.com> <50F4D9CE.90303@redhat.com> Message-ID: <50F577F0.90202@redhat.com> On 1/15/2013 11:23 AM, Endi Sukma Dewata wrote: >>> The certificate REST service has been modified to validate >>> nonce when revoking a certificate. >>> >>> Ticket #213 >> >> I retested the patch, it works as expected with nonces enabled & >> disabled. >> >> In most cases you'll get a proper error message (e.g. You did not >> provide a valid certificate) if you don't provide the required client >> cert. The only thing is that if you do a cert-request-approve using >> username & password you'll get an internal error, but this is an >> existing problem and we don't support that scenario. > > New patch attached. It fixes the problem getting the cert anonymously. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Jan 15 15:39:09 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2013 22:39:09 +0700 Subject: [Pki-devel] [PATCH] 201 Added LDAP exception converter. In-Reply-To: <50F42600.5030303@redhat.com> References: <50F42600.5030303@redhat.com> Message-ID: <50F5781D.1020902@redhat.com> On 1/14/2013 10:36 PM, Endi Sukma Dewata wrote: > A utility class has been added to convert LDAP exceptions into PKI > exceptions. > > Ticket #191, #214 ACKed by Ade. Pushed to master. -- Endi S. Dewata From alee at redhat.com Thu Jan 17 03:08:02 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 16 Jan 2013 22:08:02 -0500 Subject: [Pki-devel] Please Review: (Ticket 209)TPS token enrollment causes DS syntax violations In-Reply-To: <50F08FF7.3060502@redhat.com> References: <50F08FF7.3060502@redhat.com> Message-ID: <1358392083.16107.215.camel@aleeredhat.laptop> On Fri, 2013-01-11 at 14:19 -0800, Nathan Kinder wrote: > https://fedorahosted.org/pki/ticket/209 > > https://fedorahosted.org/pki/attachment/ticket/209/0001-Ticket-209-TPS-token-enrollment-causes-DS-syntax-vio.patch > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Th patch itself looks fine. It looks like its doing what is advertised. I have a question, though, about the effects of this patch. Prior to this patch, if DS syntax checking were turned off, then a number of attributes could be stored in the TPS data records with a value of "". Now, when these records are accessed - either for processing or display in the UI, the values are usually returned with various function calls that ultimately call something like: char *get_cert_attr_byname(LDAPMessage *entry, const char *name) This would return "" for an empty attribute, but presumably would return NULL now that the attribute does not exist in the record. Have you looked at all the places where these parameters are queried, and made sure that we handle the NULL return correctly? Ade From alee at redhat.com Thu Jan 17 20:44:27 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 17 Jan 2013 15:44:27 -0500 Subject: [Pki-devel] [PATCH] Ticket 419 - REST intrface for cert requests Message-ID: <1358455468.4296.37.camel@aleeredhat.laptop> Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0112-Ticket-419-REST-interface-for-cert-requests.patch Type: text/x-patch Size: 7583 bytes Desc: not available URL: From alee at redhat.com Fri Jan 18 03:22:45 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 17 Jan 2013 22:22:45 -0500 Subject: [Pki-devel] Announcing the release of Dogtag 10 Message-ID: <1358479366.4296.77.camel@aleeredhat.laptop> The Dogtag team is proud to announce the release of Dogtag v10.0.0. This release is being bundled with the GA release of Fedora 18, and marks the culmination of over a year of development by the Dogtag team. == Build Versions == pki-core-10.0.0-2.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.0-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Upgrade Notes == It is possible to upgrade from a Dogtag 9 instance by first upgrading your server to Fedora 18 and then updating the Dogtag software. Existing Dogtag instances will continue to work correctly using existing instances, with the Java-based instances running on Tomcat 6. However, because the new functionality and interfaces depend on instance configuration, these will not be available to existing Dogtag 9-style instances. To take advantage of these new features, new Dogtag 10 instances should be created. Documentation will soon be provided on how to migrate a Dogtag 9 - style instance to a new Dogtag 10 instance. == Highlights since Dogtag v. 9 == Infrastructure and Development Changes: * The Dogtag code base was moved to git from svn. * Java development is now done under Eclipse. * Dogtag 10 uses its own public-facing TRAC project management system. * Improvements were made to CMake modules for Java development. * Java development uses OpenJDK 7. * Python development uses Python 2.7 and Jython 2.2. * Dogtag 10 Java-based instances run on Tomcat 7. * Dogtag 10 RA and TPS instances run on Apache 2.4. Refactoring and Cleanup: * Code has been reformatted to uniform formatting and coding standards. * Based on feedback provided by Eclipse and Coverity, the following types of cleanup occurred: ** Removal of dead code and unnecessary code blocks. ** Removal of generic containers and implementation of type safety. ** Removal/ replacement of deprecated code, with the addition of JUnit tests to confirm correctness. ** Address various memory leaks and corruption issues, coding style issues etc. * The Dogtag code pre-dates many of the modern Java utilities to do encoding, HTTP and XML parsing etc. As a result, custom code was written to do these functions. This code has been replaced with standard code, and a whole package (osutil) was eliminated. REST Interface: To allow easier and more intuitive interaction with the Dogtag servers, a new REST interface has been added. This interface is based on RESTEasy framework, a fully certified implementation of the JAX-RS specification. Clients interact with this framework using intuitive REST URLs, and using standard XML or JSON inputs. Included is a Java client proxy framework which can be used by client applications to build HTTP requests on the Dogtag servers, simply by invoking methods on the client objects. This client framework is used in the new command line interface "pki" as described below. The plan is to continue over time to extend the REST interface to cover all of the essential Dogtag functionality. In this release, the following functionality has been implemented: * With a CA: ** Create, review and approve certificate requests. ** List, view, revoke, hold and release certificates. ** Get installation token from security domain ** Add/remove KRA connector configuration ** Retrieve and list certificate profiles * With KRA: ** Retrieve transport certificate ** List/ archive and recover symmetric keys * With all Java systems: ** Add/Remove/Modify/View users, groups and group members ** Start system installation service Third-party Components: * Dogtag 10 includes JQuery and the Jquery.i18n.properties plug-in. CLI: * A new intuitive command line interface has been created, based on the RESTEasy client framework. This allows administrators and agents to perform all of the operations exposed by the REST interface from the command line, or from scripts. Storage of symmetric keys in the DRM: * The DRM provides secure encrypted storage for asymmetric keys. The KRA has been extended to provide a mechanism to securely archive and recover symmetric keys. This would be useful for storing disk encryption keys for instance. SELinux changes: * In Dogtag 9, we maintained a custom SELinux policy to provide mandatory access controls for interactions with the Dogtag server. In Dogtag 10, this policy has been cleaned up, simplified and integrated into the system base policy. As a result, the pki-selinux package has been retired. ECC: * In earlier releases, Dogtag only supported ECC certificate issuance when the CA was connected to an ECC-capable external crypto token. In Dogtag 10, all CS servers (CA, OCSP, DRM, TKS, TPS) can now be issued ECC certificates and run in such environment that: ** CS servers can communicate securely with ECC SSL certificates. ** Administrators and agents can access their administration ports via SSL using ECC certificates ** ECC encryption certificates can now have their private keys archived (and recovered) by the DRM. For this feature, we used an ECC-capable HSM in our development and QE environment on the client side for development and testing. Certicom software tokens could not be used because of an issue with malformed private keys. ** The TMS testing client tool, tpsclient, can now be used to test token-based enrollment and key archival in the TMS environment (the actual smart card support will follow in a later release) New Installer: * New installer tools (pkispawn, pkidestroy) has been written in Python to create Dogtag Java-based instances (CA, KRA, OCSP, TKS). Over time, this installer will be extended to handle the remaining Apache-based instances (TPS and RA), and pkicreate/pkiremove/pkisilent will be retired and removed. * pkispawn performs the same operations that pkicreate and the pkisilent used to do, meaning that a Dogtag Java-based instance can be installed and configured in a single non-interactive step. With the right options, though, it is still possible to configure an instance by going through the web-based installation UI panels. New Directory Layout/ Architecture/ Standard Ports * It is now possible (though not required) to install multiple Java subsystems (CA, KRA, TKS, OCSP) within a single tomcat instance. This is useful for small deployments where, for example, you might want leverage the capabilities of a CA and KRA on a single server. In keeping with this change, the directory structure of a Dogtag instance has changed. * By default, Dogtag will install on the default tomcat ports (8443 and 8080). There will no longer be any separation of EE, admin and agent interfaces on different ports. Package Restructuring: * The Dogtag RPM packages have been restructured to reduce the number of packages and more accurately separate client and server components. The current packages are: ** pki-base: code common to clients and server ** pki-tools: Java and native tools used by client and server. ** pki-server: code used by Java servers, only on the server. ** pki-ca, pki-kra, pki-ocsp, pki-tks, pki-ra, pki-tps: subsystem specific code ** pki-javadoc: consolidation of the pki-common-javadoc, pki-java-tools-javadoc, and pki-util-javadoc packages ** pki-symkey: provides native symmetric key operations ** pki-console: administrative tool for CA, KRA, OCSP, and TKS * The UI packages have been rearranged and consolidated to make customizing an instance's user interfaces more straightforward, and to ensure a more consistent look and feel across subsystems. All of the subsystem-specific UI packages have been eliminated, and there is now a single UI package (dogtag-pki-server-theme) which contains all the CSS style sheets, image files and properties files for all subsystems. A customer wanting to customize the UI could simply replace the components in this package. Additionally, the pki-console requires its own UI package, dogtag-pki-console-theme. * A meta-package (dogtag-pki) has been created to conveniently install all existing Dogtag 10 PKI packages. From alee at redhat.com Fri Jan 18 03:23:12 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 17 Jan 2013 22:23:12 -0500 Subject: [Pki-devel] Announcing Dogtag 10.0.1 for pki-core and dogtag-pki Message-ID: <1358479393.4296.78.camel@aleeredhat.laptop> The Dogtag team is proud to announce the first errata build for Dogtag v10.0.0. The only packages that are being modified are dogtag-pki and pki-core, both of which are being released as version 10.0.1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.1-1.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.1-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Highlights since Dogtag v. 10.0.0 == * Nonces have been added to the RESTful interface for certificate revocation to preventing cross site scripting attacks on that interface. * A new servlet has been added to the RESTful interface to add and remove KRA connector configuration from a CA. This is used to clean up a CA when a KRA is destroyed. * The default validity of the CA signing cert has been lengthened from 8 to 20 years. * pkispawn has been modified to allow the user to specify the location of the generated admin cert PKCS#12 file. * OCSP now supports ECC CRLs. * A more robust use of interpolation has been added to pkispawn. * pkidaemon has been repaired to display the runtime status of PKI Java-based instances * A third-party license file has been added for Dogtag 10's use of JQuery and the JQuery.i18n.properties plug-in == Detailed Changes since Dogtag v. 10.0.0 == alee (12): - TRAC Ticket 367 - pkidestroy does not remove connector - Fix spec file to allow f17 to work with latest tomcatjss - TRAC Ticket 466 - Increase root CA validity to 20 years - TRAC Ticket 437 - Make admin cert p12 file location configurable - TRAC Ticket 393 - pkispawn fails when selinux is disabled - Punctuation and formatting changes in man pages - TRAC Ticket 436 - Interpolation for pki_subsystem - TRAC Ticket 433 - Interpolation for paths - TRAC Ticket 435 - Identical instance id and instance name - TRAC Ticket 406 - Replace file dependencies with package dependencies - Revert to using default config file for pkidestroy - Hardcode setting of resteasy-lib for instance cfu (1): - Bugzilla Bug 839426 - [RFE] ECC CRL support for OCSP edewata (3): - TRAC Ticket 214 - Missing error description for duplicate user - TRAC Ticket 213 - Add nonces for cert revocation - TRAC Ticket 191 - Mapping HTTP Exceptions to HTTP error codes mharmsen (4): - TRAC Ticket #430 - License for 3rd party code - TRAC Ticket 469 - Fix tomcatjss issue in spec files - TRAC Ticket 468 - pkispawn throws exception - TRAC Ticket 271 - Dogtag 10: Fix 'status' command in 'pkidaemon' From mharmsen at redhat.com Sat Jan 19 04:55:53 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 18 Jan 2013 20:55:53 -0800 Subject: [Pki-devel] [PATCH] TRAC Ticket #488 - Dogtag 10: Fix cli 'cert-find' clientAuth issue Message-ID: <50FA2759.6060903@redhat.com> Please review the attached patch which addresses the following PKI issue: * TRAC Ticket #488 - Dogtag 10: Fix cli 'cert-find' clientAuth issue -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130118-Fixed-cli-cert-find-clientAuth-FQDN-hostname-issue.patch Type: text/x-patch Size: 5777 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 22 19:49:13 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 23 Jan 2013 02:49:13 +0700 Subject: [Pki-devel] [PATCH] Ticket 419 - REST intrface for cert requests In-Reply-To: <1358455468.4296.37.camel@aleeredhat.laptop> References: <1358455468.4296.37.camel@aleeredhat.laptop> Message-ID: <50FEED39.9080900@redhat.com> On 1/18/2013 3:44 AM, Ade Lee wrote: > Please review. The command takes a --state parameter to specify the request status. Internally we're using requestState LDAP attribute, but I think in the code and in the CLI/UI we've been using "status" quite consistently. Also, in "cert-find" the --state is used to specify the subject's state (location) instead of the certificate status. So I suggest we change the parameter and the help doc to use --status to avoid confusions. Other than that everything else is good. ACK. -- Endi S. Dewata From alee at redhat.com Tue Jan 22 22:02:12 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 22 Jan 2013 17:02:12 -0500 Subject: [Pki-devel] [PATCH] Ticket 419 - REST intrface for cert requests In-Reply-To: <50FEED39.9080900@redhat.com> References: <1358455468.4296.37.camel@aleeredhat.laptop> <50FEED39.9080900@redhat.com> Message-ID: <1358892132.7620.4.camel@aleeredhat.laptop> Thanks, change made, pushed to master. On Wed, 2013-01-23 at 02:49 +0700, Endi Sukma Dewata wrote: > On 1/18/2013 3:44 AM, Ade Lee wrote: > > Please review. > > The command takes a --state parameter to specify the request status. > Internally we're using requestState LDAP attribute, but I think in the > code and in the CLI/UI we've been using "status" quite consistently. > Also, in "cert-find" the --state is used to specify the subject's state > (location) instead of the certificate status. So I suggest we change the > parameter and the help doc to use --status to avoid confusions. > > Other than that everything else is good. ACK. > From edewata at redhat.com Wed Jan 23 01:16:13 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 22 Jan 2013 19:16:13 -0600 Subject: [Pki-devel] [PATCH] TRAC Ticket #488 - Dogtag 10: Fix cli 'cert-find' clientAuth issue In-Reply-To: <50FA2759.6060903@redhat.com> References: <50FA2759.6060903@redhat.com> Message-ID: <50FF39DD.3020105@redhat.com> On 1/18/2013 10:55 PM, Matthew Harmsen wrote: > Please review the attached patch which addresses the following PKI issue: > > * TRAC Ticket #488 - Dogtag 10: Fix cli 'cert-find' clientAuth issue As discussed over IRC, the errors and warnings should always be displayed (not just in verbose mode) and they should be directed to System.err instead of System.out. Other than that it's ACKed. Here is a new ticket about allowing the user to decide what to do about the errors/warnings: https://fedorahosted.org/pki/ticket/491 -- Endi S. Dewata From cfu at redhat.com Thu Jan 24 01:28:15 2013 From: cfu at redhat.com (Christina Fu) Date: Wed, 23 Jan 2013 17:28:15 -0800 Subject: [Pki-devel] Review Request : TMS: RSA token enrollment failed : public key decode error Message-ID: <51008E2F.3080404@redhat.com> This small patch is for https://bugzilla.redhat.com/show_bug.cgi?id=903401 It fixes an unintended check-in (along with a larger check-in for https://fedorahosted.org/pki/ticket/304) It basically just reverts back the RSA part of public key handling across DRM and TPS to the original working code. Please review: https://bugzilla.redhat.com/attachment.cgi?id=686393&action=diff&context=patch&collapsed=&headers=1&format=raw thanks, Christina From mharmsen at redhat.com Thu Jan 24 19:18:10 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 24 Jan 2013 11:18:10 -0800 Subject: [Pki-devel] [PATCH] TRAC Ticket #488 - Dogtag 10: Fix cli 'cert-find' clientAuth issue (REVISED) Message-ID: <510188F2.3040702@redhat.com> Please review the attached patch which has been revised to address the following PKI issue: * TRAC Ticket #488 - Dogtag 10: Fix cli 'cert-find' clientAuth issue This revised patch was tested with the following results: * script -c "pkispawn -s CA -f /tmp/pki/cs.cfg -vvv" o successfully installed and configured with no ERRORs/WARNINGs, enrolled for a certificate, and approved a certificate * pki -h foobar -P https -p 8443 cert-find WARNING: BAD_CERT_DOMAIN encountered on 'CN=foobar.example.com,O=example.com Security Domain' indicates a common-name mismatch WARNING: UNTRUSTED ISSUER encountered on 'CN=foobar.example.com,O=example.com Security Domain' indicates a non-trusted CA cert ------------------------ 7 certificate(s) matched ------------------------ Serial Number: 0x1 Subject DN: CN=CA Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x2 Subject DN: CN=CA OCSP Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x3 Subject DN: CN=foobar.example.com,O=example.com Security Domain Status: VALID Serial Number: 0x4 Subject DN: CN=CA Subsystem Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x6 Subject DN: CN=PKI Administrator,E=caadmin at example.com,O=example.com Security Domain Status: VALID Serial Number: 0x7 Subject DN: UID=test Status: VALID ---------------------------- Number of entries returned 7 ---------------------------- * pki -h foobar.example.com -P https -p 8443 cert-find WARNING: UNTRUSTED ISSUER encountered on 'CN=foobar.example.com,O=example.com Security Domain' indicates a non-trusted CA cert ------------------------ 7 certificate(s) matched ------------------------ Serial Number: 0x1 Subject DN: CN=CA Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x2 Subject DN: CN=CA OCSP Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x3 Subject DN: CN=foobar.example.com,O=example.com Security Domain Status: VALID Serial Number: 0x4 Subject DN: CN=CA Subsystem Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x6 Subject DN: CN=PKI Administrator,E=caadmin at example.com,O=example.com Security Domain Status: VALID Serial Number: 0x7 Subject DN: UID=test Status: VALID ---------------------------- Number of entries returned 7 ---------------------------- * pki -h foobar -P https -p 8443 -n "PKI Administrator for example.com" -w XXXXXXXX -d . cert-find WARNING: BAD_CERT_DOMAIN encountered on 'CN=foobar.example.com,O=example.com Security Domain' indicates a common-name mismatch WARNING: BAD_CERT_DOMAIN encountered on 'CN=foobar.example.com,O=example.com Security Domain' indicates a common-name mismatch ------------------------ 7 certificate(s) matched ------------------------ Serial Number: 0x1 Subject DN: CN=CA Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x2 Subject DN: CN=CA OCSP Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x3 Subject DN: CN=foobar.example.com,O=example.com Security Domain Status: VALID Serial Number: 0x4 Subject DN: CN=CA Subsystem Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x6 Subject DN: CN=PKI Administrator,E=caadmin at example.com,O=example.com Security Domain Status: VALID Serial Number: 0x7 Subject DN: UID=test Status: VALID ---------------------------- Number of entries returned 7 ---------------------------- * pki -h foobar.example.com -P https -p 8443 -n "PKI Administrator for example.com" -w XXXXXXXX -d . cert-find ------------------------ 7 certificate(s) matched ------------------------ Serial Number: 0x1 Subject DN: CN=CA Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x2 Subject DN: CN=CA OCSP Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x3 Subject DN: CN=foobar.example.com,O=example.com Security Domain Status: VALID Serial Number: 0x4 Subject DN: CN=CA Subsystem Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,O=example.com Security Domain Status: VALID Serial Number: 0x6 Subject DN: CN=PKI Administrator,E=caadmin at example.com,O=example.com Security Domain Status: VALID Serial Number: 0x7 Subject DN: UID=test Status: VALID ---------------------------- Number of entries returned 7 ---------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130124-Fixed-CLI-cert-find-clientAuth-FQDN-hostname-issue.patch Type: text/x-patch Size: 9432 bytes Desc: not available URL: From cfu at redhat.com Fri Jan 25 17:50:10 2013 From: cfu at redhat.com (Christina Fu) Date: Fri, 25 Jan 2013 09:50:10 -0800 Subject: [Pki-devel] Review Request : TMS: RSA token enrollment failed : public key decode error In-Reply-To: <51008E2F.3080404@redhat.com> References: <51008E2F.3080404@redhat.com> Message-ID: <5102C5D2.8050305@redhat.com> I have created the following task to come back to visit later: https://fedorahosted.org/pki/ticket/492 - find out why EC and RSA public keys require different encoding from DRM to TPS On 01/23/2013 05:28 PM, Christina Fu wrote: > This small patch is for > https://bugzilla.redhat.com/show_bug.cgi?id=903401 > It fixes an unintended check-in (along with a larger check-in for > https://fedorahosted.org/pki/ticket/304) > > It basically just reverts back the RSA part of public key handling > across DRM and TPS to the original working code. > > Please review: > https://bugzilla.redhat.com/attachment.cgi?id=686393&action=diff&context=patch&collapsed=&headers=1&format=raw > > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From awnuk at redhat.com Fri Jan 25 18:21:07 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Fri, 25 Jan 2013 10:21:07 -0800 Subject: [Pki-devel] Review Request : TMS: RSA token enrollment failed : public key decode error In-Reply-To: <51008E2F.3080404@redhat.com> References: <51008E2F.3080404@redhat.com> Message-ID: <5102CD13.7040405@redhat.com> On 01/23/2013 05:28 PM, Christina Fu wrote: > This small patch is for > https://bugzilla.redhat.com/show_bug.cgi?id=903401 > It fixes an unintended check-in (along with a larger check-in for > https://fedorahosted.org/pki/ticket/304) > > It basically just reverts back the RSA part of public key handling > across DRM and TPS to the original working code. > > Please review: > https://bugzilla.redhat.com/attachment.cgi?id=686393&action=diff&context=patch&collapsed=&headers=1&format=raw > > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK under condition of https://fedorahosted.org/pki/ticket/492 From edewata at redhat.com Fri Jan 25 20:18:43 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jan 2013 14:18:43 -0600 Subject: [Pki-devel] [PATCH] Session-based nonces. Message-ID: <5102E8A3.3050906@redhat.com> Previously nonces were stored in a global map which might not scale well due to some issues: 1. The map used the nonces as map keys. There were possible nonce collisions which required special handling. 2. The collision handling code was not thread safe. There were possible race conditions during concurrent modifications. 3. The map was shared and size limited. If there were a lot of users using the system, valid nonces could get pruned. 4. The map mapped the nonces to client certificates. This limited the possible authentication methods that could be supported. Now the code has been modified such that each user has a private map in the user's session to store the nonces. Additional locking has been implemented to protect against concurrent modifications. The map now uses the target of the operation as the map key, eliminating possible collisions and allowing the use of other authentication methods. Since this is a private map, it's not affected by the number of users using the system. Ticket #474 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0202-Session-based-nonces.patch Type: text/x-patch Size: 49618 bytes Desc: not available URL: From edewata at redhat.com Fri Jan 25 21:22:47 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jan 2013 15:22:47 -0600 Subject: [Pki-devel] [PATCH] Session-based nonces. In-Reply-To: <5102E8A3.3050906@redhat.com> References: <5102E8A3.3050906@redhat.com> Message-ID: <5102F7A7.3020202@redhat.com> On 1/25/2013 2:18 PM, Endi Sukma Dewata wrote: > Previously nonces were stored in a global map which might not scale > well due to some issues: > 1. The map used the nonces as map keys. There were possible nonce > collisions which required special handling. > 2. The collision handling code was not thread safe. There were > possible race conditions during concurrent modifications. > 3. The map was shared and size limited. If there were a lot of > users using the system, valid nonces could get pruned. > 4. The map mapped the nonces to client certificates. This limited > the possible authentication methods that could be supported. > > Now the code has been modified such that each user has a private map > in the user's session to store the nonces. Additional locking has been > implemented to protect against concurrent modifications. The map now > uses the target of the operation as the map key, eliminating possible > collisions and allowing the use of other authentication methods. Since > this is a private map, it's not affected by the number of users using > the system. > > Ticket #474 New patch attached. Fixed the session attribute name in ProfileReviewServlet.java. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0202-1-Session-based-nonces.patch Type: text/x-patch Size: 49614 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 31 15:37:40 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 Jan 2013 09:37:40 -0600 Subject: [Pki-devel] [PATCH] 204 Merged cert-request-review/approve commands. Message-ID: <510A8FC4.4030305@redhat.com> The cert-request-approve has been merged into cert-request-review to ensure that these operations are executed in the same session. Ticket #474 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0204-Merged-cert-request-review-approve-commands.patch Type: text/x-patch Size: 14151 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 31 15:37:43 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 Jan 2013 09:37:43 -0600 Subject: [Pki-devel] [PATCH] 202 Session-based nonces. In-Reply-To: <5102F7A7.3020202@redhat.com> References: <5102E8A3.3050906@redhat.com> <5102F7A7.3020202@redhat.com> Message-ID: <510A8FC7.7000405@redhat.com> On 1/25/2013 3:22 PM, Endi Sukma Dewata wrote: > On 1/25/2013 2:18 PM, Endi Sukma Dewata wrote: >> Previously nonces were stored in a global map which might not scale >> well due to some issues: >> 1. The map used the nonces as map keys. There were possible nonce >> collisions which required special handling. >> 2. The collision handling code was not thread safe. There were >> possible race conditions during concurrent modifications. >> 3. The map was shared and size limited. If there were a lot of >> users using the system, valid nonces could get pruned. >> 4. The map mapped the nonces to client certificates. This limited >> the possible authentication methods that could be supported. >> >> Now the code has been modified such that each user has a private map >> in the user's session to store the nonces. Additional locking has been >> implemented to protect against concurrent modifications. The map now >> uses the target of the operation as the map key, eliminating possible >> collisions and allowing the use of other authentication methods. Since >> this is a private map, it's not affected by the number of users using >> the system. >> >> Ticket #474 > > New patch attached. Fixed the session attribute name in > ProfileReviewServlet.java. Rebased on top of patch #204. Fixed exception type. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0202-2-Session-based-nonces.patch Type: text/x-patch Size: 51921 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 31 17:29:50 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 Jan 2013 11:29:50 -0600 Subject: [Pki-devel] [PATCH] 199 Added interactive subsystem installation. In-Reply-To: <1357708989.16107.40.camel@aleeredhat.laptop> References: <50E5807C.9040701@redhat.com> <50E60229.8000709@redhat.com> <1357674781.16107.24.camel@aleeredhat.laptop> <1357676742.16107.26.camel@aleeredhat.laptop> <50ECD1FF.9020802@redhat.com> <1357708989.16107.40.camel@aleeredhat.laptop> Message-ID: <510AAA0E.30601@redhat.com> New patch attached. On 1/8/2013 11:23 PM, Ade Lee wrote: > The password verification is mostly for sanity checking purposes. It is > possible that the password that is entered for the DS password is > mis-typed. Having ham-fisted fingers, I tend to do that. As the > password is not displayed, its unclear until you actually start the > installation whether the password was mis-typed. On the other hand, you > are unlikely to mistype a password twice. > > So, I think it should be done for all passwords. This has been added. >>>> 3. After all inputs are entered, it would be good to output something >>>> like "Starting installation ...". It would also be good to print out >>>> the choices made, and allow them to go back and change them by typing >>>> "back" - just like DS does. >> >> OK, will add in follow up. If you type "back" you'd need to re-enter >> everything, is that ok? >> > Yes - and I understand, re-enter everything meaning that you have to go > through the prompts again. A confirmation prompt has been added. I don't think it's necessary to print out the choices again because most likely you can still see them on the screen. > Ok - I am interested in how this is documented. In particular, we want > to be careful to explain exactly what type of installation is available > using the interactive install. I would suggest writing this first - so > that we can decide if we agree on this - and if the options need to > change accordingly. The doc is available here: http://pki.fedoraproject.org/wiki/Interactive_Installation >>>> 5. For subsystem type - entering something incorrect - like RAT for >>>> example, causes an unsightly traceback. >> >> Will do the error checking in follow up. >> > OK Error checking has been added. >>>> 7. When installing KRA (and OCSP and TKS), you need to be prompted for >>>> connection info to two CA's -- the security domain CA, and the issuing >>>> CA. These need not be the same. >> >> What are the parameters for the issuing CA? Do you have an example? >> >> How common is it to have different CA's for the security domain and >> issuing CA? Note that in the interactive mode we can limit ourselves to >> support the most common scenarios only. >> > This goes back to my statements about the man page. We need to decide > exactly what we are supporting in the interactive install. > > I think its reasonable for the CA to be not the same as the security > domain CA. As discussed, since the interactive installation doesn't support clone or subordinate CA, the issuing CA will be identical to the security domain, so it's not necessary to prompt for the issuing CA separately. >>>> 8. How do you handle the admin cert ie. whether to create a new admin or >>>> reuse the cert of an old admin? I suspect this is related to question 6 >>>> above. >> >> The default pki_import_admin_cert for non-CA subsystems is True. So >> right now it only supports reusing the old admin cert, that's why in #6 >> you're asked for the cert. I'll fix the logic to use pki_import_admin_cert. >> >> There are several ways to handle this: >> a) Add another prompt asking whether to create or reuse the admin cert. >> b) Don't support that in the interactive mode. You'd have to use a >> config file. >> >> Which one would you suggest? > I like option (a) -- and if the choice is to reuse an admin cert, prompt > for its location. Prompts for importing and exporting admin certificates have been added. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0199-2-Added-interactive-subsystem-installation.patch Type: text/x-patch Size: 35075 bytes Desc: not available URL: