On Feb 22, 2006, at 4:03 PM, Stephen Farrell wrote:
Douglas Otis wrote:
OID information would not be needed with DKIM public key
information. Consider the DKIM public key cert isomorphic to that
of OpenPGP.
So, regardless of whether or not we use TXT or some binary format,
we will not go down the road of developing yet another PKI.
If that's not what you meant, sorry for jumping up and down but you
can put my sensitivity down to the fact that I was involved in the
start of PKIX, now more than a *decade* ago;-)
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 | /
+---------------+
Introduction
Public keys are frequently published in the form of a certificate and
their authenticity is commonly demonstrated by certificates and
related certificate revocation lists (CRLs). A certificate is a
binding, through a cryptographic digital signature, of a public key,
a validity interval and/or conditions, and identity, authorization,
or other information.
This appears to be a rather open definition. For DKIM, this
information would be an amalgam of that carried within the email
message. While this #37 resource record can hold X.509 certificates,
nothing appears to prevent this resource records from also holding a
DKIM key in binary form. There is an IANA assigned Certificate Type
which ensures the internal record structure is understood by the
application.
DKIM already uses a unique label to locate the RR. The DKIM draft
indicates an expectation of developing a binary RR for DKIM, which
should be within the WG charter. Owing to difficulties created by a
particular OS vendor for new RR types, utilizing an existing resource
record likely represents the best opportunity at quickly establishing
a binary RR, which is vitally needed.
IANA info
type:
9-252 Available for IANA assignment by IETF
Standards action
253 URI URI private
254 OID OID private
255 Reserved
256-65279 Available for IANA assignment by IETF Consensus
65280-65534 Experimental
65535 Reserved
DK = 17,483 or 0x44, 0x4b (only needs IETF Consensus.)
algorithm:
Currently defined in RFC4034.
Value Algorithm [Mnemonic]
----- --------------------
0 reserved
1 RSA/MD5 [RSAMD5]
2 Diffie-Hellman [DH]
3 DSA/SHA-1 [DSA]
4 Elliptic Curve [ECC]
5 RSA/SHA-1 [RSASHA1]
252 Indirect [INDIRECT]
253 Private [PRIVATEDNS]
254 Private [PRIVATEOID]
255 reserved
6 - 251 Available for assignment by IETF Standards Action.
key tag:
The key tag algorithm is the sum of the wire format of the DNSKEY
RDATA broken into 2 octet groups. First, the RDATA (in wire format)
is treated as a series of 2 octet groups. These groups are then added
together, ignoring any carry bits.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html