EN 62351-11:2017

SLOVENSKI STANDARD
01-april-2017
8SUDYOMDQMHHOHNWURHQHUJHWVNHJDVLVWHPDLQSULSDGDMRþDL]PHQMDYDLQIRUPDFLM
9DUQRVWSRGDWNRYLQNRPXQLNDFLMGHO9DUQRVWGDWRWHN;0/
Power systems management and associated information exchange - Data and
communications security - Part 11: Security for XML files
Ta slovenski standard je istoveten z: EN 62351-11:2017
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 62351-11

NORME EUROPÉENNE
EUROPÄISCHE NORM
February 2017
ICS 33.200
English Version
Power systems management and associated information
exchange - Data and communications security - Part 11:
Security for XML documents
(IEC 62351-11:2016)
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 11: Sécurité des documents XML Kommunikation - Teil 11: Sicherheit für XML-Dateien
(IEC 62351-11:2016) (IEC 62351-11:2016)
This European Standard was approved by CENELEC on 2016-11-02. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard 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 European Standard 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, 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: Avenue Marnix 17, B-1000 Brussels
© 2017 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 62351-11:2017 E
European foreword
The text of document 57/1753/FDIS, future edition 1 of IEC 62351-11, 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 62351-11:2017.
The following dates are fixed:
(dop) 2017-08-10
• latest date by which the document has to be implemented at
national level by publication of an identical national
standard or by endorsement
• latest date by which the national standards conflicting with (dow) 2020-02-10
the 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 [and/or CEN] shall not be held responsible for identifying any or all such
patent rights.
Endorsement notice
The text of the International Standard IEC 62351-11:2016 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-6 NOTE Harmonized as EN 61850-6.
IEC 61970-552 NOTE Harmonized as EN 61970-552.
IEC 62351-1 NOTE Harmonized as EN 62351-1.
IEC 62351-3 NOTE Harmonized as EN 62351-3.

Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
NOTE 1 When 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.
Publication Year Title EN/HD Year
IEC 62351-9 -  Power systems management and - -
associated information exchange - Data
and communications security - Part 9:
Cyber security key management for power
system equipment
IEC/TS 62351-2 -  Power systems management and - -
associated information exchange - Data
and communications security - Part 2:
Glossary of terms
IEC/TS 62351-8 -  Power systems management and - -
associated information exchange - Data
and communications security - Part 8:
Role-based access control
IETF RFC 6931 -  Additional XML Security Uniform Resource - -
Identifiers (URIs)
W3C -  - -
Recommended
Canonical XML 1.0
W3C Required-   - -
Canonical XML1.0
W3C XML 1.1 -  Signature Syntax and Processing_- - -
Version 1.1
W3C XML -  XML Signature Syntax and Processing - -
Signature
IEC 62351-11 ®
Edition 1.0 2016-09
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Power systems management and associated information exchange – Data and

communications security –
Part 11: Security for XML documents

Gestion des systèmes de puissance et échanges d’informations associés –

Sécurité des communications et des données –

Partie 11: Sécurité des documents XML

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.200 ISBN 978-2-8322-3636-9

– 2 – IEC 62351-11:2016  IEC 2016
CONTENTS
FOREWORD. 4
1 Scope . 6
2 Normative references . 7
3 Terms and definitions . 7
4 Security issues addressed by this document . 8
4.1 General . 8
4.2 Security threats countered . 8
4.3 Attack methods countered . 8
5 XML Documents . 8
6 XML document encapsulation . 10
6.1 General . 10
6.2 HeaderType . 11
6.3 Information . 12
6.3.1 General . 12
6.3.2 Nonce . 13
6.3.3 AccessControl . 13
6.3.4 Body . 20
6.4 Encrypted element . 21
6.4.1 General . 21
6.4.2 EncryptionMethod . 21
6.4.3 CipherData . 22
6.4.4 KeyInfo . 22
6.5 SignatureType. 23
6.5.1 General . 23
6.5.2 SignedInfoType . 23
6.6 Supporting XSD Types . 27
6.6.1 General . 27
6.6.2 NameSeqType . 27
6.7 Security algorithm selection . 27
7 Example files (informative) . 28
7.1 Non-encrypted example . 28
7.2 Encrypted example . 30
8 IANA list of signature, digest, and encryption methods (informative) . 32
Bibliography . 37

Figure 1 – Overview of IEC 62351-11 structure . 6
Figure 2 – Data in transition example . 9
Figure 3 – Secure encapsulation for XML documents . 10
Figure 4 – General IEC 62351-11 XSD layout . 10
Figure 5 – XSD ComplexType definition of HeaderType . 11
Figure 6 – XSD ComplexType definition of information. 12
Figure 7 – XSD Complex Type Definition of AccessControl . 13
Figure 8 – XSD Complex Type definition of AccessControlType . 14
Figure 9 – XSD Complex Type Definition of ACLRestrictionType . 15

IEC 62351-11:2016  IEC 2016 – 3 –
Figure 10 – XSD Complex Type definition of EntityType . 17
Figure 11 – Example of AccessControl and XPATH . 19
Figure 12 – Example of an IEC 62351-11 Body with a CIM document . 20
Figure 13 – Structure of the IEC 62351-11 Encrypted element . 21
Figure 14 – Structure of EncryptionMethodType . 21
Figure 15 – Structure of CipherDataType. 22
Figure 16 – EncryptedData element definition . 22
Figure 17 – W3C SignatureType definition . 23
Figure 18 – SignedInfotype XML structure . 24
Figure 19 – SignatureMethodType structure . 24
Figure 20 – ReferenceType structure . 25
Figure 21 – KeyInfoType Structure . 26
Figure 22 – Definition of NameSeqType . 27

Table 1 – Definitions of general structure for an IEC 62351-11 document . 11
Table 2 – Definition of HeaderType Element . 12
Table 3 – Definition of information element . 13
Table 4 – Definition of Contractual and ACL Element . 14
Table 5 – Definition of ACLRestrictionType Element . 15
Table 6 – Definition of Enumerated Values for ACLType . 16
Table 7 – Definition of Enumerated Values for Constraint . 16
Table 8 – Definition of EntityType Element . 17

– 4 – IEC 62351-11:2016  IEC 2016
INTERNATIONAL ELECTROTECHNICAL COMMISSION
_____________
POWER SYSTEMS MANAGEMENT AND
ASSOCIATED INFORMATION EXCHANGE –
DATA AND COMMUNICATIONS SECURITY –

Part 11: Security for XML documents

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62351-11 has been prepared by IEC technical committee 57:
Power systems management and associated information exchange.
The text of this standard is based on the following documents:
FDIS Report on voting
57/1753/FDIS 57/1774/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

IEC 62351-11:2016  IEC 2016 – 5 –
A list of all parts of the IEC 62351 series, published under the general title Power systems
management and associated information exchange – Data and communications security, can
be found on the IEC website.
The committee has decided that the contents of this 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.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – IEC 62351-11:2016  IEC 2016
POWER SYSTEMS MANAGEMENT AND
ASSOCIATED INFORMATION EXCHANGE –
DATA AND COMMUNICATIONS SECURITY –

Part 11: Security for XML documents

1 Scope
This part of IEC 62351 specifies schema, procedures, and algorithms for securing XML
documents that are used within the scope of the IEC as well as documents in other domains
(e.g. IEEE, proprietary, etc.). This part is intended to be referenced by standards if secure
exchanges are required, unless there is an agreement between parties in order to use other
recognized secure exchange mechanisms.
This part of IEC 62351 utilizes well-known W3C standards for XML document security and
provides profiling of these standards and additional extensions. The IEC 62351-11 extensions
provide the capability to provide:
• Header: the header contains information relevant to the creation of the secured document
such as the Date and Time when IEC 62351-11 was created.
• A choice of encapsulating the original XML document in an encrypted (Encrypted) or non-
encrypted (nonEncrypted) format. If encryption is chosen, there is a mechanism provided
to express the information required to actually perform encryption in an interoperable
manner (EncryptionInfo).
• AccessControl: a mechanism to express access control information regarding information
contained in the original XML document.
• Body: is used to contain the original XML document that is being encapsulated.
• Signature: a signature that can be used for the purposes of authentication and tamper
detection.
The general structure is shown in Figure 1.
IEC
Figure 1 – Overview of IEC 62351-11 structure
For the measures described in this document to take effect, they must be accepted and
referenced by the specifications themselves. This document is written to enable that process.
The subsequent audience for this part of IEC 62351 is intended to be the developers of
products that implement these specifications.
Portions of this part of IEC 62351 may also be of use to managers and executives in order to
understand the purpose and requirements of the work.

IEC 62351-11:2016  IEC 2016 – 7 –
2 Normative references
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.
IEC TS 62351-2, Power systems management and associated information exchange – Data
and communications security – Part 2: Glossary of terms
IEC TS 62351-8, Power systems management and associated information exchange – Data
and communications security – Part 8: Role-based access control
IEC TS 62351-9, Power systems management and associated information exchange – Data
and communications security – Part 9: Cyber security key management for power system
equipment
Recommended Canonical XML1.0 with comments, W3C,
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
Required Canonical XML 1.0, Omits comments, W3C,
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
RFC 6931, Additional XML Security Uniform Resource Identifiers (URIs)
XML Encryption Syntax and Processing Version 1.1 April 11, 2013,
http://www.w3.org/TR/xmlenc-core1/
XML Signature Syntax and Processing W3C Recommendation 10 June 2008,
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TS 62351-2 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
nonce
random or pseudo-random value used within an authentication system
[SOURCE: IEEE Std 1455-1999, IEEE Standard for Message Sets for Vehicle/Roadside
Communications]
3.2
IANA
Internet Assigned Numbers Authority
Note 1 to entry: IANA is responsible for the global coordination of the DNS Root, IP addressing, and other
Internet protocol resources.
[SOURCE: http://www.iana.org]
– 8 – IEC 62351-11:2016  IEC 2016
4 Security issues addressed by this document
4.1 General
Within the industry and the IEC, XML document exchange is becoming more prevalent. Within
the scope of the IEC, exchanges of XML documents are used for IEC 61970 as well as
IEC 61850. Within other standards, such as IEEE 1815 and IEEE C37.111 (COMTRADE),
XML is also utilized. For these standards and other XML-based documentss, the information
contained in thedocument may:
1) be sensitive to inadvertant or malicious modifications of its contents that could result in
mis-operation/misinterpretation if the exchanged information is used (e.g. a tamper
security vulnerability);
2) contain confidential or private data;
3) contain subsets of information that may be considered sensitive by the document creation
entity.
This part of IEC 62351 proposes to standardize mechanisms to protect the document contents
from tampering/disclosure when the document is being exchanged (e.g. in transit).
Additionally, this part of IEC 62351 proposes to standardize a mechanism to aid in the
protection of the information when in transition (e.g. entity A trusts entity B; B trusts A and C,
and B needs to exchange information with C. but A does not know of or trust C).
Although this document is intended to secure XML documents used within the scope of the
IEC, the mechanism/methodologies specified within this document can be applied to any XML
document.
4.2 Security threats countered
See IEC TS 62351-1 for a discussion of security threats and attack methods.
If encryption is not employed, then the specific threats countered in this part of IEC 62351
include:
• unauthorized modification (tampering) of information through XML document level
authentication.
If encryption is employed, then the specific threats countered in this part of IEC 62351
include:
• unauthorized access to information through XML document level authentication and
encryption of the documents;
• unauthorized modification (tampering) of information through XML document level
authentication regardless if encryption is utilized.
4.3 Attack methods countered
The following security attack methods are intended to be countered through the appropriate
implementation of the specification/recommendations found within this document:
• man-in-the-middle: this threat will be countered through the use of a Message
Authentication Code (e.g. Signature) mechanism specified within this document;
• message tampering: These threats will be countered through the algorithm used to create
the authentication mechanism as specified within this document.
5 XML Documents
In order to provide adequate security, there needs to be an understanding of the environment
of use that this specification is addressing:

IEC 62351-11:2016  IEC 2016 – 9 –
• Documents at rest: When XML documents are stored (e.g. at rest), tamper detection is a
minimum requirement. If the document contains sensitive information, then the
confidentiality of that information needs to be protected through the use of authenticated
encryption. In order to accomplish both objectives, this means that the un-encrypted
document needs a signature and the encrypted document also needs its own
signature/integrity protection. The protection of XML documents at rest is out-of-scope of
this standard and should be implemented through local means.
• Documents in transit: The protection of documents in transit requires tamper detection
and authentication as minimum requirements. If the document contains sensitive
information, then the confidentiality of that information needs to be protected through the
use of authenticated encryption. In order to accomplish both objectives, this means that
the un-encrypted document needs a signature and the encrypted document also needs its
own signature/integrity protection.
• Documents in transition: In the domain of the IEC, the recipients of XML documents
typically decrypt and parse the information from those documents into a database. The
information from the database can then be re-exported to a third actor, in any form
(including another XML document). If sensitive or confidential information was provided in
the initial document, there is no technological mechanism to prevent the application from
exporting that information and defining access controls.
A real example use case is the transfer of power system topology information through the
use of IEC 61970-552.
Utility A Utility B
Generates
General
Imported
General General
into
Restricted Restricted
Database
CIM XML
Provided to
Utility C
IEC
Figure 2 – Data in transition example
Figure 2 illustrates this potential problem with Data in Transition. Utility A provides a CIM
XML document to Utility B. The document contains the information that must be exchanged
between Utility A and Utility B, based upon the trust/agreements between those utilities. Utility
B imports the information into its database (e.g. EMS). A separate exchange of information
then needs to occur between Utility B and Utility C. Utility A may have no knowledge that such
a transfer may be needed and that some of the “restricted” information may be at risk for
export by Utility B. The goal of the approach to handling data-in-transition recommended here
is to allow Utility A to classify and label specific document content as being sensitive or
confidential and therefore not to be re-exported to partners of Utility B.
Note that document signing, as described herein, is not sufficient for this purpose, as Utility B
has a legitimate use for the restricted content and accordingly has the ability to decrypt it for
import into an application database. Therefore, another solution needs to be provided –
namely, the contractual access-control mechanism described in 6.3.3.
_______________
Actors in these scenarios are not confined to utilities, but may be RTOs, market exchanges/portals, consumer-
program facilitators, etc.
– 10 – IEC 62351-11:2016  IEC 2016
Within the context of the IEC, there are at least two well-known XML document types that
required protection: CIM XML and SCL documents. These documents have well formed
XSDs/formats. As such, the mechanism specified in this standard are intended to allow the
documents formats to be preserved. Therefore, encapsulation of the original documents is the
design approach.
6 XML document encapsulation
6.1 General
The concept of security encapsulation for XML documents is shown in Figure 3.
62351 Envelope
XML Encryption Information
Nonce
Bytes covered by Signature
Data in Transition
Encrypted Bytes
Original
XML
Document
Security Signature
IEC
Figure 3 – Secure encapsulation for XML documents
The concept is to utilize previously standardized XML security techniques to provide a
security header, signature, and document encryption capability. Within the “secure” document
is the original XML document and extensions specified by this standard. The IEC 62351-11
extensions provide the capability to provide:
• IEC 62351 Envelope (Header): the header contains information relevant to the
encapsulation such as the Date and Time of the encapsulation (e.g. document creation).
• XML Encryption Information: a choice of encapsulating the original XML document ACL in
an encrypted (Encrypted) or non-encrypted (nonEncrypted) format. If encryption is chosen,
there is a mechanism provided to express the information required to actually perform
encryption in an interoperable manner (EncryptionInfo).
• Data in Transition: a mechanism to express access control information regarding
information contained in the original XML document.
• Original XML Document (Body): is used to contain the original XML document that is being
encapsulated.
• Signature: a signature that can be used for the purposes of authentication and tamper
detection.
IEC
Figure 4 – General IEC 62351-11 XSD layout

IEC 62351-11:2016  IEC 2016 – 11 –
Figure 4 depicts the general XSD structure of an IEC 62351-11 document. The definitions can
be found in Table 1.
Table 1 – Definitions of general structure for an IEC 62351-11 document
Element Optional (O)/ XSD Description
Mandatory (M)/ Type
Conditional (C)
Header M HeaderType The Header contains information regarding the creation
(see 6.2) of the IEC 62351-11 document and contact information
should questions or issues arise with the document.
nonEncrypted C Information Provides access control and wrapping of the original
(see 6.3) document in a non-encrypted (e.g. original document
contents can still be viewed). This choice should be
utilized by a user should confidentiality of the
information not be of concern or if confidentiality is
being provided through an external mechanism.

Either the nonEncrypted or Encrypted XSD element
shall be present.
Encrypted C EncryptedType Provides encryption to the access control and wrapping
(see 6.4) of the original document. This choice should be utilized
by the user should confidentiality of information be
desired and is not provided through external
mechanisms.
Either the nonEncrypted or Encrypted XSD element
shall be present.
Signature M SignatureType Is a production of the W3C XML Signature information.

Any implementation claiming conformance to this standard shall implement all mandatory
elements.
6.2 HeaderType
Figure 5 shows the XSD structure of the HeaderType.
IEC
Figure 5 – XSD ComplexType definition of HeaderType
The HeaderType is a XSD complex type that consists of a sequence of XSD elements as
described in Table 2.
– 12 – IEC 62351-11:2016  IEC 2016
Table 2 – Definition of HeaderType Element
Element Optional (O)/ XSD Description
Mandatory (M)/ Type
Conditional( C )
VersionNumber M xs:float Is the version number of the IEC 62351-11
standard being implemented. The floating
point number shall specify
.. The value
shall be “1.0”
DateTimeOfEncapsulation M xs:DateTime The value specifies the date and time at
which the original document was wrapped.
FileDesc O xs:string A user supplied description of the document
and its contents. If the Body (e.g. original
document) is encrypted or hexascii
encoded, this element is mandatory since
user will not be able to determine the
contents of the document should questions
arise.
All encapsulated documents shall share this
description.
ResponsibleEntity O NameSeqType A user supplied Entity name that can be
(see 6.6.2) used by a user of the document to know
who to contact should there be issues or
questions regarding the document.
ContactInformation O xs:string Is a user supplied string that may contain
phone or email information that could be
used by a document user should problems
or questions occur.
6.3 Information
6.3.1 General
Figure 6 shows the structure of the information type.
IEC
Figure 6 – XSD ComplexType definition of information
. It is an XSD Sequence of the following sub-elements: Nonce; AccessControl; and Body. The
definition of these elements, and their types, can be found in Table 3.

IEC 62351-11:2016  IEC 2016 – 13 –
Table 3 – Definition of information element
Element Optional (O)/ XSD Description
Mandatory (M)/ Type
Conditional( C )
Nonce M xs:string See 6.3.2.
AccessControl O AccessControlType This element allows for access control
See 6.3.3  information to be expressed.
The default value for AccessControl is
Allow All if there is no AccessControl
element present.
Body M xs:anyType The element provides the capability to
encapsulate one or more documents
within the same IEC 62351-11
document.
6.3.2 Nonce
This element represents a security related attribute that ensures that if the same Body is
using the same credentials, that at least the signature will be different. In many situations, a
cryptographic nonce should be cryptographically random. However, for the purposes of this
standard, randomness is not a requirement but some uniqueness is desired.
In order to prevent the same nonce value requiring cryptographic generation, it is suggested
that an acceptable nonce value could contain a DateTime value and a UUID. The nonce must
not be reused for any key and should be random.
6.3.3 AccessControl
6.3.3.1 General
AccessControl allows zero(0), because AccessControl is optional, or more sets of access
information to be specified for the wrapped document(s). The XSD type for AccessControl is
shown in Figure 7.
IEC
Figure 7 – XSD Complex Type Definition of AccessControl
The AccessControl element is an XSD Sequence that consists of one or more
AccessControlInformation(s). Each AccessControlInformation is of an XSD type of
AccessControlType whose structure is shown in Figure 8.

– 14 – IEC 62351-11:2016  IEC 2016

IEC
Figure 8 – XSD Complex Type definition of AccessControlType
AccessControlType allows a choice between a Contractual (e.g. legally binding document)
restriction and the definition of the equivalent of an access control list (ACL). Each choice
allows the governance of access (e.g. Contract or ACLRestriction) to be applied to one or
more sets of information within the wrapped original document through the use of one or more
XPATH statements.
The Contractual choice is a XSD Sequence that consists of the elements that are defined in
Table 4.
Table 4 – Definition of Contractual and ACL Element
Element Optional (O)/ XSD Description
Mandatory (M)/ Type
Conditional( C )
ContractualDocumentName M xs:normalizedSt A user supplied reference to a legal
ring contract that contains information
relevant to the allowed access
rights/privileges regarding the
information specified in the XPATH
statements.
ACLRestriction M ACLRestriction A complex specification of access rights
Type that allow the specification of allowance
(see 6.3.3.2 ) or denial of specific types of access
based upon specific roles.
The use of ACLRestriction allows the
user to specify the equivalent of White
or Black listing.
XPATH O xs:normalizedSt This element contains the XPATH value
ring that expresses the information contained
(see 6.3.3.7) in Body for which guidance is being
given.
If there is no XPATH defined, the entire
Body is assumed.
IEC 62351-11:2016  IEC 2016 – 15 –
6.3.3.2 AccessRestrictionType
IEC
Figure 9 – XSD Complex Type Definition of ACLRestrictionType
Figure 9 shows the structure of the ACLRestrictionType. It is an XSD Complex Type that is a
sequence of the XSD elements defined in Table 5.
Table 5 – Definition of ACLRestrictionType Element
Element Optional (O)/ XSD Description
Mandatory (M)/ Type
Conditional( C )
ACLType M xs:string Specifies if the access restriction is
(see 6.3.3.3) Allow or Deny. As such, the allowed
enumerated values for ACLType are:
Allow and Deny.
ACLConstraints M Complex Allows a user to specify a sequence of
(see 6.3.3.4) rights that are allowed or denied. This
capability is provided through a
sequence of Constraint elements.
ACLAppliedTo M EntityType Allows the user to express the type of
definition used to specify what entity the
ACL applies to.
ACLExpiration O xs:dateTime Specifies the date and time at which
access control is no longer required. If
the value is not present, the ACL does
not expire.
Since there may be multiple ACLs within a single IEC 62351-11 document, an ACLType value
of Deny, shall have precedence for situations where there are common Constraint values and
the same or overlapping ACLAppliedTo values.
6.3.3.3 ACLType
The ACLType is an xs:string whose values are restricted through enumeration. The definitions
of the allowed enumerated values, and the order of enumeration, is shown in Table 6.

– 16 – IEC 62351-11:2016  IEC 2016
Table 6 – Definition of Enumerated Values for ACLType
Enumeration Definition
Value
Allow Specifies that the ACLRestrictionType is being used to create a
white list and that the specified ACLContstraints are allowed
privileges for the specified ACLAppliedTo.
Deny Specifies that the ACLRestrictionType is being used to create a
black list and that the specified ACLContstraints are disallowed
privileges for the specified ACLAppliedTo.

6.3.3.4 ACLConstraints and Constraint
ACLConstraints are a sequence of Constraint values as shown in Table 7.
The Constraint element is an xs:string whose values are restricted through enumeration. The
use of the Constraint(s) is governed by the ACLType.
Unlike file privileges which are enforceable, the Constraint values represent guidance how
Data in Transition should be handled. The values are shown in Table 7.
Table 7 – Definition of Enumerated Values for Constraint
Enumeration Definition
Value
All Specifies that all privileges of Read, Write, and List are
specified.
Read privilege, if allowed, indicates the ability to provide the
value/element to another entity.

Write privilege, if allowed, indicates the ability for an entity to
change the value/element.
List privilege, if allowed, indicates the ability for an entity to
determine if the value/element exists.

Therefore, the All value is mutually exclusive from Read,
Write, List, and Forward. If All is specified within a specific
instance of ACLConstraints, no other enumerated values shall
be used within that sequence.
TransmitValue The permission specifies the ability to convey the value of the
information, specified by XPATH, to another entity. The
specification of Read implies List. As an example, a utility
would be able to supply the information to another utility if
Allow was the ACLType.
This is the equivalent of Read and List.
Write The permission specifies the ability to allow modification the
value of the information specified by XPATH

6.3.3.5 EntityType
Figure 10 shows the structure of the EntityType.

IEC 62351-11:2016  IEC 2016 – 17 –

IEC
Figure 10 – XSD Complex Type definition of EntityType
It is a XSD sequence that allows a combination of entity specifications to be combined in
order to determine entity to which the ACL applies. The XSD elements defined in EntityType
are defined in Table 8.
Table 8 – Definition of EntityType Element
Element Optional (O)/ XSD Description
Mandatory (M)/ Type
Conditional( C )
DistinguishedName M NameSeqType User supplied name that can be used by
(see 6.6.2) a user of the document to know who
(e.g. organization or person) to contact
and to whom the ACL should be applied.
URL M xs:anyURI Allows the specification of a web
address to which the ACL should be
applied. In many cases, an organization
may be referred to via URL or a
particular FTP site may need to be
restricted.
Role O xs:string Is a string value that specifies the type
(see 6.3.3.6) of security/work role grouping to which
the ACL should be applied.
The combination of the values can be used to constrain access, As an example, the
combination of DistinguishedName and Role could be used to constrain an ACL to a role
within a given department of a company.
6.3.3.6 Role
The Role is an xs:string whose values are restricted through enumeration. The definitions of
the allowed string values are defined per IEC TS 62351-8.
6.3.3.7 XPATH
This element contains the XPATH value that expresses the information contained in Body for
which guidance is being given. If no XPATH is specified, for a specified constraint, the
constraint shall apply to the entire Body element.

– 18 – IEC 62351-11:2016  IEC 2016

As an example:

xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iec.ch/2014/01/62351-11# file:///C:/Users/root/Desktop/IEC62351-11/IEC62351-11.xsd">

2014-04-14T21:32:52
Example IEC 62351-11 non-encrypted file


8534341094
...