Shibboleth Developers

[Alistair Young <>]

> Given a requirement to encrypt, whatever the reason, how do I get  
> the public
> key of the rceipient?
dare I say it? but profile a WS method for getting it. The current  
profile describes how to get attributes/assertions from an endpoint.  
A public cert is just another attribute but of the entity rather than  
the user in a profile. Without a profile there will be no interop. A  
profile that lets an ecrypter ask an encryptee "give me your key".  
The public key is no big secret, it's public! So use REST. If I want  
the description of a WS I use it's "REST" service to get it's WSDL (? 
wsdl). Why not have a REST service to get it's public key too?

Reuse is bad so keys shouldn't be in metadata.

Alistair


On 22 Jun 2006, at 17:37, Scott Cantor wrote:

> > 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