Shibboleth Developers

[Walter Hoehn <>]

On Jul 27, 2006, at 5:36 PM, Ian Young wrote:

> Interesting.  I hadn't thought of it as a documentation issue, but  
> of course a lot of these standards are vague enough as to their  
> semantics to leave lots of interpretations open... with the  
> assumption that the community of use will settle on a definition.
>
> If we start using in-line keys round here, I will make sure to  
> describe what we mean by them.  The document that would have to  
> live in is on my plate at the moment.

Not to spark off a religious debate, but trust me... you'll be headed  
down this road eventually.

> > > If this also isn't likely to change, I am wondering why one would  
> > > use an X509Certificate instead of, say, an RSAKeyValue element,  
> > > which would presumably be a fair bit shorter?  I can see that  
> > > might be an inconvenient value to derive if someone hands you  
> > > a .pem file or whatever, but are there other reasons not to go  
> > > there?
> > No, it's entirely ease of use, and there's no reason you  
> > *couldn't* support
> > RSA direct. For all I know, Walter did. Don't think I did though.
>
> I'll take that as a provisional "no" for the system as a whole.
>
> The IdP code looks to me like it might do different things when  
> validating a signed SAML object vs. validating TLS.  In the former  
> case, I think the code just asks the Apache XMLSEC library to  
> extract a public key, and wandering through their code makes me  
> think that it would handle raw RSAKeyValue elements in there.   
> Insufficient documentation in there to tell for sure without trying  
> it.

The code for evaluating signed objects isn't used by the 1.x.x IdP.   
It was added for the original stalled Java SP development.  Some  
variation of it will be used in the 2.0 IdP, though.

> When validating TLS, I think the answer is no because the  
> BasicTrust code explicitly only looks at keys with X.509  
> certificates, and there is an additional constraint that the  
> certificate presented has to exactly match the one in the  
> metadata.  So I suppose in this sense the rest of the certificate  
> in the metadata is not actually ignored, its validity is merely not  
> checked.
>
> If Walter wanted to set me straight on any of the above, that would  
> be great!

You are correct, there is only support for X509 certificates.  I'd  
like to add support for a couple of other options in 2.0... I'd be  
more certain of getting around to it, though, if somebody wanted to  
use it.

> Apart from the extra size of a certificate vs. the raw key, I'd be  
> slightly interested in this from a "do what you say, say what you  
> do" point of view.  I've had a certain amount of push-back from  
> people who shall remain nameless but are deeply familiar with X. 
> 509; their expectation is that if all that stuff is in there they'd  
> expect the certificate constraints to be honoured.  Using explicit  
> RSA keys would make it clearer that it was indeed "just a key".  I  
> don't think this is a vital issue, though, as long as I remember to  
> document the actual position well enough.

I agree.  I'd really like to dump the useless baggage here.  The dsig  
XML format of RSA keys is a total pain for regular humans,  
unfortunately.  Heck, if we can get acceptable performance using  
encryption, I'd just as soon use pgp keys.

-Walter