Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 41389 invoked from network); 10 Oct 2006 18:12:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Oct 2006 18:12:10 -0000 Received: (qmail 58578 invoked by uid 500); 10 Oct 2006 18:12:06 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 58545 invoked by uid 500); 10 Oct 2006 18:12:06 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 58534 invoked by uid 99); 10 Oct 2006 18:12:06 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Oct 2006 11:12:06 -0700 X-ASF-Spam-Status: No, hits=4.0 required=10.0 tests=DNS_FROM_RFC_ABUSE,FROM_HAS_MIXED_NUMS,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of c1vamsi1c@gmail.com designates 64.233.182.191 as permitted sender) Received: from [64.233.182.191] (HELO nf-out-0910.google.com) (64.233.182.191) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Oct 2006 11:12:04 -0700 Received: by nf-out-0910.google.com with SMTP id c29so376587nfb for ; Tue, 10 Oct 2006 11:11:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=J/Kvj03WGTd/fb4dx5tKbHDk7KWQ39/BTXOLYoWO3cbrbRkelA383Pz8js+cS3RyfHOzwlRvDjIBAh/9mjg5jiJPEqGye4K0/didBLFGkhXTJTaBoiD0A/BNNVgT+Z39ULWvln92ra7Nr6dSASI56ceGzjChT6xRgZqOwvGJ3EI= Received: by 10.49.29.3 with SMTP id g3mr1766116nfj; Tue, 10 Oct 2006 11:11:43 -0700 (PDT) Received: by 10.49.11.12 with HTTP; Tue, 10 Oct 2006 11:11:42 -0700 (PDT) Message-ID: <22d56c4d0610101111n77c96affmeac232ccd1bb1a4b@mail.gmail.com> Date: Tue, 10 Oct 2006 23:41:42 +0530 From: "Vamsavardhana Reddy" To: dev@geronimo.apache.org Subject: Re: Fwd: Certification Authority (CA) portlet In-Reply-To: <452BE154.70503@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18388_1727615.1160503902807" References: <22d56c4d0610052329x2e2648e8u6c5bb2ab1c02e8d6@mail.gmail.com> <22d56c4d0610092350r368c9ea9w631b040603da11ac@mail.gmail.com> <452BAC65.2000307@gmail.com> <22d56c4d0610100935u483e77d2t1a3fe23908ca428c@mail.gmail.com> <452BE154.70503@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_18388_1727615.1160503902807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline That should go as part of Keystore portlet (may be), but not CA portlet. Vamsi On 10/10/06, Hernan Cunico wrote: > > Thanks for the details Vamsi. > Not that it will be used a lot (a migration scenario) but do you have any > plans for exporting a whole keystore (and then choose the type) feature? > > Cheers! > Hernan > > Vamsavardhana Reddy wrote: > > Hernan, > > > > In the "Issue New Certificate" function, there is no selection of JKS or > > p12. The CA will only be generating a certificate and the certificate > > is usually provided in a base64 encoded text. Once the requestor > > receives this text file, he/she will need to import this certificate > > into a keystore or browser where ever the private key is stored. > > > > Regarding search, search based on more criteria is needed. I am > > evolving this as I am going about develpoing the CA. The simplest > > search (and only search as of now) is based on serial number as the > > certificates are now stored as .txt. To support other > > criteria (in an efficient way) the certificates may need to be stored > > differently. > > > > N2: A PKCS10 requests will have the name information and public-key > > combined into a sequence and signed using the private-key. This is > > usually generated by tools like keytool. Some browsers support a KEYGEN > > tag which will make the browser generate a keypair, combine the > > public-key along with a "challenge" phrase, sign the same (known as > > SignedPublicKeyChallenge) and send it to the server when the form is > > submitted. CA should be able to handle both the formats for the > > requests (and any other commonly used formats, like self-signed > > certificate). > > > > Once the CA is setup, CA will need an interface (I call this "CA Helper > > App" as of now) using which certificates can be requested and downloaded > > etc. I am in the process of developing a sample application. For a > > certificate request received, processed and user downloads certificate, > > a typical workflow would be. > > > > Step 1: A user submits a certificate request by accessing a "Request > > Certificate" page in the application through the web browser. What > > happens at this step is that the browser generates a keypair, and sends > > tha public key (packaged as a SignedPublicKeyAndChallenge) and name > > information to the application. Application saves this information in a > > "CertificateRequestStore" and provides an request-id to the user. > > > > Step 2: CA accesses all these requests in the "CertificateRequestStore" > > in a screen in the CA portlet under "List Requests waiting verification" > > and approves or rejects the requests. In a real-world scenario, CA will > > have to verify the details provided by the requestor etc. Once > > approved, the request will showup in "List Requests ready to be > fulfilled". > > > > Step 3: CA accesses the requests ready to be fulfilled and processes the > > request by issuing a certificate. This certificate is stored in the > > "Certificate Store" and the fufilled request is removed from the > > "Certificate Request Store". > > > > Step 4: User will visit a "Download Certificate" page in the "CA Helper > > App", provides the request-id given to him (in Step 1) and downloads > > his/her certificate. The "CA Helper App" will upload the ceritificate > > to the user's web browser with appropriate mime-header. The browser > > will store the certificate along with the private key and the > > certificate is ready for use. > > > > I have implemented most of it and am testing the code. I am still using > > 1.1.1 code base for development since trunk is unstable and I do not > > want to be blocked by build failures. Once I complete the testing I > > will test the code by integrating it into trunk, create a patch and > > submit to JIRA. It will be a couple of days more before the new patch > > will showup in the JIRA. > > > > Thanks, > > Vamsi > > On 10/10/06, *Hernan Cunico* > > wrote: > > > > Hi Vamsi, > > I still have not had the chance to check the patch (GERONIMO-2413) > > but I do have a few questions form your first note. > > > > 4. can you select JKS or p12 in this step? I'm thinking in client > > certificates -> HTTPS with Client Authentication scenario > > > > 5. in addition on entering the serial #, any chance to list the > > existing certificates in the CertificateStore? maybe CN + Alias > > > > N1. does that mean that the CSR will be provided as a text file (on > > a specific location) and the portlet will pick them up and list > > them? if so, that would be great and a similar structure should be > > in place for already signed certificates. > > > > N2. could you expand? > > > > As for IE, I can't find a nice way to say what I think about IE and > > VBScripts. All I can say is that probaly 80% or more ( just a wild > > guess ) of the users are using IE. Using another browser to > > create/retrieve/export the certificate and then import it into IE > > does not look like a healthy workaround. Can we add something else > > on the server side to "fill-in-the-blanks" from IE? > > > > Cheers! > > Hernan > > > > Vamsavardhana Reddy wrote: > > > Hi All, > > > > > > I have not seen any replies to my last post :( > > > > > > I have identified a few more function required. These are for > the > > > work-flow a CA might want to follow: > > > 1. List Requests: There should be two pages instead of one. > > > A) Listing of requests that are received and need to be > > > verified (once verified, the request will reach a second list) > > > B) Listing of requests that are verified and ready to be > > fulfilled. > > > 2. Logging: CA should have a separate log of requests > received, > > > verified, fulfilled, certificates revoked etc. > > > > > > Comments? Suggestions? Pointers? > > > > > > Thanks, > > > Vamsi > > > ---------- Forwarded message ---------- > > > From: *Vamsavardhana Reddy* < c1vamsi1c@gmail.com > > > > > >> > > > Date: Oct 6, 2006 11:59 AM > > > Subject: Certification Authority (CA) portlet > > > To: dev@geronimo.apache.org > > > > > > > > > Hi All, > > > > > > I have uploaded a minimal version of Certification Authority (CA) > > > portlet to the JIRA. See > > > http://issues.apache.org/jira/browse/GERONIMO-2413 . The JIRA > > also has > > > some screenshots. I do not know if anyone has got a chance to > > try out > > > the portlet. Here is an overview of this portlet's functions. > > > > > > 1. Setup Certification Authority: The "CA home" page checks if > > the CA > > > has already been initialized. If not, it will provide access to > only > > > this function viz. " Setup Certification Authority". This > function > > > enables the user to provide details of CA's identity, algorithm > > > parameters for CA's keypair & signature algorithm, a serial > > number for > > > CA's self-signed certificate, validity period for CA's keypair > and a > > > password to protect CA's privatekey. Once the details are > > submitted, a > > > keypair and self-signed certificate are generated and stored in > > > "ca-keystore". CA portlet uses KeyStoreGBean to manage its own > > keypair > > > and certificate. > > > > > > 2. Lock and Unlock CA: Once the CA is setup, upon a fresh login > to > > > Geronimo Console, users will notice that the CA is in locked > state. > > > "Unlock CA" function lets the user unlock the CA by providing > CA's > > > privatekey password (provided at the time of CA setup). Once > > unlocked, > > > the user will have access to the CA functions. "Lock CA" > > function locks > > > the CA. > > > > > > 3. View CA Details: This function enables the user to see the > > details > > > of CA' certificate and the highest serial number used to by the > CA. > > > Base 64 encoded certificate text on this screen can be > > copy+pasted into > > > a text file and sent to the requestor to designate this CA as > > trusted CA > > > in their software. > > > (Note: CA stores the serial number used at the time of setup and > > > increments it each time a certificate is to be issued.) > > > > > > 4. Issue New Certificate: This functions lets the CA issue a new > > > certificate by processing the Certificate Signing Request > > (CSR) text. > > > Upon pasting the CSR text into a textarea and submitting, a > > screen will > > > show the requestor name and public key details from the CSR and > > lets the > > > user enter validity period and select the signature > > algorithm. The next > > > screen will show all details and ask for confirmation. Once > > confirmed, > > > a certificate is issued and stored in a "CertificateStore". The > > screen > > > will show the details of the certificate issued. Base 64 encoded > > > certificate text on this screen can be copy+pasted into a text > > file and > > > sent back to the requestor. > > > > > > 5. View Issued Certificate: This function lets the user view a > > > previously issued certificate by providing the certificate serial > > number. > > > > > > More work on the way: > > > After posting the patch to JIRA, I have found the necessity for a > few > > > other functions: > > > N1. List Requests: This function will list all the certificate > > > requests that are waiting to be fulfilled and provide a link on > each > > > request-id so that the user can click on the links (instead of > > entering > > > the csr text in a textarea) and proceed directly to entering > > certificate > > > validity details etc. > > > N2. Process a certificate request based on (Name Attributes + > > > SignedPublicKeyAndChallenge): Users requesting a certificate > > through > > > web browsers may not be able to submit a PKCS10 Certificate > Request. > > > Netscape, Firefox (and other browsers??) support a KEYGEN form > > tag that > > > will let the browser, upon form submission, generate a key pair, > > combine > > > the PublicKey & a Challenge string and sign (this is the > > > SignedPublicKeyAndChallenge), encode this information in base64 > > and send > > > it along with other form fields. In this case, name attributes > > are not > > > part of a "signed" request and need to be collected separately. > > > N3. CA helper application: This application will be the > > interface for > > > users using their web browsers to request a certificate from the > CA. > > > This application will have > > > a) A page with KEYGEN tag to receive > > SignedPublicKeyAndChallenge along > > > with name attribute values from the requestor. > > > b) A link using which the users can download and install CA's > > > certificate into their browsers as a trusted certificate. > > > c) A page from which the users can download and install the > > > certificate issued to them by the CA. > > > This application can store the requests so that the CA portlet > can > > > pickup these and show in "List Requests" page. > > > > > > To be explored: > > > How to do this KEYGEN equivalent through Internet Explorer? I > > know that > > > it requires some VBScript to generate a (PKCS10?) certificate > > request > > > through Internet Explorer. I have done this way back in 1998 and > > don't > > > remember any details now :o( > > > A work around would be to make the users use a browser supporting > > KEYGEN > > > tag to request and download their certificate. The certificate > and > > > privatekey can then be exported and imported into IE. (I don't > like > > > this work around. Or should this be the only option we > provide??) > > > > > > For later: > > > CRLs etc. > > > > > > Any suggestions, comments? Anything I am missing? Am I heading > > in the > > > correct direction? > > > > > > Thanks, > > > Vamsi > > > > > > > > > > > ------=_Part_18388_1727615.1160503902807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline That should go as part of Keystore portlet (may be), but not CA portlet.

Vamsi

On 10/10/06, Hernan Cunico <hcunico@gmail.com> wrote:
Thanks for the details Vamsi.
Not that it will be used a lot (a migration scenario) but do you have any plans for exporting a whole keystore (and then choose the type) feature?

Cheers!
Hernan

Vamsavardhana Reddy wrote:
> Hernan,
>
> In the "Issue New Certificate" function, there is no selection of JKS or
> p12.  The CA will only be generating a certificate and the certificate
> is usually provided in a base64 encoded text.  Once the requestor
> receives this text file, he/she will need to import this certificate
> into a keystore or browser where ever the private key is stored.
>
> Regarding search, search based on more criteria is needed.  I am
> evolving this as I am going about develpoing the CA.  The simplest
> search (and only search as of now) is based on serial number as the
> certificates are now stored as <serial-number>.txt.  To support other
> criteria (in an efficient way) the certificates may need to be stored
> differently.
>
> N2:  A PKCS10 requests will have the name information and public-key
> combined into a sequence and signed using the private-key.  This is
> usually generated by tools like keytool.  Some browsers support a KEYGEN
> tag which will make the browser generate a keypair, combine the
> public-key along with a "challenge" phrase, sign the same (known as
> SignedPublicKeyChallenge) and send it to the server when the form is
> submitted.  CA should be able to handle both the formats for the
> requests (and any other commonly used formats, like self-signed
> certificate).
>
> Once the CA is setup, CA will need an interface (I call this "CA Helper
> App" as of now) using which certificates can be requested and downloaded
> etc.  I am in the process of developing a sample application.  For a
> certificate request received, processed and user downloads certificate,
> a typical workflow would be.
>
> Step 1:  A user submits a certificate request by accessing a "Request
> Certificate" page in the application through the web browser.  What
> happens at this step is that the browser generates a keypair, and sends
> tha public key (packaged as a SignedPublicKeyAndChallenge) and name
> information to the application.  Application saves this information in a
> "CertificateRequestStore" and provides an request-id to the user.
>
> Step 2:  CA accesses all these requests in the "CertificateRequestStore"
> in a screen in the CA portlet under "List Requests waiting verification"
> and approves or rejects the requests.  In a real-world scenario, CA will
> have to verify the details provided by the requestor etc.  Once
> approved, the request will showup in "List Requests ready to be fulfilled".
>
> Step 3: CA accesses the requests ready to be fulfilled and processes the
> request by issuing a certificate.  This certificate is stored in the
> "Certificate Store" and the fufilled request is removed from the
> "Certificate Request Store".
>
> Step 4: User will visit a "Download Certificate" page in the "CA Helper
> App", provides the request-id given to him (in Step 1) and downloads
> his/her certificate.  The "CA Helper App" will upload the ceritificate
> to the user's web browser with appropriate mime-header.  The browser
> will store the certificate along with the private key and the
> certificate is ready for use.
>
> I have implemented most of it and am testing the code.  I am still using
> 1.1.1 code base for development since trunk is unstable and I do not
> want to be blocked by build failures.  Once I complete the testing I
> will test the code by integrating it into trunk, create a patch and
> submit to JIRA.  It will be a couple of days more before the new patch
> will showup in the JIRA.
>
> Thanks,
> Vamsi
> On 10/10/06, *Hernan Cunico* <hcunico@gmail.com
> <mailto: hcunico@gmail.com>> wrote:
>
>     Hi Vamsi,
>     I still have not had the chance to check the patch (GERONIMO-2413)
>     but I do have a few questions form your first note.
>
>     4. can you select JKS or p12 in this step? I'm thinking in client
>     certificates -> HTTPS with Client Authentication scenario
>
>     5. in addition on entering the serial #, any chance to list the
>     existing certificates in the CertificateStore? maybe CN + Alias
>
>     N1. does that mean that the CSR will be provided as a text file (on
>     a specific location) and the portlet will pick them up and list
>     them? if so, that would be great and a similar structure should be
>     in place for already signed certificates.
>
>     N2. could you expand?
>
>     As for IE, I can't find a nice way to say what I think about IE and
>     VBScripts. All I can say is that probaly 80% or more ( just a wild
>     guess ) of the users are using IE. Using another browser to
>     create/retrieve/export the certificate and then import it into IE
>     does not look like a healthy workaround. Can we add something else
>     on the server side to "fill-in-the-blanks" from IE?
>
>     Cheers!
>     Hernan
>
>     Vamsavardhana Reddy wrote:
>      > Hi All,
>      >
>      > I have not seen any replies to my last post :(
>      >
>      > I have identified a few more function required.  These are for the
>      > work-flow a CA might want to follow:
>      >   1. List Requests:  There should be two pages instead of one.
>      >         A)  Listing of requests that are received and need to be
>      > verified (once verified, the request will reach a second list)
>      >         B)  Listing of requests that are verified and ready to be
>     fulfilled.
>      >   2. Logging:  CA should have a separate log of requests received,
>      > verified, fulfilled, certificates revoked etc.
>      >
>      > Comments?  Suggestions?  Pointers?
>      >
>      > Thanks,
>      > Vamsi
>      > ---------- Forwarded message ----------
>      > From: *Vamsavardhana Reddy* < c1vamsi1c@gmail.com
>     <mailto:c1vamsi1c@gmail.com>
>      > <mailto: c1vamsi1c@gmail.com <mailto:c1vamsi1c@gmail.com>>>
>      > Date: Oct 6, 2006 11:59 AM
>      > Subject: Certification Authority (CA) portlet
>      > To: dev@geronimo.apache.org <mailto:dev@geronimo.apache.org>
>     <mailto: dev@geronimo.apache.org <mailto:dev@geronimo.apache.org>>
>      >
>      > Hi All,
>      >
>      > I have uploaded a minimal version of Certification Authority (CA)
>      > portlet to the JIRA.  See
>      > http://issues.apache.org/jira/browse/GERONIMO-2413 .  The JIRA
>     also has
>      > some screenshots.  I do not know if anyone has got a chance to
>     try out
>      > the portlet.  Here is an overview of this portlet's functions.
>      >
>      > 1.  Setup Certification Authority:  The "CA home" page checks if
>     the CA
>      > has already been initialized.  If not, it will provide access to only
>      > this function viz. " Setup Certification Authority".  This function
>      > enables the user to provide details of CA's identity, algorithm
>      > parameters for CA's keypair & signature algorithm, a serial
>     number for
>      > CA's self-signed certificate, validity period for CA's keypair and a
>      > password to protect CA's privatekey.  Once the details are
>     submitted, a
>      > keypair and self-signed certificate are generated and stored in
>      > "ca-keystore".  CA portlet uses KeyStoreGBean to manage its own
>     keypair
>      > and certificate.
>      >
>      > 2. Lock and Unlock CA:  Once the CA is setup, upon a fresh login to
>      > Geronimo Console, users will notice that the CA is in locked state.
>      > "Unlock CA" function lets the user unlock the CA by providing CA's
>      > privatekey password (provided at the time of CA setup).  Once
>     unlocked,
>      > the user will have access to the CA functions.  "Lock CA"
>     function locks
>      > the CA.
>      >
>      > 3. View CA Details:  This function enables the user to see the
>     details
>      > of CA' certificate and the highest serial number used to by the CA.
>      > Base 64 encoded certificate text on this screen can be
>     copy+pasted into
>      > a text file and sent to the requestor to designate this CA as
>     trusted CA
>      > in their software.
>      > (Note: CA stores the serial number used at the time of setup and
>      > increments it each time a certificate is to be issued.)
>      >
>      > 4. Issue New Certificate:  This functions lets the CA issue a new
>      > certificate by processing the Certificate Signing Request
>     (CSR)  text.
>      > Upon pasting the CSR text into a textarea and submitting, a
>     screen will
>      > show the requestor name and public key details from the CSR and
>     lets the
>      > user enter validity period and select the signature
>     algorithm.  The next
>      > screen will show all details and ask for confirmation.  Once
>     confirmed,
>      > a certificate is issued and stored in a "CertificateStore".  The
>     screen
>      > will show the details of the certificate issued.  Base 64 encoded
>      > certificate text on this screen can be copy+pasted into a text
>     file and
>      > sent back to the requestor.
>      >
>      > 5. View Issued Certificate: This function lets the user view a
>      > previously issued certificate by providing the certificate serial
>     number.
>      >
>      > More work on the way:
>      > After posting the patch to JIRA, I have found the necessity for a few
>      > other functions:
>      > N1.  List Requests:  This function will list all the certificate
>      > requests that are waiting to be fulfilled and provide a link on each
>      > request-id so that the user can click on the links (instead of
>     entering
>      > the csr text in a textarea) and proceed directly to entering
>     certificate
>      > validity details etc.
>      > N2.  Process a certificate request based on (Name Attributes +
>      > SignedPublicKeyAndChallenge):  Users requesting a certificate
>     through
>      > web browsers may not be able to submit a PKCS10 Certificate Request.
>      > Netscape, Firefox (and other browsers??) support a KEYGEN form
>     tag that
>      > will let the browser, upon form submission, generate a key pair,
>     combine
>      > the PublicKey & a Challenge string and sign (this is the
>      > SignedPublicKeyAndChallenge), encode this information in base64
>     and send
>      > it along with other form fields.  In this case, name attributes
>     are not
>      > part of a "signed" request and need to be collected separately.
>      > N3. CA helper application:  This application will be the
>     interface for
>      > users using their web browsers to request a certificate from the CA.
>      > This application will have
>      >   a) A page with KEYGEN tag to receive
>     SignedPublicKeyAndChallenge along
>      > with name attribute values from the requestor.
>      >   b) A link using which the users can download and install CA's
>      > certificate into their browsers as a trusted certificate.
>      >   c) A page from which the users can download and install the
>      > certificate issued to them by the CA.
>      > This application can store the requests so that the CA portlet can
>      > pickup these and show in "List Requests" page.
>      >
>      > To be explored:
>      > How to do this KEYGEN equivalent through Internet Explorer?  I
>     know that
>      > it requires some VBScript to generate a (PKCS10?) certificate
>     request
>      > through Internet Explorer.  I have done this way back in 1998 and
>     don't
>      > remember any details now :o(
>      > A work around would be to make the users use a browser supporting
>     KEYGEN
>      > tag to request and download their certificate.  The certificate and
>      > privatekey can then be exported and imported into IE.  (I don't like
>      > this work around.  Or should this be the only option we provide??)
>      >
>      > For later:
>      > CRLs etc.
>      >
>      > Any suggestions, comments?  Anything I am missing?  Am I heading
>     in the
>      > correct direction?
>      >
>      > Thanks,
>      > Vamsi
>      >
>      >
>
>

------=_Part_18388_1727615.1160503902807--