Re: [saag] post-X509 cryptographic identities

[Nico Williams <[e-mail]>]

On Fri, Feb 14, 2020 at 05:47:31PM -0500, Phillip Hallam-Baker wrote:
> On Fri, Feb 14, 2020 at 4:13 PM Nico Williams <[e-mail]> wrote:
> > On Fri, Feb 14, 2020 at 02:44:53PM -0500, Phillip Hallam-Baker wrote:
> > > 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.
> > [...]
> >
> > 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.
> 
> No, it doesn't have to be that way. Alice is her own trust apex but she can
> decide to delegate.

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.
> >
> > 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?
> 
> 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.

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.

> > > 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.
> >
> > 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.
> 
> 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.

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...

> 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.

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.

> > 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.)
> >
> 
> 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.

Right.  Thanks for expanding on that.

Nico
--