Remove interoperability clauses from Annex K

        - iv) the cryptographic properties of the cryptographic mechanism are known;

        - v) no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;

        - vi) the cryptographic mechanism is required for a specific set of product functions;

3. Interoperability-based: the cryptographic mechanism is listed in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms) as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).

> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.

> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context. An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.

> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.

> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.

### K.1.2 Assessment of product cryptographic configuration

The assessment in [clause K.1.2](#k12-assessment-of-product-cryptographic-configuration) verifies the cryptographic mechanisms used in the product’s default configuration against [clause K.1.1](#k11-requirement).

For ACM-extended cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is either listed in [clause K.3.2](#k32-list-of-acm-extended-cryptographic-mechanisms) or fulfils the criteria specified in [clause K.1.1](#k11-requirement) item 2.b. For interoperability-based cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is listed in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms). The assessment also verifies that the product uses the cryptographic mechanism in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.

For ACM-extended cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is either listed in [clause K.3.2](#k32-list-of-acm-extended-cryptographic-mechanisms) or fulfils the criteria specified in [clause K.1.1](#k11-requirement) item 2.b. The assessment also verifies that the product uses the cryptographic mechanism in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.

#### K.1.2.2 Assessment of ACM-listed cryptographic mechanisms

* The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with [clause K.1.1](#k11-requirement) item 2.

* The verdict FAIL shall be assigned otherwise.

#### K.1.2.4 Assessment of interoperability-based cryptographic mechanisms

##### K.1.2.4.1 Assessment objective

The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with [clause K.1.1](#k11-requirement) item 3. and used in the product’s default configuration are listed as interoperability-based cryptographic mechanisms in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms) and are used in accordance with the characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms).

##### K.1.2.4.2 Assessment preparation

* Preconditions for the assessment: The product’s default configuration shall be used for the assessment.

* The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under [clause K.1.1](#k11-requirement) item 3., including the related product function, use case where applicable, relevant parameters where applicable, the external specification or external requirement requiring its use, and the relevant entry in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms).

##### K.1.2.4.3 Assessment activities

The assessment shall include verification that:

- a) each cryptographic mechanism claimed under [clause K.1.1](#k11-requirement) item 3\. is listed in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms) as an interoperability-based cryptographic mechanism;

- b) the cryptographic mechanism used by the product corresponds to the cryptographic mechanism listed in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms);

- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms);

- d) the external specification or external requirement requiring the use of the cryptographic mechanism corresponds to the external specification or external requirement specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms);

- e) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms), where applicable;

- f) the conditions or limitations specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms) for the use of the cryptographic mechanism are reflected in the product’s default configuration;

- g) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.

##### K.1.2.4.4 Assessment evidence

The assessment evidence shall include, as applicable:

- a) description of the product’s default configuration;

- b) list of cryptographic mechanisms claimed under [clause K.1.1](#k11-requirement) item 3.;

- c) reference to the relevant entry in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms);

- d) identification of the related product function using the cryptographic mechanism and the use case where applicable;

- e) identification of the external specification or external requirement requiring use of the cryptographic mechanism;

- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;

- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms).

##### K.1.2.4.5 Assessment verdict

* The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with [clause K.1.1](#k11-requirement) item 3.

* The verdict FAIL shall be assigned otherwise.

> NOTE 1: The assessment of the external specification or external requirement itself is outside the scope of this assessment case. The assessment verifies that the external specification or external requirement is identified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms) and that the cryptographic mechanism is used by the product for the related product function.

> NOTE 2: Documentation review is a minimum assessment activity under the present annex. Functional and/or resistance testing activities can be added by vertical standards where relevant for the product category, product function or cryptographic mechanism.

## K.2 Crypto agility

### K.2.1 Requirement

## K.4 Interoperability-based cryptographic mechanisms

### K.4.0 Guidance for rapporteurs \- Selection criteria and list of interoperability-based cryptographic mechanisms

  Editor’s note for rapporteurs: This clause provides guidance for selecting interoperability-based cryptographic mechanisms when preparing a vertical standard. It is not intended to remain as normative content in the published vertical standard. This clause shall be removed before publication, after the interoperability-based cryptographic mechanisms, where any, have been identified in clause K.4.2.

When preparing the list of interoperability-based cryptographic mechanisms in clause K.4.2, the following criteria guide the selection of candidate interoperability-based cryptographic mechanisms. The criteria are cumulative: a cryptographic mechanism is to be included in clause K.4.2 only where all applicable criteria below are fulfilled:

1. the cryptographic mechanism is not claimed as ACM-extended under clause K.1.1 item 2 and is either not listed in the ACM catalogue or is subject to an ACM deprecation date, expiry date, migration condition, usage limitation, or other ACM indication that prevents its use as a state-of-the-art cryptographic mechanism for the relevant product function;

2. the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including \[list of organisations\];

3. the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;

4. the cryptographic mechanism is required for a specific set of product functions to comply with a well-defined external specification or external requirement;

5. the use of the cryptographic mechanism is subject to conditions or limitations that prevent it from being used beyond the identified interoperability need, where applicable.

    > NOTE 1: For the treatment of cryptographic protocols and their underlying cryptographic primitives, modes of operation, constructions, parameter sets and cipher suites, see clause K.1.1 and its notes.

    > NOTE 2: Cryptographic mechanisms listed in this clause are used to support the application of clause K.1.1 item 3.

    > NOTE 3: Inclusion of a cryptographic mechanism in this clause does not classify that mechanism as state-of-the-art cryptography.

    > NOTE 4: In this clause, an external requirement can be a regulatory requirement, a mandatory public-sector requirement, an operational constraint, a technical interoperability constraint, or a platform compatibility requirement requiring the use of a specific cryptographic mechanism for interoperability with an identified system, platform or operational context.

    > NOTE 5: For interoperability-based cryptographic mechanisms, specifying conditions or limitations is necessary to support the secure and constrained use of mechanisms that are not classified as state-of-the-art cryptography and to prevent such mechanisms from becoming the de facto default where a state-of-the-art mechanism is applicable. Such conditions or limitations include, for instance, permitted or excluded use cases, specific configurations, identification of the external system, external specification or external requirement requiring use of the mechanism, preference for ACM-listed or ACM-extended mechanisms during negotiation where applicable, compensating measures, migration details, warning or logging requirements, or lifecycle limitations. If such conditions or limitations cannot be applied for technical reasons specific to the product category, the reason is to be documented in the vertical standard.

### K.4.1 Requirement

Where the product’s default configuration uses interoperability-based cryptographic mechanisms, these mechanisms shall be selected from the interoperability-based cryptographic mechanisms listed in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms) for the specified product functions and external specifications or external requirements and shall be used in accordance with the conditions or limitations specified in [clause K.4.2](#k42-list-of-interoperability-based-cryptographic-mechanisms).

### K.4.2 List of interoperability-based cryptographic mechanisms

Table K.2 lists the interoperability-based cryptographic mechanisms specified by the present document.

**Table K.2: Interoperability-based cryptographic mechanisms**

| Interoperability-based cryptographic mechanism | Type of cryptographic mechanism                                                                                               | Characteristics / parameters                                              | Related product function(s) / use case(s), where applicable                  | External specification(s) or external requirement(s)                                                                                                                                                                            | Interoperability justification                       | Conditions or limitations, where applicable                                                                                                                                                     |

|:-----------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------|:-----------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

| \<mechanism name\>                             | \<Algorithm / Primitive / Scheme / Protocol / Protocol profile / Cipher suite / Mode / Construction / Parameter set / Other\> | \<key length, mode, profile, cipher suite, parameter set, version, etc.\> | \<product function, interface, protocol context, operational context, etc.\> | \<external specification, regulatory requirement, mandatory public-sector requirement, operational constraint requiring use of the mechanism, technical interoperability constraint, platform compatibility requirement, etc.\> | \<why the mechanism is needed for interoperability\> | \<constraints, permitted use, excluded use, negotiation preference, external system or requirement, compensating measures, migration expectation, warning/logging, lifecycle limitation, etc.\> |

### K.4.3 Assessment

Compliance with the requirement in [clause K.4.1](#k41-requirement) is assessed in [clause K.1.2.3](#k123-assessment-of-interoperability-based-cryptographic-mechanisms).

 > NOTE: The assessment of the external specifications or external requirements themselves is outside the scope of this assessment. Their relevance is deemed confirmed by their inclusion in the present document.

There are no interoperability-based cryptographic mechanisms specified as permissible for use as a default setting in VPNs.