Douglas Otis wrote:
> On 4/26/11 2:03 PM, Dave CROCKER wrote:
>> This ticket is invalid.
> Dave,
>
> When DKIM allows garbage input, DKIM's output is also garbage and
> untrustworthy. The saying Garbage-IN Garbage-OUT is still valid. Fake
> A-Labels can still resolve resources satisfying DKIM's signing
> algorithms. Cryptography only indicates some odd domain published a
> public key matching the key used to sign a message. The A-Label concern
> will become more apparent when UTF-8 encoding is generally permitted
> within email.
As an developer, I am mostly concern with the process functional
"blackbox" implementation modeling aspects and that comes with the
engineering faith the functional specification and the I/O were well
considered.
For RFC4871:
dkim.sig.dvalue = EncodeRFC3492(dkim.signer.domain)
For RFC4871bis:
dkim.sig.dvalue = EncodeRFC5890(dkim.signer.domain)
I don't see any software engineering issue other than to considered
backward compatibility:
dkim.signer.domain = DecodeRFC5890(DecodeRFC3492(dkim.sig.dvalue))
So all that is the easy part. But I would love to see an example of
what we are dealing with both RFC3492 and RFC5890 and see what these
labels will look like.
Can you provide a few example maybe showing how an IDN address and
domain will look like under each RFC and also UTF8 for?
From:
DKIM-Signature: d=
DNS zone record
or anything else you deem important to show the issue and/or conflicts?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
