ietf-dkim
[Top] [All Lists]

RE: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

2006-03-30 13:56:52
Mark,

        Why would I bother to read the policy record at all if the message
is signed with a signature that meets my acceptance criteria?

        I am only going to care about the policy record if the message is
unsigned or the signature fails to validate. Only then am I going to read
the policy record and it is only going to be significant to me if it tells
me to expect a message that is different to the one I received, i.e. that it
should have a sig with a particular profile. 

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Thursday, March 30, 2006 3:24 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

On Thu, Mar 30, 2006 at 10:09:24AM -0800, Jim Fenton allegedly wrote:

There's a different situation for key records and
policy/practice/(petunia?) records.  The choice of whether to use a 
new RR or a TXT key record should be retrieved is something 
that can 
be represented in the signature (the query type, q=, tag has been 
suggested which makes sense).

As a practical matter, I don't see how this can actually work 
to eliminate the DKK then TXT sequence because you don't know 
the capabilities of the verifiers. Can they fetch DKK? No one knows.

During transition, signers will be significantly at risk of 
not being verifiable if they just use q=dkk. Hence, most, if 
not all signers will likely use q=dkk,txt (or whatever the 
syntax is) to explicity tell the verifiers to try both, which 
in turn means the signer has to maintain both.

The net result is that signers will all be saying try DKK and 
fall back to TXT.

The only true advantage to being explicit with q= is that it 
lets TXT-only sites optimize away the failed DKK lookup, but 
it adds no value to signers supporting DKK.


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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

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