<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In PKIX we have a certificate Sig ({Serial, Alice, Public}, CA) and it is the certificate status that is being reported</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sig ([Serial_1, Serial_2, Serial_3, ... Serial_n), CA)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Connection = Sig ({Alice, Public_Dev}, Admin_Alice, active)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Access = {Public_Dev, true}</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This could be signed but I haven't decided whether that is a good idea yet.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what does this buy us?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Connections that are default active require a permanent record of their status to be kept.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div></div></div></div></div>