Shibboleth Developers

["Scott Cantor" <>]

> Possibly we can stop overdesigning this thing.  The whole point was
> to give some uniqueness to infocard's broken PPID.  Adding a hash
> of the card's public key accomplishes that.  The only reason the
> original PPID might not be unique is that it is a bearer item, and
> could be stolen and reused.

Well, right. It's not intended to be secure absent the ability to prove that
the same "issuer" is providing it, by verifying that the signature over the
assertion is from the same key. That's all we're trying to verify.

> We don't even know that the key hash is even beneficial.
> If I export a card to another system, the PPID might
> stay the same, but will the public key?  I don't see where
> that's guaranteed.  The system might be more useful without
> it and no more secure with it.

Actually, yes, it will be the same (because of how the self-issuing IdP is
defined). See section 8.4 of the ISIP.

> My inclination is to drop the public key - hash and all.
> If the PPID is important to the service, then the service
> can protect it.

How? The key is the only protection. The service can't protect it in any
other way.

My goal was to provide the key in a simple format and leave it at that. I
still think that's possible, but it will require some openssl functions to
pull off. It's not hard, but I don't object to avoiding linkage to openssl
either.

An alternative is a hash, but if the PKI specs have over-complicated that
like they do everything else, I'd say we should avoid anything that has the
semblance of "officialness" and just generate something.

The only thing to be careful of is that it needs to be something that can
port cleanly, because a service shouldn't have to depend on a hash value
that can't be generated by an alternative implementation of the SP. As an
example, this is C++, not Java, so what Java can do "trivially" is only
interesting to me insofar as it's something we can do (and vice versa).

-- Scott