On Feb 22, 2006, at 5:30 PM, Mark Delany wrote:
On Wed, Feb 22, 2006 at 05:11:37PM -0800, Douglas Otis allegedly
wrote:
Using this #37 RR was not a suggestion for developing yet another
PKI. This was suggesting the use of a DNS resource record defined
by RFC2538.
This RR imposes this header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+
Right. A blob container. I see no functional difference from TXT.
The difference would be an assurance the information is not
considered limited to 7 bit text, and that there is an IANA tag
ensuring no collisions with other uses of the RR. In addition, the
#37 RR header will add significant value to a DKIM Key RR.
Sourceforge links to applications using this RR was to offer
illustrative examples of routines and utilities available. If
interested, a draft and example code for this DKIM Key RR could be
provided.
Do you propose extending RFC2538 to support the plethora of tags
currently defined in Selectors or do you want to hide those in the
blob?
The RFC2538 draft would not describe the DKIM key structure, as it
does not describe any other structures for other protocols using this
RR. Only general overviews are provided. There is no structural
information provided beyond the #37 RR header. A draft for the DKIM
key structure, ideally in a binary TLV form, would define the tags
below the #37 RR header.
If you plan extension, do you have the support of the 2538 authors?
No changes to this draft appear needed. IANA could reference the
assigned Type to the draft defined by the DKIM wg. The DKIM key and
signature header amalgam could be considered an identity
certification. It should not be surprising to find the algorithm
parameter already supports the current DKIM key. Whatever algorithm
the DKIM wg selects, this will likely cover similar work in this
area. There should be no conflicts created.
If you plan blobs, are you certain that matches the intent of the
2538 authors or have you not consulted them?
This was brought several up months ago. At the time, concerns raised
regarding DKIM's uses of this RR were related to the mention of DNS
wildcard use. In conjunction with DKIM or OpenPGP, such a wildcard
record could be exploited as an attack vector to flood DNS caches.
Some DNS servers do not fair very well in these scenarios. This was
not discussed in great detail, as there was greater focus upon other
minutia. As there is a vital need to support future upgrades of the
DKIM Key RR that might not be accommodated by the TXT RR. Use of this
RR for public keys should not set a precedent where this RR is
considered nothing more than a blob container.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html