Signing and bundling data using certificates

Discussion in 'ASP .Net Security' started by Alan Fisher, Jun 17, 2005.

  1. Alan Fisher

    Alan Fisher Guest

    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
    Alan Fisher, Jun 17, 2005
    #1
    1. Advertising

  2. Alan Fisher

    [MSFT] Guest

    [MSFT], Jun 17, 2005
    #2
    1. Advertising

  3. Hello [MSFT],

    IIRC WSE does not support signing DIME attachments out of the box.

    Is this private key a raw key or is the key/cert installed in the Windows
    Cert Store??

    if in the store - you have to us CAPICOM to sign the data first and then
    attach to the SOAP message - if it is a raw key use System.Security.Cryptography.

    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > Hello,
    >
    > In .NET framework, there is a System.Security.Cryptography namespace
    > which allow you to perform both symmetric and asymmetric cryptography.
    > Yopu may take a look at this section in MSDN:
    >
    > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgui
    > de/htm l/cpconcryptographictasks.asp
    >
    > Also, you may begin with "X509Signing" in WSE QuickStart sample.
    >
    > Luke
    >
    Dominick Baier [DevelopMentor], Jun 18, 2005
    #3
  4. Alan Fisher

    Alan Fisher Guest

    Thanks for your response.

    It is using a certificate in the Windows Cert store. I need to sign a zip
    file and send the signed file as a DIME attachment. I also need to generate
    a hash of the signed data and include it in the SOAP body. Based on this, I
    presume I need to use CAPICOM?

    Regards
    Alan


    "Dominick Baier [DevelopMentor]" <>
    wrote in message news:...
    > Hello [MSFT],
    >
    > IIRC WSE does not support signing DIME attachments out of the box.
    >
    > Is this private key a raw key or is the key/cert installed in the Windows
    > Cert Store??
    >
    > if in the store - you have to us CAPICOM to sign the data first and then
    > attach to the SOAP message - if it is a raw key use
    > System.Security.Cryptography.
    >
    > ---------------------------------------
    > Dominick Baier - DevelopMentor
    > http://www.leastprivilege.com
    >
    >> Hello,
    >>
    >> In .NET framework, there is a System.Security.Cryptography namespace
    >> which allow you to perform both symmetric and asymmetric cryptography.
    >> Yopu may take a look at this section in MSDN:
    >>
    >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgui
    >> de/htm l/cpconcryptographictasks.asp
    >>
    >> Also, you may begin with "X509Signing" in WSE QuickStart sample.
    >>
    >> Luke
    >>

    >
    >
    >
    Alan Fisher, Jun 20, 2005
    #4
  5. Hello Alan,

    yes - CAPICOM is the way to go (or X509Certificate2 in whidbey)

    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > Thanks for your response.
    >
    > It is using a certificate in the Windows Cert store. I need to sign a
    > zip file and send the signed file as a DIME attachment. I also need to
    > generate a hash of the signed data and include it in the SOAP body.
    > Based on this, I presume I need to use CAPICOM?
    >
    > Regards
    > Alan
    > "Dominick Baier [DevelopMentor]"
    > <> wrote in message
    > news:...
    >
    >> Hello [MSFT],
    >>
    >> IIRC WSE does not support signing DIME attachments out of the box.
    >>
    >> Is this private key a raw key or is the key/cert installed in the
    >> Windows Cert Store??
    >>
    >> if in the store - you have to us CAPICOM to sign the data first and
    >> then attach to the SOAP message - if it is a raw key use
    >> System.Security.Cryptography.
    >>
    >> ---------------------------------------
    >> Dominick Baier - DevelopMentor
    >> http://www.leastprivilege.com
    >>> Hello,
    >>>
    >>> In .NET framework, there is a System.Security.Cryptography namespace
    >>> which allow you to perform both symmetric and asymmetric
    >>> cryptography. Yopu may take a look at this section in MSDN:
    >>>
    >>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpg
    >>> ui de/htm l/cpconcryptographictasks.asp
    >>>
    >>> Also, you may begin with "X509Signing" in WSE QuickStart sample.
    >>>
    >>> Luke
    >>>
    Dominick Baier [DevelopMentor], Jun 20, 2005
    #5
  6. Alan Fisher

    Guest

    Alan Fisher wrote:
    > 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).
    , Jun 23, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim  Wong

    Signing Certificates

    Tim Wong, Aug 23, 2005, in forum: Java
    Replies:
    13
    Views:
    815
    Greg Stark
    Sep 1, 2005
  2. Tom Parson
    Replies:
    2
    Views:
    481
    Bjorn Abelli
    May 22, 2006
  3. n33470

    Are SSL certificates and x.509 certificates the same?

    n33470, Dec 14, 2005, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    177
    n33470
    Dec 14, 2005
  4. Todd Aceman

    Getopt::Long and bundling.

    Todd Aceman, Oct 26, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    182
  5. Roedy Green

    update on Code Signing Certificates

    Roedy Green, Dec 27, 2012, in forum: Java
    Replies:
    0
    Views:
    221
    Roedy Green
    Dec 27, 2012
Loading...

Share This Page