ETSI GS NFV-SOL 004 V3.6.1 (2022-01)

Network Functions Virtualisation (NFV) Release 3; Protocols and Data Models; VNF Package and PNFD Archive specification

RGS/NFV-SOL004ed361

General Information

• Status: Not Published
• Technical Committee: NFV SOL - Solutions
• Current Stage: 12 - Completion
• Due Date: 15-Feb-2022
• Completion Date: 21-Jan-2022

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 3;
Protocols and Data Models;
VNF Package and PNFD Archive specification
Disclaimer
The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)

Reference
RGS/NFV-SOL004ed361
Keywords
data, NFV, protocol, virtualisation

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 8
4 VNF package . 8
4.1 TOSCA YAML Cloud Service Archive (CSAR) overview . 8
4.1.1 CSAR structure . 8
4.1.2 CSAR with TOSCA-Metadata directory . 8
4.1.2.1 General . 8
4.1.2.2 TOSCA.meta file extension . 9
4.1.2.3 TOSCA.meta file keynames extension . 9
4.1.3 CSAR without TOSCA-Metadata directory . 10
4.1.3.1 General . 10
4.1.3.2 TOSCA Entry definition file metadata extension for a YANG-based VNFD . 10
4.1.4 Void . 10
4.2 VNF package structure and format . 10
4.3 VNF package file contents . 11
4.3.1 General . 11
4.3.2 VNF package manifest file . 11
4.3.3 VNF package change history file . 13
4.3.4 VNF package testing files . 13
4.3.5 VNF package licensing information . 13
4.3.6 Certificate file . 13
4.3.7 Non-MANO artifact sets in a VNF package . 14
5 Adding security to TOSCA CSAR . 14
5.1 VNF package authenticity and integrity . 14
5.2 VNF package manifest and certificate files . 15
5.3 Conventions in the manifest file . 16
5.4 Signature of individual artifacts . 17
5.5 Support for security sensitive artifacts . 18
6 PNFD archive . 19
6.1 General . 19
6.2 Actors and roles . 19
6.3 PNFD archive file contents . 19
6.3.1 General . 19
6.3.2 PNFD archive manifest file . 19
6.3.3 Not applicable clauses . 20
Annex A (informative): TOSCA CSAR examples . 21
A.1 CSAR with the TOSCA-Metadata directory . 21
A.2 CSAR without the TOSCA-Metadata directory . 21
A.3 CSAR with the YANG VNFD without TOSCA.meta directory . 22
Annex B (normative): Non-MANO artifact sets registry . 23
ETSI
4 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
B.1 General . 23
B.2 Non-MANO artifact set identifier format. 23
B.3 Registered information . 23
B.4 Initial registration . 24
B.4.1 Template . 24
B.4.2 Template . 24
B.5 Registration update . 25
Annex C (informative): Bibliography . 26
Annex D (informative): Change History . 27
History . 30

ETSI
5 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
1 Scope
The present document specifies the structure and format of a VNF package file and its constituents, fulfilling the
requirements specified in ETSI GS NFV-IFA 011 [1] for a VNF package.
The present document also specifies the structure and format of a PNFD archive file and its constituents, fulfilling the
requirements specified in ETSI GS NFV-IFA 014 [i.9] for a PNFD archive.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS NFV-IFA 011: "Network Functions Virtualisation (NFV) Release 3; Management and
Orchestration; VNF Descriptor and Packaging Specification".
[2] OASIS TOSCA-Simple-Profile-YAML-v1.1-csprd01: "TOSCA Simple Profile in YAML
Version 1.1".
NOTE: Available at http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/csprd01/TOSCA-
Simple-Profile-YAML-v1.1-csprd01.html.
[3] IETF RFC 3339: "Date and Time on the Internet: Timestamps".
[4] IANA register for Hash Function Textual Names.
NOTE: Available at https://www.iana.org/assignments/hash-function-text-names/hash-function-text-
names.xhtml.
[5] IETF RFC 5652 (September 2009): "Cryptographic Message Syntax (CMS)".
[6] IETF RFC 7468: "Textual Encodings of PKIX, PKCS, and CMS Structures".
[7] Void.
[8] Recommendation ITU-T X.509: "Information technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate frameworks".
[9] Void.
[10] IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5".
[11] OASIS TOSCA-Simple-Profile-yaml-v1.3: "TOSCA Simple Profile in YAML Version 1.3".
NOTE: Available at https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/TOSCA-Simple-
Profile-YAML-v1.3.html.
[12] ISO/IEC 21320-1: "Information technology -- Document Container File -- Part 1: Core".
ETSI
7 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Void.
[i.2] Void.
[i.3] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.4] ETSI GS NFV-SOL 001: "Network Functions Virtualisation (NFV) Release 3; Protocols and Data
Models; NFV descriptors based on TOSCA specification".
[i.5] ETSI NFV registry of non-MANO artifact sets.
NOTE: Available at http://register.etsi.org/NFV.
[i.6] ETSI GS NFV-SOL 006: "Network Functions Virtualisation (NFV) Release 3; Protocols and Data
Models; NFV descriptors based on YANG specification".
[i.7] ETSI GS NFV-SOL 004 (V2.4.1): "Network Functions Virtualisation (NFV) Release 2; Protocols
and Data Models; VNF Package specification".
[i.8] ETSI GS NFV-SOL 004 (V2.5.1): "Network Functions Virtualisation (NFV) Release 2; Protocols
and Data Models; VNF Package specification".
[i.9] ETSI GS NFV-IFA 014: "Network Functions Virtualisation (NFV) Release 3; Management and
Orchestration; Network Service Templates Specification".
[i.10] ETSI GS NFV-SOL 005: "Network Functions Virtualisation (NFV) Release 3; Protocols and Data
Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [i.3] and the following apply:
non-MANO artifact: artifact for use by functional blocks beyond NFV-MANO
non-MANO artifact set: set of related non-MANO artifacts which are intended to be used together
3.2 Symbols
Void.
ETSI
8 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASCII American Standard Code for Information Interchange
CA Certificate Authority
CMS Cryptographic Message Syntax
CSAR Cloud Service ARchive
IANA Internet Assigned Number Association
MANO Management and Orchestration
NFVI NFV Infrastructure
NFVO NFV Orchestrator
PKCS Public Key Cryptographic Standard
PNF Physical Network Function
PNFD PNF Descriptor
TOSCA Topology and Orchestration Specification for Cloud Applications
URI Universal Resource Identifier
UTF Unicode Transformation Format
VNF Virtualised Network Function
VNFD VNF Descriptor
YAML YAML Ain't Markup Language
YANG Yet Another Next Generation
4 VNF package
4.1 TOSCA YAML Cloud Service Archive (CSAR) overview
4.1.1 CSAR structure
TOSCA YAML CSAR file is an archive file using the ZIP file format whose structure complies with the TOSCA
Simple Profile YAML v1.1 [2] or the TOSCA Simple Profile in YAML v1.3 [11]. According to the TOSCA Simple
Profile YAML v1.1 [2], the CSAR file shall have one of the two following structures:
• CSAR containing a TOSCA-Metadata directory, which includes the TOSCA.meta metadata file providing an
entry information for processing a CSAR file.
• CSAR without a TOSCA-Metadata directory and containing a single yaml file with a .yml or .yaml extension
at the root of the archive. The yaml file is a TOSCA definition template that shall contain a metadata section
with template_name and template_version keyname.
In addition, the CSAR file may optionally contain other directories with bespoke names and contents.
4.1.2 CSAR with TOSCA-Metadata directory
4.1.2.1 General
The TOSCA.meta metadata file includes block_0 with the Entry-Definitions keyword pointing to a TOSCA definitions
YAML file and optionally the Other-Definitions keyword as specified in TOSCA Simple Profile YAML v1.3 [11]
pointing to other TOSCA definitions YAML files used as entries for parsing the contents of the overall CSAR archive.
Any TOSCA definitions files besides the one denoted by the Entry-Definitions and Other-Definitions keyword can be
found by processing respective imports statements in the entry definitions files (or in recursively imported files).
Any additional artifacts files (e.g. scripts, binaries, configuration files) can be either declared explicitly through blocks
in the TOSCA.meta file or pointed to by relative path names through artifact definitions in one of the TOSCA
definitions files contained in the CSAR file as described in TOSCA Simple Profile YAML v1.1 [2].
Extension of the TOSCA.meta file is described in clause 4.1.2.2.
ETSI
9 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
In order to indicate that the simplified structure (i.e. not all files need to be declared explicitly) of TOSCA.meta file
allowed by TOSCA Simple profile YAML 1.1 [2] is used, the CSAR-Version keyword listed in block_0 of the meta-file
denotes the version 1.1 as described in the below example.
EXAMPLE:
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-by: Onboarding portal
Entry-Definitions: Definitions/MainServiceTemplate.yaml

END OF EXAMPLE.
4.1.2.2 TOSCA.meta file extension
The TOSCA.meta file structure extension is used when files defined in clauses 4.3.2 to 4.3.6 of the present document
are included in the VNF package and when using CSAR with TOSCA-Metadata directory, as described in
clause 4.1.2.1.
NOTE: TOSCA Simple Profile YAML v1.1 [2] does not preclude the TOSCA.meta file block _0 to be extended
with key value pairs.
4.1.2.3 TOSCA.meta file keynames extension
Table 4.1.2.3-1 specifies an extension of the list of recognized TOSCA.meta file keynames as specified in the present
document for the TOSCA.meta file. The keynames represents the entries for artifacts defined in clauses 4.3.2 to 4.3.6 of
the present document and shall be located in the block_0.
Table 4.1.2.3-1: List of TOSCA-meta file keynames extensions
Keyname Required Type Description
ETSI-Entry-Manifest yes string Location of the Manifest file as defined in clause 4.3.2
ETSI-Entry-Change-Log yes string Location of the Change history file as defined in clause 4.3.3
ETSI-Entry-Tests no string Location of the Testing files as defined in clause 4.3.4
ETSI-Entry-Licenses yes string Location of the Licensing information as defined in clause 4.3.5
ETSI-Entry-Certificate no string Location of the Certificate file as defined in clause 4.3.6

Use of the Entry-Manifest, Entry-Change-Log, Entry-Tests, Entry-Licenses and Entry-Certificate keynames defined in
ETSI GS NFV-SOL 004 versions 2.4.1 [i.7] to 2.5.1 [i.8] of the present document is deprecated. These keynames are
only provided for backward compatibility with legacy VNF Package consumers; VNF package providers are warned
that support of these keynames can be removed in subsequent versions of the present document. The key with and
without the ETSI-prefix should not be both present in the TOSCA.meta. If both are present they shall point to the same
value.
EXAMPLE:
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: MyCompany
Entry-Definitions: MRF.yaml
ETSI-Entry-Manifest: MRF.mf
ETSI-Entry-Licenses: Files/Licenses
ETSI-Entry-Change-Log: Files/ChangeLog.txt

END OF EXAMPLE.
ETSI
10 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
4.1.3 CSAR without TOSCA-Metadata directory
4.1.3.1 General
This CSAR structure is only applicable if a YANG-based VNFD as defined in ETSI GS NFV-SOL 006 [i.6] or a
TOSCA-based VNFD with single deployment flavour design as defined in clause 6.11.3 in ETSI
GS NFV-SOL 001 [i.4] is included in the VNF Package. The yaml file at the root of the archive is the CSAR Entry-
Definition file. The CSAR-Version is defined by the template_version metadata as can be seen in the below example.
The value of template_version shall be set to 1.1.
EXAMPLE:
tosca_definitions_version: tosca_simple_yaml_1_2
metadata:
template_name: MainServiceTemplate
template_author: Onboarding portal
template_version: 1.1
END OF EXAMPLE.
4.1.3.2 TOSCA Entry definition file metadata extension for a YANG-based VNFD
Table 4.1.3.2-1 specifies an extension of the list of recognized metadata keynames as specified in TOSCA-Simple-
Profile-YAML-v1.1 [2] for the main TOSCA Service Template.
Table 4.1.3.2-1: List of metadata keynames extensions
Keyname Required Type Description
yang_definitions no string Reference to a YANG definition file representing the VNFD within a VNF
Package
If a YANG-based VNFD is included in the VNF Package, the main TOSCA definitions YAML file shall include a
metadata section with an additional metadata entry, where the keyname is ''yang_definitions'' and the value is the path to
the YANG file representing the VNFD within the VNF Package. No additional contents shall be included in the main
TOSCA definitions YAML file.
NOTE: The above requirement ensures that there cannot be both a YANG-based and a TOSCA-based
representation of a VNFD in the same package.
EXAMPLE:
tosca_definitions_version: tosca_simple_yaml_1_1
metadata:
template_name: MainServiceTemplate
template_author: Onboarding portal
template_version: 1.1
yang_definitions: Definitions/myvnfd.xml

END OF EXAMPLE.
4.1.4 Void
4.2 VNF package structure and format
The structure and format of a VNF package shall conform to the TOSCA Simple Profile YAML v1.1 Specification of
the CSAR format [2]. The zip file format shall conform to Document Container Format File [12].
NOTE: This implies that the VNF package can be structured according to any of the two options described in
clause 4.1.
ETSI
11 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
The consumer of a VNF package complying with the present document shall be able to process a CSAR file structured
according to any of the two options described in clause 4.1. If the CSAR file contains a TOSCA-Metadata directory and
a single yaml file with a .yml or .yaml extension at the root of the archive, the TOSCA.meta file contained in the
TOSCA-Metadata directory shall be used as an entry information for processing the CSAR file.
4.3 VNF package file contents
4.3.1 General
A VNF Package shall contain a main TOSCA definitions YAML file representing all or part of the VNFD, and
additional files. It shall be structured according to one of the CSAR structure options described in clause 4.1.
NOTE 1: ETSI GS NFV-SOL 001 [i.4] specifies the structure and format of the VNFD based on TOSCA
specifications.
NOTE 2: ETSI GS NFV-SOL 006 [i.6] specifies the structure and format of the VNFD based on YANG
specifications.
Examples of VNF package options are described in annex A.
4.3.2 VNF package manifest file
A CSAR VNF package shall have a manifest file. In the case of a CSAR VNF package with a TOSCA-Metadata
directory, the location, name, and extension of the manifest file shall be specified by means of the "ETSI-Entry-
Manifest" keyname in the TOSCA.meta file. In the case of a CSAR VNF package without TOSCA-Metadata directory,
the manifest file shall have an extension .mf, the same name as the main TOSCA definitions YAML file and be located
at the root of the archive.
The manifest file shall start with the VNF package metadata in the form of a name-value pairs. Each pair shall appear
on a different line. The "name" and the "value" shall be separated by a colon and, optionally, one or more blanks. The
order of the name-value pairs is not significant.
The name shall be one of those specified in table 4.3.2-1 and the values shall comply with the provisions specified in
table 4.3.2-1.
The "required" column in table 4.3.2-1 specifies constraints on the presence of each name in a manifest file. If the cell
in the "required" column is set to "Yes", the corresponding name shall be included. If the cell in the "required" column
is set to "No", the corresponding name may, but need not to, be included. A name shall not be included more than once.
Table 4.3.2-1: List of valid names and values for VNF package metadata
Name Value Required
vnfd_id A sequence of UTF-8 characters. See note 1. Yes
vnf_provider_id A sequence of UTF-8 characters. Yes
See note 1.
vnf_product_name A sequence of UTF-8 characters. Yes
See note 1.
vnf_release_date_time A string formatted according to IETF RFC 3339 [3]. Yes
vnf_software_version A string. See note 1. Yes
vnf_package_version A string. Yes
See note 2.
compatible_specification_versions Indicates which versions of the present document the VNF package Yes
complies to, as known at package creation time. See note 3.
See note 4.
The value shall be formatted as comma-separated list of strings.
Each entry shall have the format .. where , and
are decimal numbers representing the version of the present
document.
Whitespace between list entries shall be trimmed before validation.
ETSI
12 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
Name Value Required
vnfm_info A comma-separated list of strings as defined in the VNFD. Yes
Whitespace between list entries shall be trimmed before validation.
NOTE 1: The value shall be identical to those specified in the VNFD.
NOTE 2: The value shall be identical to the vnfdVersion attribute specified in the VNFD.
NOTE 3: As this list is determined at the time of package creation, it should not be inferred that a
package is not compatible with future versions not present in this list. Whether the package
will be compatible with such future versions depends on whether these future versions are
backward compatible with the listed versions.
NOTE 4: A package conformant to versions prior to 2.7.1 does not include this name. Therefore, if this
field is missing, it shall be assumed that the package conforms to some previous
version of the present document, i.e. a version prior to 2.7.1 and the package shall be
considered valid.
An example of valid manifest file metadata entries follows.
EXAMPLE 1:
metadata:
vnfd_id: 2116fd24-83f2-416b-bf3c-ca1964793aca
vnf_product_name: vMRF
vnf_product_name: Virtualized PowerMRF by MyCompany Inc.
vnf_provider_id: MyCompany
vnf_software_version: 1.0.0
vnf_package_version: 1.0
vnf_release_date_time: 2017-01-01T10:00:00+03:00
vnfm_info: etsivnfm:v2.3.1,0:myGreatVnfm-1
compatible_specification_versions: 2.7.1,3.1.1

END OF EXAMPLE 1.
The manifest file shall include a list of all files contained in or referenced from the VNF package with their location,
expressed using a Source: location/name key-value pair. The manifest file itself may be included in the list.
Below is an example of valid manifest file entries for files contained in or referenced from the VNF package when
authenticity and integrity of the VNF package is implemented according to option 1 as specified in clause 5.1.
EXAMPLE 2:
Source: MRF.yaml
Algorithm: SHA-256
Hash: 09e5a788acb180162c51679ae4c998039fa6644505db2415e35107d1ee213943

Source: scripts/install.sh
Algorithm: SHA-256
Hash: d0e7828293355a07c2dccaaa765c80b507e60e6167067c950dc2e6b0da0dbd8b

Source: https://www.vendor_org.com/MRF/v4.1/scripts/scale/scale.sh
Algorithm: SHA-256
Hash: 36f945953929812aca2701b114b068c71bd8c95ceb3609711428c26325649165

END OF EXAMPLE 2.
If the VNF package is built according to option 1 (clause 5.1), the manifest file shall contain digests of all individual
files contained in or referenced from the package.
A consumer of the VNF package verifies the digests in the manifest file by computing the actual digests and comparing
them with the digests listed in the manifest file.
The manifest file in option 1 is the key for decision regarding a VNF package integrity and validity in terms of its
contained artifacts. The specification of the manifest file and specific algorithms used in digest creation and validation
is described in the security related clause.
The details of specifying the local or externally located files and their security protection are described in clause 5.
ETSI
13 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
4.3.3 VNF package change history file
A CSAR VNF package shall have a humanly readable text file describing any change in the constituency of the VNF
package. All the changes in the VNF package shall be versioned, tracked and inventoried in the change history file.
In the case of a CSAR VNF package with a TOSCA-Metadata directory, the location, name, and extension of the
change history file shall be specified by means of the "ETSI-Entry-Change-Log" keyname in the TOSCA.meta file. In
the case of a CSAR VNF package without TOSCA-Metadata directory, the change history file shall be named
"ChangeLog.txt" and located at the root of the archive.
4.3.4 VNF package testing files
To enable VNF package validation, a VNF Provider should include in a VNF package files containing necessary
information (e.g. test description) in order to perform VNF testing. The contents of VNF testing information is outside
the scope of the present document.
In the case of a CSAR VNF package with a TOSCA-Metadata directory, the location and name of a directory
containing VNF testing information shall be specified by means of the "ETSI-Entry-Tests" keyname in the
TOSCA.meta file. In the case of CSAR VNF package without TOSCA-Metadata directory, the VNF testing information
shall be located in a directory named "Tests" located at the root of the archive.
4.3.5 VNF package licensing information
As required in ETSI GS NFV-IFA 011 [1] the VNF package shall contain license information for the released VNF.
The license information shall include a single license term for the whole VNF. In addition, the license information may
also include license terms for each of the VNF package artifacts if different from the one of the released VNF.
In the case of a CSAR VNF package with a TOSCA-Metadata directory, the location and name of a directory
containing VNF licensing information shall be specified by means of the "ETSI-Entry-Licenses" keyname in the
TOSCA.meta file. In the case of CSAR VNF package without TOSCA-Metadata directory structure, the VNF licensing
information shall be located in a directory named "Licenses" located at the root of the archive.
4.3.6 Certificate file
The CSAR VNF package shall contain a certificate file if the certificate is not included in the signature container (see
note) within the manifest file. In this case or if a single certificate is provided for the signature of multiple artifacts (see
clause 5.4), the certificate file shall support one of the two following options:
1) In the case of a CSAR VNF package with a TOSCA-Metadata directory, the location, name, and extension of
the certificate file shall be specified by means of the "ETSI-Entry-Certificate" keyname in the TOSCA.meta
file.
2) In the case of a CSAR VNF package without a TOSCA-Metadata directory, the certificate file shall have an
extension .cert and the same name as the main TOSCA definitions YAML file and be located at the root of the
archive.
NOTE: Signature container refers to a structure in a standard format (e.g. CMS) which contains signature and
additional data needed to process the signature (e.g. certificates, algorithms, etc.).
If the complete CSAR file is signed by the VNF provider (see option 2 in clause 5.1), the certificate file shall be
contained in a zip file together with the CSAR file and the signature file if the certificate is not included in the signature
file. The certificate file shall have an extension .cert and the same name as the CSAR file.
ETSI
14 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
4.3.7 Non-MANO artifact sets in a VNF package
As required in ETSI GS NFV-IFA 011 [1] the VNF package shall allow to store and identify non-MANO artifact sets in
the VNF package file.
Every non-MANO artifact set shall be identified by a non-MANO artifact set identifier which shall be registered in the
registry (specified in annex B). A non-MANO artifact set identifier shall be a string that consists of sub-strings which
shall not contain characters other than the following: digits (0-9), lowercase ASCII characters (a-z), and the special
characters underscore "_" and dash "-". Sub-strings shall be separated by the dot "." character.
All files belonging to the same non-MANO artifact set shall share a common path prefix other than the root of the
package.
Non-MANO artifact sets shall be declared at the end of the manifest file. If the package contains at least one non-
MANO artifact set, an entry named "non_mano_artifact_sets:" shall be present in the package on its own line after the
"metadata" section that is defined in clause 4.3.2. The section defined by the "non_mano_artifact_sets" keyname shall
have the following structure:
• Every non-MANO artifact set shall be declared on its own line, by a key name that is equal to the non-MANO
artifact set identifier.
• Below the key name, all artifacts that belong to the non-MANO artifact set shall be listed, each on its own line,
starting with key name "Source", followed by a colon (":") and, optionally, one or more blanks, and further
followed by a file name with path for a file in the CSAR archive that is not contained in the root of this
archive.
If the Manifest file provides the integrity assurance of the VNF package (option 1 in clause 5.1), these artifacts shall
also appear in the list of blocks of name-value pairs specified in clause 5.3.
An example of the section that declares the non-MANO artifact sets in the package is provided below.
EXAMPLE:
non_mano_artifact_sets:
foo_bar:
Source: foobar/foo/foo.yaml
Source: foobar/foo/foo.script
Source: foobar/bar/descriptor.xml
prv.happy-nfv.cool:
Source: happy/cool/123.html
Source: happy/cool/cool.json
Source: happy/cool/hot/hot_or_cool.json

END OF EXAMPLE.
5 Adding security to TOSCA CSAR
5.1 VNF package authenticity and integrity
As specified in ETSI GS NFV-IFA 011 [1] a VNF package shall support a method for authenticity and integrity
assurance.
In order to provide the public key based authenticity and integrity for the whole VNF package one of the two following
options shall be followed:
Option 1: The VNF package shall contain a Digest (a.k.a. hash) for each of the components of the VNF
package. The table of hashes is included in the manifest file, which is signed with the VNF
provider private key. In addition, the VNF provider shall include a signing certificate that includes
the VNF provider public key, following a pre-defined naming convention and located either at the
root of the archive or in a predefined location (e.g. directory).
ETSI
15 ETSI GS NFV-SOL 004 V3.6.1 (2022-01)
The certificate may also be included in the signature container, if the signature format allows that.
For example, the CMS format allows to include the certificate in the same container as the
signature.
Option 2: The complete CSAR file shall be digitally signed with the VNF provider private key. The VNF
provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that
includes the VNF provider public key. Only one signature of the CSAR file shall be present. The
certificate may also be included in the signature container, if the signature format allows that.
The manifest shall be signed in both option 1 and option 2. Only one signature of the manifest shall be present.
In option 2, the VNF package delivered would therefore be according to figure 5.1-1.

Figure 5.1-1: Composition of the VNF Package zip file in option 2
This solution, either option 1 or option 2, relies on the existence in the NFVO of a root certificate of a trusted CA that
shall have been delivered via a trusted channel that preserves its integrity (separate from the VNF package) to the
NFVO and be pre-installed in the NFVO before the on-boarding of the VNF package.
NOTE: The present document makes no assumption on who this trusted CA is. Furthermore, it does not exclude
that the root certificate be issued by the VNF vendor or by the NFVI provider.
5.2 VNF package manifest and certificate files
In option 1 (see clause 5.1) the manifest file provides the VNF package integrity and authenticity assurance. In this
option the manifest contains the digests (hashes) for each individual file locally stored within the VNF package or
referenced from it. Each file related entry of the manifest file includes the path or URI of the individual file, the hash
algorithm and the generated digest. A consumer of the VNF package shall verify the digests in the manifest file by
computing the actual digests and comparing them with the digests listed in the manifest file. Furthermore, the consumer
of the VNF Package shall verify that all files in the VNF Package have their corresponding entry and digest in the
manifest and that all files listed in the manifest exist in the VNF Package.
In option1 the VNF package authenticity is ensured by signing the manifest file with the VNF provider private key. The
digital signature is stored in the manifest file itself (see clause 5.3). The VNF provider shall include an X.509
certificate [8] in the VNF Package. The certificate shall be either placed in a certificate file with extension .cert or, if the
chosen signature format allows it, the certificate may be included in the signature container itself. The certificate
provides the VNF provider public key.
In option 2 (see clause 5.1), the VNF package authenticity and integrity is ensured by signing the CSAR file with the
VNF provider private key (option 2 in clause 5.1) and, if the VNF package refers to external artifacts, with the signature
of the external artifacts. The digital signature is stored in a separate file. The VNF provider shall also include an X.509
certificate. The certificate may be included in the signature itself if the signature format allows it or in a separate file.
The signature and certificate files shall be siblings of the CSAR file, i.e. placed in the s
...