On 05/23/2011 11:17 AM, Dave CROCKER wrote: > As an impressive example of even deeper misunderstanding: >
More of CROCKER's famed civility. >> On 5/22/2011 10:49 AM, Michael Thomas wrote: >> >>> But this is exactly what DKIM is. You prove yourself fsvo "prove" >>> to the registrar who "certifies" you by virtue of placing your NS >>> records in the root servers instead of issuing a cert. Nothing >>> different in *essence* to x.509 certs. >>> > DKIM has almost literally nothing to do with proofs made to a DNS registrar. > For example, it says nothing about the relationship between a domain name and > a > brand or company name. > Where exactly did I say anything about a "brand" or a "company"? Oh, I didn't. > DKIM merely says that who ever owns use of a domain name is asserting "some" > responsibility for the signed message. > Yes, and the way that they got to "assert" that was by convincing a registrar to allow them to create and maintain NS records in the root servers. > In extremely abstract terms, a DKIM signature relates to a reasonably constant > construct that one might call an "identity" but it does not label the > identity, > except with the domain name. > A domain name is an identity. RFC4871 calls it the signing identity. > More importantly, there are none of the claims, assertions or endorsements > that > go along with Certs, except for the mild one noted above. > Assertion of identity is "mild"? It's the *key* assertion. > One would have expected a former author of the spec who so-often proclaims > their > expertise to understand the semantics of DKIM better. On the other hand, it > does nicely show that implementing code doesn't mean understanding what it is > for... > I'm not a "former" author. But thanks for the smear anyway. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
