I'm excited to see this work, Abhilash!
Do you have a demonstration instance of this code up and running anywhere?
On 07/31/2013 02:43 AM, Abhilash Raj wrote:
- Signature verification using
python-gnupgwas a PITA to me for sometime. The way it accepts the string and signature for detached signature is not documented at all and is converse of what I could think of. It just occurred to me to try out the other possibility which turned out to be the right way.
have you reported this as a bug to the python-gnupg folks? I imagine a patch to improve their documentation would be welcomed.
- Deciding the structure of the signed message that we were going to send out. Initially it was decided to leave sender's signature intact so that if someone wants to verify it he can do it, but there can-not be two 'pgp-signature' parts in a conventional multipart/signed message. I wrote the code to follow an internet-draft[2] i discovered one-day. But then I commented out the code and also added another format
mutipart/alternative { multipart/signed { text/plain, application/pgp-signature } multipart/signed { text/plain, application/pgp-signature } }
Some furthur assistance and research on which format do MUAs support the most should be implemented.
While you can't have two pgp-signature parts in a conventional multipart/signed message, you *can* have two OpenPGP signatures within a single pgp-signature part.
So it sounds like you have three options:
two OpenPGP signatures within a single pgp-signature part
your duplicated multipart/alternative approach
the recommendation in the internet draft you found.
Of those three, i recommend going with 0 first, then 2, then 1. Having a message with dual signatures is going to be surprising to many MUAs that haven't thought through the implications, no matter what formatting you choose. keeping the message structure simple and standard (suggestion 0) seems like it will be the least surprising.
Have you generated example messages of these forms and tried them with various OpenPGP-capable MUAs?
Future Plan: The next plans for this project include testing all the above parts thoroughly and then moving on to creating a PKI for the key.
Can you explain more what you mean by "a PKI for the key"? I'm curious.
Nice work on all this! I look forward to seeing it in action!
Regards,
--dkg