On 03/08/2006 12:11, Julian Mehnle wrote:
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.)
OK. Personally, as I've said before, I don't think we will get deployment
momentum on a new version, but I think that's an implementation detail. We
can probably work out what mechanisms we would want in a new version and then
see if it's feasible to backfit them into modifiers for v=spf1.
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.)
Sounds interesting.
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).
OK. The flip side is simpler. If one asserts that messages are always PGP
signed, and you get one that lacks a PGP signature, then it's easy to know
what to do with it.
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".
Yes. Anti-forgery, not anti-spam.
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.
OK.
References:
1. PGP keys can have multiple identities (identity = name + e-mail
address) which can (and have to) be signed individually.
I look forward to your introductory message.
Scottt K
-------
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