SIST EN IEC 62351-4:2019/A1:2020
(Amendment)Power systems management and associated information exchange - Data and communications security - Part 4: Profiles including MMS and derivatives
Power systems management and associated information exchange - Data and communications security - Part 4: Profiles including MMS and derivatives
Energiemanagementsysteme und zugehöriger Datenaustausch - IT-Sicherheit für Daten und Kommunikation - Teil 4: Profile einschließlich MMS und Ableitungen
Gestion des systèmes de puissance et échanges d'informations associés - Sécurité des communications et des données - Partie 4 : Profils comprenant MMS
Upravljanje elektroenergetskega sistema in pripadajoča izmenjava informacij - Varnost podatkov in komunikacij - 4. del: Profili, vključno z MMS in izpeljankami - Dopolnilo A1
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN IEC 62351-4:2019/A1:2020
01-november-2020
Upravljanje elektroenergetskega sistema in pripadajoča izmenjava informacij -
Varnost podatkov in komunikacij - 4. del: Profili, vključno z MMS in izpeljankami -
Dopolnilo A1
Power systems management and associated information exchange - Data and
communications security - Part 4: Profiles including MMS and derivatives
Energiemanagementsysteme und zugehöriger Datenaustausch - IT-Sicherheit für Daten
und Kommunikation - Teil 4: Profile einschließlich MMS und Ableitungen
Gestion des systèmes de puissance et échanges d'informations associés - Sécurité des
communications et des données - Partie 4 : Profils comprenant MMS
Ta slovenski standard je istoveten z: EN IEC 62351-4:2018/A1:2020
ICS:
29.240.30 Krmilna oprema za Control equipment for electric
elektroenergetske sisteme power systems
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
SIST EN IEC 62351-4:2019/A1:2020 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
---------------------- Page: 2 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
EUROPEAN STANDARD EN IEC 62351-4:2018/A1
NORME EUROPÉENNE
EUROPÄISCHE NORM
September 2020
ICS 33.200
English Version
Power systems management and associated information
exchange - Data and communications security - Part 4: Profiles
including MMS and derivatives
(IEC 62351-4:2018/A1:2020)
Gestion des systèmes de puissance et échanges Energiemanagementsysteme und zugehöriger
d'informations associés - Sécurité des communications et Datenaustausch - IT-Sicherheit für Daten und
des données - Partie 4: Profils comprenant le MMS et ses Kommunikation - Teil 4: Profile einschließlich MMS und
dérivés Ableitungen
(IEC 62351-4:2018/A1:2020) (IEC 62351-4:2018/A1:2020)
This amendment A1 modifies the European Standard EN IEC 62351-4:2018; it was approved by CENELEC on 2020-08-21. CENELEC
members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this amendment the
status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This amendment exists in three official versions (English, French, German). A version in any other language made by translation under the
responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as
the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62351-4:2018/A1:2020 E
---------------------- Page: 3 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
EN IEC 62351-4:2018/A1:2020 (E)
European foreword
The text of document 57/2217/FDIS, future IEC 62351-4/A1, prepared by IEC/TC 57 "Power systems
management and associated information exchange" was submitted to the IEC-CENELEC parallel vote
and approved by CENELEC as EN IEC 62351-4:2018/A1:2020.
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2021-05-21
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-08-21
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Endorsement notice
The text of the International Standard IEC 62351-4:2018/A1:2020 was approved by CENELEC as a
European Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 61850-8-1:2011 NOTE Harmonized as EN 61850-8-1:2011 (not modified)
IEC 61850-8-2:2018 NOTE Harmonized as EN IEC 61850-8-2:2019 (not modified)
2
---------------------- Page: 4 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
EN IEC 62351-4:2018/A1:2020 (E)
Annex ZA
(normative)
Normative references to international publications with their
corresponding European publications
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
NOTE 1 Where an International Publication has been modified by common modifications, indicated by (mod),
the relevant EN/HD applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available
here: www.cenelec.eu.
Replace the existing reference to ISO/IEC 9594-8 with the following reference:
Publication Year Title EN/HD Year
ITU-T X.509 - Information technology - Open systems - -
interconnection - The Directory: Public-key
and attribute certificate frameworks
3
---------------------- Page: 5 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
---------------------- Page: 6 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
IEC 62351-4
®
Edition 1.0 2020-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
A MENDMENT 1
AM ENDEMENT 1
Power systems management and associated information exchange – Data and
communications security –
Part 4: Profiles including MMS and derivatives
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 4: Profils comprenant le MMS et ses dérivés
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.200 ISBN 978-2-8322-8520-6
Warning! Make sure that you obtained this publication from an authorized distributor.
Attention! Veuillez vous assurer que vous avez obtenu cette publication via un distributeur agréé.
® Registered trademark of the International Electrotechnical Commission
Marque déposée de la Commission Electrotechnique Internationale
---------------------- Page: 7 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
– 2 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
FOREWORD
This amendment has been prepared by working group 15: Data and communication security, of
IEC technical committee 57: Power systems management and associated information
exchange.
The text of this amendment is based on the following documents:
FDIS Report on voting
57/2217/FDIS 57/2233/RVD
Full information on the voting for the approval of this amendment can be found in the report on
voting indicated in the above table.
The committee has decided that the contents of this amendment and the base publication will
remain unchanged until the stability date indicated on the IEC website under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
_____________
2 Normative references
Replace the existing reference to ISO/IEC 9594-8 with the following new reference:
ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), Information technology – Open Systems
Interconnection – The Directory: Public-key and attribute certificate frameworks
3 Terms and definitions
3.2.2
Replace the existing text:
[SOURCE: ISO/IEC 7498-1:1994 | Rec. ITU-T X.200:1994, 7.1.1.2]
with the following new text:
[SOURCE: ISO/IEC 7498-1:1994 | Rec. ITU-T X.200 (1994), 7.1.1.2]
Add, after 3.2.2, the following new definition and renumber subsequent subclauses accordingly:
3.2.3
alarm
security event that might be caused by an adversary
---------------------- Page: 8 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
IEC 62351-4:2018/AMD1:2020 – 3 –
© IEC 2020
3.2.7
Replace the existing text:
[SOURCE: Rec. ITU-T X.217:1995, 3.5.1]
with the following new text:
[SOURCE: Rec. ITU-T X.217 (1995), 3.5.1]
3.2.11
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509 (2016), 3.5.14]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.14]
3.2.12
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.21]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.21]
3.2.18
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.31]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.31]
Add, after 3.2.20, the following new definition and renumber subsequent subclauses
accordingly:
3.2.21
error
security event that is caused by bad implementation behaviour resulting in disruption of
communication
Add, after 3.2.27, the following new definition and renumber subsequent subclauses
accordingly:
3.2.28
protocol control information
information exchanged between entities of a given layer, via the service provided by the next
lower layer, to coordinate their joint operation
---------------------- Page: 9 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
– 4 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
3.2.29
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.57]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.58]
3.2.34
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.71]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.72]
3.3 Abbreviated terms
Add the following new abbreviation:
PCI Protocol Control Information
4.2 Security for application and transport profiles
Table 1 – Relationship between security and security measure combinations
Remove the end parenthesis in the first column, first row of Table 1.
4.5.3 Attacks countered in native mode
In the second set of bullet items, replace the existing text:
– Man-in-the-middle: This threat is countered through the use of authentication during end-
to-end association by use of digital signature and during data transfer by use of ICV.
with the following new text:
– Man-in-the-middle: This threat is countered through the use of authentication during end-
to-end association establishment by use of digital signature and during data transfer by use
of ICV.
6.2.6 Public-key certificate size
Replace the existing text of the first paragraph of 6.2.6 with the following new text:
An implementation that claims conformance to this document shall support a public-key
certificate size of minimum and maximum 8192 octets. It is a local issue if larger public-key
certificates are supported.
Add, after the first paragraph of 6.2.6, the following new paragraph:
In order to achieve interoperability of public-key certificates, it is necessary to set a maximum
allowed size for the public-key certificates exchanged by ACSE. This size shall be limited to a
maximum encoding size of 8192 octets.
---------------------- Page: 10 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
IEC 62351-4:2018/AMD1:2020 – 5 –
© IEC 2020
6.3.4.1 General
Replace the existing text of the second paragraph of 6.3.4.1 with the following new text:
TLS prioritizes the proposed cipher suites in the TLS handshake according to the order in the
proposed cipher suite list in the ClientHello message. To accommodate a security policy it is
strongly recommended to have the order of proposed cipher suites according to the local
security policy. Cipher suites marked as mandatory shall be stated in the proposal list of the
ClientHello message.
6.3.4.2 Mandatory and recommended cipher suites for compatibility mode
Replace the existing text of the first paragraph of 6.3.4.2 with the following new text:
All implementations that claim conformance to IEC TS 62351-4:2007 shall support
TLS_DH_DSS_WITH_AES_256_CBC_SHA at a minimum.
Replace existing Table 2 with the following new table:
Table 2 – Commented recommended cipher suites from IEC TS 62351-4:2007
Key exchange Encryption Hash IANA Value Source Support
Algorithm Signature
TLS_RSA_ WITH_RC4_128_ SHA 0x00,0x05 RFC 2246 Disallowed (RC 4
(TLS 1.0) considered weak)
TLS_RSA_ WITH_3DES_ede_CBC_ SHA 0x00,0x0A RFC 2246 o
(TLS 1.0)
TLS_DH_ DSS_ WITH_3DES_ede_CBC_ SHA 0x00,0x0D RFC 2246 o
(TLS 1.0)
TLS_DH_ RSA_ WITH_3DES_ede_CBC_ SHA 0x00,0x10 RFC 2246 o
(TLS 1.0)
TLS_DHE_ DSS_ WITH_3DES_ede_CBC_ SHA 0x00,0x13 RFC 2246 o
(TLS 1.0)
TLS_DHE_ RSA_ WITH_3DES_ede_CBC_ SHA 0x00,0x16 RFC 2246 o
(TLS 1.0)
TLS_DH_ DSS_ WITH_AES_128_CBC_ SHA 0x00,0x30 RFC 4346 o
(TLS 1.1)
TLS_DH_ DSS_ WITH_AES_256_CBC_ SHA 0x00,0x36 RFC 4346 m
(TLS 1.1)
TLS_DH_ WITH_AES_128_CBC SHA 0x00, 0x34 RFC 4346 Disallowed
(TLS 1.1) (anonymous)
TLS_DH_ WITH_AES_256_CBC SHA 0x00, 0x3A RFC 4346 Disallowed
(TLS 1.1) (anonymous)
6.3.4.3 Mandatory and recommended cipher suites for native mode
Replace the existing text of the first paragraph of 6.3.4.3 with the following new text:
All implementations that claim conformance to the native mode shall support the mandatory
cipher suites listed in Table 3.
Replace existing Table 3 with the following new table:
---------------------- Page: 11 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
– 6 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
Table 3 – Cipher suites combinations in the context of this document
Key exchange Encryption Hash IANA Value Source Support
Algorithm Signature
TLS_RSA WITH_AES_128_CBC_ SHA256 0x00,0x3C RFC 5246 m
TLS_DH_ RSA_ WITH_AES_128_CBC_ SHA256 0x00,0x31 RFC 5246 o
TLS_DH_ RSA_ WITH_AES_128_GCM_ SHA256 0x00,0xA0 RFC 5288 m
[20]
TLS_DHE_ RSA_ WITH_AES_128_GCM_ SHA256 0xC0,0x9E RFC 5288 m
[20]
TLS_DH_ RSA_ WITH_AES_256_GCM_ SHA384 0x00,0xA1 RFC 5288 o
[20]
TLS_ECDHE_ RSA_ WITH_AES_128_GCM_ SHA256 0xC0,0x2F RFC 5289 [7] o
TLS_ECDHE_ RSA_ WITH_AES_256_GCM_ SHA384 0xC0,0x30 RFC 5289 [7] o
TLS_ECDHE_ ECDSA_ WITH_AES_128_GCM_ SHA256 0xC0,0x23 RFC 5289 [7] m
TLS_ECDHE_ ECDSA_ WITH_AES_256_GCM_ SHA384 0xC0,0x24 RFC 5289 [7] o
7.1 General
Replace the existing text of item b), first bullet, with the following new text:
• Clause 12 defines the overall model or architecture for E2E security, including how E2E
security relates to an operational environment and a protected protocol.
7.2.2 ASN.1 as an XML schema definition
Replace the text EXTENDENDE-XER in item b) with EXTENDED-XER
Replace the existing text of the last sentence of item c) by the following new text:
DER is also specified by ISO/IEC 8825-1 | Rec. ITU-T X.690.
7.2.4 XML namespace
Replace the existing text:
(see 12.1)
with the following new text:
(see 16.5)
8.2 Basic cryptographic definitions
Replace the existing text of the last two paragraphs with the following new text:
A defined set represents a set of cryptographic algorithms relevant for a particular situation.
The extension mark ( . ) will cause an ASN.1 tool to accept any cryptographic object, whether
it identifies a cryptographic algorithm for the specific purpose or not. A referencing specification
or an implementers' agreement may remove the extension mark and/or add additional
algorithms.
---------------------- Page: 12 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
IEC 62351-4:2018/AMD1:2020 – 7 –
© IEC 2020
8.4 Hash algorithms
Replace the existing text of the last paragraph of 8.4 with the following new text:
IETF RFC 5754 gives the formal specification for the sha256 hash algorithm.
8.5 Signature algorithms
Replace, in the first paragraph of 8.5, "validating" with "verifying".
8.6 Symmetric encryption algorithms used for encryption only
Replace the existing title of Subclause 8.6 with the following new title:
8.6 Symmetric key algorithms
Delete the last sentence of the last paragraph of 8.6.
8.7 Authenticated encryption algorithms
Replace the existing text of the first paragraph of 8.7 with the following new text:
The AES-GCM authenticated encryption technology is used for encryption, integrity and
authentication or it is used only for integrity and authentication (the latter also known as GMAC).
It is further described in [12].
Replace the existing text of the second paragraph of 8.7 with the following new text:
When used for integrity and authentication only, i.e., as GMAC, it may be combined with AES-
CBC encryption.
9 Object identifier allocation (normative)
Delete the auth-mechanism object identifier and the text above.
10.1 Overview
Replace, in the second paragraph of 10.1, two occurrences of "within" with "in".
10.4.1 Context list
Replace the existing text:
Context-list ::= SEQUENCE SIZE(2) OF SEQUENCE {
with the following new text:
Context-list ::= SEQUENCE SIZE(2.MAX) OF SEQUENCE {
10.4.2 Abstract syntaxes
Replace the last paragraph with the following new text:
Two additional abstract syntaxes should be included for compatibility mode as specified in
11.1.3.
Two additional abstract syntaxes shall be included for native mode as specified in 15.2.1.
---------------------- Page: 13 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
– 8 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
10.4.3 Presentation user data
Replace the existing text
User-data::= SEQUENCE SIZE (1) OF SEQUENCE {
presentation-context-identifier Presentation-context-identifier,
single-ASN1-type [0] ABSTRACT-SYNTAX.&Type (CONSTRAINED BY {
-- Type corresponding to presentation context identifier --} ) }
with the following new text
User-data ::= [APPLICATION 1] IMPLICIT SEQUENCE SIZE (1) OF SEQUENCE {
presentation-context-identifier Presentation-context-identifier,
single-ASN1-type [0] EXPLICIT ABSTRACT-SYNTAX.&Type (CONSTRAINED BY {
-- Type corresponding to presentation context identifier --} ) }
10.5.3 Titles
Replace current Notes 1 and 2 with the following new text:
NOTE 1 The combination of the called-AP-title and the called-AE-qualifier is also an object identifier.
This object identifier is the object identifier that is assigned to the entity that acts as server for the association to be
established.
NOTE 2 The combination of the calling-AP-title and the calling-AE-qualifier is also an object
identifier. This object identifier is the object identifier that is assigned to the entity that acts as client for the
association to be established.
11 A-security-profile (normative)
Replace the existing title of Clause 11 with the following new title:
11 A-security profile (normative)
11.1.2 Additional session protocol requirements
Replace the existing text:
Rec.X.638:1996
with the following new text:
Rec. ITU-T X.638 (1996)
11.1.3 Additional presentation protocol requirement
Replace the current text of 11.1.3 with the following new text:
Special abstract syntaxes for A-security profile and MMS each together with an associated
presentation-context-identifier shall be included in the Contexlist together with the abstract
syntax for ACSE (see 10.4.1 and 10.4.2).
The A-security profile abstract syntax is defined as:
mmsAuthenticationAS OBJECT IDENTIFIER ::= {1 0 840 0 1 1 4 1}
NOTE This object identifier should be equal to the object identifier used for identifying the ASN.1 STASE-
MMSAuthentication-value within IEC TS 62351-4:2007. This OID was incorrectly specified and should have been {1
2 840 0 1 0 1 1}. The original value is kept to ensure backward compatibility.
Some implementation may not include this abstract syntax and may therefore not be able to
receive it.
---------------------- Page: 14 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
IEC 62351-4:2018/AMD1:2020 – 9 –
© IEC 2020
An implementation shall be able to accept an otherwise valid association request that does not
include this abstract syntax. In the association accept, it shall in this case not include this
abstract syntax.
An implementation that is able to include this abstract syntax in an association request may
keep records of communication partners that does accept an association request with this
abstract syntax included and then in its communication with such partners exclude this abstract
syntax. Alternatively, an implementation may always exclude this abstract syntax in its
association request even when it is able to receive it.
When an implementation that supports this abstract receives an association request with this
abstract included, it shall include this abstract syntax in the association accept.
The MMS abstract syntax is defined in 24.11 of ISO 9506-2:2003 as:
id-mmsAS OBJECT IDENTIFIER ::=
{ iso(1) standard(0) iso9506(9506) part(2) mms-abstract-syntax-version1(1) }
11.1.4.2 Application context
Replace the existing text:
basic-AC OBJECT IDENTIFIER ::= { iso(1) standard(0) iso9506(9505) part(2) mms-
application-context-version1(3) }
with the following new text:
basic-AC OBJECT IDENTIFIER ::= { iso(1) standard(0) iso9506(9506) part(2) mms-
application-context-version1(3) }
11.1.4.3 Authentication mechanism
Replace the existing text of 11.1.4.3 with the following new text:
The mechanism-name component of the AARQ-apdu or AARE-apdu shall be present and shall have
the following value:
{ 1 0 840 0 1 0 1 1 }
11.1.4.4 Authentication value
Replace the second occurrence of the Authentication-value ASN.1 specification with the
following new specification:
Authentication-value ::= CHOICE {
external [2] IMPLICIT SEQUENCE {
identification CHOICE {
indirect-reference INTEGER } OPTIONAL, -- for the mmsAuthenticationAS
encoding CHOICE {
single-ASN1-type [0] MMS-Authentication-value } } }
Replace the existing penultimate paragraph with the following new text:
An implementation that includes the mmsAuthenticationAS abstract syntax in an association
request or accept shall also include the identification component. Otherwise, the
identification component shall be absent.
11.2.1 General
Replace the existing note in 11.2.1 with the following new text:
---------------------- Page: 15 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
– 10 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
NOTE As this module specifies IMPLICIT TAG, implicit tagging is assumed anywhere it is relevant. It is not
necessary to use the IMPLICIT lexical item in the MMS_Authentication-value data type, but it is retained to be
consistent with IEC TS 62351-4:2007.
11.2.2 MMS-Authentication value data type
Replace in 11.2.2 the existing MMS-Authentication-value data type with this new specification:
MMS-Authentication-value ::= CHOICE {
certificate-based [0] IMPLICIT SEQUENCE {
authentication-Certificate [0] IMPLICIT SignatureCertificate,
time [1] IMPLICIT GeneralizedTime,
signature [2] IMPLICIT SignedValue,
. },
. }
In item a) replace the word "evaluating" with the word "verifying".
Replace the existing text of item b) with the following new text:
The accuracy of this time is a local issue but shall be as accurate as possible. It is equally valid
to determine the value of the time parameter during the invocation of the MMS Initiate. Request
service, Initiate Response service, or during the encoding of the ACSE PDUs for those services.
12.1 Introduction and general architecture
Replace, in the fourth paragraph of 12.1, "might" with "may".
Delete, in the fifth paragraph, the word "mutual".
Replace, in NOTE 2, the word "SecPDU" by "SecPDUs".
Replace, in the ninth paragraph, the word "of" with "for".
13.1.2 UTC time specification
Add, in item b) of 13.1.2 "in" before "24-hour clock system".
13.1.3 Handshake request
Replace the existing text of item a) of 13.1.3 with the following new text:
a) The pp component specifies the identity of the application that shall be protected by E2E
security. It shall be the nomination for the protected protocol as follows:
1) for IEC 60870-6-503 [2] the value shall be "IEC 60870-6-503";
2) for IEC 60870-6-702 [3] the value shall be "IEC 60870-6-702";
3) for IEC 60870-6-802 [4] the value shall be "IEC 60870-6-802";
4) for IEC 61850-8-1 [20] the value shall be "IEC 61850-8-1"; and
5) for IEC 61850-8-2 [21] the value shall be "IEC 61850-8-2".
Other values may be added as required in the future.
Replace the existing text of item c) of 13.1.3 with the following new text:
c) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
---------------------- Page: 16 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
IEC 62351-4:2018/AMD1:2020 – 11 –
© IEC 2020
13.1.4 Handshake accept
Replace the existing text of item b) of 13.1.4 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.5 Association reject by the protected protocol
Replace the existing text of the first paragraph of 13.1.5 with the following new text:
A protected protocol may cause an association request to be rejected by use of the
ApplicationReject SecPDU.
Replace the existing text of item b) of 13.1.5 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.6 Association reject due to security issues
Replace, in point 2) of 13.1.6, "a security event" with "an alarm event".
Replace the existing text of point 3) with the following new text:
3) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.8 Data transfer security abort
Replace the existing text of the first paragraph 13.1.8 with the following new text:
A DtSecAbort SecPDU is issued when a security problem is encountered within the E2E security
protocol control information during the data transfer phase. Integrity and authentication are
provided by a digital signature rather than an ICV.
Replace, in point a)2) of 13.1.8 "a security event" by "an alarm event".
Replace the existing text of point b) of 13.1.8 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.9 Abort by protected protocol
Replace the existing text of point b) of 13.1.9 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
---------------------- Page: 17 ----------------------
SIST EN IEC 62351-4:2019/A1:2020
– 12 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.10 Association release request
Replace the existing text of point b) of 13.1.10 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall b
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.