Subject: [dns-privacy] Entity authenticator URI

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 7 Jan 2015 10:42:38 -0500

Right now I am working on three separate projects: end-to-end secure email
(EndyMail *), private DNS (DPRIV) and PKI cert lifecycle management (DPRIV).

A building block that would be tremendously useful in all three areas is a
uri that combines an account or service identifier and authenticator for
that entity. This would be a generalization of the 'strong email address'
concept I introduced last year:

draft-hallambaker-prismproof-key-01

First, what the URI would be, next how it solves real world problems in the
three application areas.

The simplest URI would simply be either a base64URI or Base32 encoding of a
kerberos ticket, a public key or a digest of a public key. In many
applications we do not need to identify the service provider or account
holder but we do need to determine that they are the same party we
contacted earlier.

So using the digest key identifier scheme, our URI might be:

TBS::ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA

[Note that the algorithm is encoded into the key identifier digest already
so an external algorithm ID isn't needed. But we can add to taste.]

This scheme is obviously and pathetically unworkable for RSA2408 keys but
256 bit ECC keys would be practical.

A digest alone isn't very useful unless there is a way to resolve it to the
key. But this isn't much of a problem as in many cases we can pass the key
in band in a protocol.

We could have an argument as to whether we need to have tickets, keys and
key digests, but they all have uses. Keys and digests are really useful for
establishing long term secrets. Tickets are much better for short term
interactions with a single host.

We can add in an account identifier:

TBS:[email-masked]:ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA

We can also add in a service identifier using the SRV prefix convention:

TBS:_acme._tcp.example.com:
ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA

The important thing here is that we now have some identifiers that can be
used to establish the foundation of trust relationships that don't depend
on external parties to resolve. And that is really useful when working at
the level of DPRIV or ACME.

Lets say you decide to use a confidential DNS service provided by Comodo
for public (i.e. anonymous) use.

For DPRIV, the initial contact with the DNS service would be via legacy DNS
and TLS using the Web PKI (hopefully requiring an EV cert). That contact
can then establish a number of host/protocol combinations, each of which is
represented by a service URI.

Since this is a DNS client protocol, the service identifier might have an
IP address rather than a DNS name but any other service would be a DNS name.

The choice of using tickets or public keys as the authentication basis can
be left to deployment choice. If I am binding a $965 iPhone to a DNS
service for its service life then I probably want a public key. If I am
binding a lightbulb to my home network hub then I probably want a ticket as
the thing probably can't usefully rekey (i.e. it could do the math but
would leak its key in doing so).

Connecting to a private service there would be two entity URIs, one for the
service, the other for the user. So when I bind my machine to the corporate
Comodo network I can get access to the internal DNS service that will
provide resolution for internal services.

The way I would use this in Acme is that I would have the (Web) host
generate a public/private keypair that would be used to identify that
machine for cert issue and for no other purpose. I now have an identifier
that I can put in a CA database or the config file of an LRA.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Jan 2015 16:49:50 +0100

On Wed, Jan 07, 2015 at 10:42:38AM -0500,
 Phillip Hallam-Baker <[email-masked]> wrote 
 a message of 184 lines which said:

> kerberos ticket, a public key or a digest of a public key.

I do not see immediately the gain from RFC 6698?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 7 Jan 2015 12:44:01 -0500

> I do not see immediately the gain from RFC 6698?

Using the DNS to authenticate a connection to a DNS client-resolver
connection is a circular dependency. I have no idea how anyone would use
DANE to solve the problem of authenticating a service to a client and it is
obviously the wrong mechanism for authenticating a client to a service.

The TBS scheme provides a direct trust model. These are identifiers that
would be used in the presentation layer of the stack and lower. DANE and
the WebPKI support indirect trust binding an application layer identifier
(aka DNS label) to a key.

So the only link I can see to DANE is that you might perform a DANE lookup
and then use a TBS URI to represent the information you obtained in the
lower layers of the stack.

On Wed, Jan 7, 2015 at 12:12 PM, Tony Arcieri <[email-masked]> wrote:

> On Wed, Jan 7, 2015 at 7:42 AM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>
> What serialization format is this?
>
> Why not URI-safe Base64, as in e.g.:
>
> https://tools.ietf.org/html/rfc6920
>

It is the 'for the sake of example' serialization scheme. The precise
scheme does not matter a great deal. I was in the Apple store getting my
iPhone fixed with 4 minutes of battery remaining and I cut and pasted from
my most recent draft.

The design constraint motivating the use of Base32 over Base64uri was to
permit the key identifier to be prepended to an email address and they are
not case sensitive. That does not apply here of course. But it might be
desirable to permit easy interchange between the two. The other argument
for BASE32 is that this is an identifier that might have to be read aloud
over a telephone or voice connection.

I am aware of RFC6920 of course, I am an author. This is a distinct scheme
in that the ni scheme is saying 'here is a resource identified by this
digest' and in this scheme we are identifying a key that can be used to
authenticate an account holder.

I have no objection to using the same format for the serialization but it
is actually a different URI scheme because the semantics are very different.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 7 Jan 2015 09:12:05 -0800

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 7 Jan 2015 12:49:27 -0800

> over a telephone or voice connection.

Okay, well if you'd like to use Base32, perhaps consider z-base-32 instead?
It's more succinct and less "shouty" than the original all-capital version:

http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt

-- 
Tony Arcieri