On Wed, 8 Jun 2005, Hector Santos wrote:
I have not had time to read into the details but if this is a "generic
framework" that will not lock customers into a specific vendor (or joint
vendors) method, this is direction I prefer to pursue and invest resource
into.
It pretty much is. If you want you can compare it to very minimalistic
form of x509 in header. There are obviously certain things I prefer for
very good technical reasons - like using fingerprints in dns (preferably
in fixed-size binary record but for now spf/txt will do), but system
allows for other types of authorization for future as well as different
cryptography i.e. like S/MIME allows for various signature and key
algorithms. The generic 'txt' authorization type I worked out will
actually support both dk public key and fingerprint data from spf modifier,
this one I already got some code on and parsing it turned easy. Also
note that "txt" uses DNS URI with direct reference to DNS record type
so if both TXT and SPF or binary are supported on server side, verifying
client will know and will not bother doing multiple dns lookups and
will directly use correct one it supports (even though to support
multiple clients server might have to duplicate records in txt and
other specific record type).
So to answer John's question, entire framework has not been implemented
but parts of it have been. In fact the syntax you see is the result of
me working on the parser as I found previous syntax from 0.20, that one
or two people here might have seen in May, more difficult to deal with
and slightly more verbose and so I never released that. As a result of
experimentation I also found that having reference to Edigest is good
for verification and couple other minor details.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net