Date: Thu, 28 Mar 2024 19:07:49 +0000 (UTC) Message-ID: <1925444619.6835.1711652869145@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6834_446331827.1711652869143" ------=_Part_6834_446331827.1711652869143 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Version: 7 ("Gruesome Gorilla")
Editor: Leif Johansson SAML metadata [saml-metadata-2.0-os.pdf] has proven very useful in large=
-scale heterogeneous SAML deployments, providing a basis for shared trust a=
nd configuration management. This document proposes a profile for man=
agement of SAML metadata to extend its utility. Benefits of deploying=
this profile are: A metadata aggregator is an entity which collects, proofs and publishes =
metadata from an alternate location than one associated with any one entity=
. A metadata aggregate is a signed SAML metadata document containing an Ent=
itiesDescriptor element. A multi-party federation (or trust community) will maintain multiple met=
adata aggregates, for instance an aggregate of all IdPs in a federation sig=
ned by a high-assurance key (eg associated with a small-scale Ad-Hoc PKI). =
Such an aggregate could be used to support IdP discovery. In addition to publishing a metadata aggregate of all the entities a fed=
eration may choose to publish aggregates of SPs based on minimal required l=
evel of assurance (of the metadata management itself), or aggregates of IdP=
based on the minimally asserted level of assurance of the constituent iden=
tities. Entity identifiers [TBD] MUST be valid URLs using either the http or htt=
ps schemes. The Name attribute of an EntitiesDescriptor element SHOULD be a=
valid URL using either the http or https schemes. In the case of an https:-scheme URL, the metadata consumer MUST ignore a=
ny failures detected while validating the certificate chain of the TLS conn=
ection. Trust in metadata is conveyed using signatures on the metadata rath=
er than through the transport by which the metadata was retrieved. Any metadata role supporting TLS or digital signatures MUST contain at l=
east one applicable KeyDescriptor containing either a certificate or public=
key. A relying party MUST accept TLS authentication or digital signing usi=
ng any of those keys. If a certificate is present, its contents other than =
the public key MUST be ignored by the metadata consumer. Any metadata role supporting encryption MUST contain at least one applic=
able KeyDescriptor containing one or more public keys, either in the form o=
f RSAKeyValue elements or contained within X.509 certificates included as X=
509Data elements. In the case of X.509 certificates, the metadata con=
sumer ignores all components of the certificate other than the public key.<=
/p>
KeyName elements MAY be included to help in identifying keys. [NOTE - is=
n't this a repeat of what SAMLMeta already says?] Entities (eg an SP or IdP) SHOULD support generation of self-signed cert=
ificates (or keys) unless another set of certificates or keys was explicitl=
y provided. Metadata producers SHOULD allow the choice of a single key or s=
eparate keys for singing and encryption to be configured. The metadata MUST specify either a cacheTTL or expiry time and this cach=
e policy MUST be respected by consumers of the metadata. If the metadata is=
signed the signing key SHOULD be signed by a metadata signing CA. In this profile there are two ways to publish metadata: per entity trust=
ed publishing or aggregator-based publishing. Similarly there are two ways =
to establish trust in the metadata signatures: based on metadata signing ce=
rtificates (cf below) together with a traditional PKI Both forms of publishing can be combined with both forms of trust establ=
ishment. All entities mustsupport per-entity publishing. All metadata consumers m=
ust support both forms of publishing and signature trust establishment. All metadata MUST conform to the requirements in section 1. A metadata c=
onsumer SHOULD cache any downloaded metadata and retain the cached metadata=
in accordance with the cache policy expressed in the metadata cacheTTL and=
or expiry time. An HTTP GET-request to the EntityID URL MUST return SAML metadata [saml-=
metadata-2.0-os.pdf] for the entity encoded as the <TBD> mime-type.=
p>
An HTTP GET-request to the URL in the Name attribute of the EntitiesDesc=
riptor element MUST return SAML metadata [saml-metadata-2.0-os.pdf] for the=
entity encoded as the <TBD> mime-type. A metadata consumer MUST establish trust in the metadata by validating t=
he signature on the metadata, regardless of how it was obtained (eg as an a=
ggregate or as metadata for a single entity). Care should be taken not to i=
ntroduce unnecessary complication into the metadata signature validation pr=
ocess. No requirements are placed on the SubjectDN of certificates by this spec=
ification and metadata consumers MUST NOT rely on any part of the SubjectDN=
of the certificate which signed the metadata. A metadata signing certificate is any certificate which supports XML dig=
ital signatures and which contains a SubjectAltName extension containing th=
e names of the entities or collections for which the key is a trusted signe=
r. A metadata signing CA is any CA which issues metadata signing certificat=
es. If the metadata contains a single entity then the signature MUST NOT be =
trusted by the metadata consumer unless the SubjectAltName extension contai=
ns a uniformResourceLocator value which exactly matches the EntityID. If the metadata contains a collection (eg a EntitiesDescriptor element) =
then the signature MUST NOT be trusted by the metadata consumer unless the =
SubectAltName extension contains a uniformResourceLocator value which exact=
ly matches the Name attribute of the EntitiesDescriptor element. In both cases SubjectAltName values of any other type than uniformResour=
ceIdentifier (URL) MUST be silently ignored. To ensure PKIX interoperability metadata signature certificates SHOULD c=
ontain a critical KeyUsage extension with the digitalSignature bit set. Con=
sumers of metadata signatures MUST NOT check or enforce this bit. A metadata consumer MUST allow a certificates to be explicitly trusted t=
o sign metdata for a selecte EntityID or EntitiesDescriptor Name URL. A met=
adata consumer SHOULD allow multiple certificates to be simultaneously trus=
ted for a single entity/aggregate in order to support key rollover. If the metadata contains a signature using any of the trusted certificat=
es then the metadata consumer MUST trust the metadata regardless of whether=
the certificate is a metadata signing certificate in the sense of 2.2.1 or=
not. In this case the metadata consumer MUST validate the expiration time of =
the certificate but MUST NOT attempt to validate any certificate chain whic=
h may be associated with the certificate.
Contributors:=
strong> Scott Cantor, Ian Young, RL "Bob" Morgan, Nate Klingenstein=
p>
0. I=
ntroduction
1. Metadata contents requirements
2. Metadata management requirements
or using out-of-band certificates used as a form of pre-shared keys for si=
gnature validation.2.1 Metadata Publishing
2.1.1 Per Entity Publishing
2.1.2 Aggregated Publishing
2.=
2 Metadata Trust
2.2.1 PKIX-based trust using Metadata sig=
ning certificates
2.2.2 Out-of-band Pre-Shared Certificate Trust