Eliot Lear wrote:
Scott Kitterman wrote:
This draft mentions the posibility of requiring a new resource record type.
It isn't clear from the draft if the mention is in reference to the idea of
using a new RR type in parallel with TXT for some period or if the idea is
possibly deployment exclusively in the new RR type.
If it's the latter, I think that this would be an extraordinarily bad idea.
In my opinion, if this protocol is going to require a new RR type to go
forward, it will never get deployed.
Recommend a new requirement that the protocol MUST NOT depend solely on a
new
DNS RR type just so there won't be any confusion on this.
I would suggest that whatever approach SSP uses be consistent with what
has been done with the base protocol.
The considerations aren't quite the same. In the case of the base
protocol, the signature can tell (via the q= tag value) what method to
use, including which record type, to retrieve the key.
In the case of SSP, there's nothing to tell the verifier how to retrieve
the SSP record. If there is more than one way to publish SSP, then the
verifier has to try each one until they find a record or run out of
methods. This makes it a much bigger burden, both on the verifier and
the infrastructure, to have more than one lookup method. The question
then becomes whether that method should be a TXT record (presumably with
some prefix) or some other RR (not necessarily with a prefix).
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html