On Tue, Nov 15, 2005 at 11:51:10AM -0800, Michael Thomas allegedly wrote:
Right. If that is the path to take, let's make it similar to a TXT but
withut the problems. Say,
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A 16bit unsigned length followed by txt.
I think you need a Type if you want to have more than one value. Or were you
just thinking about hard coding the fields?
I was strictly address the option of using a surrogate TXT, much as
SPF has done. So in the above, "value" would consist of the text
stream of a Selector as we know and love it today excepting that it
wouldn't be broken into sub-256 length chunk as is forced on us by the
TXT format.
Mark.
See below:
That eliminates 1) and 2).
3) There is a possibility to define a less cumbersome master file
format for the record.
It will be interesting to see that in practice given that most master
files I've seen are positional and DKIM has numerous optional
tags. Would it end up looking something like this?
IN DKIMSEL 1 rsa sha256 - - - 34E7BC... - "marketing"
What I was sort of thinking for your TLV was:
DKIMSEL_PUBKEY 0
DKIMSEL_EVERYTHINGELSE 1
where
DKIMSEL_PUBKEY is the binary encoding of the public key specified by
PKCS#xxx
and DKIMSEL_EVERYTHINGELSE is the text encoding of DKIM TXT selector
representation.
>> A DKIM_EVERYTHINGELSE record MUST NOT contain a TXT representation
of the public key if a DKIM_PUBKEY TLV is present in the RR
(this preserves the ability to more or less cut and paste the
TXT record directly into the
new RR -- perhaps a nice feature for backward compatibility)
Gotcha.
Mark.
_______________________________________________
ietf-dkim mailing list
http://dkim.org