Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shibboleth-Announce] Shibboleth 2.0 SP Release Candidate 1

Subject: Shibboleth Developers

List archive

RE: [Shibboleth-Announce] Shibboleth 2.0 SP Release Candidate 1


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: [Shibboleth-Announce] Shibboleth 2.0 SP Release Candidate 1
  • Date: Wed, 6 Feb 2008 10:36:50 -0500
  • Organization: The Ohio State University

> That's right, however, so far our people had to own a certificate/key
> pair that was issued by a CA that either was controlled by us or that
> forced them to undergo identification based on paper work (according to
> one of CA acceptance policy).

None of that requires a CA. I don't understand why people think it does.
That's an RA function, not a CA function.

> This second requirement for getting an SP
> to receive attributes (besides creating the SP definition based on
> username/password authentication) is what is lost when one can just
> generate a self-signed certificate or use just any key laying around.

No, it's not lost. That's just a process decision.

> On the other hand an RRA administrator who has to approve the SP
> definition inspects the callback URL/endpoings, he (hopefully) would get
> suspicious and reject the definition.

So do that with the certificate submission. If you're claiming you need to
issue a certificate, what you're really claiming is you want an out of band
step. So add an out of band step. PoP in real time doesn't have to be that
step, and I don't think it can be, not without transport authentication.

> But true, in the end it would nevertheless be great to
> get rid of them provided we find an equally secure replacement for the
> CA solution.

It's not the CA, it's the process that goes along with issuing the
certificate (i.e. the RA). That process can be the same regardless of who
signs a certificate.

> It is clear that we won't do without also providing a way to embed other
> certificates as well because we see the necessity for using certificates
> from other CAs or self-signed certificates, especially for SPs operated
> by commercial content providers.

That at least would be a big help. Within a localized group of providers, it
makes perfect sense to provide a CA if that facilitates some kind of
relationship, as long as it's understood that as soon as they go outside
that circle nobody else is going to care about that CA.

> Personally, I tend to agree with you but as you can see, I work in
> SWITCH's security group and not all colleagues think that solely relying
> on username/password authenticated users and letting the SP endpoints
> get validated by an RRA is sufficient without any further measures to
> keep about the same level of security concerning the certificate,
> whether it is an accepted one of our CA list or an embedded one of any
> CA/selfsigned ...

Like I said, that's an RA thing, not a CA thing. If you sign metadata, you
are a CA already, no matter what's inside it.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page