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

[Tomasz Wolniewicz <twoln AT umk.pl>]

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


Wysłane z iPada

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