Stephen Farrell wrote:
Isn't it as simple as: A signer might have practices that permit header
fields to have invalid content?
If so, then that doesn't seem to be dependent on the "SSP DSD" mechanism.
I've no position on whether that's right or not, but haven't understood what
the "SSP DSD" mechanism changes.
My statement was intended to be about DKIM, per -base. Whether publication of
various signing practices changes anything is an entirely separate discussion.
So far, most of the "interesting" suggestions for SSP appear to add complexity
and overhead, with questionable likelihood of benefit, particularly if there is
a simpler approach.
DKIM says nothing about key management now. Why does this need to change,
for the particular case of having keys used by someone in another ADMD?
My earlier mail to Jim may have explained. But saying it again another way
can help so:
If we support delegation of signing ("SSP DSD") then I can easily see how to
do that (by including the delegatee name in some SSP practice statement). If
however, we don't support delegation of signing, then it may be more likely
DKIM already "supports" delegation of signing. It comes for free (with respect
to the DKIM specification) by virtue of sub-domain names.
So I think what you mean is the possibility that there is publication of an
explicit delegation list.
Still, I do not see how explicit publication of a delegation list creates any
additional burdens or requirements for documenting how key management is done.
As with the rest of DKIM, internal procedures are internal procedures, even when
"internal" happens to occur between ADMDs.
that folks make more use of delegation of keys. Once we start down the road
where delegation of keys is common (or nearly so), then there's an onus on us
to say how to do that,
Why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html