Strong Internet Names is a concept that I have been developing for about 4 years now. It is an extension of concepts that Brian LaMachia and team applied to the design of dotNET security with great success and I think it has value applied at the network level.
The current draft can be found in HTML format here: http://mathmesh.com/Documents/draft-hallambaker-sin.html The related draft describing UDFs can be found here: http://mathmesh.com/Documents/draft-hallambaker-udf.html The question I would like to pose is which group to raise the work in as it is a security specification with DNS implications. This is one of the technologies I am using to build the mathematical mesh but it is not limited to that application. The relationship is similar to that of URIs to HTTP, they are both used in the Web but URIs are much wider in scope. The basic concept of a SIN is to bind together an Internet address and a security policy that constrains the interpretation and use of that address. For example, Example Inc holds the domain name example.com and has deployed a private CA whose root of trust is a PKIX certificate with the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-2> Alice is an employee of Example Inc., she uses three email addresses: <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-3> al...@example.com <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-4>A regular email address (not a SIN). <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-5> al...@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-6>A strong email address that is backwards compatible. <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-7> al...@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz <http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-8>A strong email address that is backwards incompatible. These are addresses that can be entered into the contacts directory of any existing email client. Note the use of the mm-- prefix to identify this as a SIN. Existing policy means these labels cannot be issued as ICANN TLDs etc. That coupled with the fact that accidental collisions are statistically improbable and these names are as robust as is possible. Putting what is functionally a superset of an OpenPGP fingerprint into a domain name means that we can cryptographically harden any system. This is not necessarily a construct that would be put in front of a user, most of the time we use SINs in the mesh it is to record the outcome of a trust decision. So in the example above, Alice might give me her business card, I send her an email and when she replies, there is a header giving me her Strong email address which is bound to a security policy such as 'always use end-to-end encryption with either S/MIME or OpenPGP and here are my keys'. Certificate Authorities are currently employed as trust providers. In the SIN model, we can limit their role to that of Trusted Introducers who are only required to make the initial connection. There is of course an infinite amount of complexity in the specification and application of security policies. And the design of UDFs takes account of that with a construction that provides for isolation of semantic domains. What I want to do at this point is to get the foundations laid to allow us to build interesting stuff. The interesting stuff itself is a separate matter.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
