Requirements for SAML2 Metadata embedded certificates

Version 1.1, 2013-12-19

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

General security considerations and guidance

  • Key generation. The private key MUST be generated on a system where a strong random number generator (RNG) and sufficient entropy is available.
  • Protection of the private key. The private key MAY only be stored in unencrypted form on the system where it is going to be used. It MUST be protected with adequate file permissions. If stored on any other system, it MUST only be stored in encrypted form, i.e. protected with a strong passphrase.
  • Key reuse. Each newly signed certificate MUST NOT reuse any existing key pair.
  • Types of certificates. Certificates embedded in FEDURUS SAML2 Metadata MAY have one of two formats: self-signed or signed by a well-known CA. Depending on their type, different technical requirements apply.

Technical requirements for self-signed certificates

A self-signed certificate is a certificate where the signature is created with the private key associated with the certificate's public key.

  • Distinguished name.
    • Required and permitted is only: commonName (CN, OID 2.5.4.3). The CN MUST include the fully qualified domain name (FQDN) from the entityID of the SP/IdP. The FQDN MUST meet the naming requirements specified in RFCs 952 and 1123; in particular, it MUST NOT include the DNS wildcard ('*') character. The length of the commonName attribute is limited to 64 characters, as specified in RFC 5280.
    • Encoding of the subject DN: the commonName MUST be encoded either with the PrintableString or the UTF8String encoding. Whenever possible, the PrintableString SHOULD be used.
  • Serial number. It is RECOMMENDED to use a large random integer for the serial number; however, its size MUST NOT exceed 20 octets. Serial numbers MUST NOT be reused for a particular SP/IdP.
  • Validity. The validity (delta between notBefore and notAfter dates) MUST NOT exceed 3 years. The notBefore date MUST reflect the time when the key pair was generated (specifically, it MUST NOT be set to a future date).
  • Key size. The key MUST be an RSA key with a size of 2048 bits.
  • Signature Algorithm. SHA1 with RSA encryption MUST be used (OID 1.2.840.113549.1.1.5).
  • Certificate Extensions. Only the following Extensions SHALL be set
    • a subjectAltName extension (2.5.29.17) with two entries:
      • one of type dNSName, with its value set to the host part (FQDN) of the SP/IdP's entityID
      • one of type uniformResourceIdentifier, with its value set to the entityID of the SP/IdP (only URLs permitted, no URNs)
    • subject key identifier (2.5.29.14), with its value set to the SHA1 hash of the BIT STRING subjectPublicKey

For an example of a self-signed certificate, see appendix A.

Technical requirements for certificates signed by a well-known CA

  • Distinguished name. The subject DN MUST include the official legal name of the organization in the organizationName RDN (O, OID 2.5.4.10). The organization's name MUST have been vetted by the CA according to the industry practices for certificates of the "organizationally validated" category (or better). Specifically, domain validated (DV) certificates MUST NOT be used. The subject DN MUST include a CN RDN (OID 2.5.4.3) set to the host part (FQDN) of the SP/IdP's entityID, unless the certificate includes a subjectAltName extension with a dNSName entry for that same FQDN. The FQDN in both the CN and the subjectAltName extension MUST meet the naming requirements specified in RFCs 952 and 1123; in particular, it MUST NOT include the DNS wildcard ('*') character.
  • Validity. The validity (delta between notBefore and notAfter dates) MUST NOT exceed 3 years.
  • Key size. The key MUST be an RSA key with a size of 2048 bits.

Change history

Version 1.1: maximum validity increased to 39 months, to align with current industry practices specified in the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.