On Mar 30, 2006, at 1:47 PM, Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
1. signers MUST have a TXT and SHOULD have a new RR.
2. signers using RR indicate this with q=<newRR>.
3. verifiers that see q=<newRR> SHOULD query for that RR but
MAY query for the TXT.
Single query, no matter what the situation. No failures, so
no fallbacks.
If the signer says q=TXT,newRR then the verifier should have an
open choice.
The way I would expect to see new RRs phase in is with new signature
algorithms, in particular with signature algorithms that require
larger
keys.
If we have base64 encoding we need 342 bytes to encode a 2048 bit
key. That
does not allow much space for packaging, headers, links to certs or
any of
the other stuff we are likely to be wanting.
Agreed, but you are not including the ASCII tagging and termination
also needed.
I would even be willing to mandate the use of the new RR in the draft
describing use of the new algorithm(s).
Agreed.
I would suggest a binary structure of the form:
Algorithm : Keyblob : text flags
It seems a defined binary header structure for the DKIM key RR type
would be helpful. Also the algorithm field is 8 bits for both CERTS
and DNSsec keys. The structure below the header could be a simple
tag-length-value structure.
The tag-length portion could comprise two bytes. As several items
will be found in the header, the number of tags needed would be less
than currently found in the text structure. Although a 4-12 bit
structure would be easier to read in a hex dump, some may want more
tags. 5 bit tag, 11 bit length is another solution. This keeps the
value objects byte aligned without wasting space and allows for 32
different tags and a maximum blob size of 2047 bytes.
0 7 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 5 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Value \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tag
---
0 = reserved
1 = key data
2 = granularity
3 = services
4 = notes
5 = test (test mode defined with 0 Length)
6 - 31 reserved
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html