Subject: RE: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 30 Mar 2006 13:47:15 -0800

> [mailto:[email-masked]] 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.

One area where a new RR does provide a real tactical advantage though is in
widening out the data path. If the resolution path supports new RRs then
chances are that it will support 1024 byte lookups as well.

I would be quite happy with a new RR that was simply a new tag value for a
TXT record. But if we are going to declare new RRs and we are dealling with
crypto keys it's a bonus I will take. 

I would even be willing to mandate the use of the new RR in the draft
describing use of the new algorithm(s).

I would suggest a binary structure of the form:

Algorithm : Keyblob : text flags

Where Algorithm = a 16 bit field that is defined to be the same as the
DNSSEC identifier registry. Lets keep the IANA work to a minimum. I doubt we
would ever use more than 8 bits worth. If people need to they can define a
code for 'ASN.1 tagged blob'

Keyblob = length, <binary data>
	Crypto standards already define binary formats for key parameters,
reuse this DO NOT attempt to repeat the work, all you end up doing is making
unnecessary work.

Text flags
	A text field that is used to express any additional parameters that
might be required. Text is compact and flexible. For these data sizes space
delimited tag value pairs are as efficient as anything else.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Mar 2006 14:44:39 -0800

> the other stuff we are likely to be wanting.

Agreed, but you are not including the ASCII tagging and termination  
also needed.

> describing use of the new algorithm(s).

Agreed.

> 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