Allow attestation of fulcio claims

[lukehinds]

Establish how we can provide a method for verifiers to attest fulcio grants actually come from a real OpenID Provider.

Currently we store the signers email address into the signing certificates, but there is no way for a verify / attest that email was provided by an OpenID Provider and not entered by fuclio with no grant being performed.

I am not sure if it possible to do this with OAUTH at present, so wanted to open this up for discussion to see if anyone knows of a mechanism.

[dlorenc]

I think this is basically the role of the transparency log and monitors. I'm not sure we can do much else but I'd love to hear ideas.

[lukehinds]

Yup, the transparency logs tell us that fulcio entered X email into a cert at specific time, but we still have no guarantees that the user granted fulcio access to the scope (if a third entity wants to later attest the claimed grant happened).

I don't understand OAUTH to well yet, but I am thinking alongside the email and pub key that goes into the signing request, we also include a token of some sort that an entity can later attest with the OpenID Provider as being supplied (signed?) by the provider.

I release this might not be possible as oauth is not really designed to provide later guarantees

@bobcallaway any ideas on this?

[bobcallaway]

The only thing I can come up with is to store the entire signed ID token as an X509 extension in the signing certificate. This would allow an auditor to independently verify that the OIDC provider signed the token, but has some potential security and privacy implications that we would need to think through.

[lukehinds]

The only thing I can come up with is to store the entire signed ID token as an X509 extension in the signing certificate. This would allow an auditor to independently verify that the OIDC provider signed the token, but has some potential security and privacy implications that we would need to think through.

can the identity be extracted from the token?

[letmaik]

Token signing certs are typically rotated daily and are self-signed, so in addition to the token itself you would also have to keep an attested record of the JWKS document that was fetched from the OpenID provider and used during ID token signature validation: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration (follow jwks_uri). And probably the TLS certs as well. If you had all that, then monitors could check that the OpenID authentication was done properly.

EDIT: A simpler alternative would be if monitors kept refreshing the JWKS document from all OpenID providers themselves. The ID token would still have to be stored in fulcio, which comes with the already mentioned security/privacy issues.

[dlorenc]

EDIT: A simpler alternative would be if monitors kept refreshing the JWKS document from all OpenID providers themselves. The ID token would still have to be stored in fulcio, which comes with the already mentioned security/privacy issues.

Any thoughts here? This is the big one I'm worried about doing. Email addresses can change - but most OIDC providers also include some kind of immutable identifier that won't change across email address changes. This could be used to track people.

I'd love to do this for transparency, but don't have a solution to the privacy issue.

[dlorenc]

cc @raesene as discussed in Slack.

We should figure out how to get the OIDC provider name into the cert somewhere asap. There's gotta be some OID that makes sense to use :)

[letmaik]

EDIT: A simpler alternative would be if monitors kept refreshing the JWKS document from all OpenID providers themselves. The ID token would still have to be stored in fulcio, which comes with the already mentioned security/privacy issues.

Any thoughts here? This is the big one I'm worried about doing. Email addresses can change - but most OIDC providers also include some kind of immutable identifier that won't change across email address changes. This could be used to track people.

I'd love to do this for transparency, but don't have a solution to the privacy issue.

I looked a bit more in detail at this. What we're talking about is the sub (subject) claim of the ID token.

For Google, this is a globally unique account identifier. For Microsoft, it is a per-oauth-app unique account identifier, so you can't correlate the identifier across oauth apps but you can still correlate emails if they use fulcio with both the old and new email address from the same account. So this is definitely bad privacy-wise. Since sub is required in ID tokens per spec I guess it would require a spec change to allow omission or making it a dummy value.

For machine-type providers like SPIFFE I don't see an issue with storing the ID token.

When storing a token there has to be replay protection though, otherwise someone else can re-submit the token while within the validity period and get their own cert. Normally you would just use the nonce claim for that, but SPIFFE doesn't support that. As an alternative you could derive a nonce by hashing the token, which is probably fine since the iat (issued at) and exp (expires at) claims make it unique. I guess monitors would have to check that Fulcio's replay protection is working correctly by checking that a token only appears once in the Fulcio CT log.

For reference, this is how a Microsoft ID token requested with openid email scopes looks like (the payload of it):

{
    "ver": "2.0",
    "iss": "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0",
    "sub": "AAAAAAAAAAAAAAAAAAAAAO6-2j76CpWwpM8W3RHRcWw",
    "aud": "b218d3ca-f11a-4f2e-a15c-996c64f6a9ac",
    "exp": 1627725555,
    "iat": 1627638855,
    "nbf": 1627638855,
    "email": "...@...",
    "tid": "9188040d-6c67-4c5b-b112-36a304b66dad",
    "nonce": "252f10c83610ebca1a059c0bae8255",
    "aio": "DXDfrbxgVMvB9Ee0CmX7n..."
}

aio is "an internal claim used by Azure AD to record data for token reuse". I guess it's harmless.

And here a Google ID token:

{
    "iss": "https://accounts.google.com",
    "azp": "586477283406-u7divme85hbm35mr9fktir7vhk0hmmlf.apps.googleusercontent.com",
    "aud": "586477283406-u7divme85hbm35mr9fktir7vhk0hmmlf.apps.googleusercontent.com",
    "sub": "12345...",
    "email": "...@...",
    "email_verified": true,
    "at_hash": "p5IEpd345Zjx2CkTN1eFAQ",
    "nonce": "eba2f95be4d1d7bcfa89d7248a",
    "iat": 1627642188,
    "exp": 1627645788
}

[znewman01]

I investigated this a little bit in the context of Demonstrating Proof of Possession at the Application Layer (DPoP), a draft extension to OAuth.

tl;dr: DPoPs could enable this, but not in their current form.

[haydentherapper]

Going to close this as we are not going to take any action on this and it's been open for awhile. DPOP is promising, but isn't ready for use.