Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] reference for expired certificate warning

edugain-discuss AT lists.geant.org

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

List archive


Re: [eduGAIN-discuss] reference for expired certificate warning


Chronological Thread 
  • From: Peter Schober <peter.schober AT univie.ac.at>
  • To: edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] reference for expired certificate warning
  • Date: Tue, 19 Nov 2019 11:10:43 +0100
  • Organization: ACOnet

Γεια σου!

* 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



Archive powered by MHonArc 2.6.19.

Top of Page