Enigform, Enigmail, FireGPG, ...

[lace]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It would be great if these extensions share OpenPGP key management. Users want to try Enigform but they don't have installed GnuPG (specially Microsoft Windows users). Of course they might install Gpg4win (http://www.gpg4win.org/) or Enigmail (http://enigmail.mozdev.org/) but some of them might would like to install only Enigform, nothing more.
What about using OpenPGP key management from Enigmail (GPL/MPL).

Trying if it is possible to sign my post.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGVvqwxNd3hwNeF68RApAnAKDGtq6O+OqL/dlr1yJ6jLyvy8jghACeLr8I
WB1Us8iTVjLuj+I5hC/YgXQ=
=GN1A
-----END PGP SIGNATURE-----

[buanzo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've selected your signed text, and verified it with FireGPG's context menu, and it verified correctly (I had previously imported your pubkey).

Now, regarding your question:

FireGPG has an EXCELLENT mechanism to provide output-capturing. It's actually a very intelligent approach. I like Enigmail's IPC.xpt implementation, and I'm currently comparing both approaches for multiplatformness (does that word even EXIST?).

Now, I believe Enigmail, FireGPG and Enigform's (myself) authors should "sit down" and discuss this, as we are, together, fulfilling OpenPGP needs in eMail (content) and web (content, and transport). So, I'm pretty sure we could come up to use a standard key-management interface (Enigmail's, for example).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGWF65AlpOsGhXcE0RAkjdAJ92nYNcFed83lc1OSdPWLEMwle2HACffnEt
mK7jxm4oft6viOrjhw6oHig=
=jaWr
-----END PGP SIGNATURE-----

[buanzo]

Talking about firegpg, the latest release has a "gpgAuth" thing that, from what I've read on gpgauth.js, provides authentication for websites that support it. It seems to be in development, but it looks like a whole different approach to what Enigform/mod_auth_openpgp want to offer. I've sent the author an email asking for more information, because gpgAuth seems interesting, and it does also sound similar to some concepts I've been discussing today with some of the guys at the local 2600 meeting.

[buanzo]

Well, I just received an eMail form Kyle Huff, author of gpgAuth in FireGPG...:

Buanzo, (and everyone else getting this too.)

I have reviewed the links you sent me Buanzo, and here is the reality;

I think gpgAuth is pretty much an obsolete approach to GPG web
authentication in light of maopenpgp. (In reality, gpgAuth was always
obsolete, we just didn't know it. Where was all this info when I was
looking for a GPG-HTTP authentication method. It would have been nice
to know this before we started gpgAuth.)

When we started this project we wanted to first prove the concept in a
plug-and-play fashion that works at the web-application level (thus the
mod_python implementation), and from there move on to the web-server
level. What you have with maopenpgp is essentially the end goal we
wanted to produce with gpgAuth (the authentication working at the
web-server level, agnostic to the web-application language).

So I guess what I am saying is I do not see a value in continuing the
development of gpgAuth, as your project seems to meet our goals
(symmetric GPG authentication for apache, with plans for IIS, an RFC
with the IETF blessing, etc).

So I am having difficulty understanding how gpgAuth is useful to
maopenpgp, as Python/Perl/Ruby/ASP/etc will have access to the
headers/server variables to allow the web-application to use maopenpgp
to authenticate users and allow access to protected/per-user content.

Additionally, I think the gpgAuth integration into FireGPG also becomes
obsolete, as there is already a method of handling maopenpgp for
Mozilla (Enigform).

Unless I do not understand maopenpgp, I think maopenpgp supersedes
gpgAuth all-together, and sadly, I do not see a point in continuing
with the gpgAuth project as the only benefit to gpgAuth that I can
see, is that the web-server need only support mod_python to work.

Thoughts anybody?

Kyle L. Huff

And this is my reply:

Kyle L. Huff wrote:
> > Buanzo, (and everyone else getting this too.)

Hey Kyle. I publicly apologize for accidentally deleting your account when you subscribed to the
buanzo.com.ar forums. Sorry, it was a busy week deleting spammers (I was using phpBB Beta 5, I'm not
at rc2. Beta5 had some captcha issues, so I went into user-is-admin-activated mode).

> > I think gpgAuth is pretty much an obsolete approach to GPG web
> > authentication in light of maopenpgp. (In reality, gpgAuth was always
> > obsolete, we just didn't know it. Where was all this info when I was
> > looking for a GPG-HTTP authentication method. It would have been nice
> > to know this before we started gpgAuth.)

I always used "OpenPGP" to refer to the open standard, instead of gpg or gnupg. You probably missed
it because of that mistake on my behalf. I should have granted the gpg term more space, as it is the
only OpenPGP implementation I'm currently supporting.

> > What you have with maopenpgp is essentially the end goal we
> > wanted to produce with gpgAuth (the authentication working at the
> > web-server level, agnostic to the web-application language).

I think of m_a_o and Enigform as "OpenPGP extensions to HTTP". My initial goal was identity and
request integrity, but today is more of a general framework.

> > So I am having difficulty understanding how gpgAuth is useful to
> > maopenpgp, as Python/Perl/Ruby/ASP/etc will have access to the
> > headers/server variables to allow the web-application to use maopenpgp
> > to authenticate users and allow access to protected/per-user content.

I don't like the idea of gpgAuth dying, but rather converting it into an authentication methodology
built over Enigform/m_a_o if you prefer. I mean, you are right: Python/PHP/etc have access to
special headers, but there is no solid implementation of a registration mechanism, for example.
gpgAuth could be the missing link, maybe?

What do you people think?