[Openid-specs-ab] OpenID Connect Federation draft 09 ready for your review

Roland Hedberg roland at catalogix.se
Tue Nov 5 16:00:43 UTC 2019

> On 5 Nov 2019, at 15:40, Marcos Sanz <sanz at denic.de> wrote:
> Hi Roland,
>>> I've been thinking about this conglomerate of issues and it'd be 
> actually 
>>> easier if the TA self-signed statement were *not* part of the chain: 
> the 
>>> Consumer should be configured with the TA's name (the issuer URI) and 
> TA 
>>> public key, and it could stop walking up the chain once it finds an ES 
>>> whose iss and signature match these two configured values.
>> When how to get self-signed information became different from how to 
>> get information about an entity from another entity then the TA's 
> self-signed
>> statement was removed from the trust chain. This may not have been 
> spelled out 
>> clearly enough.
> ok, I see. Simmilarly to what RFC 5280 does, though, I'd expect the 
> Consumer to be explicitly configured with both, the TA-identifier and its 
> public key, and not only the latter like the document currently does (at 
> least, that's what it looks to me).

Ah, sorry I thought that went without saying. But one should be explicit about these things.

>> Well, it all starts with the TA. If you don’t trust the TA then you’re 
> smoked.
>> The Federation spec hinges on the fact that you do trust the TA.
> I see it exactly the other way round: you start with a self-signed leaf 
> statement and you walk your way up the trust chain via auth_hints *hoping 
> to find* a TA.

I wasn’t talking about the process of gathering the trust chain. 
Indeed what you’re describing is exactly how it must be done.

What I was alluding to was that if you don’t trust the trust anchor that you 
find at the end of a chain, then of course you can’t trust the trust chain.

> But until you do so (if you do so!), everything on the 
> journey is not to be trusted and a potential attack vector.


> For instance: 
> I am scared about rogue intermediate FEs that publish ESs via their 
> federation API endpoint with fake issuers and keys that do not relate to 
> them whatsoever (it's true that the problem would remain compartmentalized 
> with the JWT typing we are introducing further down, but still).

The only check you might want to do on the way from the leaf statement until you have
the whole chain is on the self-signed statements that you pick up along the way.
I’m not saying that this should make you trust them before you have the whole chain but
if you have a self-signed statement I think it would be a good idea to verify the signature 
on that statement before moving on.

> While inspecting the workflow anew under this light I found out that it'd 
> be important to add in 6.1.2 the requirement for the Consumer to verify 
> that iss and sub of the ES response MUST match the values of the 
> respective query parameter. In case the query had no sub query parameter, 
> the consumer MUST verify that iss = sub.

Good point.

- Roland

Otium cum dignitate - latin proverb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191105/c54e8214/attachment.html>

More information about the Openid-specs-ab mailing list