Federation Historical Keys

[David W Chadwick]

A superior entity publishes the keys of its subordinate entity in the Entity Statement that it signs for its subordinate. Therefore historical keys should be published by superior entities and not by the entities themselves. Section 7.6 says “Each Federation Entity MAY publish its previously used Federation Entity Keys at the historical keys endpoint”. This is wrong and it opens up the possibility of an attack. A fake entity statement can be published now, and the key can be published at the historical keys endpoint. No-one can tell this is fake because the superior is publishing a different key now for this entity.

[Giuseppe De Marco]

This is not wrong since each federation entity may publish its registry of the revoked or expired keys. Because it is the owner of those keys. To fake an entity statement the adversary should be in control of the private keys, whose public are attested within the trust chain, then the entity statement issued by its superior. No one could issue a fake entity statement, because the trust chain would be broken by the fake entity statement

[David W Chadwick]

If the trust chain exists and is unbroken then you don't need historical keys because all the live keys are in the trust chain. But if an entity in the chain updates its keys, then the trust chain must also change to include the new keys. Now we are left with an entity statement from the old trust chain that is signed by a key that no longer exists in the current trust chain. So you have to go to historical keys of the signer to find if it did exist. So a cheating intermediate entity can issue a fake entity statement for a subordinate entity (or itself) and put the signing key in its historical keys store. There is no way to know if the keys in the historical store are correct or not because its superior entity has not vouched for them. If you are saying that you do not need a superior entity to vouch for the keys of its subordinate entities, then why are you getting superiors to sign the keys of their subordinates in trust chains? Ans. Because you only trust the trust anchor, and there is an unbroken chain of trust in the keys of all the subordinates down to the leaf. But we do not have an unbroken chain of trust for historical keys because each entity publishes their own keys. The solution is for the superior to publishe the historical keys of its subordinates.

[Tom Jones]

The problem described by David has existed forever.

This spec, as well as any, needs to understand when an expired key is still valid for evaluating a signature. It seems that the federation spec is not the best place to clarify the correct evaluation. It is likely that the machine performing the evaluation is NOT a member of the federation.

The biggest challenge comes when a key is revoked which should not revoked any existing signature made by that key. Note that many sites have had certificates compromised and need to re-certificate their site for their own security issues.

It would be good for a full description to be made. What really bothers me is the idea that different standards might come to different conclusions.

y’all have been focusing on members of the federation. The person writing the verifier has many standards that they need to follow, many created by governments with the force of law behind them. I would guess that the architect of the verifier will be more interested in calculations dictated by law that ones in a federation standard that might be one of many that they need to address. I have built token translation systems from internal corporate policy to interface with other sites, many of them were in existence for years prior to getting tokens from me. There were 100,000 potential customers on my side. As you might imagine, my tokens being translations, were suited to my internal system, not to some spec the verifier might want. So the verifiers are constantly seeking new customers and needing to adapt to many external realities. Can you really expect them to do any more checking with details of this standard when they are operating under pressure to just get the site running? For example, consider the bar in one country getting a certificate from another country. Now this bar must satisfy their own regulations before they server restricted goods. How are they to determine if the presentation is valid? So Giuseppe’s statement is no help really. “The infrastructure is public, anybody can navigate the federation and evaluate the signature of the trust relationship between the participants.“ Note that he says can, not will or must. Even if you think about all the MUSTs in the spec, who will be checking? TO BE CLEAR - my suggestion was just that some clear description of validity of a signature should be made. Here is what is in the CA|B forum: –

• Signature Algorithm: The CA/B Forum specifies the acceptable signature algorithms and parameters for certificates, such as RSA, ECDSA, and SHA-256. These algorithms ensure the integrity and non-repudiation of the certificates.
• Certificate Revocation: The CA/B Forum requires CAs to maintain and publish revocation information for certificates, such as Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses. These mechanisms allow browsers and applications to check the status of a certificate and determine if it has been revoked by the CA for any reason.
• Certificate Transparency: The CA/B Forum supports the use of Certificate Transparency (CT), which is a system that logs and monitors the issuance of certificates by CAs. CT helps detect and prevent mis-issuance and fraud by providing public and auditable records of all certificates.
• Certificate Validation: The CA/B Forum defines the validation methods and levels for certificates, such as Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). These methods and levels indicate the degree of identity verification that the CA performed before issuing the certificate.

‌

[Giuseppe De Marco]

David, if an intermediate cheats the trust chain Will break, since it's superior wont include the int federation jwks. If the trust chain breaks, the validation fails.

Tom, openid federation Is build, at least, on top on rfc7518. Algs supported are defined there, impl may use any other alg if required, the specs doesn't want to mandate the infinite list of alg that might come in the future. For oidc compatibilità rs256 is cited. The historical registry contains the keys that are not used anymore, if expired or revoked. Having an historical trust chain, only the TA's historical keys are required to validate a long living signature. The registry Response Is signed, can be validated and stored as a long lived attestation as well. The registry makes the “transparency” we need. Then, do we have to take the same stuffs already defined by the cab forum in the federation specs or did I miss the suggestion between the lines that you kindly explained without my understanding? What’s the functional requirement? The non repudiation of an historical signature? In the current text It seems clear to me how this Is achieved but following your say consider me available in introducing the improvement you would like to read. Would you like to suggest the text/paragraph changes to improve the current specs? Sorry if i miss something, i really didn't take your suggestion, it’s me!

[Tom Jones]

ahh - the standard that most closely applies here is RFC 5280 - I doubt that you want to recreate that?

[Giuseppe De Marco]

Openid federation Is not an x.509 pki, then It wont bring texts from rfc 5280 or redefine its content. What would you like to have in federation that you have learned from rfc 5280 and you still didn't get in openid federation? In term of functional requirement I mean.

[Tom Jones]

i am not sure whether to consider this to be funny, or sad. Everyone hates PKI and is trying to recreate trust chains, and what to they all wind up with --- just another INCOMPATIBLE instance of PKI. So the people that want something different than PKI just recreate it over and over and over again. How many instances of PKI do we really need? In the EU each government will have their own version. Here is another one from Canada. Executive Summary - CIRA - Trust Registry.docx (idlab.org) PLEASE STOP THIS PROLIFERATION!

[Giuseppe De Marco]

Hey Tom, please. How your comment would be useful for federation? It seems quite distruptive and negative. Please dont do this, or differently, this Is not the right place for this kind of comment. Federation brings multiple keys, trust marks, metadata and metadata policy to satisfy requirements that x509 doesn't.

[Tom Jones]

RIght, the federation spec includes attributes that are not explicitly defined in X.509 V3. And the federation spec operates at the application level where the programers do not like to use ASN1. (Altho some are pushing COSE which seems about as difficult). What i would expect to see happen is that any trust chain evaluation will return the same result. There will be other standards, like the one i linked above that will create other trust chain evaluation criteria. I would expect that any trust chain evaluation would return the same true/false result. Can we at least agree on that? Otherwise we will have developers faced with different results depending on the order of execution.

[Giuseppe De Marco]

if different trust chains carries different stuffs, how they may give the same result? There are trust chain intended just to give cryptographic key attestations, federation trust chain does this and also the stuffs I just have listed to you … Federation give power when metadata exchange and verifiable attestations (trust marks) and metadata policies are needed, such as in the OIDC/OAuth 2.0 world and any other that needs these kind of stuffs

[Tom Jones]

Since I was one of the three people that created the original proposal i might have a better idea than you about the purpose here. Something seems to have gone off the rails in the meantime. The Federation does not exist alone, it must work with user agents that are deployed. It seems that you are assuming a browser communicating with a federation website as the only use case. If that is the case this std is only of limited interest and it certainly does not meet the needs for a multiplicity of user agents which is the way i see the ecosystem evolving.

[Giuseppe De Marco]

I dont know why you mentioned user agents using openid federation.

‌

[Tom Jones]

oops? I thought one valid subject (entity) was a user agent? If not what does this mean? “Trustmark: A URL that points to a mark/logo that the subject is allowed to display to a user of the Entity.“

[Giuseppe De Marco]

No, no worries. A federation entity Is an organizational entity, not a personal device. Federation doesn't replace TLS or the use of the https and x.509 for how we know and use it over the web

Federation is an application layer to establish trust at a different and higher level, where applicative interop Is made by exchanging metadata, policies and any other compliance proof. Such as the saml2 metadata, that are signed and distributed by a trusted third party. I’ll try to reach you in a private Channel to continue this chat

[Tom Jones]

If it’s true that the federation offers no element of actual trust to normal users, then there is no reason for any discussion. I have no use for it.

[Giuseppe De Marco]

@David if I got your issue in the right way: you’re suggesting to have another historical keys for the subordinates federation entity keys? This is a concrete proposal. At the same time, in my implementation, entities that will prevent any repudation from a party they have interacted with, they just have to save/store the historical trust chain related to them

[David W Chadwick]

@Guiseppe. Not quite. I am suggesting that only superior entities should hold the historical keys of their subordinates. After all, superior entities already hold the current keys of their subordinates - this is how the trust chain is formed. So when an entity notifies its superior about a new key pair, then the superior stores the old key in the historical keys entry. Of course, any entity that holds an existing trust chain, and stores it, does not need to access any historical keys because it can keep them in its own storage. But an entity that has never obtained any keys about another entity before, must get the keys from the trust anchor and work downwards. If it finds that the trust chain contains different keys to those which signed an entity configuration (or statement) that it has, then it needs to ask the superior for the historical keys of that entity, and not the entity itself.

[Giuseppe De Marco]

I understand perfectly your idea David, it represent a traditional approach I’m completely aware of.

The current approach we have in the Federation specs was designed to reduce the burden to the TA and to the Intermediates in the storage of the historical data.

The design principle is that every Federation Entity must be responsible of its historical keys, not Entity Statements (that are short live and may vary very often …).

The approach is designed in a way that an entity that must proof something must show the historical trust chain built at time of a specific issuance (id_token, request object …).

this approach make the federation more light and scalable in term of data storage.

An example: Me that have obtained an id_token from you. The id_token may contain the trust_chain related to you (issuer) in the form of a JWS header parameter, if not I save together with the id_token also the trust_chain related to you, containing the public keys used for the verification of the id_token.

A day in the future you change your keys without updating you federation historical keys, me can demonstrate that the id_token was issued by you just by validating the id_token and the historical trust chain, using the TA’s public keys (or the TA’s historical public keys).

I really want this approach, to remove the costs of the infrastructure, designed to use short-lived trust chain and statements. How many time you change your federation entity keys represents a cost just for you that must update your historical keys and notify these to your superiors. This doesn’t represent a cost to the superiors in terms of storage and responsibility.

[David W Chadwick]

The current approach we have in the Federation specs was designed to reduce the burden to the TA and to the Intermediates in the storage of the historical data.

And in so doing it introduces a security vulnerability.

[Michael Jones]

We discussed this on the 15-Dec-23 Federation editors' call. Giuseppe will describe the actual fanout from Intermediates to Subordinates in the Italian Federation.

[Giuseppe De Marco]

I don’t know how and why a security vulnerability might be introduced if:

• each participant who wish to retain proof of a signature, retain the used trust chain at the time of signature verification
• each trust chain can be validated using the (current or historical) trust anchor public keys

In other cases the trust chain is provided directly in the signed JWT, eg: id_token. This makes the signed JWT self-consistent for the signature verification that might be required in the future, since the participant doesn’t need to retain the trust chain related to the jwt issuer, because this trust chain is provided in the JWS protected headers.

the approach we currently have in federation actually scales. Giving the freedom to each participant to change their keys very often and whenever they want, the intermediates and TA doesn’t have to worry to store the descendants' keys. The participants that requires to proof an historical signature, even if the keys are changes over time, just have to retain the historical trust chain.

The trust to the TA is not questionable. For infrastructure that requires the non-repudiability of the signature and trust chains, the TA MUST expose the historical key endpoint. The historical trust chain demonstrates the trust established in the past and the metadata where the jwks are provided for the historical signature verification.

[Giuseppe De Marco]

Why I’m completely not in favor of a centralized approach:

The proposition that an authority, such as a Trust Anchor (TA) or an Intermediate, should store and retain all descendant keys is entirely impractical. It's a non-starter due to its inability to scale effectively. Implementing such a system would result in a massive infrastructure with high maintenance costs that would be unsustainable over time.

Consider a scenario where each participant changes their keys daily. The storage costs for the TA or Intermediate would quickly become unmanageable. Project this situation over a decade of operation, and you're looking at an unmanageable behemoth of a system.

[David W Chadwick]

the vulnerability is for entities that have not stored the old trust chain. They cannot validate it because it does not end in a TA. It ends with the superior entity that has published its own historical key. One solution is for an entity to sign its last key with its current key and store that in historical keys, then the trust chain can be validated to the TA.

[Giuseppe De Marco]

thank you D for the quick reply

the TA always ends with an entity statement issued by TA, would it be its entity configuration or a subordinate entity statement. This means that a Trust Chain can always be validated with the TA’s federation public key.

It’s up to all the participants store the trust chains if these are not provided in the signed JWTs.

all the entity statements, be these subordinate statements or entity configurations, issued by all the entities, are signed with their current federation key. Even the response of the historical keys endpoint is signed with the federation entity keys.

It appears to me that your suggestions mirror what's already present in our existing text. Therefore, I'd appreciate if you could provide specific insights on what additions or modifications we could make to enhance the clarity and comprehension of our current approach, in the federation historical key endpoint I mean

[David W Chadwick]

Even the response of the historical keys endpoint is signed with the federation entity keys.

This is the part that was not clear to me. When you look at the example of historical keys there is no signature. However, I now see that the text above the example says “The following is a non-normative example of a response, before serialization and adding a signature:” Perhaps the following clarifying text can be added somewhere in the description.

The historical keys can be validated back to the trust anchor because they are signed by the entity's current key that has itself been signed by the entity's superior

‌

[Michael Jones]

Note that the preface to the example is:

The following is a non-normative example of the JWT Claims Set for a historical keys response

It’s the JWT Claims Set part of the JWT - not the whole JWT.

[Michael Jones]

This issue was discussed on the 5-Jan-24 federation editors' call. It’s not scalable to centralize maintenance of historical keys to trust anchors. We propose to close this issue on that basis in a week if there isn’t a compelling reason identified to keep it open.

[Giuseppe De Marco]

Closed as anticipated in the thread and confirmed during the editor’s call of the 26 February 2024