Shibboleth Developers

[Scott Cantor <>]

> Umm, hmm?  Why is validation of a client cert, as part of SSL 
> processing, any more difficult than validation of a signed 
> SAML assertion, as part of the web browser profile?  The win 
> in the SAML case, it seems to me, is simply that the user 
> doesn't have to deal with certs and keys.

The only win is that starting without X.509 in the equation eliminates
presumptions about how it "ought to be done". It's pragmatic, not a
technical issue. Also, making it part of SSL processing is where you get
into trouble because of existing practice/code. If you cross that out, and
leave the processing to the thing behind the SSL, I'd agree there's little
difference. But I also don't see much point. If I really don't care about
the cert, but about the information the authority gives me about the owner,
why bother validating it?

> What you're suggesting sounds more or less like the "path 
> validation service" that has been the subject of much work in 
> PKIX (and XKMS, I think).  But having the origin AA play that 
> role for the target seems unlikely to me.  As far as I can 
> see the target will have to do full SSL/cert validation in this case.

Why? I'm not saying it couldn't, but all the target cares about is proof
that the guy presenting the cert has the private key, which SSL presumably
promises. After that, he can delegate the association of that key with data
to something else. Architecturally, I don't think it has to be the AA that
does the validation, simply that it can be done by the issuer.

> But having the Attr Authority be able to respond to any kind 
> of permanent identifier reveals a certain overloading we're 
> doing with the current handles.  The handle has a validity 
> period, even if it's only known by the origin, after which it 
> won't be useful for queries.  This is a cheap way of getting 
> a session, and ensuring that a target is asking about a 
> subject that has recently come to it.  But if the AttrA 
> handles permanent identifiers, does it have to answer any 
> legitimate requester regardless of when it asks?  If there is 
> to be a session context, where does it come from?

That's true. Currently, I'm using this for an internal purpose that isn't
exposed to any off-machine queries, so I dodged the issue. But I don't see
any difference between this and LDAP, which doesn't require presence as a
condition of answering. If I ask for attributes using a persistent
identifier, and I'm granted them, so be it.

I do think release policy needs to incoporate the difference though, the
ability to control which types of identifiers a requester is allowed to use.

> The DLF cert work from a couple of years ago invented a cert 
> attribute for that purpose.  It's obviously appealing not to 
> have to issue new certs in order to make this work, though.  
> But use of existing certs would lead us back to the target 
> digging thru it to figure out which parts to use to identify 
> the origin site ...

Yes, I'm familiar with the work. My understanding of the use case was that
using a special attribute is more or less a dealbreaker, but perhaps not. It
seems like a mapping of the Issuer to subsequent metadata would be a place
to start.

> Right, it's important that this be pluggable.

Yes, including the appropriate knobs in the ACLs.

-- Scott