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

["Zenon Mousmoulas" <zmousm AT noc.grnet.gr>]

November 19, 2019 12:22 PM, "Tomasz Wolniewicz" <twoln AT umk.pl> wrote:

> I am pretty sure that this was based on the advice from Ian Young given to 
> us a long time ago. I
> think it makes sense as a form of making sure that federations manage their 
> keys. It is up to the
> SG to decide what we should have if someone feels that the current behavior 
> should be changed than
> we could have a discussion and possibly a vote on it.
> Tomasz

I am not suggesting removing the check/warning. I am just trying to 
understand where it comes from, so that we can provide an argument to 
federation members who are asking why we ask that they update their expired 
certificates.

> Wiadomość napisana przez Peter Schober <peter.schober AT univie.ac.at> w dniu 
> 19.11.2019, o godz.
> 11:11:
> 
> Γεια σου!

Καλησπέρα!

> * 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. ;)

The question was about the warnings pertaining to the SAML signing/encryption 
certificates embedded in metadata, which are not related to the metadata 
signing certificate.

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

That was the only reference I could find on this matter, which understandably 
is only a weak RECOMMENDATION.

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

Anecdotal evidence suggests that MS ADFS, at least some versions, impose such 
a requirement. Even if only for such interop issues (rather than normative 
documents), I was hoping someone might be able to point to a more explicit 
reference.

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

I understand your point about the metadata signing certificate, but your 
suggestion above won't make the expired entity certificate warnings go away.