[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Cryptography] Revocation is always an authorization concern redux

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.

The cryptography mailing list
cryptography AT metzdowd.com