Skip to Content.
Sympa Menu

shibboleth-dev - RE: semantics of metadata signing certificate

Subject: Shibboleth Developers

List archive

RE: semantics of metadata signing certificate


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: semantics of metadata signing certificate
  • Date: Thu, 27 Jul 2006 14:27:27 -0400
  • Organization: The Ohio State University

> Understood. But the current siterefresh tool treats things
> the same as metadatatool does?

For the most part, I think so. It's a subset anyway and both of them expect
that getting the signing key is a separate task.

> By saying across the system, I think you're also talking about what the
> IdP and SP do when there is a KeyInfo with X509Certificate data in the
> metadata.

Yes.

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

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

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

> And, I suppose, this trail of questions would be incomplete if I didn't
> also ask in passing whether the current code base was able to process an
> RSAKeyValue if it saw one go by...

See above.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page