[ietf-dkim] Delegating responsibility: a make vs. buy design decision

[Dave Crocker]

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