Date: Fri, 29 Mar 2024 01:30:41 +0000 (UTC) Message-ID: <1899238874.7359.1711675841550@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7358_498758863.1711675841549" ------=_Part_7358_498758863.1711675841549 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Public keys are bound to X.509 certificates in metadata. These keys are used f= or message-level signing and encryption, and for back channel exchanges ove= r TLS.
Use of TLS Certificates
In addition to message-level signing and encryption, X.509 certificates =
in metadata are used for TLS back-channel SOAP exchanges, typically on a no=
nstandard port such as 8443. These certificates are not th=
e same as and have nothing to do with TLS server certificates used for browser-facing tran=
sactions over port 443. The latter type of TLS certificates are
Definition. A role descriptor is a metadata el= ement whose type is based on the SAML md:RoleDescriptorType type.
Examples of role descriptors familiar to site administrators include <md:AttributeAuthorityDescr=
iptor>
, <md:SPSSODescriptor>
, and so forth.
We will use the following standard key usage terminology:
A single key may be used for multiple purposes as we shall see.
Recall that there are three types of key descriptors in SAML metadata:= p>
<md:KeyDescriptor use=3D"signing">
<md:KeyDescriptor use=3D"encryption">
<md:KeyDescriptor>
A type 1 key is used for both signing and TLS. That is, the key is = used to provide authenticity and integrity but not necessarily confidential= ity.
The Actual Use of a Type 1 Key
When used for signing, a type 1 key in metadata is actually a verif= ication key, not a signing key. The private signing key is held securely by= the signing entity.
A type 2 key is used for encryption only, that is, the key is used = to provide confidentiality.
Since the use
XML attribute is missing on a type 3 key=
descriptor, such a key may be used for all of the above, that is, for sign=
ing, TLS, and encryption.
Any <md:KeyDescriptor>
element in metadata that has e=
ither a use=3D"signing"
attribute or no use
attri=
bute whatsoever is intended for use with TLS.
In the InCommon Federation, IdP metadata typically contains two role des=
criptors: an <md:IDPSSODescriptor>
element and an =
<md:AttributeAuthorityDescriptor>
element. Normally, each role=
descriptor contains a single type 1 key descriptor (with use=3D=
"signing"
XML attribute). Although not required, the two key descrip=
tors almost always contain the very same key.
For an IdP, certificate migration= is the controlled phasing in of a new type 1 key descriptor, no more = or less.
There is just one role descriptor for SPs in Federation metadata, namely=
, the <md:SPSSODescriptor>
element. Under normal circums=
tances, this role descriptor contains a single type 3 key descriptor (=
with no use
XML attribute).
For an SP, certificate migration i= s more complicated than for an IdP. This is because two decryption keys nee= d to be configured in the SP software at one time.
Most SAML V2.0 IdPs are configured to encrypt assertions sent to th= e SP. It's important, therefore, that an encryption key always be available= to a SAML V2.0 IdP, and so SP metadata must always contain an encrypt= ion key.
If an SP supports SAML V2.0, there MUST be at least one enc=
ryption key in metadata at all times; that is, there MUST be at le=
ast one <md:KeyDescriptor>
element with no use XML attribute in Federation metadata.
The only exception to the previous rule is an SP that supports SAML = ;V1.1 only. Since such SP deployments are declining rapidl= y, and since it doesn't hurt to have an unused encryption key in metadata, = it is RECOMMENDED that all SPs follow the above rule.
To avoid complications with non-conforming IdPs, it is further RECOMMEND=
ED that there be exactly one encryption key in SP metadata=
at all times. To facilitate this practice, the administrative interface pe=
rmits an existing certificate in SP metadata to be modified such that the p=
arent key descriptor has an use=3D"signing"
XML attribute if a=
nd only if there is another key descriptor with no use
XML att=
ribute. See the SP Certif=
icate Migration topic for details.