Re: [ietf-dkim] small question in draft-ietf-dkim-base-00.txt on TXTrecord

[Douglas Otis <[e-mail]>]

On Feb 21, 2006, at 9:10 AM, Hallam-Baker, Phillip wrote:
> Douglas Otis wrote:
>>
>> 2048 bits represents 256 bytes of binary data easily and reliably  
>> stored using the #37 RR.  In addition, the #37 Cert RR also  
>> provides a method to reference other key acquisition options in  
>> the event something is needed that DNS can not provide.
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext- 
>> rfc2538bis-09.txt
>>
>> With a draft describing the data structure, this could be expanded  
>> to:
>>       Value  Mnemonic  Certificate Type
>>       -----  --------  ----------------
>>           9   DKIM      DKIM Binary Key
>>          10   IDKIM     The URL of a DKIM Key Server
>>
>>
>> If the goal is to handle 2k bit keys, the need for binary encoding  
>> is paramount.
>
> I do not see the value in having a pointer to a CERT record with a  
> pointer to a cert over a pointer to the cert.

The suggestion for using #37 RR for offering a URL vector to the  
"Next means of obtaining the DKIM information" was to circumvent  
future hunting.

> If the idea is to replace the existing key format with self signed  
> X.509v3 certificates it ignores the long (and justified) history of  
> ASN.1 hatred in the IETF.

A data structure defined by the #37 RR type is not limited to X.509  
certificates.  There are many experimental values for use, pending a  
draft being accepted that defines a suitable DKIM public key binary  
structure.  The DKIM test server would need to transition from  
accepting an experimental type value to the assigned value.  To  
further reduce DNS payloads, a signature conventions could  
differentiate DKIM from that of DomainKeys, where then a label  
"_dkim" could also replace the "_domainkeys" label where just #37 RR  
would be obtained.  The use of a binary key format from the outset  
prevents the need for multiple lookups and better ensures use of 2048  
bit keys will not become a problem.  #37 RR more than doubles the  
otherwise limited name space.

-Doug 
  
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html