-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
On 03/07/2006 18:30, Julian Mehnle wrote:
Anyway, there are far fewer domain owners than end-users, so that
should explain SPF's structural advantage over PGP. But I agree that
PGP is the definite solution to the forgery problem. Banks, eBay,
etc. should really form a cooperative initiative and start propagating
PGP to their users instead of inventing silly workarounds like "never
click links in e-mails claiming to come from us".
Now since I get a lot of mail from you (via mailing lists), if I got
mail "from" you that didn't have a PGP signature, I'd be suspicious. In
a broader sense though, how would a receiver know to expect a PGP
signature from you?
SPF OPtions modifier seems to be a possible solution...
True, however I am still convinced that a new SPF revision with proper
"pgp"/"smime" mechanisms (not modifiers) is the way to go. (I have been
compiling a list of potential improvements over v=spf1 over the last few
weeks, so expect an introductory message on that from me shortly.)
op=pgp[then we need syntax to find the key] from that an automated
solution can be built to reject unsigned messages...
It's been a while since I've done much with PGP (I have to use S/MIME
professionally and so I've gotten away from PGP), do you have any
suggestions on how we might point to the key or provide perhaps a key
fingerprint in the record?
Well, SPF still applies mainly to domains, not e-mail addresses, so a
statement on PGP policy in an SPF record would have to specify a signing
key ID or fingerprint, so that every message would have to be signed by
some key that is itself signed (trusted to be authentic) by the specified
signing key. (That would be similar to how S/MIME's inherent public-key/
CA infrastructure works.)
%{l} macro expansion, e.g. as in "pgp:id-txt=%{l}.pgp-keys.%{d}" (meaning a
TXT lookup on the specified domain), could even be used to define per-user
keys. (All PGP keys are self-signed, so directly specifying end-user keys
instead of dedicated signing keys works.)
Now, a signature on a PGP key does not mean approval or affiliation, but
merely (as I wrote above) trust in authenticity, so the above might not
work as some might think. An SPF-match on "pgp:id=<key-id>" (or "pgp:
id-txt=<domain>") would in itself not mean affiliation with the domain
owner, but just that the domain owner trusts key <key-id> (usually his
own) to correctly assert the authenticity of other keys (that are used to
sign outgoing messages).
So how could affiliation be determined? There is such a concept as "trust"
in PGP, but it is by definition always local and never publicly attached
to keys, and it really means "I trust this person to correctly assert the
authenticity of other keys", not "I trust this person not to abuse my
domain in their mails".
What we _can_ do is check if the key used to sign an outgoing message
includes an identity[1]...
a. whose domain matches that of the envelope sender (for some definition
of "matches"), AND
b. that is signed by the signing key designated in the SPF policy.
References:
1. PGP keys can have multiple identities (identity = name + e-mail
address) which can (and have to) be signed individually.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEDxA5wL7PKlBZWjsRAleQAKDGXqAbms41XX70o05hlAlwpK3pngCg5cZV
rdyLYe/07YTGcw+S0ZW2Sj0=
=Z8dZ
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com