On Nov 15, 2005, at 1:54 PM, Mark Delany wrote:
On Tue, Nov 15, 2005 at 11:35:55AM -0800, Douglas Otis allegedly
wrote:
Extensibility is generally handled by adopting a Tag/Length/Value
(TLV) format which allows extensibility while retaining binary
representation.
Sure. But that's uncommon in DNS RRs. Even the complex ones are
positional.
Here is the format for RR type 37.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
There would need to be a DKIM type code defined by IANA. The key tag
and algorithm are defined in RFC4034 appendix. The area defined as
certificate would be defined by the DKIM WG. This should invite
easier use of parallel efforts related to extending the acquisition
of keys. You could make an TLV structure for holding the 's='
element for example, or define a different type and pull this in as
RR sets, if you think there is room. The h= would be part of the
algorithm definitions.
Also note that the OpenPGP format uses a
binary key. Of course, this starts with a binary RR.
One can routinely point to RRs that have a key value in them, what one
cannot readily point to are key containing RRs that have the
complexity of types that a Selector does. NAPTR gets close with it's
LTV character strings.
The RR provides a running start. The complexity is limited by your
imagination. : )
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org