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.
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. > -----Original Message----- > From: Douglas Otis [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 6:03 PM > To: Hallam-Baker, Phillip > Cc: IETF DKIM WG > Subject: Re: [ietf-dkim] small question in > draft-ietf-dkim-base-00.txt on TXTrecord > > > On Feb 20, 2006, at 1:43 PM, Hallam-Baker, Phillip wrote: > >> Douglas Otis wrote: > >> > >> DKIM should specify a binary structure used with the CERT RR. > >> This RR already offers fields defining the critical hash > algorithm, > >> for example. By just specifying the hash used in > signature header, > >> once a hash algorithm is later discovered compromised, there is no > >> means to keep bad actors from using this compromised hash > algorithm > >> for spoofing messages. It would appear the DKIM draft is > not ready. > > > > The CERT RR is utterly useless for our purposes unless you are > > confident in the ability of DNS to move DNS messages of at > least 2Kb > > reliably. > > 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-rfc2538b > is-09.txt > > Value Mnemonic Certificate Type > ----- -------- ---------------- > 0 reserved > 1 PKIX X.509 as per PKIX > 2 SPKI SPKI certificate > 3 PGP OpenPGP packet > 4 IPKIX The URL of an X.509 data object > 5 ISPKI The URL of an SPKI certificate > 6 IPGP The URL of an OpenPGP packet > 7 ACPKIX Attribute Certificate > 8 IACPKIX The URL of an Attribute Certificate > 9-252 available for IANA assignment > 253 URI URI private > 254 OID OID private > 255-65023 available for IANA assignment > 65024-65534 experimental > 65535 reserved > > > 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 > > > > My expectation is that you end up in TCP/IP fallback as mandated in > > the original DNS spec at 500 bytes. > > The minimum MTU of 576 bytes constrains DNS messages to 512 bytes. > > > > If you can move packets of that size the need for binary encoding > > vanishes. > > If the goal is to handle 2k bit keys, the need for binary > encoding is paramount. Otherwise, something other than DNS > is required, like a key server or perhaps DNSsec. : ( > > > -Doug > > > > > _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
