<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Forgive me if I was being slow. But it just occurred to me that revocation is not an authentication process, it is always an authorization process. And this is a critical distinction.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I came across this in the design of the Mesh presentation binding. The purpose of which is to enable both parties in a session to (1) decrypt the data sent by the other and (2) verify that it is authentic.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One particular little twiddle here is that I want to be able to use the presentation layer over UDP and so I would like connection packets to fit inside the Ethernet MTA of 1200 bytes.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Every Mesh device has a separate identity. So there are always two sets of credentials that are required.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) The public credential of the device</div><div class="gmail_default" style="font-size:small">2) The public credential of the profile under which it is acting. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We might have revocation of either credential. But here was the epiphany:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We don't need to check that a credential is valid to use it to decrypt/authenticate the message. We only need to check it is valid as part of the authorization. And this is especially important when we are dealing with revoked credentials as even a revoked credential is fine for purposes of returning a reason for rejecting the authorization. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">User case: Alice loses her phone, discovers the loss and disables the device. Mallet picks the phone up and attempts to use it to connect to Alice's Mesh. The device connects, is told that it is compromised and deletes all the data on the device.</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">The other thing I realized is that I only need to use the device level credentials to negotiate a session. Get the secure session established between the devices and only then exchange fat certificate chains etc and only if needed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So does my device credential work? Lets see, using X448 and 256 bit fingerprints:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><table border="0" cellpadding="0" cellspacing="0" width="357" style="border-collapse:collapse;width:268pt">
<colgroup><col width="165" style="width:124pt">
<col width="64" span="3" style="width:48pt">
</colgroup><tbody><tr height="19" style="height:14.5pt">
<td height="19" width="165" style="height:14.5pt;width:124pt">Profile Fingerprint</td>
<td align="right" width="64" style="width:48pt">2</td>
<td align="right" width="64" style="width:48pt">32</td>
<td align="right" width="64" style="width:48pt">64</td>
</tr>
<tr height="19" style="height:14.5pt">
<td height="19" style="height:14.5pt">Device Authentication Key</td>
<td align="right">1</td>
<td align="right">56</td>
<td align="right">56</td>
</tr>
<tr height="19" style="height:14.5pt">
<td height="19" style="height:14.5pt">Algorithm Id</td>
<td align="right">2</td>
<td align="right">8</td>
<td align="right">16</td>
</tr>
<tr height="19" style="height:14.5pt">
<td height="19" style="height:14.5pt">Signature</td>
<td align="right">1</td>
<td align="right">56</td>
<td align="right">56</td>
</tr>
<tr height="19" style="height:14.5pt">
<td height="19" style="height:14.5pt">Packaging</td>
<td align="right">6</td>
<td align="right">2</td>
<td align="right">12</td>
</tr>
<tr height="19" style="height:14.5pt">
<td height="19" style="height:14.5pt"></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr height="19" style="height:14.5pt">
<td height="19" style="height:14.5pt"></td>
<td></td>
<td></td>
<td align="right">204</td>
</tr></tbody></table></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thats looking pretty good. I should be able to keep the initial connection request down to 500 bytes leaving me 700 bytes for payload. It is critical that all the requests from the initiator fit into a single packet until the connection is established to keep it stateless. But the responder can send multiple packets back in response as the initiator can be stateful.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My original goal was to achieve the 'zero start' capability in TLS/1.3 but I am sorta meh on that now. I require the client credential to be sent in ciphertext for a start and I don't want to drop a non repudiable proof that the client tried to connect to a service, especially not enclair!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Another reason to be meh about zero start is that the host might well change between the first and second interactions. For example, MSP A tries to deliver a message to MSP B. A uses discovery to get the IP address of a service for MSP B. but that host is merely a switcher that tells A that they really want to go talk to this other host which is the one that is actually waiting to slurp that data.</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"><br></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"><br></div></div></div></div>