Shibboleth Developers

["Scott Cantor" <>]

> I'm not sure where you're going with this (but would dearly like to,
> since I'm up to my eyeballs in encryption specs right now).

I think you're just misunderstanding what I'm talking about here. Ignore
everything but this question:

Given a requirement to encrypt, whatever the reason, how do I get the public
key of the rceipient?

Don't answer "re-use session key foo" because there is no session key yet.
First message. What do I do?

One answer is obvious, stick the key or a cert in a KeyDescriptor and just
get it. The question is what else could/should Shib 2.0 do, if anything, and
if not (and I'm arguing not), what are the implications on other uses of PKI
in the implementation?

> What you want is not in SAML 2.0 nor is it potential errata AFACT so the
> only recourse is to specify encryption on a profile by profile basis,
> right?

No. I think low-level encryption details have no business being specified
like that, any more than signature details do. It's a meta-issue, or in some
sense a deployment issue. And it's irrelevant to what I'm asking here
anyway, since no matter what you do, you're stuck on the first turtle.

From what I've been told, all the commercials *can* do encryption on a
per-message basis using just the stuff SAML specifies, so that's interop IF
we can answer the "get the key" question. It's slower than if keys get
reused or derived, yes, but it works interoperably. If people want speed,
use C, not Java. That's my answer to that. Until we start tackling the
mobile phone market, I'm going to ignore it.

> If you have other ideas, please let me know before I invest
> loads of time rewriting a spec that may ultimately be mothballed.

That particular profile couldn't have less to do with what I'm asking about
here. That profile says stuff like "X MUST encrypt Y". That's it. I don't
think it ought to go deeper than that. If you're thinking of adding stuff
about reusing keys, it probably won't fly.

The reality is that SAML's (and every other XML spec's) profile
interoperability ends at ds:KeyInfo. Always has, probably always will based
on the feedback I usually get when I ask about it. I can't fix that, and
you're not going to get any positive feedback if you try to fix it in that
profile draft. If that's what you're asking, anyway.

Within a given community, people seem to get the idea of profiling further
so that this stuff actually works, but that's another layer down (or up, not
sure which). A cynic would say that the vendors are ensuring consultantcy
fees. Me, cynical?

-- Scott