Subject: [apps-discuss] Time bound DNS names.

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 May 2014 15:40:49 -0400

So I made a post to the IETF list yesterday in which I gave a high
level view of the Internet 2020 project and the three goals of
Security, Access and Autonomy.

The goal of Autonomy being to make the Internet user independent of
institutional control points like ICANN and the corporations trying to
establish themselves as control points.

ICANN is of course the one we have had concerns about for the longest
time and the autonomy problem is that I don't buy a DNS name, I can
only rent it. And that means that names that are DNS bound can always
be reassigned in the future. Which is one of the reasons why HTTP urls
are unsatisfactory.

Larry Masinter has of course raised this sort of concern before and
proposed dated URLs. But this morning a different approach to the
problem occurred to me:

Lets take a URL at a web site and imagine I download a page on 1st Jan 2010:
http://www.cnn.com/whatever.html

Now what if I wanted to connect up today to the same party that I
connected to last time. This is not the same as the URN or the dated
URL problem. I want to connect up to the same entity regardless of
whom ICANN happen to sell the domain name to next.

How about one of the following:

http://www.cnn.com.2010/whatever.html
http://www.cnn.com.1.2010/whatever.html
http://www.cnn.com.1.1.2010/whatever.html

DNS labels are not allowed to be all numbers but the DNS protocol
works for them. In fact they seem to work with my existing software
which was not a design goal but would be cool.

Now resolving such names would of course require a new infrastructure,
quite possibly a subscription infrastructure that would track the
changing ownership of the names over time. And this infrastructure
would probably involve Certificate Transparency like services and
DNSSEC.

But we could use this to provide persistence for Web content and for
Web services which would be incredibly cool.

We can also apply the same idea to email addresses:

[email-masked] could be anyone.
[email-masked] is uniquely my account.

---

From: [email-masked] (Henry S. Thompson)
Date: Tue, 20 May 2014 09:08:18 +0100

Phillip Hallam-Baker writes:

> . . .

> http://www.cnn.com.1.1.2010/whatever.html

This reminds me of one of the rather odd failings of the Internet
infrastructure: There is as far as I know no where to go to find the
answer to questions of the form implicit in the above proposal, that
is "Who was the owner of the cnn.com domain on 2010_01_01?".

We really ought to get a requirement of public archiving of domain
name 'ownership' records into the contractual requirements on
registrars. . .

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: "John Levine" <[email-masked]>
Date: 20 May 2014 22:20:04 -0000

>name 'ownership' records into the contractual requirements on

We're the IETF.  If you're looking for ICANN, I expect you know where
to find them.

R's,
John

---

From: Bob Wyman <[email-masked]>
Date: Wed, 21 May 2014 11:00:42 -0400

It strikes me that the Tag URI scheme defined in RFC
4151<http://tools.ietf.org/html/rfc4151>, and
used by Atom <http://tools.ietf.org/html/rfc4287>, addresses the problem of
"time bounded" names. Of course, the Tag URI system currently has no
authoritative resolution mechanism. However, it seems that one could define
and create such a thing. Thus, one could choose to either:

   - Use "http://www.example.com/index.html" to access whatever resource
   was currently so named, or
   - Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via
   the Wayback Machine <https://archive.org/web/web.php>, or something like
   it, the resource as it was on Sept 15, 2001.

The same would work, of course, for email addresses:

   - "[email-masked]" would indicate the person currently assigned the
   name "bob" by the mail server currently serving "example.com"
   - "tag:[email-masked],2001-09-15" would attempt to resolve to a current
   address for whoever had been named "[email-masked]" in 2001. That
   address might be something completely different, of it might resolve to
   whoever was currently assigned the name (and had been since 2001).

Finally, Henry S. Thompson's concern might be address by support something
like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS
response that one would have received had you made the request "whois
example.com" on 2001-09-15.

Does Tag URI address your needs? If not, what is missing? If so, then would
it be worth the effort to define a Tag URI registration and resolution
mechanism?

In any case, I am pleased to see this discussion of persistence as an
important quality for names. I've long thought that too many of those who
investigate the properties of naming systems are overly focused on just the
three edges of Zooko's
Triangle<http://en.wikipedia.org/wiki/Zooko's_triangle>(Memorability,
Global, Security) when we really should also address a
fourth edge: Persistence. (We should speak of a pyramid, not a triangle...)
For more on this, see an old posting of mine  on "The Persistence of
Identity (Updating Zooko's Pyramid)" at:
http://www.wyman.us/main/2006/12/the_persistence.html

bob wyman

On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: James M Snell <[email-masked]>
Date: Wed, 21 May 2014 08:39:35 -0700

Ah, tag URI's... those bring me back. Was it really nine years ago
already!? While tag URI's *might* work structurally, I can see a
number of issues using them for this purpose -- not the least of which
is the fact that tag URI's provide no reliable verification. I've
often considered that a variation on the "Naming Things With Hashes"
approach (RFC 6920) could be leveraged... essentially, wrap things
like HTTP URI within a hashed, timestamped URI syntax that can provide
reliable point-in-time linking.

It gets a bit ugly visually and certainly wouldn't be intended for
human readability, but something along the lines of (just a strawman)

pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add

Where:

  pit == "point in time reference"
  2014-05 is the point in time being asserted
  b0717f9a is, for lack of a better term, an Entity Tag or Validator
to be matched against the fetched resource (it can, for instance,
appear as the Entity Tag in the HTTP response)
  http%3A%2F%2Fexample.org%2Ffoo is the actual resource being
referenced at the given point in time.
  and sha-256-32:f83b2add is the hash generated from the timestamp,
validator and ref url.

The inclusion of the validator makes it possible to reference specific
versions of the target resource and the hash provides us with at least
some level of verifiability.

It's an idea, at least. Whether or not it's a good one remains to be seen ;-)

- James

On Wed, May 21, 2014 at 8:00 AM, Bob Wyman <[email-masked]> wrote:
> It strikes me that the Tag URI scheme defined in RFC 4151, and used by Atom,
> addresses the problem of "time bounded" names. Of course, the Tag URI system
> currently has no authoritative resolution mechanism. However, it seems that
> one could define and create such a thing. Thus, one could choose to either:
>
> Use "http://www.example.com/index.html" to access whatever resource was
> currently so named, or
> Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via the
> Wayback Machine, or something like it, the resource as it was on Sept 15,
> 2001.
>
> "[email-masked]" would indicate the person currently assigned the name
> "bob" by the mail server currently serving "example.com"
> "tag:[email-masked],2001-09-15" would attempt to resolve to a current
> address for whoever had been named "[email-masked]" in 2001. That address
> might be something completely different, of it might resolve to whoever was
> currently assigned the name (and had been since 2001).
>
> three edges of Zooko's Triangle (Memorability, Global, Security) when we
> really should also address a fourth edge: Persistence. (We should speak of a
> pyramid, not a triangle...) For more on this, see an old posting of mine  on
> "The Persistence of Identity (Updating Zooko's Pyramid)" at:
> On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker
> <[email-masked]> wrote:
>>

---

From: Bob Wyman <[email-masked]>
Date: Wed, 21 May 2014 12:11:30 -0400

James,
Since your "point in time reference," by including an Entity Tag or
Validator, requires knowledge of the resource's attributes at the
particular moment of interest, it would only work if people anticipated the
need to reference the resource at some future time and stored the pit:
values. It wouldn't help someone who knew nothing about the attributes of
example.org on a particular date but was attempting to discover them.

In those cases where one did anticipate the need to have a time independent
name for a resource, the hash you propose, since it is generated from
timestamp, vaildator and ref-url, essentially contains all the information
(with some loss) of the other components, thus, it seems that one could
economize by simply discarding those other bits.

Wouldn't pit:sha-256-32:f83b2add have much the same utility as
pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if
ones interest is only in the specific instance of the resource so named?

bob wyman

On Wed, May 21, 2014 at 11:39 AM, James M Snell <[email-masked]> wrote:

> address

---

From: James M Snell <[email-masked]>
Date: Wed, 21 May 2014 10:40:47 -0700

Truncating the pit reference would (a) make it harder to dereference
and (b) make it identical to the existing "naming things with hashes"
spec ;-) ... The key difference with pit would be to allow the
time-bound reference to be largely self-contained. But, you're right,
it would require specific knowledge of the resource being referenced
unless we allowed for a modified version that omitted the validator --
in which case, the timestamp becomes the validator (ala
If-Unmodified-Since).

On Wed, May 21, 2014 at 9:11 AM, Bob Wyman <[email-masked]> wrote:
> Validator, requires knowledge of the resource's attributes at the particular
> moment of interest, it would only work if people anticipated the need to
> reference the resource at some future time and stored the pit: values. It
> wouldn't help someone who knew nothing about the attributes of example.org
> on a particular date but was attempting to discover them.
>

---

From: James M Snell <[email-masked]>
Date: Wed, 21 May 2014 10:45:38 -0700

Storage is cheap yes, the potential practical/legal/privacy
ramifications of such archives, however, may not be. The ability to
dereference a resource's state, at a given point in time, without
requiring the resource state to be duplicated and stored by a
non-authoritative third party, would be an ideal solution.

On Wed, May 21, 2014 at 10:18 AM, Phillip Hallam-Baker
<[email-masked]> wrote:
> What I would like to see for archival storage is a mechanism that
> allows a document submission system to archive copies of the linked
> documents.
>
> Storage is cheap. Copyright is not always an obstruction.
>
> So for example, say I am writing an RFC, I submit the document to the
> IETF, the publication system sees that it references docs X, Y, Z and
> archive copies of them.
>
>
>
> On Wed, May 21, 2014 at 12:11 PM, Bob Wyman <[email-masked]> wrote:
>> James,

---

From: Bob Wyman <[email-masked]>
Date: Wed, 21 May 2014 13:58:30 -0400

"allows a document submission system to archive copies of the linked
documents."
Would you only want to copy the documents linked to directly? What about
the documents that they link to? How would you decide how "deep" you wanted
links to be followed? And, even if copyright wasn't an issue, what about my
"right to be forgotten?"

I assume that you wouldn't want to force a fresh copy every time that a
document is referenced unless it has changed since the last copy. What I
think you would probably prefer is building your archive as a web of
documents. Each document would have one or more versions and inter-document
links would be modified so that they referenced specific versions of other
documents. Something like tag uri or hash codes would serve your needs in
this case.

Of course, given a system like this, you'd probably realize that you only
need to copy the documents if you can't trust them to remain accessible
somewhere else. Generally, for instance, we can trust the IETF to keep
copies of RFC's on-line. So, you wouldn't need to actually copy referenced
RFC's -- you would accomplish the same semantic purpose by convincing the
IETF to adopt some agreed upon method to identify unique versions of
documents. The same goes for other sites. If copyright is an issue, this is
all you could hope for...

But, this leaves us with an interesting question... Does a document author
have the right to have some version of a document be "forgotten?" If you've
linked to a document that I wrote and I later discover that I've said
something profoundly stupid in that document, do I have the right to erase
it and thus prevent anyone from reading the evidence of my stupidity in the
future? Perhaps Europeans would say "Yes" and thus insist that you must not
copy on reference. On the other hand, others might say "No"...

bob wyman

On Wed, May 21, 2014 at 1:18 PM, Phillip Hallam-Baker <[email-masked]

> particular
> if
> >> It's an idea, at least. Whether or not it's a good one remains to be
> seen
> >> ;-)
> >>
> >> - James
> >>
> >> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps
> via
> >> > the
> >> > might be something completely different, of it might resolve to
> whoever
> >> > was
> >> > investigate the properties of naming systems are overly focused on
> just
> >> > the
> >> > really should also address a fourth edge: Persistence. (We should
> speak
> >> > of a
> >> > pyramid, not a triangle...) For more on this, see an old posting of
> mine
> >> > on
> >> >> Lets take a URL at a web site and imagine I download a page on 1st
> Jan
> >> >> 2010:

---

From: Bob Wyman <[email-masked]>
Date: Wed, 21 May 2014 14:30:24 -0400

If your primary concern is "papers" that would be actively archived by
their authors upon publication, could you use something like the "Handle
System" defined in RFC 3650 <http://tools.ietf.org/html/rfc3650>, RFC
3651<http://tools.ietf.org/html/rfc3651>
 and RFC 3652 <http://tools.ietf.org/html/rfc3652> and which is based, in
part, on Robert Kahn and Robert Wilensky's ideas for "A Framework for
Distributed Object Services <http://www.cnri.reston.va.us/k-w.html>"?

Another existing system that you might consider is the  Document Object
Identifier <http://en.wikipedia.org/wiki/Digital_object_identifier> system
defined by ISO 26324 <http://www.doi.org/ISO_Standard/sc9n475.pdf> . That
system provides for persistent identifiers which are independent of
location and time and defines a
resolution<http://www.doi.org/doi_handbook/3_Resolution.html>process
to dereference these things. (See
www.doi.org for more info)

bob wyman

On Wed, May 21, 2014 at 1:59 PM, Phillip Hallam-Baker <[email-masked]

> One simple approach would be to offer a service to allow authors to
> intern their own papers into the archive on publication.
>
> Most of the links in my papers are to other academic and/or
> professional papers. The people that publish them have much the same
> copyright interest as I do. It is likely that 80%+ of the material
> could be covered by a CC type license.
>
>
> In the traditional paper based publication model, editors act as the
> gate keeper on both quality and for persistence. But now space is
> cheap we can change the model.
>
> So lets imagine we have a consortium of five university departments
> that agree to maintain and publish a complete copy of an archive
> repository that people can post to for free with only minimal
> restrictions to keep out the kiddie porn, bomb making instructions,
> etc.
>
> If I am writing a paper that I want to be published and be available
> for free I can submit it to the archive. And then other people can
> link to it as a resource.
>
>
> Most university departments had some sort of monograph series back in
> the paper days. This would be similar.
>
> Now obviously there are going to be papers that rely on resources that
> are copyright. But remember that the purpose of copyright is to allow
> authors to extract revenues. So a link to a NYT article that hits
> their paywall is fine. The NYT has a business model that will support
> publication of their content indefinitely.
>
> We could also posit some sort of permanent repository that provides
> payments to the authors based on readership on the iTunes or Kindle
> model. If people link to those resources they will stay in print.
>
>
> So when we look at the persistence problem, I think the copyright
> problems solve themselves because they come with a business model. Its
> the free content that has the issues.
>
>
>
> On Wed, May 21, 2014 at 1:45 PM, James M Snell <[email-masked]> wrote:
> >>>> > It strikes me that the Tag URI scheme defined in RFC 4151, and used
> by
> >>>> > Atom,
> >>>> > addresses the problem of "time bounded" names. Of course, the Tag
> URI
> >>>> > system
> >>>> > currently has no authoritative resolution mechanism. However, it
> seems
> >>>> > that
> >>>> > Wayback Machine, or something like it, the resource as it was on
> Sept
> >>>> > 15,
> >>>> > 2001.
> >>>> >
> >>>> > Does Tag URI address your needs? If not, what is missing? If so,
> then
> >>>> > would
> >>>> > important quality for names. I've long thought that too many of
> those
> >>>> > who

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 May 2014 11:08:26 -0400

The tag system is interesting. But there are two separate issues here

1) Access to archival content, return the content that would have been
returned at date X.

2) Access to the resource that the owner of the domain in question
continues to intend to provide.

Providing the first means having to have a wayback machine type archive.

Providing the second would require a capability that does not yet exist but
could be built on top of Trans+DNSSEC.

So for example, let use imagine that Wyman Oil decides to offer you $20K
for wyman.us. And you want the biggest RepRap on the block so of course you
take the money.

Currently I have no way to reach you with an email. But under the proposal
if you checkpointed your DNS name in 2013 and kept the pointers up to date,
I could send you a message via [email-masked]

No, I don't know if this would be an attractive service or a practical one.
But it possibly solves one of the main problems I have had with enterprise
PKI which is the mess that happens when companies merge or split or shed
divisions.

On Wed, May 21, 2014 at 11:00 AM, Bob Wyman <[email-masked]> wrote:

> It strikes me that the Tag URI scheme defined in RFC 4151<http://tools.ietf.org/html/rfc4151>, and
> used by Atom <http://tools.ietf.org/html/rfc4287>, addresses the problem
> of "time bounded" names. Of course, the Tag URI system currently has no
> authoritative resolution mechanism. However, it seems that one could
> define and create such a thing. Thus, one could choose to either:
>
>    - Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps
>    via the Wayback Machine <https://archive.org/web/web.php>, or
>    something like it, the resource as it was on Sept 15, 2001.
>
>    - "tag:[email-masked],2001-09-15" would attempt to resolve to a
>    current address for whoever had been named "[email-masked]" in 2001.
>    That address might be something completely different, of it might resolve
>    to whoever was currently assigned the name (and had been since 2001).
>
> Does Tag URI address your needs? If not, what is missing? If so, then
> would it be worth the effort to define a Tag URI registration and
> resolution mechanism?
>
> three edges of Zooko's Triangle<http://en.wikipedia.org/wiki/Zooko's_triangle>(Memorability, Global, Security) when we really should also address a
> On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 May 2014 10:59:48 -0400

Henry is totally correct that there is no way to do this at the moment.

But TRANS is currently looking at a mechanism that would create a
fixed time series of X.509v3 PKIX certificates.

It is a fairly straightforward matter to extend that model to DNSSEC.
Basically we just output a traditional X.509 certificate (supported by
all the DNSSEC libraries I know of because they are typically built on
SSL libs). Then we enter that cert into the log.

What nobody has proposed so far is what use TRANS+DNSSEC would be.
Supporting persistent DNS name claims is that application. If I enter
my DNS name in a TRANS log then my claim to the DNSSEC name lasts as
long as I keep the key.

As with a few of my projects, it requires work in areas A and B to
produce a result that is applicable in area C.

Here the mechanism is in PKI and DNS space but the utility appears in
application space.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 May 2014 13:18:49 -0400

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 May 2014 13:59:56 -0400