Information security requirements

This chapter describes the requirements that apply to the information security measures that are implemented.

Digital signature — To guarantee authenticity, integrity and non-repudiation, each message described MUST be provided with a digital signature from the message sender. The message recipient MUST validate all of the digital signatures in the message before processing it. The recipient MUST check that the message is signed with a valid digital signature that envelopes the whole message with Enveloped Signature Transform. The recipient MUST NOT process the message if it contains parts that are not signed with a valid digital signature. The following requirements apply to generating digital signatures: The digital signature is embedded in the message content with Enveloped Signature Transform http://www.w3.org/2000/09/xmldsig#enveloped-signature . Canonicalization MUST be carried out according to the exclusive c14n method without comments, as identified by 'http://www.w3.org/2001/10/xml-exc-c14n#' (see http://www.w3.org/TR/xml-exc-c14n/ ) Digests MUST be calculated with the SHA256 algorithm. The SignatureValue MUST be calculated with the RSA-SHA256 algorithm. The sender MUST sign messages with a PKIoverheid certificate (see for requirements PKIoverheid) with a key length of at least 2048 bits. The (extended) key usage of the used certificate MUST allow use for signing. In case of signing metadata, the <Signature> element MUST contain only an <X509Data> element with an <X509Certificate> element. In all other cases, The signature MAY contain a <KeyInfo> element that contains a <KeyName>. The <KeyName> MUST match the <KeyName> stated in the metadata of the sender for the respective role. The signature MUST NOT contain other elements (such as <X509Data>). If a <KeyInfo> element is not included in the message, the metadata MUST contain at least one (1) valid certificate against which the message can be validated. If the metadata contains more than one certificate, the participant MUST validate the message against each valid certificate. The participant MAY agree with its service consumers to limit the period in which the metadata contains more than one certificate. This enables the high utilization of the system to be controlled. The Reference MUST refer to the signed element via an ID attribute in the local document, as per the signature profile of SAML2.0 core (§5.4) and SAML 2.0 Metadata (§3.1).

PKIoverheid

Encryption

SAML encryption — Encryption in combination with SAML is achieved via XML-encryption. This paragraph provides an explanation of encrypted elements as well as elements encrypted to multiple recipients.

End-to-end encryption — End-to-end encryption is applied in Elektronische Toegangsdiensten to protect privacy of anyone (acting users) or organisations (especially "single person businesses" or "eenmanszaak"). The BSN is one of the main privacy concerns, following from Dutch law, but other personally identifiable information must also be protected. Using end-to-end encryption as described on this page avoids an Herkenningsmakelaar (HM) becoming an unintended hotspot for information on service usage.

Secure cookies

Secure connection — The network wants to promote the use of strong cipher suites with minimum discomfort for end-users. Those roles that are in direct contact with their customers (e.g. a HM with it's DV's and an AD/MR with its users) are allowed to tighten security based on their risk analysis. All communication between peers in these specifications is based on HTTP. All communication MUST be secured using Transport Layer Security, TLS. As a result, all communication MUST be transported over HTTPS (https://tools.ietf.org/html/rfc2818). For HTTPS and TLS, any implementation MUST take the recommendations in BCP195 (https://tools.ietf.org/html/rfc7525) and the latest version of the NCSC-security guidelines for TLS-usage (currently https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1/ICT-beveiligingsrichtlijnen+voor+Transport+Layer+Security+v2.1.pdf). The following requirements are applicable for this specification in relation to the NCSC guidelines: For back-channel communication, the guidelines categorized as "good" MUST be applied. For front-channel communication, the guidelines for "good" MUST be applied and the guidelines for "sufficient" MAY be applied, depending on target audience and support requirements. Guidelines categorized as "insufficient" MUST NOT be applied and those categorized as "phase out" SHOULD NOT be used. As HTTP itself is stateless, implementations are free to choose a method of maintaining state or sessions with a User-agent when applicable. The following applies for any HTTP state/session mechanism: HTTP servers MUST ensure session and state information is secured and User-agents are properly instructed with relevant security settings (e.g. proper cookie lifetime, Secure setting for cookies, CORS headers and similar). Any HTTP session or state tracking mechanisms MUST be implemented using current best practices to avoid session hijacking and other attacks. For more information, see for instance https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md .

Synchronize system clocks

DNSSEC