Robert J. Hansen wrote: > Daniel Kraft wrote: >> Ok, I see.... So you don't think that Enigmail would want to add >> some extra functionality over GnuPG's OpenPGP stuff?
No.
> Although I am part of Enigmail's help team, I don't have any say in
> Enigmail's future direction -- nor do I want to have a say. :)
Also a team member
> What I will say is this: historically, Enigmail has been tightly focused
> on supporting OpenPGP via use of GnuPG. That's been one of our
> strengths over the years. As soon as we open the door and start
> supporting things that are, at present, completely unrelated to OpenPGP,
> we lose our focus.
Indeed. There is only one feature of Enigmail that I can think of that is not
dependent on GnuPG -- Per-Recipient Rules. Everything else relies in one way
or another on GnuPG. Enigmail is a front-end to GnuPG for Mozilla-based email
platforms. That's all. To borrow from Doug McIlroy, "Do one thing and do it
well." We believe we do.
>
>> Of course we could try to become an official part of OpenPGP.
>
> It's not necessary that it become official. After all, the HKP
> keyserver protocol isn't documented in RFC4880. It's just necessary
> that it become a de-facto standard way of querying for keys. If/when it
> becomes a de-facto standard, GnuPG will quickly add support for it as a
> keyserver protocol, and Enigmail will follow suit.
HKP has been the de-facto standard for querying OpenPGP keyservers since it
was first implemented by Marc Horowitz. It is documented in David Shaw's draft
RFC and this is the document the SKS keyservers follow. (I should know, I've
written enough SKS patches for things in the draft but that nobody uses so
that SKS is 'draft conformant'.) It keeps getting discussed as needing an
informational RFC to officially document it, but most folks are comfortable
with the draft.
>
>> Do you think this is an extension that could eventually be accepted
>> into OpenPGP?
Personal opinion, no. The OpenPGP standard doesn't deal with key storage or
retrieval issues.
> This is a question that should be addressed to the OpenPGP working
> group. :)
As well as the GnuPG developer's list.
I also want to return to Rob's bootstrapping discussion.
>> There's a serious bootstrapping problem here.
Very.
>> Enigmail's mission statement: "We provide a convenient front-end to
>> GnuPG's OpenPGP functionality. No more and no less."
>>
>> GnuPG's mission statement: "We provide implementations of OpenPGP
>> (RFC4880) and S/MIME (RFC5721). No more and no less."
RFC4880 and extension RFCs such as Camellia and ECC.
Enigmail relies on GnuPG for all keyserver operations.
GnuPG follows the hkp draft for assembling hkp requests.
HKP (and its most widespread implementation SKS) allowing searching by key ID
or words. Key ID may by short, long or V4 fingerprint. Words are taken from
parsing the user IDs on the key, eg, my email address parses to three words:
jpclizbe, gingerbear, and net, then add first and last names.
Key IDs up to the fingerprint and User ID strings. Retrieval through GnuPG
(for Enigmail's purposes). Those are what is in place. Those are the existing
limitations.
Each tool depends on standards, either RFCs or a de-facto one like HKP.
Focusing on Enigmail for this is like designing a municipal water supply by
first speccing out the faucets. You need to be much higher on the protocol
ladder to have this done by Enigmail.
Have you talked to the monkeysphere folks? I think they have done some work
integrating OpenPGP with the Bitcoin specs.
--
John P. Clizbe Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or
mailto:[email protected]?subject=HELP
Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enigmail-users mailing list [email protected] https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
