An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Schober <peter.schober AT univie.ac.at>]

Γεια σου!

* Zenon Mousmoulas <zmousm AT noc.grnet.gr> [2019-11-19 09:37]:
> What is the basis for validator warnings about expired
> signing/encryption certificates found in metadata?

FWIW, the eduGAIN MDS checks only apply to your upstream feed.
If a warning troubles you by all means re-wrap your signing key into a
certificate that's not expired (maybe stretching the expiration date
until the end of the UNIX epoch for good measure, as I've done with
the eduID.at metadata signing certificate) and sign at least (or only)
your eduGAIN upstream with that. ;)

> It is mentioned in BCP as a low significance condition:
> 
> https://wiki.geant.org/display/eduGAIN/Best+Current+Practice

I don't recall ever having seen those before.

> It is also mentioned in SAML2 MetaIOP §2.5.1: "it is RECOMMENDED
> that certificates be unexpired"

That's the only thing that would have initially come to mind -- *but*
that's about embedded certificates relating to SAML *entities*, not
about keys that may have signed the metadata and where therefore the
certificate identifying the signing key may be present in metadata
too (via inclusion of an <ds:Signature> element):

* 2.3 "In other words, this profile does not define how (or how often)
  metadata is exchanged or how and why it is trusted, but rather assumes
  that it is exchanged and trusted, and proceeds from that starting
  point."

I.e., everything in SAMLMetaIOP assumes "the metadata" only applies to
what comes after that initial starting point (having accepted the
metadata). That alone should be sufficient, IMO, but even in the
individual sections later there are repeated references to metadata "roles":

* 2.5 (setting up this section/topic):
  "Within the context of a particular role (and the protocols it
  supports, as expressed in its protocolSupportEnumeration attribute)
  ..." and again
  "Any <md:RoleDescriptor> element (or any derived element or type)
  appearing in the metadata instance  MUST conform to this profile's
  requirements." -- IDPSSODescriptor and SPSSODescriptor derived from
  RoleDescriptor.

* 2.5.1: "Each key included in a metadata role MUST be ..."

* 2.6.1 "Each key expressed by a <md:KeyDescriptor> element within a
  particular role MUST be treated as valid ..."

So I don't think SAMLMetaIOP really applies to your question.

Which does pose the question how the MDS came to add this to the list
of requirements.

But as I said above, it should be rather easy to avoid expired signing
certificates in most or all cases.

Best,
-peter