Subject: Re: [saag] post-X509 cryptographic identities

From: Tony Rutkowski <[email-masked]>
Date: Tue, 11 Feb 2020 07:26:50 -0500

> > 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.
And who is going to assume the antitrust liabilities?  See, e.g., 
https://www.vox.com/recode/2020/2/6/21125026/big-tech-congress-antitrust-investigation-amazon-apple-google-facebook

X.509 has the advantage of originating as a government SDNS standard 
that became and intergovernmental one.  The antitrust culpability in 
this arena recently is a magnet for antitrust enforcement already.

--tony r

---

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

> https://www.vox.com/recode/2020/2/6/21125026/big-tech-congress-antitrust-investigation-amazon-apple-google-facebook

Well, that's a reason why re-creating There Shall be Only One PKI is a bad
idea.  RFC2692/RFC2693 already gave us a lot of alternative views.

Typical PKI implementations just makes it really hard for end users to
actually manage their trust anchors, because it pretends that the local trust
anchors were a pronouncement from god.

https://www.rfc-editor.org/rfc/rfc2693.html#section-2.4

2.4 Rethinking Global Names

   The assumption that the job of a certificate was to bind a name to a
   key made sense when it was first published.  In the 1970's, people
   operated in relatively small communities.  Relationships formed face
   to face.  Once you knew who someone was, you often knew enough to
   decide how to behave with that person.  As a result, people have
   reduced this requirement to the simply stated: "know who you're
   dealing with".

   Names, in turn, are what we humans use as identifiers of persons.  We
   learn this practice as infants.  In the family environment names work
   as identifiers, even today.  What we learn as infants is especially
   difficult to re-learn later in life.  Therefore, it is natural for
   people to translate the need to know who the keyholder is into a need
   to know the keyholder's name.

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

---

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

On Tue, Feb 11, 2020 at 03:31:59PM +0100, Michael Richardson wrote:
> Well, that's a reason why re-creating There Shall be Only One PKI is a
> bad idea.  RFC2692/RFC2693 already gave us a lot of alternative views.

It seems like a miracle that we have DNS at all.

And when you talk about x.509 naming, it really does seem to mean that
you're referring to dNSName SANs, so, DNS.

It seems unlikely to me that we could replace a global system we have
(DNS) with a non-global system.  That's a lot of value to leave behind!

> actually manage their trust anchors, because it pretends that the
> local trust anchors were a pronouncement from god.

Yes.  But that's not a fault of PKIX, or DNS, or anything other than the
fact that not having name constraints widely implemented in 1993 meant
they were effectively not implemented at all, and _that_ turned PKIX
into WebPKI.

Whereas DNS of necessity has name constraints fully built-in, and had
them from day 0.

So we have one system (WebPKI) bolted onto another (DNS), and we have
this impedance problem of the first not having the necessary element of
name constraints.  Name constraints can't be retrofitted into WebPKI now
that we have a mess of root CAs overlapping each others namespaces -- a
mess that cannot be cleaned up.

It's not ccTLDs or any kind of naming hierarchy we need anyways, but
resolving names to registration authorities -- that is essential!  DNS
gives us that, while WebPKI does not.

So I take the opposite view: a single global namespace IS fine.  It may
well be the single biggest key to the Internet's success.  WebPKI is
busted.  ISTM incorrect to conclude that because WebPKI is busted, and
that because the "I" in it wanted it to be a single global namespace,
that then it must be that a global namespace is bad.

>    to know the keyholder's name.

Locality in naming usage does not imply that a global namespace is bad.

Nico
--

---

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

> (DNS) with a non-global system.  That's a lot of value to leave behind!

SPKI permitted things like:
     DNS's www.cryptonector.com
or:  Nico's second-floor bathroom

and in particular it would permit:
or:  Russia's nameservice cryptnector.com        (national DNS root)
or:  employer.example.com's www.amazon.com       (forced corporate proxy)

    > Yes.  But that's not a fault of PKIX, or DNS, or anything other than

I agree, it's not inheirently the result of PKIX, but then we got meaningless
junk like CPS which makes it really hard for people (even lawyers) to have
their own.

    > that then it must be that a global namespace is bad.

In the SPKI days I wanted no DNSSEC root.
I wanted 158 national roots with k-of-n cross-signatures.
Countries would recognize (in the political/legal, UN sense) each other by
signing each other's ccTLD trust anchors.

Everyone in Canada would be obligated by law to use the "CA" trust anchors,
and to get to "amazon.DE", I'd have to go "CA-cross->DE->amazon".

Which definitely lets my government spoof me, which they already say they
have the right to do under certain circumstances, but it doesn't let them
spoof you.   Would we have to kill ".com", etc. and all the ICANN zoo?  
Maybe. It's not a big loss to me, but others would object.  And we don't need
to do it overnight.

It also means that my government is assuming liability if I get spoofed,
which also seems reasonable. 

    > Locality in naming usage does not imply that a global namespace is bad.

So, we see this in things like maps where national authorities inform
google/bing/etc. what the official name of a conquored place is, in
contradiction to what name the locals, (and possibly, the world) use.
I don't know which name is global and which name is local, but I can do all
of that with relative (SPKI) names.

-- 
]               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: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2020 14:33:07 -0600

> or:  Nico's second-floor bathroom

And for the first it's no different than PKIX.  And it'd better have
name constraints or it's worth diddly squat.

(It's hard to come up with a generic syntax for the second name form
that is amenable to name constraints, of course.  Name constraints in
that case have to be relying-party-side configuration.  That's OK for
simple name forms that are not meant to scale to Internet scale.)

> or:  employer.example.com's www.amazon.com       (forced corporate proxy)

Sure, but PKIX let's you have this too: it's just an alternate issuer
(root).

What would SPKI have given us, really?

> junk like CPS which makes it really hard for people (even lawyers) to have

CPS is useless lipstick on a pig (WebPKI), so don't use it.

> I wanted 158 national roots with k-of-n cross-signatures.

Cross-signing roots ~= a root anyways.

Every country could run its own roots with mostly or entirely the same
contents as all the others.  From a relying party's point of view,
there's a single root, and _that_ is what matters.

(A relying party might need to change root trust anchors when traveling
if they are forced to or want to change roots.)

I.e., DNS and DNSSEC are no as strongly single-rooted as they are made
out to be, we can continue to have interop with multiple mostly-the-same
national roots, and still avoid the mess of WebPKI because for every RP
there will always only be one root.  This can only introp well provided
that the alternate roots keep the same public keys for all the TLDs,
naturally, but it's feasible and workable and radically different from
WebPKI.

> and to get to "amazon.DE", I'd have to go "CA-cross->DE->amazon".

Sure.  We could still have this, but people sure like their .com
domains.  Without legal requirements to use ccTLDs, they won't be.

> Maybe. It's not a big loss to me, but others would object.  And we don't need

Yes.  But if governments won't force you to do this, I don't mind.  That
is, we can have a single-root PKI (or a cross-signed root if you
prefer) in all cases.  And we can have mandatory or optional use of
ccTLDs.  It's all good.

> which also seems reasonable. 

Sovereigns always immunize themselves.  You will not be able to sue your
government over attacks on you resulting from your country's ccTLD
private keys being compromised.  At best some may be able to avoid some
losses when their counter-party is also operating in the same country,
but only entities other than their government will be taking the losses.

> of that with relative (SPKI) names.

Names relative to global names are still global names.

Names relative to name-less issuers are truly local names: local to RPs
that trust those issuers.  But RPs cannot trust very many such issuers,
so PKI for local names is not very interesting.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Feb 2020 13:57:33 +0100

Nico Williams <[email-masked]> wrote:
    >> and in particular it would permit: or: Russia's nameservice
    >> cryptnector.com (national DNS root) or: employer.example.com's
    >> www.amazon.com (forced corporate proxy)

    > What would SPKI have given us, really?

No, PKIX does not have an alternate issuer.
That's outside of the PKIX.  It's another instance of PKIX.
What SPKI gives is the alternate roots are explainable and codifiable within
the system, rather than making it an externality.  

    >> In the SPKI days I wanted no DNSSEC root.  I wanted 158 national roots
    >> with k-of-n cross-signatures.

    > there's a single root, and _that_ is what matters.

This would almost be the same thing, except for the liability and soveignty issue.

    > if they are forced to or want to change roots.)

Yes, possibly.  It's definitely an open question, and there is a tussle there.

    >> Which definitely lets my government spoof me, which they already say
    >> they have the right to do under certain circumstances, but it doesn't
    >> let them spoof you.  Would we have to kill ".com", etc. and all the
    >> ICANN zoo?  Maybe. It's not a big loss to me, but others would object.
    >> And we don't need to do it overnight.

    > Yes.  But if governments won't force you to do this, I don't mind.
    > That is, we can have a single-root PKI (or a cross-signed root if you

The carrot could revolve around liability.

    >> It also means that my government is assuming liability if I get
    >> spoofed, which also seems reasonable.

    > Sovereigns always immunize themselves.  You will not be able to sue
    > your government over attacks on you resulting from your country's ccTLD

"I relied upon the trust anchor my government provided me, so, your Honour, I
am not guilty"

---

From: Nico Williams <[email-masked]>
Date: Sat, 15 Feb 2020 12:48:28 -0600

> That's outside of the PKIX.  It's another instance of PKIX.

Sounds like a matter definitions.

> the system, rather than making it an externality.  

Out of curiosity, why couldn't that have been done with PKIX?

> This would almost be the same thing, except for the liability and

Indeed.

> Yes, possibly.  It's definitely an open question, and there is a tussle there.

Sure.  At worst the traveler's origin country and destination might have
conflicting requirements and even great firewalls.

> "I relied upon the trust anchor my government provided me, so, your Honour, I

I was referring to the government's civil liability.  For an
individual's liability, especially criminal liability, no doubt this is
(would have to be) a defense.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Feb 2020 12:22:38 +0100

Nico Williams <[email-masked]> wrote:
    >> Nico Williams <[email-masked]> wrote: > Sure, but PKIX let's
    >> you have this too: it's just an alternate issuer > (root).
    >> 
    >> No, PKIX does not have an alternate issuer.  That's outside of the
    >> PKIX.  It's another instance of PKIX.

    > Sounds like a matter definitions.

It's not.  It's critically important.
PKIX has no way to name another trust anchor/namespace from within your
current trust anchor/namespace.

X509 was architected on the "There shall be only one" principal, and
all the patching we've had to do (from path name constraints to CT) is to
deal the fact that this is not how things worked out.
[In a strict hierarchal, top-down, PKI, I think a subservient CA would only
ever be able to extend the DN, never change it. That is, constrained would
have been implied]

    >> What SPKI gives is the alternate roots are explainable and codifiable
    >> within the system, rather than making it an externality.

    > Out of curiosity, why couldn't that have been done with PKIX?

Of course, you can write any ASN.1 you want, and you can encode SPKI concepts
in ASN.1, but it wasn't done.

    >> > (A relying party might need to change root trust anchors when
    >> traveling > if they are forced to or want to change roots.)
    >> 

    > Sure.  At worst the traveler's origin country and destination might
    > have conflicting requirements and even great firewalls.

So, just like with Netflix: do I get the access of the geo-location of my
credit card, or the geolocation of my device?  Today, in Berlin, I can watch
Big Bang Theory and Dr.Who on netflix (both licensed in Canada to Bell),
while I can't watch Elementary [on Prime].

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Feb 2020 09:54:13 -0600

> ever be able to extend the DN, never change it. That is, constrained would

I'm skeptical.  Extensions could have been added for dealing with this.

PKIX is extensible.  Protocols that use PKIX (e.g., TLS) are generally
extensible as well.

> Of course, you can write any ASN.1 you want, and you can encode SPKI
> concepts in ASN.1, but it wasn't done.

Aha!  :)

_Sometimes_ shoehorning a new thing into an existing system is a decent
recipe for success.

>     >> > traveling if they are forced to or want to change roots.)
>     >> 

Exactly.

I don't relish a balkanized Internet, but I accept that national
sovereignty implies that has to be a possibility, and, in some cases
and places, a current reality.

I don't think DNS/DNSSEC/PKIX preclude that.  No, indeed, they do not.

But this thread has elucidated -for me- something important: it's
important to be able to name things in smaller-than-universal
namespaces, and it's important to be able to identify those namespaces
and their trust anchors.  DNS/DNSSEC almost by definition cannot provide
a solution for smaller-than-universal namespaces, but I don't see why
PKIX with appropriate extensions couldn't.  After all, WebPKI violates
PKIX's definitions, so other things too could reuse parts of PKIX and
change its semantics somewhat too.  Reusing and adapting PKIX is a
matter of taste, code reuse (or code non-reuse, even), and such
considerations.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Feb 2020 11:05:22 -0500

On Mon, Feb 17, 2020 at 09:54:13AM -0600, Nico Williams wrote:

> DNS/DNSSEC almost by definition cannot provide a solution for
> smaller-than-universal namespaces,

That's may not be exactly the case (haven't read most of the thread, so
perhaps missed something important posted before).

Your last hop (or stub) resolver can be configured with whatever
trust-anchors you want for suitable private branches of the namespace.

So if ".local" is your thing, then feel free to set a local trust-anchor
for ".local" and publish TLSA, ... there.

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Feb 2020 10:52:41 -0600

> for ".local" and publish TLSA, ... there.

That's why I put in that weasel word, "almost", in the above.  I had
that sort of thing in mind, among others, but I didn't want to
immediately jump into them, though I'm glad you brought it up!

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Feb 2020 20:48:45 +0000

> trust-anchors you want for suitable private branches of the namespace.

I had something vaguely SKPI-flavoured in mind when I wrote
https://mailarchive.ietf.org/arch/msg/saag/jlVNCTQxyhLRjBLYLl9V0Wk_UKI

And also something related to the notion of "petnames" for capabilities
as a way to tame Zooko's triangle
http://www.erights.org/elib/capability/pnml.html

Interesting things happen when you combine SPKI-style path names with
petnames as local roots, especially for IOT and MANET applications. When I
create a secure association with a device, I give it a petname which is my
personal human-readable stand-in for its public key. And it I want to
share some devices with a friend, they don't have to import a petname per
device, they can just link to my root.

And you can graft a global namespace into such a system by having the
vendor pre-populate petnames for well-known registries. These
pre-populated names become equivalent to the DNS root.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lough Foyle to Carlingford Lough: West or southwest 6 to gale 8, occasionally
5 later. Mainly very rough or high in north, otherwise moderate or rough.
Squally thundery showers. Good, occasionally moderate.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Feb 2020 11:07:57 +0100

Tony Finch <[email-masked]> wrote:
    >> > DNS/DNSSEC almost by definition cannot provide a solution for >
    >> That's may not be exactly the case (haven't read most of the thread,
    >> so perhaps missed something important posted before).
    >> 

    > http://www.erights.org/elib/capability/pnml.html

I am very enthusiastic about PetNames.

    > petnames as local roots, especially for IOT and MANET
    > applications. When I create a secure association with a device, I give
    > it a petname which is my personal human-readable stand-in for its
    > public key. And it I want to share some devices with a friend, they
    > don't have to import a petname per device, they can just link to my
    > root.

I am completely onboard here.