Re: Location of users private key in PKI solution

From: Paul Mateer (p.mateer@meridio.com)
Date: 04/10/03 

From: p.mateer@meridio.com (Paul Mateer)
Date: 9 Apr 2003 15:25:29 -0700

Firstly, thanks to everyone for the replies.

It sounds as though I should design the system so that the client
application performs the signing operation as that is the most likely
place for the private key to reside. I had been trying to avoid this
as it would have been a neater solution to have all the
signing/verification technology incorporated into the server.

Presumably the steps in signing will be as follows:

1) Client indicates desire to sign document
2) Document is transferred from server to client
3) User selects Certificate (and key) to sign with
4) Signature is generated for document
5) Signature is transferred from client to server for storage

I do have an additional question though. Assuming that signing must
occur on the client machine, is it still possible for the server to
perform the signature verification? If I design the system to generate
a signature with the signers certificate embedded in it then the
server should be able to validate the signature, right? On that note,
would there be any problem with the server establishing the chain of
trust back to a root CA?

Thanks for the help,

Paul Mateer
Meridio Limited
www.meridio.com

"Michel Gallant \(MVP\)" <neutron@istar.ca> wrote in message news:<OzQ#Acr$CHA.1156@TK2MSFTNGP12.phx.gbl>...
> Paul,
> The private key is typically located on the users machine.
> This document describes the location of the encrypted private
> key blob itself (although the exact details of location depends to
> some extent on WinOS):
>
> http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/prork/prdd_sec_grhc.asp
>
> If your keypair was generated with an "exportable" private key,
> than it is fairly easy to port your credentials securely, using an exported
> .pfx file (in pkcs#12 format) which contains a (suitable chosen and strong)
> password protected encrypted private/public key container.
> You can put these credentials on a floppy or CD-ROM and use directly
> (say via CAPICOM) or import to any other win machine so you can
> easily sign, encrypt etc. from any machine. Of course, this is only as secure
> as your physical security of guarding that .pfx file and ultimately how strong
> your pfx password is.
> This is what I call a "poor man's" portability of your signing credentials, as
> an alternative to smart-card technology.
> You can do this for any type of certificate (Class 3 code-signing, personal S-MIME
> cert etc..).
>
> The following shows a typical implementation leveraging basic portability
> of signing credentials:
> http://pages.istar.ca/~neutron/cryptoutils/jacrypt/
>
> - Michel Gallant
> MVP Security
> JavaScience Consulting
> http://pages.istar.ca/~neutron
>
> "Paul Mateer" <p.mateer@meridio.com> wrote in message
> news:424f2ade.0304090410.6a05da60@posting.google.com...
> > Hi,
> >
> > I am trying to design a document signing solution for an existing
> > document management system, and I have a question (or two) that will
> > influence the design.
> >
> > Basically I need to know where a users private key is located in a PKI
> > solution. Does it reside on the users machine, or is it held in some
> > sort of central repository (with access to a particular key restricted
> > to the user in question).
> >
> > Does the answer to this question depend upon the PKI solution in use
> > (I'm particularly interested in Windows Certificate Services)? If a
> > users private key is installed on their PC how to they sign documents
> > and emails if they are working of a different PC?
> >
> > If private keys are located in some central repository, then I can
> > design a system where the document repository (at the request of a
> > user) signs a document on their behalf (by assuming the identity of
> > the user and then acquiring their private key for encryption).
> >
> > If private keys are stored on individual PC's then my solution will
> > have to transfer the document to be signed to the client PC, sign it
> > and then return the signature to the server.
> >
> > My knowledge of PKI is somewhat limited, so hopefully I haven't asked
> > any questions that are stupid or don't make sense.
> >
> > Thanks for any help on this matter,
> >
> > Paul Mateer
> > Meridio Limited
> > www.meridio.com

Relevant Pages

  • Re: Location of users private key in PKI solution
    ... If clients and server are Windows platforms, check out CAPICOM as it would ... > It sounds as though I should design the system so that the client ... > application performs the signing operation as that is the most likely ... >> The private key is typically located on the users machine. ...
    (microsoft.public.security)
  • Re: Location of users private key in PKI solution
    ... If clients and server are Windows platforms, check out CAPICOM as it would ... > It sounds as though I should design the system so that the client ... > application performs the signing operation as that is the most likely ... >> The private key is typically located on the users machine. ...
    (microsoft.public.win2000.security)
  • Re: Location of users private key in PKI solution
    ... It sounds as though I should design the system so that the client ... signing/verification technology incorporated into the server. ... Presumably the steps in signing will be as follows: ... > The private key is typically located on the users machine. ...
    (microsoft.public.security)
  • Re: Passing certificates between processes (and machines)
    ... key, and as I said, private key should be kept secret. ... server do the signing, that means the server must have access to the private ... of you, the server, signing on his/her behalf. ...
    (microsoft.public.security)
  • Re: Passing certificates between processes (and machines)
    ... key, and as I said, private key should be kept secret. ... server do the signing, that means the server must have access to the private ... of you, the server, signing on his/her behalf. ...
    (microsoft.public.win2000.security)