by means of Win32 Crypto API?
I studied Win32 Crypto API documentation and found how to extract all
information from .p7m files but did not found how to add signatures
without
access to private key. All functions for adding signature require
access to
certificate with private key.
I need it because files to be co-signed by many users are stored on a
server. Users can download file, read it, co-sign (actual sign is
performing
in smart card). After sign it would be good to upload to server only
signed
hash and signer's certificate with public key, which have to be added
to
existing .p7m file on server. It could minimize network traffic
(original
data to be signed are huge and must be signed by many users) and allow
to not
lock file on server for time period while user is reading and signing
it. But
I don't know how to add signature and certificate to crypto message
without
access to private key, which never can be transferred via network.
Can anybody help me?
Thanks in advance,
Leonid
Is your question:
How do I use MS API to compose an SMIME message? If so:
Have you read rfc 2633?
I dont know what you mean when you say signing is encryption. Do you
have a key pair (RSA for SMIME)? Does the receiver have the public key,
or are they to receive it as a certificate?
Will the receiver be getting this message as an email (using an smime
compatible email client), or are you writing the client as well?
The private and public keys are mathematically linked, you cant just
use one and any old number for the other. Note that the signing and
encryption key pairs need not be the same.
http://www.ietf.org/html.charters/smime-charter.html
I hope thats what youre after.
rou...@yahoo.com wrote:
> Leonid,
>
> Is your question:
> How do I use MS API to compose an SMIME message? If so:
My question is: How do I use MS Win32 CryptoAPI to compose PKCS#7
message from original data, signed hash of this data and signer's
certificate with public key (without private key)?
> Have you read rfc 2633?
Yes, I read it and 3851, also 2315. But there is nothing about MS Win32
CryptoAPI in these documents, because they are
recommendations/standards, not implementation.
> I dont know what you mean when you say signing is encryption. Do you
> have a key pair (RSA for SMIME)? Does the receiver have the public key,
> or are they to receive it as a certificate?
I meant that signing is encryption of HASH of original data to be
signed with private key.
Key pair is inside smart card. Signing (encryption of hash) is
performed inside smart card, it is never possible to get private key
from smart card, but it is possible to get certificate with public key
from smart card.
> Will the receiver be getting this message as an email (using an smime
> compatible email client), or are you writing the client as well?
My task is not sending messages by email. The task is the following:
documents to be signed are stored in a database or filesystem on a
server and accessible for read/sign via web application. Users can
download either original data or signed data in PKCS#7 format. Users
have to co-sign original data, in this case signatures and certificates
must be added to PKCS#7 data on a server. I need to develop
application, which will consist of two parts: client part and server
part. Client part has to download data from server, show data to user
and sign it in smart card. After sign, signed hash and certificate with
public key must be uploaded to server. Server part must receive signed
hash and certificate and add this new co-signer's information to
existing PKCS#7 data.
I know how to extract ANY existing information from PKCS#7 format by
Win32 CryptoAPI, but I don't know how do I compose PKCS#7 signed data
by Win32 CryptoAPI without access to private key. I wonder, whether is
it possible at all with Win32 CryptoAPI? Because all functions require
access to private key.
I know that it is possible to use OpenSSL or other open source
libraries to perform required task, but my question is about Win32
CryptoAPI.
"Dlugi" <pgasz...@gmail.com> wrote in message
news:1132354476.7...@g14g2000cwa.googlegroups.com...
> Go to www.cryptigo.com
>
"Dlugi" <pgasz...@gmail.com> wrote in message
news:1132354274....@g44g2000cwa.googlegroups.com...
> Go to www.cryptigo.com (smime)
>
You imply that you get up to CryptSignMessage(). I think you must get
this far, otherwise you wouldnt be asking about PKCS#7 format, you'd
just be asking about using smart cards for cryptoapi. But if you get
this far, then whats CryptoAPI got to do with it? So I still dont get
where you're stuck.
If you do have a signed blob (the hash). Why then do you ask about the
private key?
> ...is never possible to get private key from smart card, but it is
possible to get certificate with public key from smart card.
Working as intended. Isnt this what you need to store with the message,
a public key certificate?
If you're writing a web app, I'd probably go with XML/SAML over SSL. If
PKCS#7 is mandated however, then I recommend creating a PKCS#7 class,
which follows ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc In
particular:
Use CertSaveStore to get a X509 certificate store blob for all of the
signers, and add it to the SignedData certificates type
Add the message itself to SignedData contentInfo type
Add the signers hashes to the SignedData signerInfos type
I think in all cases you can convert octet strings to base64, which
might be prefferable for a web app.
PS I think signed and not encrypted is p7s not p7m.
I hope I helped this time.
rou...@yahoo.com wrote:
> I'm sorry, I'm a bit slow but I'm finally starting to get it. There is
> no encryption, each viewer adds their signature to a document so you
> have a list of people that have viewed it. Don't know what the
> "spammer" comment was about, seems legitimate to me.
>
> You imply that you get up to CryptSignMessage(). I think you must get
> this far, otherwise you wouldnt be asking about PKCS#7 format, you'd
> just be asking about using smart cards for cryptoapi. But if you get
> this far, then whats CryptoAPI got to do with it? So I still dont get
> where you're stuck.
>
> If you do have a signed blob (the hash). Why then do you ask about the
> private key?
I didn't ask for private key, I meant that CryptMsgControl function
with CMSG_CTRL_ADD_SIGNER operation, which I tried to use for adding
signature to existing message on server, requires private key.
>
> > ...is never possible to get private key from smart card, but it is
> possible to get certificate with public key from smart card.
>
> Working as intended. Isnt this what you need to store with the message,
> a public key certificate?
>
> If you're writing a web app, I'd probably go with XML/SAML over SSL. If
> PKCS#7 is mandated however, then I recommend creating a PKCS#7 class,
> which follows ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc In
> particular:
>
> Use CertSaveStore to get a X509 certificate store blob for all of the
> signers, and add it to the SignedData certificates type
> Add the message itself to SignedData contentInfo type
> Add the signers hashes to the SignedData signerInfos type
Yes, I can use CertSaveStore or CryptMsgGetParam to get signer's
certificate from signed message, I can use CryptMsgGetParam to get
other necessary information.
But the question is HOW to ADD certificates and signed hashes to
message using Win32 CryptoAPI? What functions can be used to perform
this task?
It is sure possible to develop PKCS#7 and ASN1 encoding algorithm
myself or use encoders from OpenSSL or other open source libraries, but
I would like to do my task with Win32 CryptoAPI (the less different
libraries - the less possible bugs and the less problems with versions
compatibility). Of course, if it is possible.
Do functions, which can be used for adding certificates and signed
hashes to message, exist in Win32 CryptoAPI?
If exist, could you please point me to them?
> I think in all cases you can convert octet strings to base64, which
> might be prefferable for a web app.
>
> PS I think signed and not encrypted is p7s not p7m.
I don't know exactly, RFC 2633 specifies the following MIME types and
file extensions:
.p7m - application/pkcs7-mime (signedData,envelopedData)
.p7c - application/pkcs7-mime (degenerate signedData "certs-only"
message)
.p7s - application/pkcs7-signature
Several different programs for sign files, which I evaluated before,
saved signed files with .p7m extension, so I use this extension too.
You're doing something like this?
CryptAquireContext for the smart card CSP
CryptGetUserKey using the cert (and the CSP handles the
private key bit)
CryptMsgOpenToDecode using the smart card provider
CryptMsgUpdate providing the original message
CryptMsgControl using CMSG_CTRL_ADD_CERT and signing cert
CryptMsgControl using CMSG_CTRL_ADD_SIGNER and signer
info
CryptMsgGetParam using CMSG_ENCODED_MESSAGE to produce
composed message
Good luck with your project!
Sure, I am doing something similar on client, where smart card is
inserted in reader and I can get HCRYPTKEY* phUserKey by call of
CryptGetUserKey and use phUserKey in subsequent functions calls. After
all I can get signing certificate and signature and upload them to
server.
But the question is: how to compose encoded message (add certificate
and signature) on server, where phUserKey handle from smart card CSP is
not accessible?
As far as I know the CryptMsg api's wont be any good cause they'll be
wanting to do the hash, which you've already got. Maybe another reader
has successfully pre-stored the hash and convinced the update handler
not to try and do it again.
I'm sorry but I know of no other way, using CAPI, to compose a PKCS#7
message. Pity you can't download the whole document to the client or
compose it manually.