Re: makecert EnvelopedData 'bad key'
From: Michel Gallant (neutron_at_NOSPAMistar.ca)
Date: 11/17/03
- Next message: Ryan Menezes [MSFT]: "Re: A question about CRYPT_MACHINE_KEYSET flag from CryptAcquireContext"
- Previous message: magister: "Re: makecert EnvelopedData 'bad key'"
- In reply to: magister: "Re: makecert EnvelopedData 'bad key'"
- Next in thread: magister: "Re: makecert EnvelopedData 'bad key'"
- Reply: magister: "Re: makecert EnvelopedData 'bad key'"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 17 Nov 2003 13:46:33 -0500
"magister" <MBaskey2003@yahoo.com> wrote in message
news:a000d88c.0311171033.903e885@posting.google.com...
> > > What would be the best way to create a certificate for a client
> > > machine for a client machine, which would allow encryption on the
> > > client and decryption on the server?
> >
> > The question is who is the encryption targetted to? Don't forget that SSL/TLS
> > protocol already takes care of a lot of what you might be wanting to do!
> >
> > If it is only meant for a server process to decrypt, then an AT_KEYEXCHANGE
> > certificate, issued to server is what you might need. The client then could use the
> > standard enveloping approach:
> >
> > - generate a new cryptographically-strong and random secret encryption key (e.g. 3DES or AES
if
> > available ..)
> > - bulk encrypt any size data with this secret symmetric key
> > - encrypt this secret symmetric key with the server-certificate's public key
> > - package this up and send it to server (a good structured packaging of this is
CMS/EnvelopedData
> > format pkcs#7)
> >
> > Note that it if you use this approach, you might want have the client issued a cert too.
> > This way, the client can sign (with the client-cert's publickey) the enveloped data above,
> > and that way, the server can ensure that someone hasn't maliciously encrypted bad data to the
> > server (always possible in PKI, since the RSA public keys are usually publically available).
> >
> > > Many thanks mitch, mvp for a good reason
> > Geez, I just like using MS/crypto technology (mainly to build what I consider to
> > be useful utilities). Certainly NOT because my main background is/was Java ;-)
>
> Yes this is something like what I want to do, but I thought signing
> occurs with the clients private key? no?
Yes, that should be signed with private key (verifiable with public key).
> I think maybe I don't even need the server to decrypt anything, but
> rather 3 clients. Client A submits some encrypted files with
> signiture (with options to allow either just client B or both client B
> and C to decrypt) , client B validate signature, and cosign data, and
> can always decrypt everything (admin) (may also decrypt and reencrypt
> for client C), client C can verify cosignature from client B and
> signature from client A and decrypt and thus process files in the
> workflow.
>
> I am not sure I would have a symetric key encryption, because I am
> basically in a safe intranet environment, but still must ensure that
> documents can be pass confidentially and only for certains eyes only.
> I would think asymetric where client A's file are encrypted with the
> public key of client B and sign with their own (client A's) private
> key is what I am looking for. However if the file was intended for
You can only encrypt (or sign) a small amount of data with RSA asymmetric
cipher .. typically ~ (key size -11), so for standard 1024 bit (128 bytes),
you can only encrypt 117 bytes of data! That is why you need symmetric
cipher.
If you want confidentiality, you need encryption (over the wire with SSL,
persistent on desktop or server via file encryption of some sort).
> client B and C then is there a way to encrypt the same file with 2
> public keys, or perhaps I could have client B as the master key
> holder, and essentially owns the private key of client C as well as
> its own.
>
> I know my question is getting more complex, and perhaps a bit
> convuluted, hopefully however some logic does come through in my
> explaination. Perhaps also you can see some flaw in it. Anyway if
> there is a more comprehensive resource on using makecert that you know
> of it would help me, even just knowing that what I explain above is
> possible, it would be a great help. The scant info on msdn and the
> varied responses on usenet postings gives me very little to go on.
The best (and only detailed) overview of makecert and related is:
http://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/signing.asp
> Although from a non-Java background, I also am finding CAPICOM to have
> the potential I need to make a really nice secure workflow oriented
> web app, if I could only work out these certs. Unfortunately
> Certificate Services is not a possibility, but my impression is that
> makecert will do.
CAPICOM's strength is ability to very easily handle CryptoAPI certificate
stores, and generate and verify standard CMS/SignedData, EnvelopedData
and Authenticode SignedCode. It does not have functionality to generate certs
or keypairs explicitly.
> Also concerning the makecert command that you did provide me, how can
> I make that certificate appear as trusted.....? Surely if this is for
> my local intranet I do not have to pay Verisign?
>
If you generate a "self-signed" certificate, (using -r switch), then you can easily
make it trusted by importing the certificate to the Root certificate store (after
exporting it, say, from your CU MY cert store). Since the Subject is the same
as the Issuer, this will provide trust ladder validation, even though the certs
are in fact the same :-)
- Mitch Gallant
- Next message: Ryan Menezes [MSFT]: "Re: A question about CRYPT_MACHINE_KEYSET flag from CryptAcquireContext"
- Previous message: magister: "Re: makecert EnvelopedData 'bad key'"
- In reply to: magister: "Re: makecert EnvelopedData 'bad key'"
- Next in thread: magister: "Re: makecert EnvelopedData 'bad key'"
- Reply: magister: "Re: makecert EnvelopedData 'bad key'"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
