You might worry about applications of OpenPubkey where the OpenID ID Token is broadly exposed to the public inside the PK Token. For example, in Docker’s container signing usecase, the PK Tokens are exposed in the container registry. If the ID Token is broadly exposed to the public, there is a risk that the ID Token could be replayed and used for unauthorized access to other services.
This is why we have a slightly different PK Token for applications where the PK Token is made broadly available to the public. For those applications, OpenPubkey strips the IdP’s signature from the ID Token before including it the PK token. The IdP’s signature is replaced with an Guillou-Quisquater (GQ) non-interactive proof-of-knowledge for an RSA signature (which, for short, is also known as a “GQ signature”). Now, the ID Token cannot be replayed against other services, because the IdP’s signature is removed. An ID Token without a signature is useless.
So, in applications where the PK Token must be broadly exposed to the public, the PK Token is a JSON Web Signature (JWS) which consists of:
☑️ The ID Token excluding the IdP’s signature
☑️ A GQ signature on the ID Token
☑️ The user’s public key
☑️ The random noise used to compute the hash of the user’s public key
☑️ A signature, under the user’s public key, of all the information in the PK token
The QC signature allows the client to prove that the ID Token was validly signed by the IdP, without revealing the IdP’s signature. The OpenPubkey client generates the QC signature to cryptographically prove that the client knows the IdP’s signature on the ID Token, while still keeping the IdP’s signature secret. GQ signatures only work with RSA, but this is fine because every OpenID Connect provider is required to support RSA.
Because GC signatures are larger and slower than regular signatures, we recommend using them only for usecases where the PK Token must be made broadly available to the public. BastionZero’s infrastructure access usecase does not use GQ signatures because it does not require the PK Token to be made public. Instead, the user only exposes their PK Token to the target (e.g. server, container, cluster, database) that they want to access; this is the same way an ID Token is usually exposed with OpenID Connect.
Finally, we note that most IdPs that use OpenID Connect allow you to scope the fields in the ID Tokens. For instance, Google’s IdP is by default scoped to only include userinfo-email claims: name, email address and icon. However, some IdPs may include additional claims in the ID Token that the application may wish to keep private. For this reason, when you build an application with OpenPubkey, we recommend that you carefully consider which OpenID Connect providers you will choose to integrate, and what they expose in the ID Token.