[Acme] Entity authenticator URI

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

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:[e-mail]: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.