Date: Fri, 29 Mar 2024 14:01:49 +0000 (UTC)
Message-ID: <1079252015.8067.1711720909187@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_8066_1574167539.1711720909185"
------=_Part_8066_1574167539.1711720909185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Phase 2 Report of the MD-Distro Subcommittee
Terminology
- signing key: a private key used for signing metadata; an RSA 2=
048-bit private key
- signing certificate: an X.509v3 certificate containing a publi=
c key used to verify the signature on a metadata file; a container for an R=
SA 2048-bit public key
Introduction
The following Phase 2 deliverables were included in the Phase 1 Implementation Plan=
:
- Elicit and capture short to mid-term requirements for metadata aggregat=
ion=20
- Devise a plan to transition the metadata signing algorithm to SHA-2=20
- SHA-2 is an important driver for Phase 1
- The Pha=
se 1 Implementation Plan stipulates that all SAML deployments shall con=
sume metadata signed with a SHA-2 digest algorithm by June 30, 2014
- Determine the desirability, feasibility, and impact of changing the InC=
ommon metadata distribution point=20
- A new vhost for XML metadata distribution will be introduced in Phase&n=
bsp;1
The following Phase 2 deliverables are included in this Phase =
2 plan:
- Expand the usage of multiple metadata aggregates.
- Conduct a pilot study that explores the feasibility and utility of per-=
entity metadata
- Conduct a community-driven review of InCommon key management practices<=
/li>
- Conduct a landscape study of the potential needs and uses of hardware s=
ecurity modules
- Participate in the samlbits.org project
The following issues identified in the charter were discussed but not addressed in=
this Phase 2 plan:
- per-organization metadata
- metadata aggregates based on self-asserted entity attributes
- support for both XML and JSON formats (both signed)
RECOMMENDATION: Investigate and subsequently expand the uses of multiple=
metadata aggregates=
to facilitate a broad range of metadata deployment scenarios.
- Multiple metadata aggregates were introduced in Phase 1 to facilit=
ate the migration to SHA-2:=20
- production metadata aggregate
- fallback metadata aggregate
- preview metadata aggregate
- Initially, the production metadata aggregate will be signed us=
ing a SHA-2 digest algorithm while the fallback metadata aggregate=
will be signed using the SHA-1 digest algorithm. When the two aggregates a=
re identical at the end of Phase 1, they become available for other us=
es as discussed on the metadata aggregates wiki page.
- The preview metadata aggregate has no actual purpose in Phase&=
nbsp;1. It was introduced early for completeness. It is available for other=
uses at any time.
- The long-term intended uses of the metadata aggregates are documented in the wiki. (Thi=
s wiki page is considered to be a Phase 2 deliverable.)
As the Federation grows, and campuses introduce larger numbers of SPs in=
to InCommon metadata, the batch-oriented distribution model used today will=
become strained. While it's noteworthy that we are nowhere near real limit=
s on that mechanism, there has already been progress on both specifications=
and software to supplement the use of more granular files for metadata dis=
tribution without losing the notion of third-party certification that under=
lies the current model.
While there are certainly many ways one might change this model, the con=
crete proposal that has so far been implemented in limited fashion is based=
on a REST-like API over HTTP for requesting and receiving signed, per-enti=
ty metadata in a negotiated format (typically SAML's XML format).
RECOMMENDATION: Conduct a pilot study that explores the utility of this =
approach as an alternative to metadata aggregates, and evaluate current imp=
lementations of this model to discover problems or identify new requirement=
s.
- The pilot will be focused on use of the Metadata Query Protocol (Internet-Draft tracker, working area) and its SAML profile (Internet-Draft tracker).
- A call for participation will be made to both deployers and software pr=
ojects, the latter directed at projects that either have working code or ar=
e interested in developing it. The Shibboleth Project has already delivered=
production SP releases with per-entity metadata support, and is willing to=
work with the pilot study while developing the IdP capability, yet to be r=
eleased.
- The pilot may or may not make use of the existing InCommon metadata sig=
ning infrastructure and/or key.
- Overlaps or synergies with the samlbits.org conversation will be explored and leverage=
d if possible (but this subgoal shall not block completion of this pilot st=
udy).
RECOMMENDATION: Publish an InCommon Key Management Practice Statemen=
t that describes current practices surrounding the InCommon metadata s=
igning key.
- Conduct a community-driven review of InCommon key management practices.=
- The scope of this review is limited to the current metadata signing key=
. Other keys managed by InCommon Operations are explicitly out of scope.
- The InCommon Technical Advisory Committee (TAC) will appoint three (3) =
community members to review the key management practices employed by InComm=
on Operations. The review will result in a written report to be submitted t=
o the InCommon TAC. The report will describe the current key management pra=
ctices and recommend alternative practices if necessary.
- The InCommon TAC will review the report and advise InCommon Operations =
accordingly.
Ha=
rdware Security Modules: A Landscape Study
RECOMMENDATION: Conduct a study on the potential uses of Hardware Securi=
ty Modules (HSMs) to secure XML signing keys and other high-value secrets.<=
/p>
Possible use cases for HSMs include:
- The current metadata signing key=20
- On-premise deployment
- Impact: The current metadata production process that results in three (=
3) signed SAML metadata aggregates (production, preview, fallback)
- A new metadata signing key=20
- On-premise or cloud deployment
- Impact: A new post-process that consumes the InCommon production metada=
ta aggregate and produces a set of signed, per-entity metadata
- Impact: A new post-process that consumes the InCommon production metada=
ta aggregate and an alternate source of metadata (such as the eduGAIN metad=
ata aggregate) to produce a combined metadata aggregate
- A new IdP signing key=20
- On-premise or cloud deployment
- Impact: The production Multifactor IdP Proxy, an instance of simpleSAML=
php
SAMLbits.org
RECOMMENDATION: Deploy a server node that participates in the experiment=
al samlbits.org metadata content delivery network.
------=_Part_8066_1574167539.1711720909185--