Re: [saag] post-X509 cryptographic identities

[Phillip Hallam-Baker <[e-mail]>]

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.

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.



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




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

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.

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

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.