Subject: [saag] post-X509 cryptographic identities

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 11:55:16 +0100

Stephen Farrell <[email-masked]> wrote in a IETF-last call thread:
    > Anyway overall I take this as more evidence that
    > x.509-based pki has outlived it's useful lifetime.
    > Given the webpki needs CT (which it totally does)
    > and now maybe novel revocation mechanisms like this,
    > (as well as soon-to-be PQ schemes if we believe
    > what people tell us), I'd argue it may well be time
    > to try see if there's any consensus on a post-x.509
    > direction towards which to head.

I agree with you strongly.
A centralized, single CRL from the single global PKI was certainly among the
original ideas envisioned.
Then we decentralized the PKI, add CT and added OCSP.

Now we are unifying again :-)
Mozilla could, for instance, create a new higher-level CA, sign all of the
existing trust anchors they ship, and effectively be back at X509.

----

While I am generally not in favour of extensive requirements processes, I
think that this does merit it.   Including publishing the document as
RF*Comments*, and seeking comments widely from other parties.

I am sure that mathmesh fits in here.

I think that the document needs to semi-biographical (or whatever the word is
for a history of thing).
{a creative author could write this in the first person: memoirs of X509}

I think that the document would say a series of things:
  The designers of X500/X509 intended X, but it turned out that this
  did not happen, and instead PKIX did Y.

(One could substitute X=DN, Y=SAN for instance)

I think that it is important for any new identity system to recognize what
forces pushed us away from the original vision.
We made engineering tradeoffs based upon time, code, bandwidth, round-trips
and threats.   Not every such decision is still justified.

So this requirements document would essentially be some kind of loving
criticism.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Derek Atkins" <[email-masked]>
Date: Tue, 11 Feb 2020 08:30:39 -0500

On Tue, February 11, 2020 5:55 am, Michael Richardson wrote:
[snip]
> So this requirements document would essentially be some kind of loving

Should this document also include the history of other PKIs, such as SPKI
and/or OpenPGP's WoT?  I think it would be interesting to put an
historical contrast on the visions behind the various methods/standards
and perhaps try to document the reasons (if possible) that "market forces"
took us in one direction vs another.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 15:26:44 +0100

> took us in one direction vs another.

Yes, I think that it has to.

Each evolved either as a response to X509.  Restating 2692/2693 or the design
requirements for OpenPGP is not called for; distilling what criticism were in
common and why SPKI did not fly is important.  And is there something
technical wrong with OpenPGP, or are we dealing with implementation issues?

---

From: "Derek Atkins" <[email-masked]>
Date: Tue, 11 Feb 2020 09:40:27 -0500

[snip]
> technical wrong with OpenPGP, or are we dealing with implementation

My personal opinion is that it was neither a technical issue nor an
implementation issue that caused the market to choose X509 vs OpenPGP, but
rather a philosophical issue (or perhaps business-money-making choices).

On the other hand, if we're going to rehash the design requirements for
X.509, I think it makes sense to also rehash the differences in
requirements for SPKI and OpenPGP (and maybe even DNSSec).  Specifically,
it's important to discuss how they differed, but also in what ways they
overlapped.  I do agree we don't need to go into the full history of all
of them (including X.509).

Again, this is just my opinion from someone who was deep in the trenches
back in the 1990s.

-derek

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 11 Feb 2020 09:57:35 -0500

The earliest public description of PKI development and objectives can be 
found in the seminal paper presented by Ruth Nelson in 1987.  See
Ruth Nelson, SDNS Services and Architecture, 10th National Computer 
Security Conference Proceedings, Sept 1987. 
https://csrc.nist.gov/publications/detail/conference-paper/1987/09/21/proceedings-10th-national-computer-security-conference-1987

The specification first appeared in the 1988 CCITT (now ITU-T) Blue Book 
where it was entitled "The Directory - Authentication Framework," in 
conjunction with the OSI internet ensemble of protocols.
https://www.itu.int/itu-t/recommendations/rec.aspx?rec=14033

That was followed in 1990 by its treatment by NIST as part of the GOSIP 
profiles.  See NISTIR 90-4250, Secure Data Network System (SDNS) 
Network, Transport, and Message Security Protocols, 
https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir90-4250.pdf

Shortly afterwards, in 1992, the original 1988 guide for X.509 
implementations was revised.  See ITU-T F.500 (08/1992), International 
public directory services
https://www.itu.int/itu-t/recommendations/rec.aspx?rec=676

ITU-T X.530 (11/2008), Information technology – Open Systems 
Interconnection – The Directory: Use of systems management for 
administration of the Directory,
https://www.itu.int/itu-t/recommendations/rec.aspx?rec=9601

Today, responsibility for X.509 remains with its longtime editor, Erik 
Andersen, who with Jean-Paul Lemaire is working on an updade on 
implementations.  They can speak to their efforts to evolve the 
specification and use.  These include two work items:
X.pki-em, Public-key infrastructure: Establishment and maintenance,
https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=13536
X.509prot, Protocol specifications for public-key infrastructure and 
privilege management infrastructure
https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=14393

The legal and public policy issues were extensively treated and 
developed to further the PKI industry through the International Law and 
Policy Forum (ILPF) which was established in the early 1990s and quickly 
evolved to focus on PKI provisioning.  The ILPF was modeled after the 
IETF to treat legal matters.

The IETF's involvement in the space was facilitated by the Internet 
Society purchasing considerable liability insurance in the early 1990s.  
Collaboration on PKI implementations invokes rather considerable 
potential antitrust and tort liability culpability - which is why the 
ITU-T remains the principal responsible body. You might wish to 
collaborate with others dealing with these matters in ITU-T SG17 Q11/17 
led by Jean-Paul, and the X.509 Editor, Erik Andersen.

--tony r

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 11 Feb 2020 10:30:48 -0500

Hi Derek,

The market was a minor factor.  PKI invokes more legal and public policy 
considerations than probably any other electronic communication sector.  
It emerged as a governmental platform for trusted identity management 
and was pursued in intergovernmental bodies with links into treaty 
instruments.

The ILPF very quickly came to focus almost exclusively on PKI in work 
led by Stewart Baker who had just left as NSA's GC. Verisign's early 
hire was Michael Baum who as Vice President of Practices and External 
Affairs, helped enable the marketplace by dealing with legal issues, and 
played a major role in getting PKI accepted worldwide. (Acknowledgement: 
I was also a VeriSign VP and a lawyer.)

PKI is a fundamental part of the EU's regional security strategy, as it 
is in most nations.  PKI implementations also dramatically shape 
marketplace competition - a subject now of rather intense scrutiny on 
both sides of the pond - and culpability extends both to individuals and 
standards bodies.

--tony

---

From: Watson Ladd <[email-masked]>
Date: Tue, 11 Feb 2020 08:54:00 -0800

> both sides of the pond - and culpability extends both to individuals and

Let's actually look at the dominant by order of magnitude application of
the PKI, namely authenticating servers identified by domain names.

The authoritative information is in the DNS. The CA system is only an extra
point of failure here, which is why things like DANE are promising.

None of the extensions like policy mapping etc.  matter.

> >>      > Should this document also include the history of other PKIs,
> such as
> >> SPKI
> >>      > and perhaps try to document the reasons (if possible) that
> "market
> >> forces"
> >> requirements for OpenPGP is not called for; distilling what criticism
> were
> >> in
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 10:57:21 -0600

> existing trust anchors they ship, and effectively be back at X509.

The worst thing about x.509/PKIX was x.500 naming, and that's
essentially fixed by using appropriate SANs.  Sure, it's still awful
ugly on the inside, but the naming on the outside is now OK.

That leaves only one lasting bad thing about x.509/PKIX: revocation, and
the answers to that we already know and have and would implement for
PKIX as much as for any PK-based replacement.  Short-lived credentials,
CT, a real root (see below) -- these are things we know to do.

I wouldn't throw the baby out with the bathwater.

However, if we must, then naming is the first thing to get right.
Naming is where the crypto rubber meets the UI/UX road.

And can I refrain from mentioning that DNSSEC is the _only_ true rooted
PKI we've ever managed to deploy?  Evidently I can't.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 11:02:12 -0600

> point of failure here, which is why things like DANE are promising.

Yes!  And with DNSSEC/DANE we can even have an appropriate link to PKIX
and avoid killing off PKIX altogether.

With DANE each site can operate a private CA and attest to it in their
DNS.  For now that's not a workable option for HTTPS server certs
because relying parties are still mired in WebPKI, but there's hope yet.

One could even use TLSA RRsets to indicate the issuer for user
certificates with rfc822Name SANs from a given domain.

> None of the extensions like policy mapping etc.  matter.

+1

Nico
--

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 11 Feb 2020 12:08:06 -0500

Hi Nico,

Does the OID namespace qualify as true rooted?  Ref. 
http://www.oid-info.com/introduction.htm

--tony

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 11:19:29 -0600

> http://www.oid-info.com/introduction.htm

Yes, but it's not a user-friendly naming scheme, and it has no PK, so
"no", not in the sense we're discussing here.

DNS, which is very similar, does qualify because a) DNS has a user-
friendly naming scheme (or at least users are all quite used to it by
now!) and b) DNS does have a PKI (DNSSEC).

Nico
--

---

From: Henry Story <[email-masked]>
Date: Tue, 11 Feb 2020 18:32:42 +0100

Hi all,

  I think that if one is going to rethink security and identity
on the internet one needs to revisit some deep assumptions about
what web site identities are and their relation to legal spaces.

DNSSEC DANE can be an answer to identity of web sites and it can be politically acceptable if DNSSEC moves towards being decentralized on a national basis the way it was designed to be. But it cannot deal with the 
legal aspect of identity which requires deeper tie in to legal systems.

The same is true of X509. It can also work to verify identifiers for
web sites, and Let’s encrypt does a great job for that. 
I explain what is is good and what the limitations are in
"Stopping (https) phishing"
https://medium.com/cybersoton/stopping-https-phishing-42226ca9e7d9

But one has to think much bigger and from an epistemological point
of view. That is one has to consider what it is that the user of
a browser can learn from the information given to him.
I explain that in 
”Epistemology of the Screen”
https://medium.com/cybersoton/phishing-in-context-9c84ca451314

Currently one learns nearly nothing from an X509 certificate. Nothing
that is interesting enough and useful enough to a user, that they would feel 
like looking there. And nothing that really helps establish trust in an international environment. That requires one to tie these into rich data
provided by legal systems tied into a ”Web of Nations” 
https://co-operating.systems/2019/07/29/Web_of_Nations.proposal.pdf

This is following an idea that we are both individuated by the nations
in which we live (or smaller local structures) and individuate them 
(by helping create standards for example, or writing great poetry, or educating children...). We  then individuate each other through commerce
and intellectual exchange.

In the international space it is nations that provide guarantees of legal status. They themselves form a social network of higher level 
agents of which we are part. To defend this requires some deeper philosophical, and I can provide links to some thinkers working on 
it if needed.
The idea is to build a structure for internations, by linking 
them together in an  open non coercive way, and make it possible for companies to make their legal ties visible to citizens around 
the world, in a purely opt-in manner. 

Hope that helps,

Henry Story
https://co-operating.systems/
@bblfish on Twitter

> On 11 Feb 2020, at 17:57, Nico Williams <[email-masked]> wrote:
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 11:33:51 -0600

On Tue, Feb 11, 2020 at 11:19:29AM -0600, Nico Williams wrote:
> ...

I should add that IIRC someone patented the use of DNS for OID arc
resolution.  Lame (because obvious).  What's to resolve an OID to?
Symbolic form.  Authority.  Documentation and/or document references.

Just some trivia for you.

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 11:45:44 -0600

On Tue, Feb 11, 2020 at 06:32:42PM +0100, Henry Story wrote:
> DNSSEC DANE can be an answer to identity of web sites and it can be
> politically acceptable if DNSSEC moves towards being decentralized on
> a national basis the way it was designed to be. But it cannot deal
> with the legal aspect of identity which requires deeper tie in to
> legal systems.

Anyone can mirror and sign their own ., observing and controlling key
rotations for TLDs, and avoiding active (MITM) attacks by anyone
possessing the keys to the root.

There's your decentralization.

Q: Why even want decentralization?
A: For protection from active attacks by roots.

Better than decentralization, let's discuss protection from active
attacks by privileged entities with access to root/TLD private keys:

 - Use QName minimization to make life much harder for any would-be
   privlieged entity to mount active attacks.

 - Add CT-like after-the-fact auditing of past resolutions, and you have
   all the active attack protection you can expect from a rooted PKI.

   One does not even need CT to do this to some degree and get some
   protection, though adding CT for DNSSEC would help.

> web sites, and Let’s encrypt does a great job for that. 

WebPKI can never have a root.  WebPKI is already decentralized.

The problem with WebPKI is not lack of a root nor centralization, but
lack of name constraints.

DNSSEC has name constraints fully built-in to the system.

> https://medium.com/cybersoton/stopping-https-phishing-42226ca9e7d9

Phishing is a whole different and separable issue.  The fundamental
problem with phishing is that humans too-easily fall for scams, and no
authentication technology can stop this.

> a browser can learn from the information given to him.

See above.  Humans are stupid and fall for scams too easily.  Technology
cannot provide a complete answer to that.

> that is interesting enough and useful enough to a user, that they
> would feel like looking there. And nothing that really helps establish
> trust in an international environment. That requires one to tie these
> into rich data provided by legal systems tied into a ”Web of Nations” 

See above commentary about name constraints.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Tue, 11 Feb 2020 19:05:01 +0100

> On 11 Feb 2020, at 18:45, Nico Williams <[email-masked]> wrote:
> 
>> 

I am not arguing against DNS-SEC Dane nor X509, but to
enlarge one’s view of how names get meaning. Those
two systems only allow one to tie a name to a referent.
They don’t give the meaning of a name, which it squires by
how it is related to other entities.

This is similar to ideas from Category theory, that
an object in a category is determined by its relation
to all other objects in that category. One does not
need the relation to all other things to be visible, for
a web site, but one needs more than a name. 

Paying Certificates provide a little more: an address. But that
is static, and epistemologically quite problematic: who knows
all geography so well that they can tell from an address 
where the site is located? 

> authentication technology can stop this.

How can you ever improve your system if you start with such a
flawed psychological theory? 

Humans are not stupid. They have limited time to dedicate to
the task of understanding where an web site is located. This
could be improved by making the information
 1) enriching the information provided to be interesting and relvant
 2) by making the information dynamic
 3) and making it visible to the users.

You can’t do anything in the User interface of interest with the
information provided in certificates currently. That is just because
the information is so poor, and it is so poor because no private
entity wants to risk certifying more information than the minimal
amount. 

> cannot provide a complete answer to that.

That is equivalent to the standard argument from epistemological skepticism,
you cannot know that you are not dreaming, so how can you know anything.

It is not because you cannot remove all potential security threats, 
that you cannot make big steps forwards.

> See above commentary about name constraints.

Clearly you did not spend any time reading any of the links I sent
there. As you would see that my point is not that naming is broken
but that the linking between the names is non existent.

Henry

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 11 Feb 2020 13:55:10 -0500

Hi Nico,

The patent would be worthless.  DNS for OID arc resolution was 
originally proposed by VeriSign's Michael Mealling about 20 years ago in 
RFC3061, introduced again by VeriSign in ITU-T about 15 years ago, and 
then pursued by Korea's ETRI as a series of ITU-T standards X.672, 
X.674, X.675 and X.676.  The root resolver authority is allocated to the 
Korean Information Security Agency. It is known as the OID Resolution 
System (ORS).  Orange's research centre has long maintained a http based 
resolver at the OID Repository site, www.oid-info.com.  Note the KISA 
Activity for the ORS on the OID-INFO site.

OIDs rank as one of the most ubiquitous object identifiers and in 
addition to ASN.1 code and X.509 PKI cert information, it has found 
favor in recent years for IOT tagging.  It is resolved to all kinds of 
information.

--tony

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 13:17:14 -0600

On Tue, Feb 11, 2020 at 07:05:01PM +0100, Henry Story wrote:

[Quoting out of order]

> entity wants to risk certifying more information than the minimal

This is one thing we can improve: the binding of HTTPS URL authority to
an actual owner.  The certificate is useless, indeed, and cannot bring
any more metadata into the picture than the hostname -- the binding of
that to authorization by a proper owner is essential, and the WebPKI
cannot provide this well enough.

Providing _more_ metadata likely won't help human users: they can barely
cope with the concept of a domainname, let alone more stuff.

> two systems only allow one to tie a name to a referent.

I don't think I implied that you were.

> [...]

You're headed right for the identity problem, and thorny problems in
philosophy like the Ship of Theseus problem.

You will not find an answer to these problems in cryptography.

All of our naming schemes have a layer of indirection where the tie to a
physical entity is weak (a physical entity whose own "identity" is
weak).

> flawed psychological theory? 

Oh?

> could be improved by making the information

Humans are _often_ quite stupid.  Not always, but also not never.

>  3) and making it visible to the users.

You quickly run into issues.  UIs that are too busy.  Different people
having different attention spans, different likes and dislikes for UIs.

There is no one-size-fits-all UI.

Browser developers have been struggling for decades with this problem.

"Look to epistemology" is a platitude.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 13:21:29 -0600

On Tue, Feb 11, 2020 at 01:55:10PM -0500, Tony Rutkowski wrote:
> The patent would be worthless.  DNS for OID arc resolution was originally
> proposed by VeriSign's Michael Mealling about 20 years ago in RFC3061,

Yes, I know it was long ago enough that it's probably expired.  It's a
minor relief to know it must be!

> introduced again by VeriSign in ITU-T about 15 years ago, and then pursued
> by Korea's ETRI as a series of ITU-T standards X.672, X.674, X.675 and
> X.676.  The root resolver authority is allocated to the Korean Information
> Security Agency. It is known as the OID Resolution System (ORS).  Orange's
> research centre has long maintained a http based resolver at the OID
> Repository site, www.oid-info.com.  Note the KISA Activity for the ORS on
> the OID-INFO site.

Interesting.  Thanks for the info.

> OIDs rank as one of the most ubiquitous object identifiers and in addition
> to ASN.1 code and X.509 PKI cert information, it has found favor in recent
> years for IOT tagging.  It is resolved to all kinds of information.

Yes.  But they are not useful for _humans_.

We even use OIDs in APIs, e.g., the GSS-API.  A mistake that.  URNs are
much simpler and easier to use for developers.

Just say not to OIDs.  Use URNs, and if you have an OID, remember that
there's a URN form for OIDs.

Yes, of course, on the wire in PKIX and many other protocols we have to
use OIDs where the relevant protocols use them.  But there's no need to
bleed these into APIs, let alone UIs.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Tue, 11 Feb 2020 21:11:54 +0100

> On 11 Feb 2020, at 20:17, Nico Williams <[email-masked]> wrote:
> 

I believe you are drawing completely the wrong conclusions from the
data. In my view they can’t cope with the domain name info because
it is completely uninteresting (given the many other tasks they are
involved in when using the Web). 

Just try to think your way back to a user first discovering the 
certificate description box. What information do they find there
that would warrant them coming back? Do they find a telephone number?
Shop opening times? information about if the CEO landed in Jail?
No. They may just find a URL. Why would anyone ever come back?

They then find that a certificate authority signed it. Who is that CA?
No idea. 

Now adding more data does not of course help if you don’t display it
intelligently. That is what designers make their profession. But they
can’t do anything if there is nothing to display.

> philosophy like the Ship of Theseus problem.

The Ship of Theseus problem is the ancient puzzle that asks if the ship
is the same if one changes one plank, then another, … until one has
changed all planks.

That is: it is about the identity of a changing thing over time. When is 
it the same and when is it other? The answer depends on one’s criteria of identity for a given type of thing. Usually opinions vary.

In our situation the question would be: when is the site the same 
and when different?  Is it different 
- when a page changes? No
- when the owners change? Perhaps…
- if the owners stay the same but move to different country? …
   what if that country is at war with yours?

Importantly: this criterion of identity does not need to be decided once and
for all, in abstraction of all individual cases. 

The user can decide on a set of policies to make him aware 
depending on his relation to the owner of the domain. Eg. 
a user that has a contracts with that domain, would be very 
interested in knowing that a web site has changed legal space.
Someone going to a restaurant may be very interested if the cook
changed.

These criteria can be set by the user and these may be enhanced
in some countries by legal requirements. Eg. an owner can’t claim
his web site is different and that he does not have to abide
by his contracts because he changed a page.

> You will not find an answer to these problems in cryptography.

I agree. 

> physical entity is weak (a physical entity whose own "identity" is

yes. My claim is that one needs to tie these into national or regional
institutions that have been set up for over a century to do this job.
The UK has a company index called Company House that has JSON machine
readable versions of their records.

See the curl example on 

> There is no one-size-fits-all UI.

Exactly. That is why UIs have to be personalized. It’s not an easy job,
but it is not impossible. Look at how many people are using Unix now
that it has a GUI called Android or one called iOS. (In the early
1990ies people would laugh if you told them that Unix would be
widely used because they would boggle quite rightly at the idea
that everyone would use the command line).

> Browser developers have been struggling for decades with this problem.

yes, because there is no information for them to work on!

> "Look to epistemology" is a platitude.

Btw. I don’t just say ”Look to epistemology”.

I have an analysis of where the problem comes from, and some suggestions
on where one has to look to fix it. It is not easy to see, because
it is in very different place from where the IETF has its focus
(to simplify: protocols) whereas here we are thinking of linking
nations into a peer to peer decentralized social network: a Web
of Nations, in order to provide users information about the legal space
of web sites they are in. So one has to have a view of the whole space
of what makes an individual: what they do, the society they are in, the relations of those societies to each other and to yours, … and the tools
they are using which transforms the above space.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Feb 2020 21:05:50 +0000

Hiya,

As a quote of mine seems to have started this...

> I agree with you strongly.

Great.

Unfortunately for me, I figure I disagree with the
direction of almost all the discussion in the rest
of this thread so far;-)

- I like DNSSEC, but at ~1% penetration in 20 years
it is not the answer, regardless of whether or not
it ought be the answer. (Even so, continued effort
to improve DNSSEC deployment by paying registrars
etc is good as it does mitigate real vulnerabilities
when deployed.)
- I like some of PHB's ideas wrt his meshy thing,
but I do not believe that a single all-encompassing
model like that that starts from better crypto will
fit all needs. I'd be happy to be wrong, but also
surprised.
- I like abstract discussions sometimes, but IIRC
I think I've seen those more abstract points made
various times over the years with them leading to
nothing much.
- While I probably got fed up with x.509 about the
turn of the century after a decade of writing code
for it, I recall that even before then I concluded
it had been a pretty bad error to lawyer-up any of
those discussions before we knew how to schlep the
bits around, so I'd run a mile if someone wanted
to start from there;-)

For me, I'd be interested in starting with a much
less ambitious goal, e.g. perhaps how to integrate
PQ algs into TLS and SSH without x.509, or maybe
whether we could do even better than ESNI inside
HTTPSSVC, or maybe if there's a way to unify smime
and pgp via new key packaging (that MUA folks would
accept). Or other relatively modest but still quite
hard things like those.

If some set of similar designs addressing a few
such concrete problems could be deployable alongside
the current stuff, and people started coding 'em up,
then we might be on to something.

Cheers,
S.

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 11 Feb 2020 16:27:04 -0500

Hi Stephen,

Given the state of affairs today, the folks involved here as well as the 
IETF Trust are unlikely to avoid lawyering up.  You might also get the 
Trust to "insurance up" for you, and provide better guidance on high 
risk activities.  The previous treatment of the subject is now a bit old 
and was inclusive. https://www.ietf.org/jabber/logs/antitrust/  It also 
didn't treat other problem areas like tort liability.

This is also all assuming that there is no direct engagement from 
government authorities as they once did - which might actually be a good 
thing from an lawyering up and insurancing up standpoint. They assume 
the responsibility and provide the cover - which is what occurs in ITU-T 
X.509 activities.

-t

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 22:39:25 +0100

> rather a philosophical issue (or perhaps business-money-making

I'm not actually trying suggesting that they served the same purpose.
X509 encrypted email (SMIME) is astonishingly rare, despite hundreds of
millions being spent within Governments deploying things.  It's important to
understand if there were technical decisions that resulted in market failures.

    > of them (including X.509).

What I want to understand is: are we living with technical decisions that
made sense at the time, but which are now resulting in pain?

---

From: Henry Story <[email-masked]>
Date: Tue, 11 Feb 2020 23:50:36 +0100

> On 11 Feb 2020, at 14:30, Derek Atkins <[email-masked]> wrote:
> 
> 

After my intervention in this thread earlier today on the importance
of the relation of data and naming, it occurred to me that the
early X509 standards where bound to a data protocol X500, which later lead
to LDAP. (I don’t know this story in detail but I am sure many
here could write books about it). The important thing then is that 
it could be argued that the architecture of naming made sense when complemented with a system for tying identities to richer data. 
As these protocols failed to function at global scale one was left 
only with only identity/reference working.

I claim that Data should be thought of as putting things into relation 
to one another. If I can invoke some mathematics here, a very 
clear way of presenting databases in Category Theory developed 
by Spivak at MIT is as a functor from of a small category (the schema)
onto the category Set. See the very clearly written
  ”Functorial Data Migration”
https://arxiv.org/abs/1009.1166

Now a key concept in this view is that of a Grothendieck construction,
which is a category that arises out of a database instance (i.e. such
a Functor) by flattening the schema and the data together.
This is explained in that article in a few short paragraphs. 
In later work they use this construction  in order to give a mathematical model of how DB queries work. 

Spikvak in that article see this as being the structure behind RDF, 
the semantic web standard developed at W3C, though it turns out that 
this works better when instead of using a functor to Set one works with 
functors from bicategory of Relations to the category Rel of sets and relations. (shown in a recent article)
https://arxiv.org/abs/1706.00526

There is thus some deep mathematical reasons to think that the 
structures behind the Semantic Web project are the right ones
to build databases. Furthermore it was designed
to work in decentralised systems that use all the protocols developed
here at the IETF. So the analysis of data as relational, 
and their tie to identity (each name being an identifier) 
and the need for both to work together, shows it seems to me, that
in order to fulfill the original vision of X509, one should
perhaps help oneself of the 20 years of work done at W3C,
and in universities across the world.

Henry
@bblfish

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Feb 2020 00:52:48 +0100

> As a quote of mine seems to have started this...

:-)

    > direction of almost all the discussion in the rest

A bunch of people went into solution space without stopping to ask what went
well, and what didn't go well.

    > accept). Or other relatively modest but still quite

Those are interesting things; challenging to do without some lead people who
write MUAs.

would https://datatracker.ietf.org/doc/draft-birkholz-core-coid/ fit into
your idea?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 16:02:16 -0800

[Trimming extensively]

On Tue, Feb 11, 2020 at 1:06 PM Stephen Farrell <[email-masked]>
wrote:

> PQ algs into TLS and SSH without x.509

Well...
It's already straightforward to integrate PQ key establishment into TLS w/o
X.509.
It's also possible to do PQ authentication w/ Delegated Keys.

Finally, TLS supports new credential types via the "certiifcate_type"
extension, so if you were to define some new kind of credential structure,
TLS could take it easily. However, it's hard to see how that would actually
fit into existing deployments of TLS, which are already rooted in the
WebPKI; if we wanted to add PQ signatures to TLS for the Web, we would do
it by defining new algorithms for X.509.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Feb 2020 18:21:27 -0600

Post-x.509 identifiers...  This isn't just about x.500 naming being
awful?

What do humans deal in?  Well, we deal in:

 - (trade)marks (trademarks, DBAs, ...)
 - personal names
    - and various documentary ID types (typically government-issued, but
      not necessarily)
    - bank account numbers and such
 - place names

Names, names, names.  Off-line too.  Book titles.  TV station names.
Play names, show names, movie names.  Names, and almost nothing but
names.

On the web humans mostly deal with domainname mappings of (trade)marks.
Indeed, the domainnames themselves are marks.

How much of a revolution in this state of affairs do you suppose the
IETF can drive?

Can we move past domainnames?  Maybe.  What is realistic?

One possibility is to do everything via smartphone apps, with app store
operators acting as curators.  Naming would still be about (trade)marks
(including icons, at least for those who are not sight-impaired), but we
might get past domainnames.  Who wants such a world?

What about laptops and desktops?

There's also corporate environments to think about, where naming of
_services_ is not after marks, but other things, and where web apps are
king rather than smartphone apps.

IMO domainnames aren't going away.  Indeed, people know what they are,
and interact with them.  Why should we ask users to forget about
domainnames just when they got used to them?

IMO as long as we have anything like names, there will be confusables
and phishing.  And I don't see us getting away from names.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Feb 2020 00:34:56 +0000

Hiya,

> It's already straightforward to integrate PQ key establishment into TLS w/o

I don't accept "straightforward" fwiw for the reason set
out at the end.

> It's also possible to do PQ authentication w/ Delegated Keys.

Yes, possibly so. Delegated keys is not IMO a part of x.509
but kind of extends that a little but is a new model.
Should such keys become common, that might get interesting.

> WebPKI; 

Yes, it would be hard to change the web from the WebPKI
being the only source of CA public keys for TLS. (Mind
you, the real root of trust is the browser or OS s/w update
mechanism which is not what many would call the WebPKI.)
Any also yes, any such change would have to be desirable
for those involved - there's no point in a supposedly
better technical thing that nobody relevant likes. (I
guess that's part of where DANE didn't work for the web
in the end.)

> if we wanted to add PQ signatures to TLS for the Web, we would do

I agree that that is the approach most likely to be the
initial one considered by those interested in the status
quo:-)

To be fair though, yes, the TLS issues would be fairly
straightforward if we had a new PQ algorithm that we all
considered good enough by itself. I don't believe that
that will be the case though, for fairly well rehearsed
and not-crazy reasons. And the mix of multiple algorithms
in one cert thing is just not x.509 IMO, no matter how
often someone tries to put that lipstick on that animal.
(And the same applies to stateful signature schemes.)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 16:51:24 -0800

> I don't accept "straightforward" fwiw for the reason set

Well, I see what you say at the end, but I don't understand it. In TLS 1.3,
key establishment does not involve the cert, which is used for
authentication. So, it's straightforward to swap in a new key establishment
algorithm and we've already seen a bunch of combined EC/PQ algorithms
(masquerading as new EC curves).

> Should such keys become common, that might get interesting.

Well, the point being that you can just gradually roll out a new PQ
signature algorithm at the endpoints without touching the PKI.

> initial one considered by those interested in the status

Well, if by "interested in the status quo" you mean "by far the easiest
thing to do with the world as it is", then yes. The key point being that we
are going to have to have X.509 for the indefinite future so some new
parallel thing is extremely expensive.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Feb 2020 01:09:01 +0000

On 12/02/2020 00:51, Eric Rescorla wrote:
> authentication. 

Sure. And in a PQ world one might worry about factorisation
and propose unwise changes to x.509 that involve >1 alg in
the certificate signature and SPKI fields. My main point is
that I think that'd be unwise. (Not so much because of TLS
details, but more because of x.509 library details.)

It'd be similarly unwise to want to try handle public keys
for PQC KEMs via x.509 and given the entire world is not
yet on TLS1.3, that'd maybe still be a bit of an issue.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 17:16:25 -0800

> yet on TLS1.3, that'd maybe still be a bit of an issue.

Well, I don't think there is going to be much enthusiasm for adding PQ to
TLS 1.2, but even if there was, you would most likely do it the same way as
in 1.3, as a new DH "group"

-Ekr

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Feb 2020 01:21:32 +0000

On 12/02/2020 01:16, Eric Rescorla wrote:
> On Tue, Feb 11, 2020 at 5:09 PM Stephen Farrell
> <[email-masked]> wrote:
> 
>> 
>> 
>>> Well, I see what you say at the end, but I don't understand it.
>>> In TLS
>> 1.3,
>> Sure. And in a PQ world one might worry about factorisation and
>> propose unwise changes to x.509 that involve >1 alg in the
>> certificate signature and SPKI fields. My main point is that I
>> think that'd be unwise. (Not so much because of TLS details, but
>> more because of x.509 library details.)

I'm not sure if you're agreeing with me in the above
or just skipped over that. But that's ok.

>> 
>> It'd be similarly unwise to want to try handle public keys for PQC
>> KEMs via x.509 and given the entire world is not yet on TLS1.3,
>> that'd maybe still be a bit of an issue.
>> 
> 
> Well, I don't think there is going to be much enthusiasm for adding
> PQ to TLS 1.2, but even if there was, you would most likely do it the
> same way as in 1.3, as a new DH "group"

That would make sense, yes. History seems to me to
indicate that people will want every possible way to
do it to be well-defined, leading to those x.509
library complications in the code, even if it's rarely
executed. (A well-known undesirable thing.)

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 17:25:06 -0800

> or just skipped over that. But that's ok.

I didn't think it was that relevant to the topic of KE, as noted below.

> executed. (A well-known undesirable thing.)

Well, I suppose that's possible, but as that would require defining TLS
cipher suites that used those certificates, and I agree that would be a bad
thing, we would presumably have an opportunity to say so.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Feb 2020 01:29:19 +0000

> thing, we would presumably have an opportunity to say so.

Correct again. I do however, think that setting out in
a direction that doesn't lead there would be better (if
such a direction exists, which I'm not making a strong
claim is the case).

It's often hard to resist the impetus to define such
code-points once people have started meandering down
the path that leads them to eventually ask for those.

Cheers,
S.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 12 Feb 2020 15:51:07 +0000

Tony Rutkowski <[email-masked]> writes:

>found in the seminal paper presented by Ruth Nelson in 1987.  See Ruth
>Nelson, SDNS Services and Architecture, 10th National Computer Security
>Conference Proceedings, Sept 1987.

Uhh, that doesn't talk about PKI at all, it talks about SP3/SP4, key
agreement/transport, and the use of key management centres.  In particular
certs are issued by the KMC, which makes it more a type of server-assisted
crypto mechanism where you contact a server in order to communicate securely
with someone else, which was done by the Public File about a decade earlier.

Peter.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 12 Feb 2020 16:04:40 -0500

Hi Peter,

Ruth was the leader of one of the higher level SDNS teams.  If you go to 
the paper on SP4 (IPSEC), you can see how PKI is used and managed in the 
paper by Branstad, Dorman, Housley, and Randall.

> SP4 was designed to be independent of encryption algorithm and method 
> of key distribution. Either symmetric or asymmetric algorithms can be 
> used.
> SDNS uses SP4 with a symmetric key algorithm. SP4 depends on the key 
> manager to establish and update traffic keys. The SDNS key manager 
> uses public key cryptography to generate these traffic keys
--tony r

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Feb 2020 14:51:01 +0000

> might get past domainnames.  Who wants such a world?

When I wonder about this kind of thing, I try to think about the
practicalities: would the OS vendors want to run registries for hundreds
of millions of names themselves, or would they prefer to outsource it?
Would the setup be something like certification authorities? How would the
namespace relate to the market structure: would they be parallel like the
DNS, or unrelated like WebPKI? Would we end up with something like the
CA/B forum, except also responsible for the top-level of the namespace,
and thus effectively performing the same function as ICANN?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes: Cyclonic 5 to 7, becoming south or
southeast 7 to severe gale 9, occasionally storm 10 later in Bailey and
Faeroes. Rough or very rough, becoming very rough or high and very high later
in Bailey. Wintry showers, rain later. Mainly good, becoming moderate or poor
later.

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2020 11:13:25 -0600

> of millions of names themselves, or would they prefer to outsource it?

That's the gist, isn't it.  Registries.  Authorities.  Ultimately a tie
to legal dispute resolution mechanisms.  Messy stuff.

DNS was a worldwide revolution in naming affairs by creating a scalable,
global registration and authority system to go with a scalable
resolution system.

(From a UI perspective, DNS is just an evolution: before we had names,
after we had names.)

DNS and the Internet created realities on the ground that sovereign
entities had to recognize.  That seems likely an accident of DNS
stepping into a vacuum.  Now that the vacuum has been filled, any
replacement may well require significantly more willpower to establish.

> Would the setup be something like certification authorities? How would
> the namespace relate to the market structure: would they be parallel
> like the DNS, or unrelated like WebPKI? Would we end up with something
> like the CA/B forum, except also responsible for the top-level of the
> namespace, and thus effectively performing the same function as ICANN?

Yes, any future revolution in naming will have to deal with registries,
and will have to deal with sovereign entities.

Nico
--

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 13 Feb 2020 12:34:12 -0500

Hi Nico,

We have had hierarchical trusted name systems for a while.  PSTN numbers 
still serve that function - which drove ENUM.

The old idealized legacy DNS model arguably disappeared with vigorous 
competition among alternative root servers, e.g, 1.1.1.1, 8.8.8.8, etc.

Then there is also the shift to E2E MEF Ethernet...or with DONA's Handle 
System.

All of this arguably underscores the continuing need for a trusted PKI 
cert.  As you note, sovereign registries have value.

--tony

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2020 11:56:27 -0600

> competition among alternative root servers, e.g, 1.1.1.1, 8.8.8.8, etc.

The registries and registrars haven't changed.  The quad-Ns have not yet
balkanized the namespace.  They could, and they might, but it'd be
awfully controversial, and it's not likely to happen.

Moreover, DNSSEC still prevents namespace balkanization, and the quad-Ns
aren't yet replacing the root keys with their own.  Nation states _can_
pull this off because they can force people within their jurisdictions
to use balkanized DNS.  And quad-N providers might even provide that
service to nation states, but we're not there yet, and that's not
evidence that a global namespace is bad.

> cert.  As you note, sovereign registries have value.

The registries need not be sovereign, but the dispute resolution
mechanisms they tie into must be.

Users need ways to establish trust.  Person-to-person (or device-to-
device) trust establishment is amenable to TOFU, but customer-to-
provider trust is not really.  The latter requires a namespace that
users can navigate to find -ultimately- where to bring civil suit if
need be.

Nico
--

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 13 Feb 2020 13:18:36 -0500

Antitrust and tort liability are significant components here as well, 
and the support by sovereigns provides immunity.  Why antitrust 
enforcement or litigation hasn't occurred already, seems almost improbable.

The billions of OID tagged objects with certificates originally 
envisioned by Jim White and others at PARC, was predicated on immunity 
provided by sovereigns.  Indeed, the US portion of the namespace was 
covered by a DOC proceeding in 1992.  Two years later, the newly 
free-floating IANA would adopt a no trust approach to generate money for 
the growing DARPA DNS domain name business.  See 
http://www.circleid.com/posts/20180113_the_meeting_that_changed_the_darpa_datagram_internet/

--tony

---

From: Henry Story <[email-masked]>
Date: Thu, 13 Feb 2020 19:48:18 +0100

> On 13 Feb 2020, at 19:18, Tony Rutkowski <[email-masked]> wrote:
> 
> Antitrust and tort liability are significant components here as well, and the support by sovereigns provides immunity.  Why antitrust enforcement or litigation hasn't occurred already, seems almost improbable.
> 
> The billions of OID tagged objects with certificates originally envisioned by Jim White and others at PARC, was predicated on immunity provided by sovereigns.  Indeed, the US portion of the namespace was covered by a DOC proceeding in 1992.  Two years later, the newly free-floating IANA would adopt a no trust approach to generate money for the growing DARPA DNS domain name business.  See http://www.circleid.com/posts/20180113_the_meeting_that_changed_the_darpa_datagram_internet/

I think one has to take it as a ”fait accompli” that domain name dilution
has happened. In any case asking people to remember the meaning of 2 character codes for country names globally would have required a huge
investment in teacher training, child training etc… to accomplish. 
Most Europeans have trouble remembering where US states are located
even though it is taught in final years around the age of 17-18. Most
US citizens have trouble remembering all the states of Europe, even
though many had ancestors the immigrated from here.

That is not the way to do things. Instead lets accept that choosing domain names is taken over by marketing folks, that poor countries are selling
their domains to make much needed money, etc… Furthermore the only way to
get rid of domain name squatters is to make their business irrelevant by
just adding new domain names.

Instead one should lead the Sovereigns to enter into the web by providing
data in machine readable format, about the companies and web sites that
wish to tie themselves to those legal institutions, the benefits of 
which are not to be underestimated: you only need to live some time in lawless zones, from squats onwards to understand how helpful the law is.
This can be done in a purely opt in basis, though it would require 
some conventions to be agreed upon, and the basic naming infrastructure 
to work securely.

I describe towards the end of chapter 3 of my second year report 
in different language a detailed version of how this can work.

https://co-operating.systems/2019/04/01/PhD_second_year_report.pdf

In a way it is one of the core principles of URIs: one should not 
try to encode semantics in them. 

Btw. one of the reasons why the system worked for so long, is that initially
the web of trust on which domain names and URIs built was built up
in a peer to peer manner by people linking pages. Those pages that got
the most links rose to the top in search engines that started using that
information (At AltaVista we did not know how to do it).

Now that undermining the system of links through bots has a lot of 
value, that architecture no longer works. One actually now needs the
systems that have evolved to deal with law and law breakers, which
are called states, and which exist in diplomatic/anarchic relations
with one another.

This is an interesting conversation, that is giving me a lot of
good ideas on how to structure my final thesis.

Henry

> <19921014_USdomainProcedures.pdf>_______________________________________________
> saag mailing list
> [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2020 13:19:53 -0600

On Thu, Feb 13, 2020 at 07:48:18PM +0100, Henry Story wrote:
> I think one has to take it as a ”fait accompli” that domain name
> dilution has happened. In any case asking people to remember the
> meaning of 2 character codes for country names globally would have
> required a huge investment in teacher training, child training etc… to
> accomplish.  Most Europeans have trouble remembering where US states
> are located even though it is taught in final years around the age of
> 17-18. Most US citizens have trouble remembering all the states of
> Europe, even though many had ancestors the immigrated from here.

That's a misconception, that peole need to know country codes.  Or that
we need anything like geopolitical hierarchy in the DNS, except for the
purposes of registration and dispute resolution, which requires
namespaces with registries, registrars, and sovereign jurisdictions, but
not much more.

> That is not the way to do things. Instead lets accept that choosing
> domain names is taken over by marketing folks, that poor countries are

Yes.

> selling their domains to make much needed money, etc… Furthermore the
> only way to get rid of domain name squatters is to make their business
> irrelevant by just adding new domain names.
> 
> which are not to be underestimated: you only need to live some time in
> lawless zones, from squats onwards to understand how helpful the law
> is.  This can be done in a purely opt in basis, though it would
> require some conventions to be agreed upon, and the basic naming
> infrastructure to work securely.

We have this now.

You might propose tweaking governance.  You might propose all sorts of
things, but some will be easier to pull off than others.

> information (At AltaVista we did not know how to do it).

Yes, the search engines function as a sort of registry.

> are called states, and which exist in diplomatic/anarchic relations

Yes.  But would any alternative look that different to the current DNS?
I am very skeptical.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Thu, 13 Feb 2020 21:33:47 +0100

> On 13 Feb 2020, at 20:19, Nico Williams <[email-masked]> wrote:
> 

This official data is being put together in machine readable format
such as JSON-LD, under umbrella projects going under the name of ”Open Data”. 

> Yes, the search engines function as a sort of registry.

One that depends on the correctness of the information published,
even if only statistically. 

> Yes.  But would any alternative look that different to the current DNS?

As I see it, the problems is not at the naming layer
at which DNS is located where the problem is that of attaching a name 
to an IP Address. Whatever system is used - bare ipv6-addresses, 
namecoins, onion domains,… - all these  only give a way to identify 
agencies in charge of machines. What is important is knowing what
agencies those are!

What is needed is rich information that ties these ”publication machines” 
to machine readable official information about those entities.  This info
exists: states put that together to gather taxes, provide services, base legal enforcement on it, … 

The web site could link to such official machine readable information
by using a ”registry” Link relation in an http header.

I have illustrated this on my web site 

$ curl -I https://co-operating.systems/
HTTP/1.1 200 OK
Date: Thu, 13 Feb 2020 20:08:05 GMT
Server: Apache/2.4.38 (Debian)
Last-Modified: Thu, 16 Jan 2020 21:48:01 GMT
ETag: "22d6-59c48c7766109"
Accept-Ranges: bytes
Content-Length: 8918
Vary: Accept-Encoding
Link: <https://api.companieshouse.gov.uk/company/09920845>; rel="registry"
Content-Type: text/html

The data one can get by following that link, is the following
(though for some reason the machine readable version of the public
information is currently protected by a api token)

$ curl -u token https://api.companieshouse.gov.uk/company/09920845
{
  "registered_office_address": {
    "locality": "London",
    "address_line_1": "2, Harlequin Court",
    "address_line_2": "6 Thomas More Street",
    "country": "United Kingdom",
    "postal_code": "E1W 1AR"
  },
  "undeliverable_registered_office_address": false,
  "has_insolvency_history": false,
  "company_number": "09920845",
  "jurisdiction": "england-wales",
  "company_status": "active",
  "has_charges": false,
  "type": "ltd",
  "company_name": "CO-OPERATING SYSTEMS LTD.",
  "date_of_creation": "2015-12-17",
  "domain": ["co-operating.systems","www.co-operating.systems"], 
  "accounts": {
    "next_due": "2018-09-30",
    "accounting_reference_date": {
      "day": "31",
      "month": "12"
    },
    "last_accounts": {
      "period_start_on": "2015-12-17",
      "made_up_to": "2016-12-31",
      "period_end_on": "2016-12-31",
      "type": "dormant"
    },
...,
}

Notice the ”domain” attributes, which provides a link back, in
order to allow the web agent to verify that the json-ld record above
is indeed information about that web site, and not some other.

How does the agent know https://api.companieshouse.gov.uk is
an official web site? Well the same game is played once more
creating a chain of trust up to a Web of Nations linking to
the browser users trust anchor. For a US citizen that could
be gov.us 

I summaries this in 2 pages here:

Technically this is pretty simple. Most of the standards to 
do this exist. Some ontologies would need to be developed and
agreed upon.

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2020 14:51:59 -0600

On Thu, Feb 13, 2020 at 09:33:47PM +0100, Henry Story wrote:
> > Yes.  But would any alternative look that different to the current
> > DNS?  I am very skeptical.
> 

DNS is not just for resolving names to IP addresses and such!

DNS is very much also about registries and registrars, and that is where
the rubber (protocol) meets the road (international law).

In fact, purpose, authority, and delegation of authority are the
essential aspects of DNS, not the protocol, not how it's used, not even
the data model.

You could replace the UDP port 53 protocol with a RESTful HTTP JSON API
running of any version of HTTP (including 3), including accessible RDATA
representations (i.e., not binary).  You could even replace all the
RRtypes and RDATA and have only domainnames in common with today's DNS.
That's all a matter of software and schema mapping.  But the one thing
that cannot be anywhere near as easy to replace is the business and
legal ends of it: authority, delegation, registries.  That and
domainnames (because they have bled into the UI/UX).

> What is needed is rich information that ties these ”publication
> machines” to machine readable official information about those
> entities.  This info exists: states put that together to gather taxes,
> provide services, base legal enforcement on it, … 

DNS already has this by way of the registrars, which already have this.

> by using a ”registry” Link relation in an http header.

Whether such metadata should be public or not is a policy matter for
each registry and associated governance framework (i.e., in the
registry's legal jurisdiction(s)).  The IETF should not mandate
publication of that data because publication is a policy matter, and the
IETF has no leverage to impose such a mandate anyways.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Thu, 13 Feb 2020 22:21:05 +0100

> On 13 Feb 2020, at 21:51, Nico Williams <[email-masked]> wrote:
> 

I have seen no DNS registrar publishing anywhere near the rich type
of information currently being published by companyhouse
https://www.gov.uk/government/organisations/companies-house 

That is unlikely to happen either as DNS registrars are not in 
the business of describing legal entities, and they would not 
want to be liable for that type of information anyway. 

On the other hand it is the role of national company registrars,
such as companyhouse.gov.uk to provide that.

It depends on what one considers a registrar.

> domainnames (because they have bled into the UI/UX).

It’s a lot easier for state registrars to publish their data
in extensible human and machine readable formats such as JSON-LD
on HTTPS servers that in DNS. So that’s where it is happening
and that’s where I expect it to continue happening.

> DNS already has this by way of the registrars, which already have this.

Those are just special type of registrars. If you extend your
view of registrars, then you will see that what is
needed is to tie web sites (via DNS or HTTP headers or X509
fields) to those that are ultimately responsible for the rich
data that is needed, namely state based company or institution 
registrars.

> IETF has no leverage to impose such a mandate anyways.

The IETF like the W3C takes on the role of building spaces for
different groups to come to a consensus on some topic of relevance.
Improving security on the internet and the web is relevant to both.
I guess that the W3C is better equipped to help governments come
to consensus with web browsers on ontologies. Nevertheless there
would certainly be a role also at the IETF level too. In any case
being aware of this possibility could help direct future work here.

Henry Story
Twitter: bblfish

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2020 15:39:54 -0600

> https://www.gov.uk/government/organisations/companies-house 

They have the information.  Whether or not to publish it is a policy
decision for the _registries_ and the sovereigns who have jurisdiction
over them.

> want to be liable for that type of information anyway. 

They could require, at registration time, permission to publish, though
they almost certainly wouldn't.  They could reserve the right to publish
it, or share it with researchers -- this most probably do.

Yes.

What's your proposal though?  To have us force them to publish this
data?  To replace DNS so we can force publication of this data?
Something else?  I'm confused.

> and that’s where I expect it to continue happening.

Meh.  Either way.

> data that is needed, namely state based company or institution 

Who needs that?  The public?  Maybe.  The public needs trust, and that
could be transitive via the registries.  I don't think the public is
going to be able to review this metadata anymore than they can review
PKIX certificate and issuer metadata.  And having this metadata gets us
no closer to solving the WebPKI problems.

I'll make an assertion we can debate: it will be easier to earn user
trust if there's a proper rooted issuer chain mirroring the DNS (i.e.,
DNSSEC), but even then we'll need better regulation of registries by
nation states, and of registrars by registries and nation states.

> being aware of this possibility could help direct future work here.

We don't quite have the political reach to solve the legal problems.  We
can advise nation states.  We can attempt to create a replacement for
the DNS and once again create monopolistic registries that nation states
can then choose to regulate.  We probably cannot do much better than
that.

Nico
--

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 13 Feb 2020 17:02:16 -0500

All important electrical communication identifier systems invariably end 
up at the point of nation state regulation. Consider what is occurring 
now with telephone CallerID which went through a full cycle of 
regulation to deregulation to re-regulation.  There are several 
compelling bases.  On one side, nation states have sovereign 
jurisdiction over all communication within their geospatial boundaries 
and assert it for a swath of national security and law enforcement 
reasons.  On the other, the providers seek indemnification (antitrust 
and tort) and the end users an expectation of trust and consumer 
protection.  Consider it a recognition of relevance.

The DARPA DNS itself went through a cycle of strong government 
regulation to deregulation to Ira Magaziner's scheme for healthcare 
governance (a/k/a ICANN) and now likely to re-regulation or irrelevance.

-t

---

From: Henry Story <[email-masked]>
Date: Thu, 13 Feb 2020 23:12:54 +0100

> On 13 Feb 2020, at 22:39, Nico Williams <[email-masked]> wrote:
> 

Let’s say the company registrars have the information for sure: 
they use it to collect taxes. DNS registrars may or may not be
able to get it, but it’s not as useful to them, they can’t 
use it to get taxes. 
In every country there are government appointed company
registrars that have been doing the job for at least a century.
It is just a question of tying them into the system. That’s 
what linked data is about.

> it, or share it with researchers -- this most probably do.

See point above about the reason for governments to collect
this information and keep it. It’s very important to the
functioning of the state.

> Something else?  I'm confused.

State registrars are already starting to publish this data. I
gave you an example earlier in the thread about CompanyHouse
publishing it in json-ld.

They also have it available in html
https://beta.companieshouse.gov.uk/company/09920845

And you can query it with SPARQL
http://business.data.gov.uk/companies/app/explore/sparql.html

So there is no need to force them to do anything.

What is needed is to get a few of these national registrars to
agree on an ontology, so as to make it valuable for browsers
to get that information and display it in an elegant and
attractive fashion when needed, and for there to be
a way for that to be findable, either from the web site
or through DNS or both or more.

> no closer to solving the WebPKI problems.

That’s a User Interface issue.
I think it is quite clear that amazing user interfaces can
be built inside browsers.
That these have not been build around X509 is partly to do
with the poverty of the information available in those 
certificates, the static nature of them, the difficulty on
agreeing on OID standards to extend them, etc...

> nation states, and of registrars by registries and nation states.

If you include company house they are already regulated, and they
are already publishing. They need to standardize somewhat so
that browsers can more easily consume the information, but that’s
it.

> can then choose to regulate.  We probably cannot do much better than

Or we can do a duck-rabbit trick and see that what we need is right
there emerging in front of our eyes. :-)

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2020 16:20:15 -0600

On Thu, Feb 13, 2020 at 05:02:16PM -0500, Tony Rutkowski wrote:
> All important electrical communication identifier systems invariably end up
> at the point of nation state regulation. Consider what is occurring now with
> telephone CallerID which went through a full cycle of regulation to
> deregulation to re-regulation.  There are several compelling bases.  On one
> side, nation states have sovereign jurisdiction over all communication
> within their geospatial boundaries and assert it for a swath of national
> security and law enforcement reasons.  On the other, the providers seek
> indemnification (antitrust and tort) and the end users an expectation of
> trust and consumer protection.  Consider it a recognition of relevance.
> 
> The DARPA DNS itself went through a cycle of strong government regulation to
> deregulation to Ira Magaziner's scheme for healthcare governance (a/k/a
> ICANN) and now likely to re-regulation or irrelevance.

I am in full agreement.

It is fair to predict that anything new that might replace WebPKI or DNS
will have to deal with regulation of registries eventually, and should
be designed with it in mind.

I'm just quite skeptical that the DNS could be replaced.  The protocol,
perhaps, some of the details, sure, but domainnames?  the registries?
nah.  Anything new will have to be in-addition-to DNS for a long time,
or bolted-onto DNS (e.g., DANE).

Back to Henry S.'s call for more public metadata...  More metadata
doesn't help the user.  E.g., when I need some less-well-known app from
an app store, I often find apparent dups by different vendors, and it's
hard to tell which one is legitimate if any, and the vendor names
(metadata) often don't help in the least because they are obscure enough
that the user can't really do anything with them -- the user is entirely
at the mercy of the curators, and the curators are obviously not doing a
good enough job.  Requiring more public metadata may not help at all,
not without lots more regulation and off-line authentication of said
metadata, with attendant problems.

PS: The telephone system has the great misfortune of being stuck with
    SS7; the DNS is ahead on security.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 13 Feb 2020 17:30:31 -0500

It is interesting that no one is addressing Bob Kahn's evolving models.  
Bob, after all, approved, paid for, and nurtured DARPA's DNS and BIND 
namespace/platforms. (The BIND part proved serendipitous but ultimately 
critical because some Berkeley grad students needed a funded project.)

In the 1990s, he created the DOI namespace and infrastructure to 
identity and resolve all network based objects with IPR significance.  
He achieved a measure of success by obtaining both government support 
and transferring authority to a nominally global non-profit foundation 
(the International DOI Foundation) while maintaining some continuing 
control of the BIND equivalent. It has been quite successful, and even 
RFCs now have DOIs.

Shortly afterwards, he rolled out Handles as a superstructure for all 
network identifiers.  Success for that namespace and platform proved 
more difficult.  Ultimately he used a combination of intergovernmental 
nexus (ITU-T X.1255) plus treaty conference resolutions - combined with 
a slightly more independent global non-profit foundation based in Geneva 
(the DONA Foundation).  The success has proven more elusive, even as 
some nations have considered it as an alternative/backup for DNS, and in 
theory solves the meta-identifier problem that will get more vexing as 
object namespaces proliferate.

Views?

--tony

---

From: Henry Story <[email-masked]>
Date: Fri, 14 Feb 2020 09:18:52 +0100

> On 13 Feb 2020, at 23:20, Nico Williams <[email-masked]> wrote:
> 

Indeed a lot has been built on these, and one can build a lot more.

> metadata, with attendant problems.

Metadata just as data by itself is not the answer, of course. It all
depends on who is making the claim. If someone in a bar tells you
to take some medicine, it has a different value than if your
doctor tells you exactly the same thing in his office, even if both
use exactly the same words. 

So I am not making a call for "more public metadata” as if it were a question of quantity. What is important is for official enforceable 
data to be standardized so as to be useable by browsers and the OS to
help inform the user about what web site they are visiting for example,
or who is responsible for writing an app running on their device.

If an App store is to be thought of as a service that verifies application
then the only added data that legitimately the Store needs to assert is that they verified App ”TicTacToe” (to take an arbitrary example), that came from 
company <https://tictacktoe.example/> registered at <https://regitry.ca.us/co/TickTackToeCorp>.  

In terms of BAN logic of "saying that” [1] we need to distinguish who says what. Whether later you sign that statement or refer to a statement
someone else made is not logically that much of a difference.

AppStore says { <ttt> a VerifiedApp;
                      :verified <apps/ticktacktoe/>;
                      :source <https://tictacktoe.example/app/ttt>;
                      :builtBy <https://regitry.ca.us/co/TickTackToCorp> }
     
We think of { … } as quotes.
Of course if you download the info from AppStore’s web site then you won’t find AppStore says { … } just as when one speaks to someone one does not start every sentence by saying ”I say …”. That is something inferable from the pragmatic context, and verifiable on the web through TLS authentication 
for example. 

Still you may wonder: how do I know I am on the AppStore? 

Well it works for Apple and Android because their marketing power
is good enough that they can teach everyone in the world to remember
their URL (or indeed build it into their OS). 

But most other companies have to rely on trust because the links to real government registrars with legal clout is not there. If it were there it
could provide completely new security for Apps as I describe in this short
post applying Modal Logic used in Epistemology to User Interfaces.

Henry

[1] https://en.wikipedia.org/wiki/Burrows%E2%80%93Abadi%E2%80%93Needham_logic
https://www.sciencedirect.com/science/article/pii/S1571066107000746

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 14:49:38 +0100

> replacement may well require significantly more willpower to establish.

And, the regulators were not paying attention, and they are now.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 14 Feb 2020 09:51:32 -0500

That old DNS+DARPA internet universe has become vastly more complex with 
all kinds of "end point objects."

In the rapidly emerging 5G world of virtualised networks and alternative 
protocols, we are entering a new universe of alternative transport and 
network protocols and end point addresses.  It creates potentially a new 
world of competitive resolver platforms.  The likely winners will be 
those who know how to find the end points, run the scripts to create the 
virtual network to get to them, and provide user friendly, AI assisted 
interfaces like the Googles and Amazons of the world are already doing, 
as well as larger data centre operators.  DNS clearly will become ever 
more irrelevant.  Antitrust and national security factors will dominate.

Bob Kahn knows that well - hence DONA and Handles.  However, that 
presumes that there is some level of global support for that structure - 
which requires enormous administrative overhead and seems dubious at 
best.  The brave new world of 5G resolvers will be fascinating to watch 
- and established in venues like 3GPP and GSMA.

--tony r

---

From: Watson Ladd <[email-masked]>
Date: Fri, 14 Feb 2020 07:33:14 -0800

> object namespaces proliferate.

I'd prefer to focus on real world experience and the lessons learned, and
solving tractable problems that are serious.

In this world plenty of economic transactions take place with DNS names as
the only identifier. Plenty of people are known by monikers that have
nothing to do with any government: Muhammed Ali, Prince, Kirk Douglass,
Liberace, etc. The state doesn't determine these: remember "Say my name!"?

For all the supposed essentially of tying DNS names and cert issuance to
the real world, the WebPKI has focused on domain control and been widely
accepted. OV and DV certs have completely failed to deliver, with the
browser UI becoming depreciated due to serious issues with assuming
globally unique names and consequent security. OCSP didn't work because CAs
can't meet the uptime requirements. Shortlived certs can't work because
they would clog CT logs, and X509 is too hairy for what it is used for now.

Where is the running code for all these wonderful ideas? Where is the
demonstration that they will actually add value?

Sincerely,
Watson Ladd

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 20:31:54 +0100

Watson Ladd <[email-masked]> wrote:
    > In this world plenty of economic transactions take place with DNS names
    > as the only identifier. Plenty of people are known by monikers that
    > have nothing to do with any government: Muhammed Ali, Prince, Kirk
    > Douglass, Liberace, etc. The state doesn't determine these: remember
    > "Say my name!"?

Agreed, and those are all, btw, local names.

Those people convince the world to accept them as their name, to enter it
into our personal trusted store.  That we all happen to believe we are each
referring to the same person when say "Prince" just means that they are
effective. (But, an aunt has a dog named "Prince", and I know who is
referring to when she says _Prince_.  It's Mimi's Prince, not AMI's Prince)

So, they don't, in general, register them with some authority who them
imposes it on us.  DNS names are registered with an authority.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Feb 2020 14:44:53 -0500

Sorry for the driveby. Due to current circumstances it is difficult for me
to read. So I could only take in the first dozen or so posts.

The origin of PKIX is to be found in Kohnfelder's Msc thesis at MIT. It
describes CAs, CRLs and the directory. It is essentially X.509v1. The big
weakness in that work is that the set of constraints it is designed to
address no longer exist. Today network connectivity is
essentially ubiquitous, back then it was rare.

PKI is a combination of three principle elements

1) Structure
2) Ceremony
3) Syntax

Naming is a consequence of structure. In X.509, trust flows down from the
root node of the directory. PKIX then subverts this entirely by grafting on
a completely separate naming structure via SANs. So the X.509 naming
infrastructure is essentially inconsequential.

The big difference between DNSSEC and PKIX is that in DNSSEC the naming
system and the structure of trust are the same. Which is one of the reasons
DNSSEC doesn't really meet modern trust needs.

SPKI is not quite so dead as people imagine. Brian LaMacchia applied many
of the concepts in the Strong Naming infrastructure in .NET. But the
approach is ultimately solipsistic.

The approach I tried to take in Shen in the 90s and have revisited with the
Mesh is to make every individual the apex of their own trust hierarchy. My
original hope was we could do something of the sort with PKIX. But X.509 is
simply too complex for most organizations to manage let alone individuals.

DNSSEC cannot meet my security needs because it insists all trust flows
from one point. If I am designing an embedded system, I want to be able to
specify the roots of trust.

Ceremony is a topic Carl Ellison introduced. If you want to understand the
security of the system, you have to understand more than just the protocol
and the math. If you want to understand a PGP key signing, you need to
understand it as ceremony.

IETF has ignored ceremony for too long under the motto 'we don't do UI'.
Well you have to do ceremony to do security. So its about time we changed
that. I am currently working (or trying to) on a paper on onboarding
ceremonies which I hope will show the point.

Syntax is the least important part of PKI but it is a part of the puzzle.
Why oh why do people think canonicalization is relevant? If you want to be
able to verify a signature, you have to keep the original bits that were
signed. End of story.

That said, XML is better than ASN.1 DER because it isn't completely stupid.
JSON is better as a data serialization than XML because it is designed to
be a data serialization not a document markup. Requiring elements be
presented in a particular order and schema validation are bogus.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Feb 2020 15:13:05 -0500

> referring to when she says _Prince_.  It's Mimi's Prince, not AMI's Prince)

Let's start thinking in a post anti-Trust IoT world in which the majors are
no longer trying to establish monopolies with their voice control systems
and we want to be able to give voice commands to any of the devices we own
from any of the voice input devices and we want them all to give the same
result.

That is the following commands should all have the exact same result:

"Alexa, shut off the lights in the basement"
"Siri, shut off the lights in the basement"
"Zen, shut off the lights in the basement"

This can only work if there is a common understanding of "in the basement".
Which means that all the systems are using the same catalog to interpret
'basement'. And this has to be a local name. I want the system to do the
right thing even if I have more than one house.

According to Noth, a name is a signifier that has no direct correspondence
to the signified, it is a purely conventional relationship mediated by some
agreed registrar. In the case of my basement, that registrar is obviously
going to have to be me or someone in my house. Certainly not ICANN.

DNS names attempt to be universal names. They aren't quite, because the
registration is only temporary. The names are leased, not owned.

There is a role for universal names in PKI but we go about it the wrong
way. Not wanting to mention blockchain, let us consider a Merkle Tree
authenticated sequence as in CT or a DARE Sequence.

The logical implementation of the RPKI is as an incrementally authenticated
sequence. Each IP address block assignment is enrolled in the sequence as
it is granted or transferred. The entry specifying the range(s) of IP
addresses it applies to and the signature key(s) to which they are bound.

This structure allows a single signature by the registry to verify the
entire RPKI. We can extract individual range assignments and the
corresponding Merkle proof chain or we can just synchronize the entire
database.

We can imagine constructing something of the sort for 'real names' with a
different binding. So 'Microsoft', the Microsoft Logo, the Microsoft
enterprise root key and the address of the .Microsoft DNS server might be
enrolled in such a sequence after going through a CABForum EV type process
plus some form of trademark verification.

Issuing .Microsoft in this way would naturally upset folk thinking that
TLDs should cost $750,000 because they want a nice yacht. But it could
easily be done for $1000 without the need for any renewal fees. Though
there would be a need for a dispute arbitration process etc. And we might
want to have a rule that name owners have to make a maintenance post every
so often so as to allow unused names to be recycled.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 14 Feb 2020 15:15:01 -0500

+1

On 2020-02-14 3:13 PM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Feb 14, 2020 at 2:32 PM Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Watson Ladd <[email-masked] <mailto:[email-masked]>>
>     wrote:
>         > In this world plenty of economic transactions take place
>     with DNS names
>         > as the only identifier. Plenty of people are known by
>     monikers that
>         > have nothing to do with any government: Muhammed Ali,
>     Prince, Kirk
>         > Douglass, Liberace, etc. The state doesn't determine these:
>     remember
>         > "Say my name!"?
>
> Let's start thinking in a post anti-Trust IoT world in which the 
> majors are no longer trying to establish monopolies with their voice 
> control systems and we want to be able to give voice commands to any 
> of the devices we own from any of the voice input devices and we want 
> them all to give the same result.
>
> This can only work if there is a common understanding of "in the 
> basement". Which means that all the systems are using the same catalog 
> to interpret 'basement'. And this has to be a local name. I want the 
> system to do the right thing even if I have more than one house.
>
> According to Noth, a name is a signifier that has no direct 
> correspondence to the signified, it is a purely conventional 
> relationship mediated by some agreed registrar. In the case of my 
> basement, that registrar is obviously going to have to be me or 
> someone in my house. Certainly not ICANN.
>
> DNS names attempt to be universal names. They aren't quite, because 
> the registration is only temporary. The names are leased, not owned.
>
> There is a role for universal names in PKI but we go about it the 
> wrong way. Not wanting to mention blockchain, let us consider a Merkle 
> Tree authenticated sequence as in CT or a DARE Sequence.
>
> The logical implementation of the RPKI is as an incrementally 
> authenticated sequence. Each IP address block assignment is enrolled 
> in the sequence as it is granted or transferred. The entry specifying 
> the range(s) of IP addresses it applies to and the signature key(s) to 
> which they are bound.
>
> We can imagine constructing something of the sort for 'real names' 
> with a different binding. So 'Microsoft', the Microsoft Logo, the 
> Microsoft enterprise root key and the address of the .Microsoft DNS 
> server might be enrolled in such a sequence after going through a 
> CABForum EV type process plus some form of trademark verification.
>
> Issuing .Microsoft in this way would naturally upset folk thinking 
> that TLDs should cost $750,000 because they want a nice yacht. But it 
> could easily be done for $1000 without the need for any renewal fees. 
> Though there would be a need for a dispute arbitration process etc. 
> And we might want to have a rule that name owners have to make a 
> maintenance post every so often so as to allow unused names to be 
> recycled.
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2020 14:36:34 -0600

On Fri, Feb 14, 2020 at 09:51:32AM -0500, Tony Rutkowski wrote:
> That old DNS+DARPA internet universe has become vastly more complex with all
> kinds of "end point objects."
> 
> world of competitive resolver platforms.  The likely winners will be those
> who know how to find the end points, run the scripts to create the virtual
> network to get to them, and provide user friendly, AI assisted interfaces
> like the Googles and Amazons of the world are already doing, as well as
> larger data centre operators.  DNS clearly will become ever more
> irrelevant.  Antitrust and national security factors will dominate.

Maybe.  I think it's the opposite.  We could easily see the use of
DNS(SEC) to bootstrap trust in environments where domainnames are not
very relevant -- domainnames can still be brands, and DNSSEC can be the
PKI that authenticates them.

Put another way: if any new thing will have legal obstacles, why bother?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2020 14:40:10 -0600

> demonstration that they will actually add value?

+1.

I'll posit two plausible approaches that don't suck: a) DNS registrars
functioning as PKIX issuers for (effectively) name-constrained
certificates, b) DANE binding issuers for certificates.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Fri, 14 Feb 2020 21:42:44 +0100

> On 14 Feb 2020, at 20:44, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Syntax is the least important part of PKI but it is a part of the puzzle. Why oh why do people think canonicalization is relevant? If you want to be able to verify a signature, you have to keep the original bits that were signed. End of story.

The way to make syntax unimportant is to work on the semantic level. That is
in a way what the Semantic Web does by starting from naming, and leaving syntax decisions open, allowing multiple ones: RDF/XML, JSON-LD, Turtle, NTriples, Binary RDF, CSV …

But once one moves away from syntax it then becomes very important
to canonicalize data, exactly so as to move away from being tied to syntax.
A Canoncicalisation of a data then allows one even to discard the original
bytes, if one does not wish to keep to versions of everything around.

See 
  https://json-ld.github.io/normalization/spec/
and it’s use for signatures
  https://w3c-dvcg.github.io/ld-signatures/

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2020 15:12:57 -0600

On Fri, Feb 14, 2020 at 02:44:53PM -0500, Phillip Hallam-Baker wrote:
> Mesh is to make every individual the apex of their own trust hierarchy. [...]

Yes, but that way lies TOFU.  That's fine for many things, but not all
things.  You could argue the inverse is also true, that rooted naming
and trust are fine for many things, but not all things -- I would agree
with that.

>                                                                         My

I'm curious about this.  Are you referring here to the use of ASN.1/DER
and the ASN.1 types in RFC5280, or are you referring to semantics, or
something else?

> specify the roots of trust.

Thanks for expanding on that.  I can agree with mesh-like trust and
naming for this, but for many things we'll still need a rooted trust
system like DNSSEC.

+1

> able to verify a signature, you have to keep the original bits that were

See below.

> presented in a particular order and schema validation are bogus.

BER/DER/CER, and all TLV ERs are idiotic, yes.  JSON is OK.  The rest of
what you say in this paragraph, not so much.

BTW, Heimdal's ASN.1 compiler lets you name types whose encodings have
to be saved in a `_save` structure field by the decoder.  It's very
nice, and, for PKIX, essential.  General purpose JSON decoders however
generally don't decode to a schema the way decoders compiled from an
ASN.1 module do, so it's harder to add a "save this part as encoded for
later signature verification" feature -- not impossible, but not widely
available either.  So one has to resort to base64-encoding the JSON
texts to be signed/encrypted and then sending those as strings in other
(possibly JSON) documents (e.g., JWT).  (In Kerberos we do the moral
equivalent and wrap things to be signed/encrypted in OCTET STRINGs.)

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Feb 2020 17:26:36 -0500

On Fri, Feb 14, 2020 at 3:42 PM Henry Story <[email-masked]> wrote:

> > Syntax is the least important part of PKI but it is a part of the
> puzzle. Why oh why do people think canonicalization is relevant? If you
> want to be able to verify a signature, you have to keep the original bits
> that were signed. End of story.
>
> in a way what the Semantic Web does by starting from naming, and leaving
> syntax decisions open, allowing multiple ones: RDF/XML, JSON-LD, Turtle,
> NTriples, Binary RDF, CSV …
>

No, it does not become important to canonicalize. We have been trying and
failing at that for 30 years and there is no reason to believe things will
change in the future.

Digital signatures authenticate the presentation of the data. If you are
using Schnorr signatures, the usual form of the signature isn't even
deterministic. So sign the same octet sequence twice and you get two
different signatures.

I have never seen a situation. where discarding the signed octet sequence
makes the slightest sense. I am currently using a machine with 64GB of RAM
and 2TB of disk and that isn't uncommon. A RaPi4 comes with up to 4GB these
days. Signed assertions (SAML, PKIX, Mesh) are rarely more than a few KB.

The immense complexity of canonicalization means that it should be avoided
wherever possible. Instead we have people swooping in demanding that it be
required. Well time to put a lid on that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Feb 2020 17:47:31 -0500

> and trust are fine for many things, but not all things -- I would agree

No, it doesn't have to be that way. Alice is her own trust apex but she can
decide to delegate.

Alice might decide to delegate trust to the ICANN DNSSEC root and Mozilla
CA root store. So she has pretty much the standard trust config we have
today. The only difference being she can change it.

Bob can pick and choose his trust providers. So he decides to only trust
certs issued by the ten major CAs and ignore all the others.

Carol might decide to outsource picking trust roots to Symantec, like she
does her AV needs.

Doug might pick the Mozilla CA root store minus some CAs he considers
dodgy. And instead of trusting the ICANN DNSSEC root, only trust four or
five domains.

Being the apex of trust means you have control, including the ability to
delegate that control as you choose.

> and the ASN.1 types in RFC5280, or are you referring to semantics, or

The idea was people would be able to edit their own trust stores in a
meaningful way. But never worked out how to make it tractable.

> naming for this, but for many things we'll still need a rooted trust

Depends on the purpose. If I am running a SCADA system for a chemical
plant, it would make every sense to decouple from ICANN and instead bind to
the dozen or so domains of interest directly.

Or I can use ICANN as an introducer or ICANN plus additional credentialing.

I would like to see two persistent naming schemes established. One for
essentially randomized names and the other for curated names. I don't want
my names to expire, that is the key thing.

> equivalent and wrap things to be signed/encrypted in OCTET STRINGs.)

Yup, it is currently painful and right now I am Base64 encoding everything
when using JSON. But I also have a binary encoding option, JSON-B. That is
simply JSON with the option of encoding a binary blob as a base64 string or
as a length-data production.

I have not fully worked out how to integrate this into a schema generator
but I think the key part is to decide on an envelope format and use it
consistently.

Right now, I have schema fields like:

Struct DareEnvelope EnvelopedProfileMesh

What I would prefer is

Struct DareEnvelope<ProfileMesh> EnvelopedProfileMesh

So the serializer/deserializer can generate the necessary static methods
for encoding/decoding the field.

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2020 18:02:18 -0600

> No, it doesn't have to be that way. Alice is her own trust apex but she can

Yes, for the case where Alice is enroling a new device in her world.
But for Alice being introduced to Bob...  In person, they can engage in
a ceremony, but otherwise we're looking at TOFU or having an introducer.

> > > My original hope was we could do something of the sort with PKIX.
> > > But X.509 is simply too complex for most organizations to manage
> > > let alone individuals.
> >

But is this a PKIX issue, an API issue, or something else?  In meshy
world you'd have to locally associate an issuer with each peer you know.

> Or I can use ICANN as an introducer or ICANN plus additional credentialing.

Right.  No need for DNS here.  Unless you're using a browser or
something (though you can have your own PKI for that).

The thing is that the browser is a fantastic client.  It's hard to give
it up, and as long as you don't...

> my names to expire, that is the key thing.

Curated names -> DNS (and/or app stores, search engines, etc.).  My
point earlier in this thread is that we'll always need that one, so
don't throw out that baby with the bathwater.

> as a length-data production.

Right.  Thanks for expanding on that.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Sat, 15 Feb 2020 09:36:43 +0100

On 14 Feb 2020, at 23:26, P. Hallam-Baker <[email-masked]> wrote:

>>> Syntax is the least important part of PKI but it is a part of
>>> the puzzle. Why oh why do people think canonicalization is relevant? If
>>> you want to be able to verify a signature, you have to keep the original
>>> bits that were signed. End of story.
>>
>> The way to make syntax unimportant is to work on the semantic level. 
>> That is in a way what the Semantic Web does by starting from naming, 
>> and leaving syntax decisions open, allowing multiple ones: 
>> RDF/XML, JSON-LD, Turtle, NTriples, Binary RDF, CSV …
>>
>> But once one moves away from syntax it then becomes very important to
>> canonicalize data, exactly so as to move away from being tied to syntax.
>> A Canoncicalisation of a data then allows one even to discard the 
>> original bytes, if one does not wish to keep to versions of 
>> everything around.
>>

It is true that I am not sure what the computational properties 
of the RDF Normalisation algorithm are. Manu Sporny will have more 
to say on that. 

> deterministic. So sign the same octet sequence twice and you get two

(I wonder if we are talking at cross purposes here.) 
If one has a working Normalisation algorithm, one can reconstruct 
the exact byte sequence from the data at any time. Hence there is no
need to keep the signed byte-sequence around. Clearly one should
not discard the signature itself, but add that to the database.

> and 2TB of disk and that isn't uncommon. A RaPi4 comes with up to 4GB 
> these days. Signed assertions (SAML, PKIX, Mesh) are rarely more than 
> a few KB.

Ah I see. You have a hash of a document which you then sign, and that is
no more than a few KB, which one should keep. I am fine with that. 
And you are right that that is probably all you need if you are signing
a document. But what if you are signing data?

The problem there is that in order to verify the hash, one needs to be able 
to reconstruct from the data the same byte-sequence. The data would usually be a lot larger than a few KB. 

Furthermore the data may be stored in any number of formats which I listed
above including binary formats. So you’d rather like to avoid having to
recompute a signature every time someone requests a different format.
If you tie a signature to a data format, then you can never get rid of the
format in which the data was initially signed. On the other hand if it
is not tied to the format, it can be calculated once, and then served up
whatever the requested format.

> wherever possible. Instead we have people swooping in demanding that it
> be required. Well time to put a lid on that.

So it makes sense for documents that are tied to a byte sequence to not
go through canonicalization. But for data it is a different problem.

Henry