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

[Ian Young <ian AT iay.org.uk>]

Belated reply from me.

> On 9 Apr 2015, at 11:43, Tomasz Wolniewicz <twoln AT umk.pl> wrote:
> 
> Hi,
>  Following up on some metadata expiry cases we have re-visited the
> following clause of the eduGAIN metedata profile:
> "The metadata root element MUST contain validUntil attribute with a
> value not later than 28 days after the signature timestamp"
> 
> While this clause mentions a signature timestamp which does not exist in
> federation upstream metadata, it has a clear intention of not allowing
> federations to provide metadata with very long lifetimes.

That's exactly right. The threat here is the ability to replay "very old" 
metadata which contains known-compromised key material. The balance is 
between protecting against that and forcing members to re-sign more 
frequently than they find convenient, a particular issue in federations where 
signing is a manual operation.

> So far our approach was to react to situations where the validUntil
> value was more then 28 days in advance from the current time, we did not
> inspect any elements of the metadata file itself.

That is what I recall as the expectation when we wrote the profile. Although 
the wording might be improved to avoid talking about the instant of signing 
(which you can't see) there is in my view no need to push towards higher 
precision. "not more than 28d after the instant of retrieval" is fine for 
such an arbitrary boundary, and if we ever revise the profile I'd suggest we 
take that approach.

> If we wanted to be
> more exact, then the only way we can implement it is by using the
> creationInstant value within the PublicationInfo element as a substitute
> of this signature timestamp. Unfortunately creationInstant is optional.

Strictly, the creation instant is the instant of creation of the aggregate, 
and could be very different to the instant of creation of the signature.

> On the eduGAIN status page: https://technical.edugain.org/status.php you
> can now see blue exclamation marks, which mark a minor problem with
> federation metadata (this will become red if something is seriously
> wrong, like not access to metadata).

Seems like a very useful indicator. Any chance of getting a list of the 
issues detected by hovering overt the "!"? There's nothing at present to tie 
it to the issue listed when you expand the entry (and which is in red!)

> Right now this blue exclamation
> mark means that metadata does not contain the creationInstant attribute
> in PublicationInfo, or does not contain the PublicationInfo at all (we
> do not distinguish between these two). You can see that there are many
> of these. The ones which are not marked do have the creationInstant and
> you can see its value when you expand the view. There is one special
> case - Ecuador MINGA - they do have a creationInstant but is shows
> 2014-11-27 14:14:00, while the validUntil is 2015-04-20 00:00:01 -
> definitely too big a difference. This is most likely a simple mistake or
> interpretation of the creationInstant meaning, MINGA does resign their
> metadata, changing the validUntil to an approapriate value, but they
> seem to keep creationInstant untouched.

If they don't change the actual entity metadata for long periods, but simply 
re-sign it with a new validUntil, that might actually be valid. Five months 
seems unlikely, though, and worth talking through with them.

    -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature