From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On
Behalf Of Hector Santos
Sent: Tuesday, April 12, 2011 12:57 AM
To: SM
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] [dkim-ops] key validation question
SM wrote:
> Adding text in RFCs to prevent lies doesn
SM wrote:
> Adding text in RFCs to prevent lies doesn't usually solve problems. :-)
Sure, but that is what h= attempts to trap using another level of
authenticity requirements. We can categorized that scenario many ways
but its simply about the domain trying to exclude an method a "bad
guy" ca
Hi Hector,
I don't feel strongly about the change.
At 22:59 11-04-2011, Hector Santos wrote:
>But the domain must not lie, which was one of the OP's concern, so I
>think additional text to require the signer to use one of the h= specified.
Adding text in RFCs to prevent lies doesn't usually sol
SM wrote:
> [I suggest following up on the DKIM WG mailing list]
>
> You are restating a MUST. :-) I agree that it is important. The
> problem here is that it still leads to various interpretations due to
> the keywords.
>
> I'll try rewriting the text in Section 3.6.1:
>
> h= Accepta
ipassoc.org; IETF DKIM WG
>> Subject: Re: [ietf-dkim] [dkim-ops] key validation question
>>
>> Mr Nit Picker suggests:
>>
>> Refer to Section 3.3 for a discussion of the hash algorithms
>> implemented by Signers and Verifiers. The algorithms liste
> -Original Message-
> From: dkim-ops-boun...@mipassoc.org [mailto:dkim-ops-boun...@mipassoc.org] On
> Behalf Of Tony Hansen
> Sent: Monday, April 11, 2011 2:40 PM
> Cc: dkim-...@mipassoc.org; IETF DKIM WG
> Subject: Re: [dkim-ops] [ietf-dkim] key validation question
>
> >> Mr Nit Picker
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of John R. Levine
> Sent: Monday, April 11, 2011 12:34 PM
> To: SM
> Cc: dkim-...@mipassoc.org; IETF DKIM WG
> Subject: Re: [ietf-dkim] [dkim-ops] ke
> Please refer to Section 3.3 for a discussion of the hash algorithms
> implemented by Signers and Verifiers. Which algorithms are listed
> in h= is an operational choice made by the sender.
Mr Nit Picker suggests:
Refer to Section 3.3 for a discussion of the hash
Hi Tony,
[I suggest following up on the DKIM WG mailing list]
At 08:07 11-04-2011, Tony Hansen wrote:
>The MUSTs *are* redundant with section 3.3's first paragraph. However,
>it's still important.
>
>If this section were rewritten, I'd suggest something like this:
>
> h= Acceptable hash algo
