I agree with what Stephen says about these, and in particular, that as
we look at the threats doc we consider carefully what belongs there, as
opposed to what should be brought up in discussion of the base doc.
Doug, if you decide to separate any of these out to ask that a new issue
be opened, please really, really try to keep what you say concise -- I
have trouble sifting through it, and I'm sure that the non-native
English speakers have more trouble.
Providers offering low cost or free services will not be able to
adequately vet their many users, who often number in the millions.
This same provider may wish to send messages from the same domain and
have these messages receive a trustworthy evaluation. Perhaps these
would be messages from a system administrator indicating that the
user's system appears compromised or that their payment information is
no longer valid. The use of trusted/non-trusted keys would permit the
signing domain to both retain their trustworthy status and prevent
un-vetted users within the same domain from spoofing with "trusted"
messages.
That's largely sales talk and I can't see any valid issue applying
to the threats draft. Another expedient assessment.
It's definitely not relevant to the threats doc, but I do think it could
be a useful discussion to have about the base doc. We've suggested that
domains that want to divide their reputation create subdomains (the sort
of thing like "official.bigbank.example" vs "users.bigbank.example"),
but for various reasons not all domains want to do that. It would be a
reasonable discussion to have if one wanted to propose a tag in the key
that defined the level of "officialness" or "trust" or some such that
the signing domain places on the use of this key. That allows the
domain to use selectors, rather than subdomains, to make this division.
Doug's item 5 fits here too, but takes the discussion directly into the
formation of reputation, which is out of this WG's scope. I'd like to
see more discussion of this in a separate group that addresses
reputation and accreditation standards.
In any case, again, this is definitely NOT a threats doc issue.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html