Trust Chain for Trust Anchor?

[zachmann]

When running the Conformance Tests I stumbled upon a question.

The testing instructions include the following:

entity_identifier
    The entity identifier for the primary federation entity under test, which could be a leaf, an intermediate or a trust_anchor.

trust_anchor
    The intended trust anchor for the entity specified by the entity_identifier. If the federation entity under test is a trust anchor, this field will be equal to the entity_identifier field.

So I tried to use a Trust Anchor in entity_identifier, i.e. entity_identifier==trust_anchor.

For this case the resolve test failed with my implementation, because my resolver implementation did not resolve a trust chain from TA to TA.

So I wondered what others are thinking. Is this something a resolver should do or not? Or more general can there be a Trust Chain from an entity to itself?
I would say that the definition of Trust Chain does not allow this. (Also it does not really make sense since the trust anchor is trusted out of band).

[peppelinux]

• the trust anchor is trusted out of band and does not need any chain.

[cicnavi]

Can a Trust Anchor then be a Trust Mark Issuer? In 7.3. Validating a Trust Mark, it is noted that trust is to be resolved when validating Trust Mark Issuer:

To validate a Trust Mark Issuer, follow the procedure defined in Section 10

If it is OK for a Trust Anchor to be a Trust Mark Issuer, maybe consider noting that as a "special case" or similar, for validating Trust Mark Issuer.

[zachmann]

IMO it is quite straightforward that a TA can be a TMI and verifying the trust path to the TA would be as simple as "I trust this entity".

But I fully agree that this is a special case that might be noted explicitly.

[malmgren01DF]

Thanks a lot for your observation, @zachmann! I will happily admit that the conformance tests that you ran are early versions and not all cases are accounted for or properly thought through, so it's very useful to have your feedback as we continue to develop and evolve the tests. Thank you.

[malmgren01DF]

Issue duplicate created in the conformance suite project: https://gitlab.com/openid/conformance-suite/-/issues/1507

[malmgren01DF]

@selfissued asked me about this in today's Atlantic call, and I thought a little about this:

The specification doesn't say that the subject of the trust chain must be a leaf or an intermediate, I believe. It only says that it begins with the subject and ends with a trust anchor. So what would such a trust chain look like? Well, it would be a single-element array which contains only the EC of the TA.

We recall that the rules for constructing a trust chain (the part that reads like a mathematical definition) are these:

Let us refer to the Entity Statements in the Trust Chain as ES[j], where j = 0,...,i, with 0 being the index of the first Entity Statement and i being the zero-based index of the last. Then:

• ES[0] (the Entity Configuration of the Trust Chain subject) is signed using a key in ES[0]["jwks"].
• The iss claim in an Entity Statement is equal to the sub claim in the next. Restating this symbolically, for each j = 0,...,i-1, ES[j]["iss"] == ES[j+1]["sub"].
• An Entity Statement is signed using a key from the jwks claim in the next. Restating this symbolically, for each j = 0,...,i-1, ES[j] is signed by a key in ES[j+1]["jwks"].
• ES[i] (the Trust Anchor's Entity Configuration in the Trust Chain) is signed using a key in ES[i]["jwks"].

The single-element trust anchor trust chain complies with this definition since

• the first statement is true since that's what we said above, that the array would contain only the EC of the TA.
• the second and third conditions can be considered to be true by default since there is no "next", i.e. these conditions will never be false in a single-element chain.
• the fourth statement is true because ES[i] = ES[0] = the EC of the TA.

In a way, this feels a little bit like an academic excercise but the original issue description here says:

I would say that the definition of Trust Chain does not allow this. (Also it does not really make sense since the trust anchor is trusted out of band).

But as I've tried to argue, unless I missed something, it seems to me that the TC definition does allow it, and perhaps it could even be considered the "implementation" of trusting a TA out of band – you trust its EC as it is, stand-alone.

A possible advantage of looking at it this way could be that it solves the problem raised by @cicnavi above, namely that it covers the parts of the spec that say that trust chain validation must happen.

[zachmann]

Indeed, the spec seems to allow a single EC trust chain. I originally thought that the spec would require the chain to have at least three statements (Leaf's EC, TA's ES, TA's EC), but that was a misconception I did not check.

So the correct trust chain for a trust anchor would be only its entity configuration; therefore that would also be the correct result for a resolve request.

So I guess we can close this.