<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">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:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://www.youtube.com/watch?v=t705r8ICkRw">Starbase Tour with Elon Musk [PART 1] - YouTube</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</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">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</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 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">PHB</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div></div></div></div>