ISO 15118-20:2022/AMD1:2026

• Status: Published
• Publication Date: 12-Jul-2026
• ICS: 43.120 - Electric road vehicles
• Technical Committee: TC 69 - Electrical power/energy transfer systems for electrically propelled road vehicles and industrial trucks
• Drafting Committee: JWG 1 - TC 69/JWG 1
• Current Stage: PPUB - Publication issued
• Start Date: 24-Jul-2026
• Completion Date: 28-Sep-2026

• Amends: ISO 15118-20:2022 - Road vehicles - Vehicle to grid communication interface - Part 20: Network and application protocol requirements
• Effective Date: 01-Nov-2024

ISO 15118-20:2022/AMD1:2026 is Amendment 1 to ISO 15118-20, published through IEC and ISO cooperation. It updates the vehicle to grid communication interface for road vehicles by adding AC DER service, MCS service, and a revised security concept. The amendment is written for implementers and validators of EVCC and SECC behavior, certificate handling, and service negotiation.

What does ISO 15118-20:2022/AMD1:2026 specify?

ISO 15118-20:2022/AMD1:2026 specifies changes to Part 20 of the vehicle to grid communication interface. The amendment focuses on three areas: MCS communication, AC DER communication, and certificate and security handling.

The document is organized as an amendment to the first edition of ISO 15118-20. It updates Clause 2 on normative references, Clause 3 on terms, Clause 4 on abbreviations, Clause 5.2 on requirement numbering, and several clauses in the main body that control service discovery, TLS certificate handling, message selection, and synchronization. It also revises Annexes B, C, H, K, L, and M.

Annex	What it covers
Annex B	Certificate profiles, certificate validation, extensions, OCSP, cross-certification, and TPM-related certificate rules
Annex C	Identifier formats and lengths for EVSEID, SECCID, and EVCCID
Annex H	Certificate structure examples, cross-certification, and trust-anchor use
Annex K	MCS messages, timing, service selection, and error handling
Annex L	AC DER IEC messages, service parameters, and grid-code related behavior
Annex M	AC DER SAE messages, service parameters, and grid-code related behavior

What are the key requirements of ISO 15118-20:2022/AMD1:2026?

ISO 15118-20:2022/AMD1:2026 adds new protocol branches and tightens the security model for V2G communication. The most important changes are the service-specific requirements for MCS and AC DER, and the certificate and TLS rules that support them.

Service identification and requirement structure

Clause 5.2 replaces the requirement structure with a numbered format based on unique [V2G20-XXXX] identifiers. ISO 15118-20:2022/AMD1:2026 also marks AC DER-only requirements with [DER] and MCS-only requirements with [MCS]. In practice, this makes implementation tracking and test-case mapping much easier.

Clause 8.2.1 adds the namespaces for AC DER IEC and AC DER SAE to supportedAppProtocolReq. When an EVCC intends to use one of those services in a session, it must advertise the matching namespace and version. That is the entry point for selecting the right service branch later in the transaction.

Clause 8.4.3.2 and the new subclauses for MCS and AC DER connect service selection to the annexes. Once MCS, MCS_BPT, AC_DER_IEC, or AC_DER_SAE is selected and confirmed, the matching annex requirements apply, and the base AC requirements still apply unless a service-specific rule overrides them.

MCS behavior and ISO 15118-10 use

Clause 7.4 adds pause handling for MCS and MCS_BPT. If the EVCC sends SessionStopReq with ChargingSession set to Pause, both sides move into the data-link pause behavior and follow the sleep and wake-up rules from ISO 15118-10:2025. That matters for implementations that need a controlled pause rather than a full session end.

Clause 7.5 and Clause 7.10.1 make ISO 15118-10 the additional data-link layer reference for MCS, including 10BASE-T1S communication. The amendment also sets the SDP payload types and discovery behavior for MCS communication. It further states that backward compatibility with ISO 15118-2 shall not be implemented for EVCC or SECC when MCS is used.

Annex K then defines the MCS message set, timing, sequencing, and error handling. It ties MCS and MCS_BPT to the same V2G session flow concepts used elsewhere in the standard, but with MCS-specific parameters and synchronization.

AC DER service behavior

Clause 8.2.1 and Clause 8.4.3.2 add two AC DER service paths: AC_DER_IEC and AC_DER_SAE. If either service is selected, the EVCC and SECC must implement the service parameters defined in Annex L or Annex M, respectively. For AC_DER_IEC, the amendment also says the AC service requirements still apply unless stated otherwise.

Annex L covers AC DER IEC functions such as voltage and frequency support, active power support, reactive power support, and scheduled control. Annex M covers AC DER SAE behavior using the SAE J3072-based model. In practice, this means the EV and the EVSE need to exchange grid-support settings, operating-mode information, and limit values, not just charging power.

Certificate handling and security concept

Clause 7.3.2 and Clause 7.7.3.3 update how the EVCC and SECC use the "certificate_authorities" extension, certificate chains, and OCSP responses. The EVCC only advertises available roots when it has them, and it omits the extension in CPM4PE. The SECC then chooses a certificate chain that matches the roots indicated by the EVCC, or sends its own chain when no roots were provided.

Clause 7.3.2.1 and related security requirements tighten OCSP signer rules. The OCSP signer certificate for SECC, contract, vehicle, and OEM provisioning status checking must chain to the appropriate root CA or to a V2G root CA acceptable to the relying party. That matters because the amendment ties certificate-status checking to the certificate hierarchy instead of treating OCSP as a separate trust path.

Annex B adds certificate-profile rules that certificate implementers need to follow, including required extensions that relying parties must be able to process. It also sets precedence rules when document requirements and external PKI standards overlap. Annex H gives concrete chain and cross-certification examples so that implementers can see how the certificate paths are expected to work.

TPM 2.0, Curve448, and contract key handling

Clause 7.9.2.5.2 to 7.9.2.5.4 extend the certificate-installation flow to 456-bit keys, Curve448, and X448. The amendment defines how the contract certificate private key is encrypted and decrypted, how the IV, ciphertext, and tag are placed in the transport field, and how the EVCC validates that the decrypted private key matches the certificate.

The TPM 2.0 path is also expanded. The amendment adds storage-key and OEM-provisioning key profiles, direct import of the encrypted contract key into the TPM, and rules for using the OEM provisioning certificate extension that carries the Contract Transport Public Key. For integrators, this is the part that connects the V2G security model to actual TPM provisioning and key usage on the EVCC side.

What terms does ISO 15118-20:2022/AMD1:2026 define?

ISO 15118-20:2022/AMD1:2026 adds or clarifies several control and grid terms that matter in AC DER and MCS implementations.

• charge enable state (CE state) - The state defined by the charge enable function in IEC 61851-23-3.
• megawatt charging system (MCS) - A charging system according to IEC 61851-23-3.
• area EPS - An area electric power system as defined in IEEE 1547.
• cease to energize - Stopping active power delivery and limiting reactive power exchange under steady-state and transient conditions.
• distributed energy resource (DER) - A source of electric power not directly connected to a bulk power system.
• enter service - The parameter set used to start energizing or re-energizing the electric power system.
• permit service - The setting that indicates whether a DER may enter or remain in service.
• ride-through - The ability to withstand defined voltage or frequency disturbances and continue operating as specified.
• trip - Inhibition of immediate return to service.

Who uses ISO 15118-20:2022/AMD1:2026?

ISO 15118-20:2022/AMD1:2026 is used by EVCC and SECC implementers who need to support MCS, AC DER, and the updated security flow. It is also relevant to OEMs, eMSPs, charge point operators, and PKI engineers.

Test laboratories and certification teams use it to check message selection, certificate chains, OCSP behavior, TPM-based key handling, and service-specific timing. Grid-integration engineers and buyers use it when they need V2G communication that fits MCS signaling or DER control behavior.

What changed in ISO 15118-20:2022/AMD1:2026 from the previous edition?

ISO 15118-20:2022/AMD1:2026 amends the first edition of ISO 15118-20. The amendment introduces these main changes:

• Adds AC DER IEC and AC DER SAE services, including new namespaces, message sets, and annexes L and M.
• Adds MCS and MCS_BPT support, including Annex K and the use of ISO 15118-10 for relevant communication behavior.
• Updates the security concept for certificate chain selection, OCSP, certificate extensions, and certificate-authorities handling.
• Adds TPM 2.0 and Curve448/X448 handling for contract key transport and import.
• Revises requirement numbering, abbreviations, figures, and several tables.
• Updates identifier rules in Annex C and certificate-profile rules in Annex B.

Which standards are used with ISO 15118-20:2022/AMD1:2026?

ISO 15118-20:2022/AMD1:2026 adds two normative references in Clause 2:

• ISO 15118-10:2025 - Provides the physical layer and data link layer requirements for single-pair Ethernet. The amendment uses it for MCS, including 10BASE-T1S behavior and sleep and wake-up handling.
• IEC 61851-23-3:2025 - Defines the DC EV supply equipment context for Megawatt charging systems. The amendment uses it for MCS definitions and charge enable behavior.

The amendment also uses several companion standards and external specifications in security and DER clauses, including IETF RFC 5280, RFC 6960, RFC 8032, RFC 8446, RFC 7748, NIST FIPS PUB 202, NIST SP 800-38D, ISO/IEC 11889-1:2015, ITU-T X.509, and IEEE 1547.

What does the ISO 15118-20:2022/AMD1:2026 document contain?

ISO 15118-20:2022/AMD1:2026 contains revised protocol overview material, updated figures, new service-specific clauses, and expanded security guidance. It replaces and updates Figure 2, Table 14, Table 17, Table 19, and multiple certificate-profile tables in Annex B.

It also contains detailed message and data-type definitions for MCS, AC DER IEC, and AC DER SAE, plus timing and sequence rules for those services. Annex H adds cross-certification examples and trust-anchor explanations that help implementers build usable certificate chains.

The document includes procedures for certificate installation, OCSP handling, certificate-chain selection, and TPM 2.0 direct import of encrypted contract keys. For readers doing implementation or conformance work, those annexes provide the structures, message models, and certificate profiles needed to design, test, and validate a compliant V2G system.

International
Standard
ISO 15118-20
First edition
Road vehicles — Vehicle to grid
2022-04
communication interface —
AMENDMENT 1
Part 20:
2026-07
2nd generation network layer and
application layer requirements
AMENDMENT 1: AC DER service, MCS
service, and improved security concept
Véhicules routiers — Interface de communication entre véhicule
et réseau électrique —
Partie 20: Exigences des couches réseau et application de 2ème
génération
AMENDEMENT 1: Service RED en CA, service MCS et concept de
sécurité amélioré
Reference number
ISO 15118-20:2022/Amd.1:2026(en) © ISO 2026

ISO 15118-20:2022/Amd.1:2026(en)
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
ISO 15118-20:2022/Amd.1:2026(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared jointly by Technical Committee ISO/TC 22, Road vehicles, Subcommittee
SC 31, Data communication, Technical Committee IEC/TC 69, Electrical power/energy transfer systems for
electrically propelled road vehicles and industrial trucks, in collaboration with the European Committee for
Standardization (CEN) Technical Committee CEN/TC 301, Road vehicles, in accordance with the Agreement
on technical cooperation between ISO and CEN (Vienna Agreement).
A list of all parts in the ISO 15118 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iii
ISO 15118-20:2022/Amd.1:2026(en)
Road vehicles — Vehicle to grid communication interface —
Part 20:
2nd generation network layer and application layer
requirements
AMENDMENT 1: AC DER service, MCS service, and improved
security concept
Clause 2, Normative references
Add the following references at the end of the clause:
ISO 15118-10:2025, Road vehicles — Vehicle to grid communication interface — Part 10: Physical layer and data
link layer requirements for single-pair Ethernet
IEC 61851-23-3:2025, Electric vehicle conductive charging system - Part 23-3: DC electric vehicle supply
equipment for Megawatt charging systems

Clause 3, Terms and definitions
Add the following terms and definitions at the end of the clause:

3.72
charge enable state
CE state
state according to the charge enable function defined in IEC 61851-23-3
3.73
megawatt charging system
MCS
charging system according to IEC 61851-23-3
3.74
area EPS
area electric power system as defined in IEEE 1547
3.75
cease to energize
cessation of active power delivery under steady-state and transient conditions and limitation of reactive
power exchange
Note 1 to entry: After the cessation is over, the EV is allowed to return immediately into service without following the
enter service rules.
ISO 15118-20:2022/Amd.1:2026(en)
3.76
distributed energy resource
DER
source of electric power that is not directly connected to a bulk power system
EXAMPLE Generators and energy storage technologies capable of exporting active power to the electrical grid.
Note 1 to entry: An interconnection system or a supplemental DER device that is necessary for compliance with this
document is part of a DER.
3.77
enter service
set of parameters that defines how to start energizing or re-energizing the electric power system
Note 1 to entry: If voltage and frequency values are not within the desired range, the distributed energy resource (DER)
(3.76) will not be allowed to start injecting power to the grid/electric power system.
3.78
frequency droop curve
parameterized curve of the frequency-watt function
Note 1 to entry: The parameters include a frequency dB (dead band) and a unitless factor k which defines the rate
of power output change due to the frequency change. This operation limits active power generation or consumption
when the line frequency deviates from nominal by a specified amount.
3.79
level 1 charging
charging with a maximum power between 1 kW and 1,8 kW, via a standard 120 Vrms AC single phase outlet
Note 1 to entry: This power limit is only applicable in the United States of America.
3.80
level 2 charging
charging with a maximum power between 3 kW and 22 kW, via a dedicated AC charger
Note 1 to entry: In the United States of America the voltage supplied is typically 240 Vrms AC whereas in Europe is
230 Vrms AC.
3.81
may trip region
region of voltage or frequency within which the EV is allowed to cease to energize (3.75) and to trip (3.88)
the connection
Note 1 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.82
momentary cessation region
region of voltage or frequency within which the EV will temporarily cease to energize (3.75) (inject power
to) an electric power system in response to a disturbance of the applicable voltages or the system frequency
Note 1 to entry: When entering this region, the EV will retain the capability of immediate restoration of the output of
operation when the applicable voltages and the system frequency return to within the defined ranges.
Note 2 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.83
must trip region
region of voltage or frequency within which the EV must cease to energize (3.75) and must trip (3.88) the
connection
Note 1 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.

ISO 15118-20:2022/Amd.1:2026(en)
3.84
open loop response time
time to ramp up to 90 % of the new target in response to the step change of the control input signal
3.85
permit service
setting that indicates whether a distributed energy resource (DER) (3.76) is allowed to enter or remain in
service
3.86
return to service
enter service (3.77) following recovery from a trip (3.88)
3.87
ride-through
ability to withstand voltage or frequency disturbances inside defined limits and to continue operating as
specified
3.88
trip
inhibition of immediate return to service (3.86)
Note 1 to entry: Once the distributed energy resource (DER) (3.76) has permission to come back to service, it shall
follow the enter service (3.77) rules.

Clause 4, Abbreviated terms
Add the following abbreviations to the list:

CE charge enable
CL charge loop
DER distributed energy resource (in the context of AC DER)
MCS megawatt charging system
Modify the existing abbreviation DER as follows:
DER distinguished encoding rules (in the context of X.509v3 certificates)

5.2
Replace the entire subclause including its title with the following subclause:
5.2  Requirement and provision structure
This document uses the requirement structure defined here. Also, important provisions that are no
requirements (“shall”), but permissions (“may”) or recommendations (“should”) use the structure defined
here. A unique number identifies each individual requirement or provision defined in this document.
Systematic and ordered requirement (provision) structure enables readers to find the target requirement
(provision) number easily.
The following format is applied for newly added and updated requirements or provisions:

ISO 15118-20:2022/Amd.1:2026(en)
"[V2G20-"XXXX"]" "requirement/provision text", where:
— "V2G20" represents this document;
— “XXXX” represents the unique requirement or provision number consisting of four digits starting from
1 000;
— "requirement/provision text" includes the actual text of the requirement or provision.
— For purely AC DER or MCS specific requirements, an identifier is added as follows: "[V2G20-"XXXX"]
[DER]" or "[V2G20-"XXXX"] [MCS]”, respectively.
EXAMPLE 1 [V2G20-0000]  This shall/may/should be an example requirement introduced in this document.
The following format is applied for requirements taken over from ISO 15118-2 Ed.1:
[“V2G20”-"YYY"] "requirement/provision text", where:
— "V2G20" represents this document;
— “YYY” represents the unique requirement or provision number as already defined in ISO 15118-2 Ed.1;
— "requirement/provision text" is the same text as specified in ISO 15118-2 Ed.1.
EXAMPLE 2 [V2G20-000]  This shall/may/should be an example requirement originally defined in ISO 15118-2
Ed.1.
Clause 6
Replace Figure 2 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Figure 2 — Vehicle to grid communication document overview

7.3.2
Replace Table 2 with this table:

ISO 15118-20:2022/Amd.1:2026(en)
Table 2 — Certificate extension examples
Certificate extensions Description
Usage of the corresponding private key (e.g. digital signature, non-repudia-
Key usage
tion, key encipherment, …)
Further specification of key usage using OIDs, e.g.:
— server authentication (1.3.6.1.5.5.7.3.1)

— client authentication (1.3.6.1.5.5.7.3.2)
NOTE Sometimes the following values are encoded here:
— Netscape SGC (1.3.6.1.4.1.311.10.3.3)
Extended key usage
— Microsoft SGC (2.16.840.1.113730.4.1)
SGC stands for server gated crypto and indicates that the
server can also use strong cryptography for the connection
with the client’s browser. This extension was used at the time
of strong crypto export control to enable financial web site to
provide appropriate protection of the data transfer.
CRL distribution point Location to retrieve certificate revocation lists
OCSP Location to retrieve OCSP. Refer to IETF RFC 6960 as updated by
IETF RFC 8954 for details.
Authority information Additional authorization information
Subject alternative name Alternative names of the entity
Basic constraint = CA True if the certificate is a root certificate or a sub-CA certificate.
Subject information Additional information about the subject

Replace NOTE 8 with:
NOTE 8 Additionally, key length of 456 bits is used with certain curves in the application of this document. If a V2G
entity can manage and utilize 521 bit keys, it can be capable of managing and utilizing 456 bit keys as well.

Add the following new paragraph below NOTE 14 to requirement [V2G20-1234]:
In this document, the size of certificate is less than or equal to 1 600 bytes. This limit considers resource
constraints in embedded systems. To reduce the size of certificates, things to consider are for example to be
cautious when adding long URLs, 4-byte characters in distinguished names, or multiple certificate policies
as these can increase the size of the certificate significantly. It can be necessary to use only one, either
CRLDistributionPoints or AuthorityInfoAccess, and not both, if including both makes the certificate larger
than 1 600 bytes.
Replace the requirement [V2G20-1004] with the following new requirements and note:
[V2G20-3000] The relying parties shall ensure that the certificates are valid exclusively within the
validity of their issuer's certificate.
NOTE 15 The CA is expected to only issue certificates that are valid exclusively within the validity of its own
certificate.
[V2G20-3001] While validating certificates, EVCC and SECC shall ensure that [V2G20-3000] is fulfilled.
Replace first bullet point in NOTE 20 (old numbering) with:
NOTE 20  […].
ISO 15118-20:2022/Amd.1:2026(en)
a) The content of the leaf certificate has not been altered after issue. This means it is possible to check and
confirm the signature up to the trust anchor level and thus the integrity of the signed content.
— […].
Renumber old NOTE 15 and following notes, starting with number 16.

7.3.2.1
Replace the requirement [V2G20-2327] and NOTE 3 with:
[V2G20-3002] The OCSP signer certificate used to sign the OCSP response for the SECC certificate sta-
tus shall be generated using a certificate chain that either uses the same V2G root CA
certificate as the trust anchor as the SECC certificate whose status is being checked or
uses one of the V2G root CA certificates, as the trust anchor, whose DN was included by
the EVCC in the “certificate_authorities” extension sent by the EVCC in the “ClientHello”
message. Refer to Figure 5 for a pictorial representation. Refer to Annex H for further
details. Refer to H.1.6 for examples of certificate structure. Refer to Annex B for details
of the certificate profile.
NOTE 3 This document does not mandate usage of a particular V2G root CA. In case multiple V2G root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
SECC certificate (or the sub-CA certificate(s) in the SECC certificate chain) chains up to the same V2G root CA that
signs the SECC certificate chain that the SECC is transmitting to the EVCC for this particular TLS handshake. This is,
however, out of scope of this document.
Replace the requirements [V2G20-2330] and [V2G20-2332] with the following new requirements,
respectively:
[V2G20-3003] The OCSP signer certificate used to sign the OCSP response for the contract certificate
status shall be generated using a certificate chain that uses either the same eMSP root
CA certificate or the same V2G root CA certificate as the trust anchor of the contract
certificate whose status is being checked. Refer to Figure 6 for a pictorial representation.
Refer to Annex H for further details. Refer to H.1.6 for examples of certificate structure.
Refer to Annex B for details of the certificate profile.
[V2G20-3004] The OCSP signer certificate used to sign the OCSP response for the vehicle certificate
status shall be generated using a certificate chain that uses either the same OEM root CA
certificate or the same V2G root CA certificate as the trust anchor of the vehicle certificate
whose status is being checked. Refer to Figure 7 for a pictorial representation. Refer to
Annex H for further details. Refer to H.1.6 for examples of certificate structure. Refer to
Annex B for details of the certificate profile.
Replace NOTE 10 with:
NOTE 10 This document does not mandate usage of a particular V2G root CA. In case multiple V2G root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
vehicle certificate (or the sub-CA certificate(s) in the vehicle certificate chain) chains up to the same V2G root CA that
signs the vehicle certificate chain whose status is being checked. This is, however, out of scope of this document.
Replace the requirement [V2G20-2334] and NOTE 12 with:
[V2G20-3005] The OCSP signer certificate used to sign the OCSP response for the OEM provisioning
certificate status shall be generated using a certificate chain that uses either the same
OEM root CA certificate or the same V2G root CA certificate as the trust anchor as the
OEM provisioning certificate whose status is being checked. Refer to Figure 7 for a pic-
torial representation. Refer to Annex H for further details. Refer to H.1.6 for examples of
certificate structure. Refer to Annex B for details of the certificate profile.

ISO 15118-20:2022/Amd.1:2026(en)
NOTE 12 This document does not mandate usage of a particular V2G root CA. In case multiple V2G root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
OEM provisioning certificate (or the sub-CA certificate(s) in the OEM provisioning certificate chain) chains up to the
same V2G root CA that signs the OEM provisioning certificate chain whose status is being checked. This is, however,
out of scope of this document.

7.3.4
Delete the following requirements: [V2G20-1235] and [V2G20-2646].

7.4
Add the following new requirements and note at the end of this subclause (below Figure 9):
[V2G20-3006] [MCS] In case of an MCS and MCS_BPT: If the EVCC sent the message SessionStopReq
with parameter ChargingSession equal to "Pause" it shall pause the Data-Link
(D-LINK_PAUSE.request()) after receiving the message SessionStopRes with Re-
sponseCode set to "OK" and follow the sleep and wake-up requirements defined in
ISO 15118-10:2025, 7.6.
[V2G20-3007] [MCS] In case of an MCS and MCS_BPT: If the SECC received the message SessionStopReq
with parameter ChargingSession equal to "Pause" it shall pause the Data-Link
(D-LINK_PAUSE.request()) after sending the message SessionStopRes with Re-
sponseCode set to "OK" and follow the sleep and wake-up requirements defined in
ISO 15118-10:2025, 7.6.
NOTE 3 Requirements [V2G20-1227] and [V2G20-1777] are not applicable for an MCS and MCS_BPT.

7.5
Replace second sentence of the first paragraph with:
ISO 15118-3, ISO 15118-8, and ISO 15118-10 define additional details on data link layer to be covered.
Add the following new requirement at the end of this subclause:
[V2G20-3008] [MCS] If a V2G entity communicates by 10BASE-T1S, the V2G entity shall comply with
ISO 15118-10.
7.5.1.2
Replace Figure 10 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Key
1 App layer communication protocol
2 IEEE 802.1X communication protocol
Figure 10 — IEEE 802.1X example with backend authentication for WPT
7.7.3.3
Add the following new NOTE after NOTE 8 below [V2G20-2368]:
NOTE 9 Although this requirement specifies using RDNs from Issuer field of the root certificates, per IETF RFC
5280:2008, 4.1.2.4 (as updated by IETF RFC 6818, IETF RFC 8398 and IETF RFC 8399) for root certificates these RDNs
must be the same between the Issuer field and the subject field.
Replace the requirements [V2G20-2369], [V2G20-2370] with the following new requirements, respectively:
[V2G20-3373] If no V2G root CA certificate(s) and PE private root CA certificate(s) are available in the
EVCC, "certificate_authorities" extension shall not be present in the "ClientHello" message.
[V2G20-3374] While the EVCC is in CPM4PE, it shall not include "certificate_authorities" extension in
the "ClientHello" message regardless if the EVCC has any V2G root CA certificate(s) and
PE private root CA certificate(s) or not. Refer to H.2.2.3 for details of CPM4PE.

Delete the following requirement: [V2G20-2371]

Replace the requirements [V2G20-2378], [V2G20-2379] with the following new requirements, respectively:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3375] If the EVCC did not provide any indication of the available roots according to [V2G20-
3373], a public SECC shall send in the "ServerHello" message its own certificate chain
(SECC certificate chain) including any necessary cross certificates up to a root (excluding
the root certificate itself) of its own choosing.
[V2G20-3376] If the EVCC provides a list of the available roots according to [V2G20-1006], the public
SECC shall follow IETF RFC 5280:2008, 7.1, as updated by IETF RFC 6818, IETF RFC 8398
and IETF RFC 8399, to utilize the received "DistinguishedNames" (see [V2G20-1006]) to
choose an SECC certificate chain originating from one of the received "Distinguished-
Names" and provide it to the EVCC in "ServerHello" message as defined in IETF RFC 8446.

Replace the requirements [V2G20-2383], [V2G20-2384] with the following new requirements, respectively:
[V2G20-3377] If the EVCC provides a list of the available roots according to [V2G20-1006], the private
SECC shall follow IETF RFC 5280:2008, 7.1 as updated by IETF RFC 6818, IETF RFC 8398
and IETF RFC 8399, to utilize the received "DistinguishedNames" (see [V2G20-1006]) to
choose a PE certificate chain originating from one of the received "DistinguishedNames"
and provide it to the EVCC in "ServerHello" message as defined in IETF RFC 8446.
[V2G20-3378] If the EVCC did not provide any indication of the available roots according to [V2G20-
3373], a private SECC not in CPM4PE shall send in the "ServerHello" message its own
certificate chain (PE certificate chain) including any necessary cross-certificates up to a
root (excluding the root certificate itself) of its own choosing.

Replace the requirement [V2G20-2388] with:
[V2G20-3379] Since the EVCC used the "status_request" extension to request OCSP response for the
certificate chain sent by the public SECC, it shall include an OCSP response for each cer-
tificate in the certificate chain sent by the public SECC in the "Certificate" message. Refer
to IETF RFC 6960 (as updated by IETF RFC 8954) and IETF RFC 8446 for further details.

Replace the requirement [V2G20-2391] with:
[V2G20-3380] Since the EVCC used the "status_request" extension to request OCSP response for the
certificate chain sent by private SECC, if the private SECC supports PnC, it shall include
an OCSP response for each certificate in the certificate chain sent by the private SECC in
the "Certificate" message. Refer to IETF RFC 6960 (as updated by IETF RFC 8954) and
IETF RFC 8446 for further adetails.

Replace NOTE 21 below [V2G20-1008] with:
NOTE 21 As defined in IETF RFC 6960 (as updated by IETF RFC 8954), an OCSP responder can either be the sub-
CA itself, or it can be an entity which is directly signed by the corresponding sub-CA/root CA using a key pair with a
special extended key usage flag in the certificate.
Replace the requirements [V2G20-2404], [V2G20-2405] with the following new requirements, respectively:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3381] If no V2G root CA certificate and OEM root CA certificate is/are available in the public
SECC or private SECC not in CPM4PE, the "certificate_authorities" extension shall not
be present in the "CertificateRequest" message.
[V2G20-3382] A private SECC in CPM4PE shall send not include "certificate_authorities" extension in
the "CertificateRequest" message. Refer to H.2.2.3 for details of CPM4PE.

Add the following new NOTE after NOTE 29 below [V2G20-2403]:
NOTE 30 Although this requirement specifies using RDNs from Issuer field of the root certificates, per IETF RFC
5280:2008, 4.1.2.4 (as updated by IETF RFC 6818, IETF RFC 8398 and IETF RFC 8399) for root certificates these RDNs
must be the same between the Issuer field and the Subject field.
Replace the requirements [V2G20-2426], [V2G20-2427], [V2G20-2428] with the following new requirements,
respectively:
[V2G20-3383] If the SECC provides a list of the available roots according to [V2G20-2401] or [V2G20-
2402], the EVCC shall follow IETF RFC 5280:2008, 7.1, as updated by IETF RFC 6818,
IETF RFC 8398 and IETF RFC 8399, to utilize the received "DistinguishedNames" (see
[V2G20-2401]) to choose a vehicle certificate chain originating from one of the received
"DistinguishedNames" and provide it to the SECC in "Certificate" message as defined in
IETF RFC 8446.
[V2G20-3384] If the public SECC did not provide any indication of the available roots according to
[V2G20-3381], the EVCC shall send a "Certificate" message containing its own certifi-
cate chain (vehicle certificate chain) including any necessary cross-certificates up to the
corresponding root (excluding the root certificate itself) of its own choosing.
[V2G20-3385] If the private SECC did not provide any indication of the available roots according to
[V2G20-3381], an EVCC not in CPM4PE shall send a "Certificate" message containing its
own certificate chain (vehicle certificate chain) including any necessary cross-certificates
up to the corresponding root (excluding the root certificate itself) of its own choosing.

Renumber all NOTEs starting from the original NOTE 9.

7.7.3.10
Add the following new requirements and note at the end of the subclause:
[V2G20-3009] [MCS] Backwards compatibility with ISO 15118-2 shall not be implemented for an EVCC
using an MCS.
[V2G20-3010] [MCS] Backwards compatibility with ISO 15118-2 shall not be implemented for an SECC
using an MCS.
NOTE 10 Requirements [V2G20-2054] through [V2G20-2070] are not applicable for an MCS and MCS_BPT.

7.8.3.1, Table 14
In Table 14: replace the table row with payload type value 0x8007 - 0x8100 with the following new rows:

ISO 15118-20:2022/Amd.1:2026(en)
Payload type value Payload type identifier Explanation
0x8007 - 0x8009 Not applicable Reserved for future use
EXI encoded V2G messages of this document
which are exchanged as part of the main
stream of the communication flow and are
specific to AC DER IEC. This set of messages
0x8010 AC-DER-IEC-PayloadID
is using the XSD schema with the namespace
"urn: iso:s td: iso: 15118: -20: AC -DER -IEC".
Refer to Annex L for the definition of this
message set.
EXI encoded V2G messages of this document
which are exchanged as part of the main
stream of the communication flow and are
specific to AC DER SAE. This set of messages
0x8011 AC-DER-SAE-PayloadID
is using the XSD schema with the namespace
"urn: iso:s td: iso: 15118: -20: AC -DER -SAE".
Refer to Annex M for the definition of this
message set.
0x8012 - 0x8100 Not applicable Reserved for future use

7.9.1.3
Add the following new requirement below requirement [V2G20-5125]:
[V2G20-3011] [DER] The XML schema with the namespace "urn:i so:s td:i so:1 5118:- 20:A C- DER- IEC" shall be
used for encoding and decoding EXI streams sent or received with AC-DER-IEC-Pay-
loadID and defined in Annex L.
[V2G20-3386] [DER] The AC-DER-IEC-PayloadID shall only be used for the AC DER IEC service.
[V2G20-3161] [DER] The XML schema with the namespace "urn:i so:s td:i so:1 5118:- 20:A C- DER- SAE" shall be
used for encoding and decoding EXI streams sent or received with AC-DER-SAE-Pay-
loadID and defined in Annex M.
[V2G20-3387] [DER] The AC-DER-SAE-PayloadID shall only be used for the AC DER SAE service.

7.9.2.4.2
Add the following requirement and note below the requirement [V2G20-2476] and renumber all NOTEs
starting from the original NOTE 2:
[V2G20-3012] NIST FIPS PUB 202 defines SHAKE256 as an extendable-output function (XOF). Hence the
output length of SHAKE256 (referred as “d” by NIST FIPS PUB 202) can be configured to
any necessary value as needed by the application. For signatures as defined by [V2G20-
2476], the output length “d” of SHAKE256 shall be 114 bytes (912 bits).
NOTE 2 IETF RFC 8032:2017, 5.2 specifies using 114 bytes (912 bits) as the output length of SHAKE256. This
requirement keeps the SHAKE256 output length consistent between the IETF RFC 8032 and this document.

7.9.2.4.3
Replace Table 17 with this table:

ISO 15118-20:2022/Amd.1:2026(en)
Table 17 — Overview of applied XML based signatures
Verifying
XML message Protected fields Signing entity (sender) entity (re-
ceiver)
EVCC; signed with private key
associated with the contract
AuthorizationReq PnC_AReqAuthorizationMode SECC
certificate provided within PnC_
AReqAuthorizationMode
EVCC; signed with private key
associated with OEM provision secondary
CertificateInstallationReq OEMProvisioningCertificateChain
certificate (transmitted in mes- actor
sage body element)
secondary actor; signed with the
private key associated with the
CertificateInstallationRes SignedInstallationData EVCC
leaf certificate of the certificate
provisioning service
EVCC; signed with private key
associated with the contract cer-
MeteringConfirmationReq SignedMeteringData SECC
tificate (certificate is transmitted
in AuthorizationReq message)
secondary actor; signed with the
AbsolutePriceSchedule + PriceLev-
ScheduleExchangeRes private key associated with the EVCC
elSchedule
eMSP Sub-CA2 certificate
Replace NOTE 1 below the requirement [V2G20-2479] with:
NOTE 1 The key in the “value” field of “generalName” parameter of “accessLocation” field of “accessDescription
(x448PublicKey)” parameter in the extension “subjectInfoAccess” is encoded for use only in ECDH algorithm. It is not
possible to use it to verify signatures using the Ed448 algorithm.
7.9.2.5.2.1
Replace the requirement [V2G20-2492] with:
[V2G20-3388] Additional authenticated data (AAD) shall be calculated by concatenating the PCID received/
used in the CertificateInstallationReq message with capital letters and digits without
separators (18 bytes), followed by the SKI value of the contract certificate included in
the CertificateInstallationRes encoded as a hexa-decimal string with capital letters and
digits according to IETF RFC 5234 (16 bytes for method 2 and 40 bytes for method 1).

7.9.2.5.2.2.1
Replace the name of the subclause with:
Common requirements for encryption of 521-bit and 456-bit contract certificate private keys for EVCC
without TPM 2.0
Replace the requirement [V2G20-2495] with:
[V2G20-3389] When using 456-bit ephemeral public key in requirement [V2G20-2497], the sender shall
not include any extra filler/padding bytes to reach DHPublicKey size of 133 bytes.

7.9.2.5.2.2.3
Replace the name of the subclause with:

ISO 15118-20:2022/Amd.1:2026(en)
Encryption of 456 bit contract certificate private key for EVCC without TPM 2.0

Replace the requirement [V2G20-2500] and NOTE 2 with:
[V2G20-3390] The 456-bit private key corresponding to the contract certificate shall be encrypted by
the sender (the SA (eMSP)) using the same session key used to encrypt the 521-bit private
key in [V2G20-2497]. The sender shall apply the algorithm AES-GCM-256 according to
NIST Special Publication 800-38D for this encryption. The initialization vector (IV) for
this encryption shall be randomly generated before encryption and shall have a length
of 88 bits with minimum entropy as defined by the implementer(s). The AAD for this
encryption shall be calculated according to [V2G20-2492]. The encryption shall produce
the 456-bit long ciphertext (encrypted private key) and 128-bit long authentication tag
("tag" for short).
NOTE 2 No explicit padding is required here since the 456-bit private key is byte aligned.
Replace Figure 19 with this figure:
Figure 19 — 456-bit contract certificate private key encryption
Replace the text above [V2G20-2502] with the following text:
The output of AES-GCM-256 encryption will be the ciphertext and the authentication tag. The 456-bit
ciphertext is the encrypted contract certificate private key.

Replace the requirement [V2G20-2502] with:
[V2G20-3391] The IV (as defined by [V2G20-2497]) shall be transmitted in the 11 most significant
bytes of the X448_EncryptedPrivateKey field. The ciphertext (encrypted private key)
of 57 bytes shall be written after the IV in the X448_EncryptedPrivateKey field. The
tag (as defined by [V2G20-2494]) shall make up the 16 least significant bytes of the
X448_EncryptedPrivateKey field. Figure 20 provides this structure in pictorial format.
Replace Figure 20 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Figure 20 — X448_EncryptedPrivateKey

7.9.2.5.2.3
Replace the name of the subclause with:
Common requirements for decryption of 521-bit and 456-bit contract certificate private keys for EVCC
without TPM 2.0
7.9.2.5.2.3.1
Replace the requirement [V2G20-2504] with:
[V2G20-3392] If the decryption of either the 521-bit private key or 456-bit private key or both fails, the
receiver shall reject the CertificateInstallationRes message as invalid.

7.9.2.5.2.3.3
Replace the name of the subclause with:
Decryption of 456-bit contract certificate private key for EVCC without TPM 2.0

Replace the requirement [V2G20-2508] with:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3393] Upon reception of X448_EncryptedPrivateKey, the receiver (EVCC) shall decrypt the
contract certificate private key using the same session key used to decrypt the 521-bit
private key in [V2G20-2505] and applying the algorithm AES-GCM-256 according to NIST
Special Publication 800-38D. The IV shall be read from the 11 most significant bytes of
the X448_EncryptedPrivateKey field. The ciphertext (encrypted private key) shall be
read from the 57 bytes after the IV in the X448_EncryptedPrivateKey field. The AAD
for this decryption shall be calculated before decryption following [V2G20-2492]. The
authentication tag shall be read from the 16 least significant bytes of the X448_Encrypt-
edPrivateKey field.
Replace Figure 23 with this figure:
Figure 23 — 456-bit contract certificate private key decryption overview

Replace Figure 24 with this figure:
Figure 24 — 456-bit contract certificate private key decryption
Replace the requirement [V2G20-2509] and [V2G20-2510] with:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3394] The EVCC shall use the 456-bit decrypted data as the 456-bit contract certificate private key.
[V2G20-3395] Upon receipt of a contract certificate, the EVCC shall verify that the 456-bit private key
received with the certificate is a valid 456-bit private key for that certificate:
— its value shall be strictly smaller than the order of the base point for x448 curve;
— multiplication of the base point with this value shall generate a key matchingthe
456-bit public key of the contract certificate.
7.9.2.5.3, Figure 25
Replace Figure 25 with this figure:
Figure 25 — Process for CertificateInstallationRes for EVCC equipped with TPM 2.0

7.9.2.5.3.3, Figure 26
Replace Figure 26 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Figure 26 — Contract key encryption for direct import into EVCC’s TPM 2.0 (for (elliptic curve) EC
P-521/secp521r1)
Replace NOTE 5 below Figure 26 with the following note:
NOTE 5 Key encryption process and structures illustrated in Figure 26 are valid for both currently specified
(elliptic curve) ECs.
Add the following note below Figure 26:
NOTE 7 As the authValue of the contract key is part of the encrypted contract private key, it is known only to
the SA and not to a TPM's local controller in the EVCC. It is thus recommended to provision the contract key with a
policyDigest and use a policy session to authorize signing with this key. This policy session can include for example
the command TPM2_PolicySecret whose authorization is ensured by proving knowledge of the authValue of an entity.
Choosing the storage key as the entity allows the SA to compute the policy, as it requires knowledge of the name of the
key whose public part is present in the OEM provisioning certificate extension.

Renumber all notes starting from the original NOTE 7.

7.9.2.5.3.1
Replace the requirement [V2G20-2511] with:
[V2G20-3433] The EVCC’s TPM 2.0 shall contain a storage key pair. The storage key pair in the EVCC’s
TPM shall use the storage key profile from Table 19 for the default ECC algorithm (elliptic
curve P-521/secp521, see [V2G20-2674]) or the storage key profile from Table 19 for the
alternative ECC algorithm (Curve448, see [V2G20-2319]).

Replace Table 19 with the following new table:

ISO 15118-20:2022/Amd.1:2026(en)
Table 19 — TPM key profiles for (elliptic curve) EC P-521/secp521r1 and Curve448 (public area)
Parameter Content for secp521r1
Storage key OEM provisioning key Contract key
type TPM2_ALG_ECC TPM2_ALG_ECC TPM2_ALG_ECC
nameAlg TPM2_ALG_SHA512 TPM2_ALG_SHA512 TPM2_ALG_SHA512
fixedTPM = 1 fixedTPM = 1 fixedTPM = 0
stClear = 0 stClear = 0 stClear = 0
fixedParent = 1 fixedParent = 1 fixedParent = 0
sensitiveDataOrigin = 1 sensitiveDataOrigin = 1 sensitiveDataOrigin = 1
userWithAuth = 1 userWithAuth = 0 (1 if no userWithAuth = 0 (1 if no
policy) policy)
adminWithPolicy = 0
objectAttributes adminWithPolicy = 1 (0 if no adminWithPolicy = 1 (0 if no
noDA = 0
policy) policy)
encryptedDuplication = 0
noDA = 0 noDA = 0
restricted = 1
encryptedDuplication = 0 encryptedDuplication = 0
decrypt = 1
restricted = 0 restricted = 0
sign = 0
decrypt = 0 decrypt = 0
sign = 1 sign = 1
authPolicy
size 0 64 (0 if no policy) 64 (0 if no policy)
buffer NULL OEM chosen policy digest OEM chosen policy digest
parameters
symmetric.algorithm TPM2_ALG_AES TPM2_ALG_NULL TPM2_ALG_NULL
symmetric.keyBits 256 NULL NULL
symmetric.mode TPM2_ALG_CFB NULL NULL
symmetric.details NULL NULL NULL
scheme.scheme TPM2_ALG_NULL TPM2_ALG_NULL TPM2_ALG_NULL
scheme.details NULL NULL NULL
curveID TPM2_ECC_NIST_P521 TPM2_ECC_NIST_P521 TPM2_ECC_NIST_P521
kdf.scheme TPM2_ALG_NULL TPM2_ALG_NULL TPM2_ALG_NULL
kdf.details NULL NULL NULL
unique
x.size 0 0 66
x.buffer NULL NULL x-coordinate of the public key
y.size 0 0 66
y.buffer NULL NULL y-coordinate of the public key
Parameter Content for Curve448
Storage key OEM provisioning key Contract key
type TPM_ALG_ECC TPM_ALG_ECC TPM_ALG_ECC
nameAlg TPM_ALG_SHA512 TPM_ALG_SHA512 TPM_ALG_SHA512

ISO 15118-20:2022/Amd.1:2026(en)
TTabablele 1 199 ((ccoonnttiinnueuedd))
objectAttributes fixedTPM = 1 fixedTPM = 1 fixedTPM = 0
stClear = 0 stClear = 0 stClear = 0
fixedParent = 1 fixedParent = 1 fixedParent = 0
sensitiveDataOrigin = 1 sensitiveDataOrigin = 1 sensitiveDataOrigin = 1
userWithAuth = 1 userWithAuth = 0 (1 if no userWithAuth = 0 (1 if no
policy) policy)
adminWithPolicy = 0
adminWithPolicy = 1 (0 if no adminWithPolicy = 1 (0 if no
noDA = 0
policy) policy)
encryptedDuplication = 0
noDA = 0 noDA = 0
restricted = 1
encryptedDuplication = 0 encryptedDuplication = 0
decrypt = 1
restricted = 0 restricted = 0
sign = 0
decrypt = 0 decrypt = 0
sign = 1 sign = 1
authPolicy
size 0 64 (0 if no policy) 64 (0 if no policy)
buffer NULL OEM chosen policy digest OEM chosen policy digest
parameters
symmetric.algorithm TPM_ALG_AES TPM_ALG_NULL TPM_ALG_NULL
symmetric.keyBits 256 NULL NULL
symmetric.mode TPM_ALG_CFB NULL NULL
symmetric.details NULL NULL NULL
scheme.scheme TPM_ALG_NULL TPM_ALG_EDDSA TPM_ALG_EDDSA
scheme.details NULL NULL NULL
curveID TPM_ECC_CURVE_448 TPM_ECC_CURVE_448 TPM_ECC_CURVE_448
kdf.scheme TPM_ALG_NULL TPM_ALG_NULL TPM_ALG_NULL
kdf.details NULL NULL NULL
unique
x.size 0 0 57
x.buffer NULL NULL Public key compressed format
y.size 0 0 0
y.buffer NULL NULL NULL
Replace NOTE 4 with the following notes:
NOTE 4 Table 19 contains the TPM Key Profiles for the default ECC algorithm (elliptic curve P-521/secp521) as
defined by [V2G20-2321] and the TPM Key Profiles for the alternative ECC algorithm (Curve448) according to [V2G20-
2319]. Further ECC algorithms supported by TPM 2.0 are specified in TCG algorithm registry.
NOTE 5 Table 19 contains the TPM key profiles (TPMT_PUBLIC structure) used as input to the key creation
commands for the storage key and the OEM provisioning key and the import command for the contract key.
NOTE 6 The OEM provisioning key based on the curve TPM_ECC_CURVE_448 is not defined as a general-purpose
key because it is not possible to sign with Ed448 scheme and exchange a secret with X448 scheme using the same key.
NOTE 7 The public part of a signing key based on the curve TPM_ECC_CURVE_448 is represented in the compressed
format as detailed in IETF RFC 8032.
7.9.2.5.3.2
Replace the requirement [V2G20-2512] and NOTE 8 with:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3396] The OEM provisioning key pair shall be generated using the provisioning key profile from
Table 19 for the default ECC algorithm (elliptic curve P-521/secp521, see [V2G20-2674])
or using the provisioning key profile from Table 19 for the alternative ECC algorithm
(Curve448, see [V2G20-2319]).
NOTE 8 The policy digest is part of the TPM key profile (see "authPolicy") and is created using the "nameAlg"
algorithm of the key. In case of the default or the alternative ECC algorithm as defined by [V2G20-2674] and [V2G20-
2319], the EVCC's TPM policy digest uses SHA-512 and is 64 byte long (see Table 19).
7.9.2.5.3.3
Replace the requirement [V2G20-2518] and NOTE 2 with:
[V2G20-3397] In order to enable a direct import of the encrypted contract certificate private key into
the EVCC’s TPM, the contract certificate private key shall be encrypted with the TPM
storage key of the EVCC's TPM from the OEM provisioning certificate extension (in con-
trast to [V2G20-2529] and [V2G20-3013]). This encryption shall comply with ISO/IEC
11889-1:2015, 23.3.2 and only use the outer duplication wrapper. This encryption shall
use the values from Table 19 for the default ECC algorithm (elliptic curve P-521/secp521,
see [V2G20-2674]) or shall use the values from Table 19 for the alternative ECC algorithm
(Curve448, see [V2G20-2319]), whereby the contract certificate public key is inserted
into the buffers of the contract key profile’s "unique" field. If a policy digest is provided
in the OEM provisioning certificate of this EVCC, the value of the policy digest shall be
included in the encryption of the contract certificate private key via the "authPolicy"
field of the contract key profile.
NOTE 2 The values from Table 19
...