I’m so happy I don’t have any *real* interop to do with WSE2 (yet). I want to learn it first, then dig into the harder stuff (and let’s not forget that this harder stuff, the interop, is the true intention of the WS* specs and therefore of WSE2, even if we do find it to be a nice neat way to deal with ws security in our .net to .net apps). Anyway, Simon Guest reports an issue with using X509 certificates other than the quickstart ones supplied with the SDK when interoping with JWSDP.

Posted from BLInk!

I had an awful moment in my WSE talk at ASPConnections thanks to great difficulty sleeping the previous night, so I want to be sure to write out my explanation of how a digital signature works here.

I have what I know is a terrific visual diagram to help explain digital signatures. What confused me when the slide popped up is seeing a private key next to the word encryption, which is correct for digital signatures but not for normal encryption. I had just walked the encryption diagrams and then hit the digital signing slide, saw that private key and my first thought was “but we don’t encrypt with a private key, we do it with a public key.” I really froze. In reality, my slide was right as I absolutely knew what I was talking about. Unfortunately i did not just allow myself to get past that moment of doubt. (which is a whole different topic about the balance of my knowledge, my presentation skills (both pretty good) and my confidence in them.)

So here’s the deal with why we are encrypting with the private key in this case. You can encrypt with any key you want, but you choose between them depending on your goals.

Encryption to achieve confidentiality: In this more common encryption scenario where we are trying to hide a message from prying eyes, we encrypt with the public key so that only the owner of the private key is able to decrypt. Anyone can see the message, but they won’t have the ability to decrypt it and view its’ actual contents.

Encryption as part of a digital signature: When digitally signing a message, we are creating a copy of the message body, hashing it (remember hashing can’t be undone) and then encrypting the hash. In the end, the validation is to ensure that the hash of the received message body matches this hash that we have sent along with the message body. If someone has mucked with the body or the hash (or both) there is no way that there will be a match on the other end. The encryption of the hash is done with a private key and then undone with the public key from the pair.

So this begs the question, why bother encrypting it if anybody can decrypt it? By encrypting with the private key, the recipient is absolutely assured that it was the sender (the only person with the private key) who created the digest. Think of this scenario: some devilish person could grab the message on its’ way, modify the message body and then create a new digest of that body. That would mean the digest would match the body when it’s received. But, that devilish person doesn’t have the correct private key to create the digest with. The recipient’s public key would recognize that immediately and the message would be invalidated.

So the process of signing doesn’t prevent anyone from mucking with the data (nor from even looking at the data – as this is the job of encrypting the message body), but just acts as a big red flag if the received message has been “violated” along the way.

Along those same lines, it’s good to note that encrypting a message body may prevent the wrong person from reading the actual data, but it is no guarantee that someone hasn’t taken the string of cipher text and altered it in anyway.