InCommon metadata support

[Tom Scavo <>]

[copying metadata-support; David, can you please direct further
discussion to the mailing list?]

On Mon, Mar 24, 2014 at 3:39 PM, David Bantz 
<>
 wrote:
>
> (1) I have verified the certificate signatures as described in the wiki.
> I did so on my workstation rather than directly on the IdP server.  (copied
> below)
> I suppose there some greater assurance of trust in the certificate;
> should I in fact do the signature trusting on the IdP server itself?

That's a good question. It depends on how the metadata signing
certificate is moved around from host to host. If there are doubts,
you could, I suppose, move the certificate to the target IdP server
and then recheck the fingerprints right there to be sure.

>  (2) I have pointed my development IdP's metadata provider config
> in relying party.xml to the new aggregate at md.incommon.org
> and verified that IdP loads the new config and according to the IdP
> logs loads metadata from md.incommon.org.
>
> Is that it?

I assume you mean the new *production* aggregate, but basically, yes,
you are done.

> (3) My production IdP is 2.1.2 %-{
> Any issue with pushing this config to production on 2.1.2?

Well, that's a Shibboleth question, not a Federation question, so you
should probably ask those on the shib mailing list.

Personally, I would want to use Shib IdP 2.2 (or later) since 2.2 has
significant metadata functionality compared to its predecessors. That
said, apparently you've been using 2.1.2 all this time without issue,
so simply changing the source of the metadata aggregate shouldn't
cause any issue.

> (4) extra credit: why is this url http rather than https?

I answered that question the other day on this list but I'll answer
again since it's a FAQ. InCommon metadata has *always* been published
as an ordinary http:// URL (not https://) since the beginning of time.
So this is not new. (You're just noticing it now for the first time :)

The metadata file is signed for authenticity and integrity. Securing
the transport (with HTTPS) doesn't obviate the need to verify the XML
signature on the aggregate. Speaking of which, be sure to compare your
config to this one: https://spaces.internet2.edu/x/XAQjAQ

> Because the data itself is not "secret" and is separately verified for
> integrity using SHA 256?

Those are two separate questions. Confidentiality of metadata is not a
goal so the confidentiality benefit of a secure channel is a poor
argument in favor of a secure channel. Put another way, there are some
minor benefits of retrieving metadata over a secure channel but
confidentiality is not one of them.

The use of hashing algorithms (such as SHA-256) in XML Signature is
complicated. Here are some resources:

https://wiki.shibboleth.net/confluence/x/H4O3
https://wiki.shibboleth.net/confluence/x/SIFC

The latter is particularly thorough.

Hope this helps,

Tom


> On Wed, 12 Mar 2014, at 12:12 , Tom Scavo 
> <>
>  wrote:
>
> At 2014-03-14 16:00
>
> q:~ dabantz$ MD_CERT_LOCATION=https://ds.incommon.org/certs/inc-md-cert.pem
> q:~ dabantz$ MD_CERT_PATH=/Users/dabantz/inc-md-cert
> q:~ dabantz$ /usr/bin/curl --silent $MD_CERT_LOCATION > $MD_CERT_PATH
>
> q:~ dabantz$ /bin/cat $MD_CERT_PATH | /usr/bin/openssl x509 -sha1 -noout
> -fingerprint
> SHA1 Fingerprint=7D:B4:BB:28:D3:D5:C8:52:E0:80:B3:62:43:2A:AF:34:B2:A6:0E:DD
> q:~ dabantz$  /bin/cat $MD_CERT_PATH | /usr/bin/openssl x509 -sha256 -noout
> -fingerprint
> SHA256
> Fingerprint=2F:9D:9A:A1:FE:D1:92:F0:64:A8:C6:31:5D:39:FA:CF:1E:08:84:0D:27:21:F3:31:B1:70:A5:2B:88:81:9F:5B
>
> Checks with fingerprints provided at
> https://ops.incommon.org/inc_md_cert.html
>
> SHA256
> Fingerprint=2F:9D:9A:A1:FE:D1:92:F0:64:A8:C6:31:5D:39:FA:CF:1E:08:84:0D:27:21:F3:31:B1:70:A5:2B:88:81:9F:5B
>
> SHA1 Fingerprint=7D:B4:BB:28:D3:D5:C8:52:E0:80:B3:62:43:2A:AF:34:B2:A6:0E:DD
>
>
>