[Cryptography] Revocation is an Authorization issue

[Phillip Hallam-Baker]

I have said it before but not quite in these terms which were inspired by
Elon Musk's statements on a factory tour he did. If you are interested,
here is the first part:

Starbase Tour with Elon Musk [PART 1] - YouTube
<https://www.youtube.com/watch?v=t705r8ICkRw>

One of the things he said is delete before you try to optimize. And that is
exactly what I think we need to do for certificate revocation. Over the
years I have spent many hours optimizing cert revocation as a part of the
authentication process. I now reject that position and argue revocation is
always an authorization issue.

The reason that the confusion arises is that the WebPKI uniquely conflates
authentication and authorization. Recall that the original purpose of the
WebPKI was authentication, encryption was limited to 40(!) bits. The WebPKI
was designed to make shopping online as safe as shopping in a traditional
store. The point of a VeriSign Class 3 cert was to tell the user that the
merchant was accountable to law enforcement in a particular jurisdiction.

The WebPKI is somewhat peculiar then in that the source of authorization
data is the same as the authentication data and is not a direct party. For
efficiency, it is convenient to bind both to a static signed token. If I
was to design the WebPKI from scratch, I would simply use short lived
certificates of 24 hours and provide an online service to provide trusted
time reinforced by a Merkle-Tree, Blockchainey sort of thing.


My present concern is the client side. Or rather how do we authenticate and
authorize user devices. Client/Server is about which side initiates a
conversation and is really not a very useful nomenclature. The difficulty
of 'client side' PKI is not that we have to speak first, it is that
authenticating people turns out to be much harder than authenticating
corporations. That is because corporations are by definition created by the
process of government accreditation, people are not. People do not come
with a life long identifier.

In the WebPKI, the authorization of the service is implicit in the user's
decision to visit it. Even more so in the current diminished incarnation
where all we are trying to do is provide slightly more robust
confidentiality than that afforded by an on the fly ephemeral exchange.
That isn't the case in a user/client PKI because the purpose of the
authentication step is to decide whether or not to bind the request to a
user account. It is the user account which provides authorization.

One of the ideological shibboleths of Internet architecture is the
dedication to the peer-to-peer model. Which was a fine argument in the
1980s when the machine on my desktop that the mainframe mafia sneered at
was often vastly more powerful than their POS. It does not make sense when
we are asking if we should allow Bob's toaster to talk to Alice's coffee
pot. The principle of least privilege says that conversation is
unnecessary. If the machines are to connect at all, that conversation
should be mediated.

Should Alice's cell phone talk to Bob's directly? That is a more complex
call but the answer I come up with again is 'absolutely not'. If we are to
provide minimal privacy guarantees, the presence protocol needs to be
mediated as a three corner model or anyone can track Alice through the
presence protocol. And if we want to give really good guarantees, it needs
to be mediated as a four corner model.


So when we look at the protocol flows, every user device interaction is
going to be mediated through a service[1] which knows which devices are
currently valid and which have been revoked. Every inter-domain connection
is mediated through the same service.

Revocation is an authorization issue - is this device still connected to
the account? There is no need to treat the issue any differently to other
authorization issues like why is the coffee pot trying to talk to someone
else's toaster.

PHB

[1] In the Mesh all communications are mediated through a service but
people are free to run their own service if they choose. In either case,
the use of threshold cryptography minimizes the degree to which the service
must be trusted by the user. The service is not trusted for integrity and
is not trusted as a single point of failure for confidentiality.

As with any service, a Mesh service is trusted for service provision. But
this is also mitigated through accountability controls and by allowing the
user exit. Users are free to switch their Mesh service at any time with no
switching cost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210810/a7050ebc/attachment.htm>