Re: Passing certificates between processes (and machines)
From: Daniel Sie \(MS\) (dsie@online.microsoft.com)
Date: 04/16/03
- Next message: Steven L Umbach: "Re: Domain Admin Locked out!"
- Previous message: cy: "Re: SubCA unable to find Parent CA"
- In reply to: Paul Mateer: "Re: Passing certificates between processes (and machines)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Daniel Sie \(MS\)" <dsie@online.microsoft.com> Date: Tue, 15 Apr 2003 19:47:06 -0700
Paul,
You are missing the point. In order to sign, one must posses the private
key, and as I said, private key should be kept secret. If you have the
server do the signing, that means the server must have access to the private
key, and doing so will defeat the purpose of PKI.
What you can do in this case is to have the server sign using its own
private key "on behalf" of the user. Of course, the user must give consent
of you, the server, signing on his/her behalf. There are many ways to
indicate consent, and one way is to send the signature created by the server
back to the user to counter-sign the signature.
-- Thank you, Daniel Sie [MS] This posting is provided "AS IS" with no warranties, and confers no rights. "Paul Mateer" <p.mateer@meridio.com> wrote in message news:424f2ade.0304080131.2db16a61@posting.google.com... > The system in question is a document management system, and I wanted > to keep all the signing/verification cide restricted to the server > rather than having the signing component built into the clients and > the verification component built into the server. > > The clients communicate with the server via RPC so if the original > approach is questionable, would a more acceptable approach be to have > the server adopt the id of the client (using the > RpcImpersonateClient() function) for the lifetime of the > signing/verification call? In this situation the server would, in > effect be the person performing the signing. > > One problem with this approach would be if the user had access to more > than one certificate. In this case it wouldn't know which certificate > to use. How likely is this senario? I can think of a couple of > possible approaches to this, however I don;t want to spend a lot of > time on it if it's an almost unheard of situation. > > "Michel Gallant \(MVP\)" <neutron@istar.ca> wrote in message news:<#tDtzYx#CHA.3208@TK2MSFTNGP11.phx.gbl>... > > As Daniel says, you musn't even consider moving your private key (used > > for signing docs) to another "principal" for signing. > > Remember a secret known by more than 1 person, is not a secret at all! > > > > The only think which makes sense is dnld whatever doc that you > > are prepared to sign (you DO want to know what you are signing, right?), > > sign it locally, and then upload to the required repository location. > > This could probably be made fairly transparent in terms of browsing > > through database files, indicating one/many you wish to sign, and > > then start the download/sign-locally/ upload process; this is starting > > to sound like a real web-application. > > > > - Mitch > > > > "Daniel Sie (MS)" <dsie@online.microsoft.com> wrote in message > > news:#y421xw#CHA.392@TK2MSFTNGP12.phx.gbl... > > > To sign, one must posses the private key for the certificate. So, having > > > just the X509 cert is not enough. In order to have the server doing the > > > signing, you need to also pass on the private key along with the > > > certificate, and the best way to do this is via a PFX file. > > > > > > However, this model, having the server to sign using the client's key, is > > > flawed. The whole idea of PKI is to keep the private key only to yourselve. > > > > > > Can you elaborate why do you need to have the signing done on the server's > > > side? > > > > > > -- > > > Thank you, > > > > > > Daniel Sie [MS] > > > > > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > > > > "Paul Mateer" <p.mateer@meridio.com> wrote in message > > > news:424f2ade.0304040601.4983751e@posting.google.com... > > > > I'm trying to put together a system that will allow a user running a > > > > client to digitally sign a document on a server (which may be on their > > > > PC or another PC entirely) > > > > > > > > What would be the best way to pass the certificate from the client > > > > application to the server (the client and server communicate using > > > > RPC)? > > > > > > > > Is it just a case of passing the dwCertEncodingType, pbCertEncoded, > > > > and cbCertEncoded items to the server and then calling the > > > > CertCreateCertificateContext() API function to create an new > > > > certificate? > > > > If so, will it matter that the server will be running under a > > > > different NT account from the user running the client? > > > > > > > > If you can't or shouldn't pass the certificate from the client to the > > > > server in this manner, what would the recommended transfer mechanism > > > > be? > > > > > > > > Thanks for any help offered, > > > > > > > > Paul Mateer > > > > Meridio Limited > > > > www.meridio.com > > > > > >
- Next message: Steven L Umbach: "Re: Domain Admin Locked out!"
- Previous message: cy: "Re: SubCA unable to find Parent CA"
- In reply to: Paul Mateer: "Re: Passing certificates between processes (and machines)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
