[ppml] 2007-1, was Re: mail auth proposals

> Perhaps the issue is that its unclear what the goals are for deploying
> this email authentication. There can actually be two gaols:
>   1. To verify that email address sent to ARIN really came from listed
>      email address
>   2. To verify that the person sending the email and using email address
>      is really who he says he is

For the purposes of replacing mail-auth..
It seems neither #1 nor #2 are truly essential, and concentrating on providing
verification features seems a nice distraction.. the needed rigorous
verification
process to perform verification effectively (I.E. having to examine government-
issued ids in person) would encumber uptake of the new auth method and delay
realization of some of the utility PGP can offer.

I agree there is benefit of having positive verification of public
keys associated
with a contact also, but I think it should be optional, so contacts don't have
that particular "cumbersome verification is required" excuse to stay with
mail-from auth method which doesn't provide much safety against mail spoof/
bogus requests.


I suggest it also be made possible to register a whois-invisible
"update password"
on a contact record.   Presumably some confirmation e-mail would be used
to verify establishment of the password.

Instead of using merely the from address,  you now have a keycode,
that should be filled in to make changes.

Users don't need specialized software to include a passcode in their template,
and for a third-party to spoof a request, they would need to acquire a copy of
a valid e-mail request.

That would be a major improvement over simple mail-from auth, and certainly
beats using merely mail-from auth to establish the initial PGP key for
a contact.

For contacts that didn't have a passcode before, generate one randomly,
next time any PGP key change is requested, and send an informative e-mail
with their generated passcode.

Including the passcode later will demonstrate that the person making the
request can at least read the e-mail incoming to the listed address. This would
provide a means to "bootstrap" the contact's initial PGP public key
that is less
cumbersome than "chain of trust" in that it does not require third-party
signatures to be made on the key, before ARIN could be sufficiently
convinced of its legitimacy.

Once a passcode is assigned...
allow updates that contain the password (whether using PGP or not),
provided mail-from auth is also correct.

Then provide two options that do use PGP

(a) Include the passcode and encrypt the message with a single public
PGP key that the registry would provide

In fact, this would allow some protection using PGP's encryption, without
the contact actually having a PGP key of their own registered yet.

And...
(b) Provide the option of signing the message using a public key
stored on a keyserver and whose fingerprint is part of the WHOIS
record for the contact.


In this case, the passcode is not included in the message, and neither
plaintext nor option (a) is accepted any longer once (b) is
successfully utilized.

Once (b) is utilized, e-mail address and passcode are irrelevent, at least
until such time as the key expires or the user found need to upload a
revokation
certificate for  their PGP key (I.E. due to a later discovery that the key was
compromised).
[...]


--
-J