Page History

...

• The use of long-lived, self-signed certificates in Federation metadata is strongly RECOMMENDED.
  • Certificates with lifetimes between 10 and 20 years of at least 10 years are RECOMMENDED to avoid unnecessary technically-imposed deadlines on key rollover.
  Service providers MUST include an encryption key in SP metadata.
  • The encryption key is used by IdPs to encrypt SAML V2.0 assertions transmitted to the SPCertificates SHOULD expire before 2038 to avoid the so-called Year 2038 problem.
• RSA keys with a minimum size of 2048 bits MUST be used for all new certificates introduced into Federation metadata.
  • New certificates with keys less than 2048 bits are not allowed in Federation metadata.All participants MUST upgrade to 2048-bit keys by December 2012.
  • Certificates with keys greater than 2048 bits are NOT RECOMMENDED .
  The decision to generate a new private key and submit a certificate with a new public key is subject to policy (or necessity in the event of a suspected key compromise). For example, some sites choose to rekey every 3 years but local policy will vary greatly
  • since such keys require relying parties to perform unnecessary computation.
• Expired certificates SHOULD NOT be introduced into Federation metadata. An expired certificate in metadata SHOULD be removed once a certificate migration process to a new certificate has been completed.
• If a private key is lost or stolen, a new private key MUST be configured immediately and the corresponding public key certificate MUST be introduced into metadata. Since there are no other known attacks on RSA 2048-bit keys, generating a new private key for any other purpose is NOT RECOMMENDED.
• Service providers MUST include an encryption key in SP metadata.
  • The encryption key is used by IdPs to encrypt SAML V2.0 assertions transmitted to the SP.
• InCommon does not validate Subject information in self-signed certificates because this information is irrelevant to the federated security contextfrom a security perspective. However, at its own discretion, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresented Subject information as decided by InCommon on a case-by-case basis. Generally, subject Subject information should express a somewhat reasonable relationship between the certificate and your the organization.

...