ietf-dkim
[Top] [All Lists]

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

2006-08-18 17:07:27
Hector Santos wrote:

----- Original Message -----
From: "Paul Hoffman" <phoffman(_at_)proper(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, August 18, 2006 4:07 PM

If that is what the OA domain (FROM) declares, sure.
Good. Glad we can have a shorter description.

But first he has to first declare he allows others to sign.
Why? To me, the above requirement makes sense even for
someone who is going to sign their own messages.

The proposed 3PS (3rd party signer) options are:

1   3PS NOT ALLOWED (what many of you guys did not want)
2   3PS ALLOWED NO RESTRICTIONS (what you guys want)

I wish you'd stop putting words into people's mouths. There is a major disconnect between your understanding of what is needed and as far as I can tell just about everybody else's. Whether a third party signature is present or not is completely irrelevant to the question of whether there is a valid first party signature. And it's totally bogus to impugn that people have somehow shifted positions between now
and mailsig, and even if they did... so what?

      Mike

3   3PS ALLOWED WITH RESTRICTIONS
4   3PS EXPECTED W/O RESTRICTIONS

The SSP-01 draft basically lacked the restrictions which nearly all the SSP
proponents agreed a delegation ideas was required since last year.

If by "you guys" you mean DAC, it would be nice if you didn't
put words in our mouths. To be specific, DAC hasn't made
any statements on SSP because there is nothing to make
statements on yet.

You should not make conclusions like this, but if the shoe fits...

By "You guys" I meant those who have shown to be nearly 100%consistently
opposed or resistant to any kind of 3rd party signature restrictions which
has been the numero uno basis division going back to MAILSIG.

I personally never argued against a open-ended 3PS, but it does come with
high risk for exploitable, therefore it seems to me to be prudent to allow
the option for domains who wish have restrictive domain signing practices.

I see no technical reason not to allow for strong/restrictive policies.


--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>