[Cryptography] Revocation is always an authorization concern redux

Phillip Hallam-Baker phill at hallambaker.com
Tue Aug 31 12:15:36 EDT 2021


Reducing ideas to code requires greater clarity. There is a very important
point here that was botched in PKIX that I have been forced to clarify.

In PKIX we have a certificate Sig ({Serial, Alice, Public}, CA) and it is
the certificate status that is being reported

Sig ([Serial_1, Serial_2, Serial_3, ... Serial_n), CA)

Which seems like the right idea but it is not because what actually matters
is what uses are or are not allowed for the key.

So in the Mesh, a device has a device authentication key. A Mesh connection
assertion looks like a certificate except that it is for a device belonging
to Alice and it is signed by Alice's admin device:

Connection = Sig ({Alice, Public_Dev}, Admin_Alice, active)

The value of active can be true or false. If true, the connection is
authorized unless the authorization is revoked, otherwise the connection
requires explicit authorization.

An authorization assertion is recorded in the acces catalog. Instead of the
serial number (which doesn't exist) the subject of the assertion is the
device key Public_Dev.

Access = {Public_Dev, true}

This could be signed but I haven't decided whether that is a good idea yet.


So what does this buy us?

1) Connections that are default active require a permanent record of their
status to be kept.

2) Connections that are default deny only need to be tracked for as long as
they are active. We can deauthorize simply by removing them from the
catalog.

The reason I need the default active connection is that I need a mechanism
to be able to bootstrap the access catalog. I might well eliminate the
permanent record requirement by setting an expiry on the active default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210831/284631bc/attachment.htm>


More information about the cryptography mailing list