Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> > So, the only part of the X509Certificate that is used in the validation 
> > of assertions in that case is the embedded RSA key?  Everything else in 
> > there is just decorative?
>
> Yes, and this is largely because XML syntax for RSA keys is ugly. Inline
> certs are easier.

Agreed about the ugly part, and of course the absence of a tool that 
takes a .pem file and writes the RSA key in XML DSIG format makes this a 
hard road to go down...

> > Again, I'm interested in knowing whether this case is just-for-now or 
> > you might change it in the future (you say you're not interested in 
> > changing the out-of-band verification case, but I suppose this is the 
> > in-band verification case you excluded there).
>
> For consistency reasons, I don't see any argument for changing it. Other
> plugins could interpret inline certs differently in metadata, but I realized
> that at a federation level, if you're driving the existing code it's
> important to be clear with people that the meaning of that metadata is "the
> public key is valid", and the cert is irrelevant.
>
> In other words, all interoperability stops at ds:KeyInfo. There's nothing we
> can do about that, so it's a documentation exercise.

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.

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

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!

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.

        -- Ian