Okay, this is an interesting application that would certainly require some sort of 6761-style action. Do you believe that it is not covered by the current problem statement?
On Sun, Sep 18, 2016 at 9:00 PM, Phill <hal...@gmail.com> wrote: > There is actually a fifth type of name, escaped names. Right now, the only > names we have of this type are SRV protocol tags, (_http._tcp.example.com) > and internationalized names (xn—wev.com) > > I want to add a third set of escaped names, one that has similar > functionality to .onion but does not leak as much information. > > example.com.m > f-- > b2gk > > 6 > - > duf5 > > y > - > gyyl > - > jn5e > d > > > This is a strong domain name and to interpret it we require a policy that > is validated under the UDF fingerprint b2gk > > 6 > - > duf5 > > y > - > gyyl > - > jn5e > d. This in turn is a base 32 encoding of 92 bits of digest value plus an > 8 bit version string. The fingerprint is over a content type identifier > plus some content as specified here. > > https://tools.ietf.org/html/draft-hallambaker-udf-03 > > The content is typically going to be some sort of cryptographic key (PGP, > PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states > how the address ‘example.com’ is to be interpreted. > > The trick here is that we can now bind security policy direct to any DNS > name without having to muck about with DNSSEC, or for that matter any other > PKI standard other than the particular standard we want. > > > Lets say that Alice is using OpenPGP and her OpenPGPv5 key is > mw83i-32ri4-83klq-3odp3. We can form an address from that: > > al...@example.com.mf--mw83i-32ri4-83klq-3odp3 > > Now that isn’t an address that we can interpret without access to Alice’s > public key. Which is actually what I kinda want because I am fed up of > spam. The fact that I give you my address does not mean I want just anyone > being able to use it. > > In the ordinary course of business, my ‘strong name aware’ mailer knows > that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can > use that email address. If I just type it into Outlook, the client will > happily pass it on to my mail server and then it will get ‘stuck’ unless > the mail system can figure out how to use that address. Which is exactly > what you would want to happen with confidential mail. > > If the address can be resolved, the result is normally going to be a > policy that says what protocols the address can be used with and how. > > Now, naturally, a split horizon DNS would be one natural place to provide > access to a resolution service, but it need not be the only one. > > > The use of strong DNS names represents a major step forward in achieving a > genuinely decentralized Web. Instead of there being an institution at the > trust apex of the Internet, there is a digest function and a PKI scheme. > > > On Sep 16, 2016, at 2:13 PM, John Levine <jo...@taugh.com> wrote: > > The drafts are: > https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/ > https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/ > > > Having read them both, neither one thrills me but I'd give the nod to > adpkja. The "Internet Names" in tldr seems to me a bad idea, since > there are a lot of other names on the Internet such as URIs and handle > system names, and this is about domain names. > > It seems to me there are four kinds of names we have to worry about, and > neither draft calls them all out clearly: > > * Names resolved globally with the DNS protocol, i.e. > ordinary DNS names > > * Names resolved globally with an agreed non-DNS protocol, e.g. > .onion via ToR > > * Names resolved locally with an agreed non-DNS protocol, e.g, > .local via mDNS > > * Names resolved locally with unknown protocols, e.g. .corp and > .home, the toxic waste names > > R's, > John > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
