Size explosion using trust_chain header

[Stefan Santesson]

I see a potential serious problem with the trust_chain header and its potential to generate a size explosion due to its recursive application in headers.

Consider a chain of entity statements using a common TA: Leaf → IE3 → IE2 → IE1 → TA

If all these entities issue Entity Statement containing a trust_chain header size this could result in this:

IE1 Entity statement trust_chain header( TA1) → ES Size = 2 Entity statements
IE2 Entity statement trust_chain header( IE1(TA), TA) → ES Size = 4 Entity statements
IE3 Entity statement trust_chain header( IE2(IE1(TA), TA), IE1(TA), TA) → ES Size = 8 Entity statements

Full chain = Entity statements from Leaf + IE3 + IE2 + IE1 + TA → Chain size = 1 + 8 + 4 + 2 + 1 = 16 Entity statements

Explaining calculation

IE3 includes in its header the Entity Statement from IE2, which in turn includes the Entity Statement from IE1, which in turn includes the Entity Statement from TA. Then it includes the Entity Statement from IE1, which in turn includes the Entity Statement from TA, and finally it adds the Entity Statement of the TA. This makes a total of 7 Entity Statements in the header + then plus the Entity Statement that contains the header, making this 8.

‌

Why is this chain header parameter needed?

I struggle to see the need or even point of the trust_chain header. A chain of Entity Statements can be validated without this header by applying the of the key of the entity statement. This is also reflected by the fact that the header is optional. The question is why it is there at all, given its potential size explosion potential.

A problem is that if it is present, there are requirements in the specification that it must be processed (se section 10). So allowing it causes implementation requirements for many entities.

This issue also highlights why we define an option to include a trust_chain in OIDC requests. If it is not needed, perhaps it should never be sent. Especially if it can grow very big.

[Giuseppe De Marco]

the trust chain header parameter is needed for wallet offline flow, in the same way we have in the jws headers the X.509 Certificate Chain.
Could be a X.509 Certificate Chain longer than 8? Probably yes, probably not.

static trust chain also reduces the ost of the federation entity discovery because only with the TA’s public key it is possibile to validate the chain, and using the source_endpoint in the ES it is also possibile to fastly renew the trust chain, without fetching the entity configuration of each iss in the chain.

these are optional devices that may be used in impl profile. It is not mandatory using these device.
Is there any other similar consideration about the size been made for x5c too?

[Michael Jones]

We talked about this in the 16-Nov-23 working group call. Giuseppe points out that the ability to cache the Trust Chain makes offline use possible.

[Stefan Santesson]

I guess what I’m asking is. If you need a chain of Entity Statements, Why do you not deliver that as a list of individual Entity Statements? Why put the list in the header of one statement?

If you are not careful, you will get this recursive effect if the Entity Statements you put in your header also have a header with their chain.

Another threat is if you put a chain of Entity Statements in your header, and some of those Entity Statements have a completely different chain in their header, and so on.

Again. If this is what you intended, pleas feel free to close this issue.

I just wanted to bring your attention to this.

[Michael Jones]

I agree that, at the very least, we should discuss the size tradeoffs you’ve identified.

[Giuseppe De Marco]

An entity statement should not have a jws header trust chain with itself in the chain!

I agree that we should Say that EC and es must not have the trust chain jws header parameter, with themselves in

That would be a weird matrioska …

[Stefan Santesson]

Guiseppe. That depends on what you mean by (itself). If a statement is issued for B by A, then it is natural to include A in the chain. Is that itself? So if you state such rule, it must be clear.

Of course self signed EC should never include itself, that would be pointless.

But I think that is secondary. The explosion happens anyway if all ES in the chain contains a chain in the header

The longer the chain, the worse it gets.

This could very easily happen if every Intermediary/TA always include a chain in the ES they they publish

‌

Nobody still has explained why you wouldn’t just provide a chain of ES/EC without trust_chain headers, instead of one Entity Statement with a trust_chain header.

Because even if you just provide one EC/ES with the trust_chain in the header, then those ES in the trust_chain header, may also have a trust_chain header repeating the Entity Statements in the trust_chain. And you can’t do anything about it because they are not issued by you.

It becomes messy. I would choose one of three solutions:

• remove the trust_chain header from the spec. Always deliver a trust chain as a list of Entity Statements / Entity Configurations.
• State that the trust_chain header MUST NOT appear in any Entity Statement. It can only be included in Entity Configuration if the entity is not a TA.

I would prefer the first. But using the last option, you could still present an Entity Configuration with a complete trust_chain header as a single verifiable object.

[Giuseppe De Marco]

The second one, as already said in my previous comment, EC and es must not contain the trust_chain header parameter

[Stefan Santesson]

Did I misread it?

You said:

EC and es must not have the trust chain jws header parameter, with themselves in

I said that no ES should have any trust_chain header parameter at all. Containing no ES/EC. Not their own, at not anyone else's either.

Only the EC that is the self-signed statement in the beginning of a chain can contain a trust_chain header.

Did we mean the same thing?

[Giuseppe De Marco]

No, neither the EC, because in the trust chain the First [0] element Is a EC

Having the TC header in the EC would mean having itself replicated in the TC in an infinite recursion

It would became a Pink Floyd album cover

[Stefan Santesson]

I don’t regard the EC statement as part of the trust chain. The trust chain (in my definition) the the statements other than “this one” that can be used to validate “this one”

So there we fully agree.

The biggest point I’m making is that ES should never contain a trust chain in its header. Do you agree?

[Giuseppe De Marco]

Yes I agree @Stefan Santesson , and this is the related PR to prevent this https://bitbucket.org/openid/connect/pull-requests/675

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/675