Versions Compared

Old Version 3

changes.mady.by.user Andrijana Todosijevic

Saved on

compared with

New Version 4

changes.mady.by.user Lukas Haemmerle

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

You can respond to this consultation directly by filling in the table below, commenting on the eduGAIN SG list or sending your comments to nicole.harris@geant.org. 

ReferenceCommentCommenterActions
e.g. line numberyour comments hereyour name hereplease leave blank 
Metadata Signing

Code Block
languagexml
 I wonder if the signing section of the profile should bot use a more
formal language, like this borrowed from Ian, modified and used in the
Aggregation Statement document:

----
In order to assure metadata integrity and originality, each federation
aggregate MUST be signed as specified in [Metadata for the OASIS
Security Assertion Markup Language (SAML) V2.0]. This signature made
with the key matching the one supplied to the eduGAIN OT is the only
element on which trust is based. In particular the eduGAIN aggregator
does not use trust that might be derived from an https endpoint details.

Metadata signature verification is done against the public key alone. If
the public key for the channel is supplied in the form of an X.509
certificate, other aspects of the certificate such as its expiry date do
not form part of signature verification. This is in accordance with the
SAML metadata interoperability profile. In particular an expired
certificate will still be used for the verification purpose.
---


Tomasz W 
Metadata Signing
Include the following:


Code Block
languagexml
- The signature was made using an explicit ID reference, not an empty
reference.
- The signature reference refers to the document element.
- The signature's digest algorithm is at least as strong as SHA-256.
Specifically, MD5 and SHA-1 are not permitted as digest algorithms.
- The signature's signature method is RSA with an associated digest at
least as strong as SHA-256. Specifically, MD5 and SHA-1 are not
permitted as digest algorithms.
- The signature's transforms contain only permissible values:
-- Enveloped signature
-- Exclusive canonicalisation with or without comments


Tomasz W
Terms (Entity)Replace exchanged by published in the following sentence:
"In this document, an Entity refers to an entity’s metadata that a Participant Federation has exchanged through eduGAIN."		Thomas L
Terms (Home Organisation)

Replace: "The organisation with which the end users are affiliated."
with: "The organisation with which an end user is affiliated."

Thomas L
Terms (eduGAIN Policy Framework)

Typo: SAML Profil  -> SAML Profile

Thomas L
Terms (SAML V2.0)Replace: "Security Markup Language"
with "Security Assertion Markup Language"		Thomas L
Terms (SAML Metadata)Sort this term before SAML Metadata Producer.Thomas L
Terms (SAML Metadata)This requirement should not be hidden in the Terms, but move to '3 Metadata Production":
"Valid SAML Metadata MUST meet the requirements defined in the SAML Metadata Specification [SAMLMeta] including [SAMLMetaErrata]."		Thomas L
Terms (Metadata Registration Practice Statement (MRPS))Drop the second sentence "Every eduGAIN Member Federation must publish an MRPS.". This requirement is alreaedy included in 2 Metadata Registration on line 60. Thomas L
line 65The reference for [REFEDS-MDRPS] is missing.Thomas L
line 84The referene for [SAMLCore] is missing.Thomas L
line 88The reference for [MDRPI] is missing.Thomas L
line 90The reference for [MDUI] is missing.Thomas L
line 103-104Drop "other values in the service's native languages for the elements where appropriate." since it is already mentioned on lines 127-128.Thomas L
A general remarkThe current eduGAIN policy is supposed to be technology agnostic, from which it follows that the requirement for the presentation of the federation policy at the moment of joining may be fairly lax. At the moment of enabling a given profile, we should probably require additional documents like a profile-specific part of the federation policy, this should perhaps be mentioned as a required document in the SAML profile?Tomasz W
Metadata registrationI find this somewhat misleading. Other sections of the document refer mostly to how the federation aggregate is produced, signed etc. This section mentions the internal document of a federation which describes how the entities make their way to the federation itself. While I fully support the need to have the registration statement requirement, I would see this particular as an element of something bigger. I would suggest that this section speaks about elements that need to be registered with the OT and which are now mentioned in several places, like the signing key, the registartionAuthority value, the metadata location. This section should state that this information needs to be passed to the OT in a trust preserving way, I would not however specify what this means, this might be specified in the Operations document.Tomasz W
General questions

1. The aim of this profile seems to be to improve interop among entities in different federations by means of definng common practices by fed ops and edugain ops. Interop issues can sometimes result from different filtering policies implemented by different federations when they consume edugain metadata. Examples include federation-specific standards for end point scheme (HTTP vs HTTPS) and minimum key length (1024 vs 2048+). Is this profile the right place at which to define eduGain-wide standards for such things? If so, is this the right time to consider doing so in these two instances?

2. Members of federations are advised by their federations' operators to check the signature of their federation metadata to verify its authenticity and integrity. Does eduGain do likewise in the process of aggregating member federations' metadata for redistribution? If not, should it, and if it does not but should, is this profile the right place in which to address that requirement?

Tom Barton

...

eduGAIN SAML Profile Review - the Long Read

...