A point I've seen both ways
What you describe will work, but there's an additional potential check. In the body of the message hashed by the sender can be, minimally, some plain text, and preferably, a "inner signed signature", or ideally inner signature and trusted time stamp, also signed by a trusted third party.
Again, you method will work, but I try to add features that can add a human as well as a pure crypto check. Howard C. Berkowitz 14:01, 10 November 2008 (UTC)
- Yes, once you have the basic method, you can add other things. Use digital signatures to build either a PKI structure or a PGP-type "web of trust", put them in certificates, sign time stamps, or archived copies, build signature mechanisms that require a majority of keyholders to sign something, ... All those could be added in later sections, and should certainly at least be linked to. Other issues like the legal status of digital signatures also need discussion.
- But I think the introduction needs more-or-less exactly what is there, a description of the signature mechanism itself. Maybe some elaboration on what a hash and a public key cryptosystem are, and what they bring to this party, but no other complications in the overview. Sandy Harris 11:35, 11 November 2008 (UTC)
Should it be established that the signer should have first authenticated with at least two factors? Howard C. Berkowitz 14:07, 10 November 2008 (UTC)
- Current text has "obtain the sender's public key and verify its validity". I think that is all we need there. There certainly needs to be something somewhere on validating keys. My guess would be a small section (maybe only a paragraph?) later in this article on establishing trust in keys, with links to text on the more general problem in public key and/or information security. Sandy Harris 11:41, 11 November 2008 (UTC)
- We are probably in agreement. For whatever reason, "verify its validity" just didn't register. Perhaps alternate wording such as "authenticate the key integrity and source", or something along those lines? I agree a short statement here with pointers elsewhere is all that's really needed; perhaps some reinforcement that a key is often (but not always) within a certificate. Howard C. Berkowitz 15:45, 11 November 2008 (UTC)
Is there enough context?
There's nothing incorrect here, but I'm not sure that is sufficient for Approval. My sense is that this really has to be interlinked with material on the source of trust of the signature, be it PKI or PGP-style. I think some application examples are needed, not just origin but probably nonrepudiation. Howard C. Berkowitz 01:51, 21 March 2009 (UTC)
- Yes, there's a lot more that could and probably should be said. Once you've got sigs, you can build timestamped or notarized documents, certificates, a PKI, a web of trust, ... Some of that is discussed at Cryptography#Combination_mechanisms. Should parts of it be duplicated or moved here? Or into a PKI article? Does it need expansion? Sandy Harris 11:12, 21 March 2009 (UTC)
- My thought would be that the minimum needed to get this to approval would be a well-developed Related Articles page, with at least definitions of terms. Do you know our "lemma" trick for definitions and R-templates?
- The article needs to say that trust needs to be verifiable, and at least mention some of the approaches (centralized/hierarchical vs. distributed web trust, trusted timestamps, certificate revocation, etc.). Using the lemma method, as long as you have a good definition, the links don't have to be red.
- Thinking out loud here, I wonder if there should be links that address common real-world problems. What do you do when you encounter a self-signed certificate to which your browser objects; when do you let it in? What are the real dangers of the SSL/hash situations? How will signed DNS roots affect operation, much less secure DNS as a whole, and how does it interact with PKI? As you know, I've started some of the DNS. Howard C. Berkowitz 16:05, 21 March 2009 (UTC)