Alan said:
I am attempting to use a private key from a digital certificate that I have
installed on my pc to sign some data (a dime attachment) which is sent to a
WebService. The scenario is very similar to the one explained in
http://msdn.microsoft.com/library/d...-us/seccrypto/security/digital_signatures.asp
I wish to use the .Net framework to acheive this. I have looked at the WSE
2.0 sample code and have successfully located the certificate in the store
but am now struggling with signing the data.
Can someone point me in the right direction? Sample code would be much
appreciated
Also, how does the destination user actually get the public key?
TIA
Alan
the technology is asymmetric key cryptography .... there are a pair of
keys ... and what one key encodes the other key decodes. This is
different from symmetric key cryptography where the same key is used
for both encoding and decoding.
there is a business process called public/private key ... where one key
is made public (public key) and the other key is kept confidentential
and is never divulged (private key).
there is a business process called digital signature authentication ...
where a hash of some data is made and then encoded with private key.
the corresponding public key can be used to decode the digital
signature ... and then compares it with a recomputed hash of the
message. If the recomputed hash and the decoded digital signature are
the same, then the recipient knows that 1) the message hasn't been
modified and 2) authenticates the originator of the message.
in standard business practice ... somebody registers their public key
with destinations and/or relying parties ... in much the same way they
might register a pin, password, SSN#, mother's maiden name, birth date,
and/or any other authentication information. The advantage of
registering a public key over some sort of static, shared secret ... is
that a public key can only be used to authenticate digital signatures
..... it can't be used for impersonation (as part of generating a
digital signature).
http://www.garlic.com/~lynn/subputkey.html#certless
On-file, static, shared secret authentication information can not only
be used for authentication ... but also impersonation.
http://www.garlic.com/~lynn/subpubkey.html#secrets
Digital certificates are a business process that addresses an offline
email scenario from the early 80s ... where the recipient dails up
their local (electronic) post office, exchanges email, hangs up ... and
then is possibly faced with authenticating some first time
communication from a total stranger (and had no recourse to either
local information and/or online information for obtaining the necessary
information). It is somewhat analogous to the "letters of credit" used
in the sailing ship days.
A trusted party "binds" the public key with some other information into
a "digital certificate" and then digital signs the package called a
digital certificate. The definition of a "trusted party" is that
recipients have the public key of the "tursted party" is some local
trusted public key repository (for instance browsers are shipped with a
list of trusted party public keys in an internal trusted public key
repository).
The originator creates a message or document of some sort, digital
signs the information and then packages up the
1) document,
2) digital signature, and
3) digital certificate (containing some binding of their public key to
other
information)
and transmits it.
The recipient/relying-party eventually gets the package composed of the
three pices. The recipient looks up the trusted party's public key in
thier trusted public key repository, and validates the digital
signature on the enclosed digital certificate. If the digital
certificate is valid, they then check the "bound" information in the
digital certificate to see if it relates to anything at all they are
interested in. If so, then they can take the sender's public key
(included in the digital certificate) and validate the digital
signature on the message. If that all seems to be valid ... they then
make certain assumptions about the content of the actual message.
In normal business operations ... where there is prior relationship
between the sender and the receiver ... the receiver will tend to
already have authentication information about the sender in a local
trusted (public key) repository (and not have to resort to trust
redirection thru the use of trusted party public keys and digital
certificates).
Another scenario is that in the early 90s, there were x.509 identity
digital certificates where the trusted parties (or certification
authorities ... i.e. CAs) were looking at grossly overloading the
"bound" information in the digital certificates with enormous amounts
of personal information. This was in part because the CAs didn't have a
good idea what future relying parties might need in the way of
information about individuals that they were communicating with.
You started to see some retrenchment of this in the mid-90s ... where
institutions were started to realize that x.509 identity digital
certificates grossly overloaded with personal information represented
significant privacy and liability issues. Somewhat as a resort there
was some retrenchment to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
which contained little more information than the individual's public
key and some sort of account number or other database index. The actual
database contained the real information. However, it is trivial to show
that such replying-party-only certificates not only violate the
original purpose of digital certificates, but are also redundant and
superfluous ... aka the relying party registers the indivuals public
key in their trusted repository along with all of the individual's
other information. Since all of the individual's information (including
their public key) is already in a trusted repository at the relying
party, having an individual repeatedly transmit a digital certificate
containing a small, static, subset of the same information is redundant
and superfluous.
In some of the scenarios involving relying-party-only certificates from
the mid-90s it was even worse than redundant and superfluous. One of
the scenarios involved specification for digitally signed payment
transactions with appended relying-party-only digital certificate.
Typical payment transactions are on the order of 60-80 bytes. The
typical erlying-party-only digital certicates involved 4k-12k bytes.
Not only were the relying-party-only stale, static digital
certificates, redundant and superfluous, they also would represent a
factor of one hundred times payload bloat for the payment transaction
network (increasing the size of payment transaction by one hundred
times for redundant and superfluous stale, static information).
