BastionZero (acquired by Cloudflare)

Our brand new IETF internet draft is making the rounds, so I’m excited to share a new blog explaining why Richard Barnes and I are introduced the PIKA: Proof of Issuer Key Authority. PIKAs allow us to cache and redistribute an OpenID Provider (OP)’s public keys. PIKAs are useful for #OpenPubkey, #oidc and many other places where you need a JWT. Today, if you want to verify any object issued by an OP, you need to request the OP public keys from an HTTPS endpoint. The OP has to be online and the HTTPS endpoint has to be available.  This has performance and privacy issues, and makes it hard to verify objects that were signed by the OP In the past. PIKAs introduce a new reality where the process of obtaining the OP's public key can be done *offline* rather than being restricted to *online* only. The PIKA is a signed object that uses the Web PKI to prove that an OP’s public key really was issued by that OP.  Specifically, in a PIKA ☑ the payload contains the OP’s public key,  ☑ the header contains a certificate proving that the key signing the PIKA chains up to the root of the WebPKI.  ☑ the signature is under the public key in the certificate You can cache and redistribute the PIKA, which 💡 reduces load on the OP and 💡 improves privacy (because third parties can verify objects without interacting with the OP), and 💡 supports applications that require caching or historical information about OP keys, which is important for software #supplychainsecurity. Nerd out with me in the blog linked in the comments below!

We added GitLab (gitlab-ci) support to #OpenPubkey but how we did it is more interesting. Adding Gitlab-ci support to OpenPubkey required the use of a very cool #cryptography primitive invented in the 1980s called a Guillou-Quisquater (GQ) signatures. This cryptographic compatibility trick of using GQ signatures enables us to support for identity providers we never thought possible. I wrote a blog post explaining what GQ signatures are, why so valuable from a compatibility standpoint, and how we are using them to generalize OpenPubkey to any OpenID Provider. In fact, GQ signatures mean that in the future OpenPubkey might even be able to support non-#OIDC protocols like SAML! Thanks to Jonny Stoten John Merfeld and Joel Kamp who wrote the GQ signature library in OpenPubkey.

Really excited to share a new IETF internet draft that Richard Barnes and I submitted to the OAuth working group this week. We introduce PIKA: Proof of Issue Key Authority, to solve a problem relevant to #openpubkey, #oidc and JWTs in general. What's a PIKA and why do I care? (Beside the fact that it's always fun to return to my IETF roots?) Well, OpenPubkey uses PK Tokens to allow an OpenID Provider (OP) to bind user identities to user-held public keys. This essentially allows the OP to act like a certificate authority, without any changes to today's OIDC. PK Tokens are signed by the OP's signing keys. But, OP's rotate their signing keys over time (e.g. biweekly). What happens if we need to use a PK Token *after* the OP rotates signing key? This is where the PIKA comes in. In this draft, we introduce the PIKA and show how it can be combined with a timestamping authority to allow PK Tokens to be used even after the OP rotates it signing key. The PIKA is a secure object that allows you to cache the OP's key, and verify using the OP's key even if the OP is offline. And that's why I got interested in this work. But our solution is much more generic and widely applicable than to just OpenPubkey. PIKAs allow the verification of JWTs, ID Tokens and other OIDC Tokens without querying the OP directly. You can use them to reduce the load on a OP, or to build applications that require caching or historical information about OP keys. Historical information about signing key is a particularly important in #softwaresupplychain usecases. We're still digesting all the different ways that PIKAs can be used. Draft is linked below, feel free to get in touch if you have any feedback!