I think what you're saying is reasonable. I started breaking up decrypt into decryptAndVerifySignature which is closer to how I think it should go, public keys can be passed in, and both the text and signature validity is returned. I do not expect this implementation to be final, but is a step closer to one path I think we could use. Feedback is welcome.
I have kind of bypassed the get_signature_keys/get_encryption_keys in my implementation by looking up public keys with the associated email address, however this functionality definitely would still be useful. I think it would make sense to have a top level openpgp.decrypt_message that takes in armored text and associated keys, as I think this provides an intuitive API to consumers of the application. Also, yes, signatures are made somewhat more complicated because in many cases we have to decrypt first, which seems conducive to just one overarching API call. Sean On Thu, Mar 22, 2012 at 5:12 AM, Carsten Wentzlow <[email protected] > wrote: > Hi! > ~~~ > > On 03/22/2012 01:54 AM, Sean Colyer wrote: > > Carsten -- > > > > I've been noticing that there are places where the openpgp.js code > references openpgp.keyring within certain methods. I think this is > problematic because it makes the assumption that the available keyring has > the necessary information, which can easily not be the case for extensions. > > > > Generally if we're going to have extensions that use content scripts > with a separate options page (as I believe both you and I had envisioned) > these calls will fail. I do not believe that any of these calls are truly > "essential" to operation but are seen in cases like signature checking. > (One of the cases I just ran up against is openpgp.msg.message.js:62). > Which is why I think it may not appear to be an obvious issue. > > > > Also in methods like this I think we need to change the returned value > from a string to some other data type that includes the string and other > information (such as the status of a signature). > > > > I think the longterm solution has to be to take the assumed sender's > public key (or an array of possibilities) as an input to this method. > Unfortunately in this case we don't get the ID that we absolutely need > until we're already partway through the method but I think it would be > acceptable to pass in all of the public keys associated with a given email > address and then check those keys for an ID that matches what is in the > signature. > > > > Thoughts? > > I totally agree. The current API is far from perfect. I was also concerned > about this design when implementing decryption and signature verification > because i wanted to avoid parsing the message several times. When reading > the standard it becomes clear that OpenPGP is designed as a stream of > packets which should be parsed with one cycle holding a bit of state on the > way. One way could introduce functions on message parsing the message and > returning key ids for decryption and signature verification such as: > > openpgp.get_signature_keys(openpgp_msg_message); > openpgp.get_encryption_keys(openpgp_msg_message); > > and adding more arguments to the decrypt() and verifySignature() function. > Also providing the sessionkey to decrypt the message is currently not very > well designed. I did this because of the privatekey unlocking that is > required to decrypt the message. Another problem is also that signatures > packets are mostly within the encrypted data so you can't determine the > presence of signatures before decryption. > > On the other hand we could introduce a function for that where the user > has to provide all private and public keys for decrypting e.g. > openpgp.decrypt_message(private_keys, public_keys, > string_asciiarmored_message) and calls an unlock event on the private key > used to decrypt which MUST be implemented on client side. With this > approach we only have to parse the message once. > > Maybe we should also look into other OpenPGP implementations how they > provide an OpenPGP API. > > best regards, > carsten > > _______________________________________________ > > http://openpgpjs.org >
_______________________________________________ http://openpgpjs.org
