The following is a copy of the technical paper "FCG AG10085 FDI Package Signature Processing" published 8 March 2019.  A PDF version is available to FieldComm Group members via ShareFile (Shared Folders > Application Guides and Technical Papers).

For tips on using the FDI Signing Tool please see the following support articles: 

How to Sign an FDI Device Package 

Help with Signing Certificates and the FDI Package Signing Tool 

Purpose

The purpose of this paper is to promote interoperability with consistent FDI Package Signature processing algorithms. While digital signatures is not a new technology, it is a new technology to FDI and a technology more associated with the Information Technology (IT) as compared to the Operations Technology(OT). This document assumes you have some familiarity with FDI, Open Packaging Conventions (the other OPC) and some knowledge   on digital signature using public key infrastructure (PKI). PKI is a complex topic and well beyond this paper. Elements of PKI are only briefly introduced to help the reader understand the concepts and potential pitfalls with FDI Technology. This white paper does not address all aspects PKI.

Scope

FDI Specification define the use of digital signatures, making explicit references to ETSI EN 312 219-2 and ISO/IEC 29500-2 and defining constraints on how to implement those technologies within FDI. This document takes those specifications, along with ETSI EN 319-102-1 to define an interoperability process for validating FDI Package signatures.

Figure 1

History

Normative References

XML Signature Syntax and Processing Version 1.1 (11 April 2013), https://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/

XML Advanced Electronic Signatures (XAdES) (2004-02-20), https://www.w3.org/TR/XAdES/

ISO/IEC 29500-2 (3^rd Edition, 2012-09-01), Information technology — Document description and processing languages — Office Open XML File Formats — Part 2: Open Packaging Conventions, http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

ETSI EN 319 132-1 (v1.1.1, 2016-04), Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures, http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf

ETSI EN 319 132-2 (v1.1.1, 2016-04), Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 2:  Extended XAdES  signatures, http://www.etsi.org/deliver/etsi_en/319100_319199/31913202/01.01.01_60/en_31913202v010101p.pdf

ETSI  TS 101 903 (v1.2.2  2004-04), XML Advanced Electronic Signatures (XAdES), http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf

ETSI EN 319 102-1 (v1.1.1, 2016-05), Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of  AdES Digital  Signatures;  Part 1:  Creation and Validation, http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf

ETSI TS 119 172-1 (v1.1.1, 2015-07), Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 1: Building blocks and table of contents for human readable signature policy documents, http://www.etsi.org/deliver/etsi_ts/119100_119199/11917201/01.01.01_60/ts_11917201v010101p.pdf

RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, https://tools.ietf.org/html/rfc5280

RFC 5652, Cryptographic Message Syntax, https://tools.ietf.org/html/rfc5652

RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, https://tools.ietf.org/html/rfc6960

RFC 6818, Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile https://tools.ietf.org/html/rfc6818

RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)https://tools.ietf.org/html/rfc3161

FCG TS62769-4 (Edition 1.1, 2017-09-07), Field Device Integration (FD) – Part 4: FDI Packages, https://docs.fieldcommgroup.org/62769/TS62769-4/1.1/

FCG PD10050 (Edition 1.0, Preliminary C,  2018-06-27), FDI Package Signing Policy, https://fieldcommgroup.sharefile.com/d-sacd8a09f5dd34e25af62e5e8170f6858

Informative References

In addition to the above references, the reader may also find the following useful to better understand this paper.

https://portal.etsi.org/tbsitemap/esi/esiactivities.aspx

Primer to FDI Package Signatures

Open Packaging Conventions

The use of digital signatures is covered in detail in FCG 62769-4, section 7. In summary, a signature provides   means to verify that the data inside the package has not been changed (integrity) as well and provide means that the representation of the data can be confirmed by a trusted source (authenticity).

FDI uses Open Packaging Conventions (the “other” OPC) to define digital signatures. In all references in this paper, OPC refers to Open Packaging Conventions. FDI also provide additional FDI package specific constraints to those defined in OPC. Standard OPC signature processors are fully compatible, however FDI limits how OPC can be used.

The signature concept in OPC is built on XML Digital signatures, however it has been further enhanced to support OPC specific features. A standard XML digital signature processor is fully compliant with OPC signatures, however there are additional validation requirements necessary to fully validate the OPC signature.

Certificates used for these digital signatures have validity dates. After those date, the certificate is no longer maintain, and therefore cannot be trusted. This is where time stamp  servers help.  If  the time stamp from the  time server is trusted, then we know that the signature was issued within the validity of the signing certificate, then the certificate can be trusted.

RFC3161 defines a time stamping protocol, and along with RFC 5652, define a way to encode this in a digital signature.

XAdES

XML Advanced Signatures (XAdES) introduced an extension the XML Signatures to support trust timestamping.  There are many features and use cases in XAdES, but the one of interest here is XAdES-T.

While this work began in W3C, work on this topic further continued in ETSI, heavily driven by European regulations on digital signatures.

It’s important to note that OPC and XAdES are built on XML Digital Signatures, but neither standard reference each other. Essentially, these are side by side, so  care must be  taken to assure all pieces fit together.  Luckily,  there  are several commercial examples where these all fit together. For example, MS WORD documents, based on OPC, can be signed with XAdES signatures. While no the entire set of standards, Figure 2 helps illustrate the layering.

The work done by W3C is not sufficient to develop interoperable standards to support advanced signatures. Therefore, FDI references ETSI EN 319 132-2 for the use of XAdES-T, which were renamed a few times in various versions of this (and related) standard. This paper will continue to use XAdES-T. To validate XAdES-T, this paper also depends on ETSI EN 319-102-1 for FDI package signature validation.

Figure 2

FDI Package Signature Model

The overly simplified model is that a package is just a collection of “parts” connected with  “relationships.” Packages are encoded using ZIP containers, but they are not just an ordinary zip container. There is a well-defined structure. Parts (files) are not only ZIPed up but must be explicitly referenced by relationships, special xml files. Simply adding a random file to an OPC package will not been seen from the view of an OPC consumer. In  fact,  these additions wouldn’t even affect a digital signature check!

This is a possible security vector. While a standard OPC consumer wouldn’t see these extra files, an end user that might “unzip” a package would see these. This demonstrates a security concern, and FDI Signature processing will provide additional rules to verify package integrity by disregarding packages that do not conform to OPC standards.

Figure 3 illustrates how signatures makes these explicit references to parts and relationships. Simply put, signatures are encryption over hashed data. Hash data is taking a large object (like a file) and calculating a smaller number that represents that object. And, most important, that number should be unique such that someone couldn’t take that file and modify it such as way to produce the same number. OPC makes reference to SHA1 however, by current standards, this hashing algorithm (also referred to as a digest algorithm) is becoming obsolete and being replaced with SHA256 (and others).

Within the digital signature (and specified by XAdES) is a commitment type. This helps consuming applications know why the signature was added to the package. FDI Specifies the commitment type for signing as the “owners” of the package and another for used by registration authorities. Different signatures can sign all or parts of the package. Signing the signature relationship part will prevent further signatures from being added.

Figure 3

FDI Package Signature walkthrough

Figure 4 shows a representation of a digital signature in an FDI Package. It is no means complete and uses some words in a more generic function. The purpose of this figure is to help illustrate how these different specifications fit together. A signature document is an xml document.

Figure 4

The signature of the FDI package is calculated using the private key of the signer as well as a hash of the SignedInfo. The SignedInfo references OPC specific data “IdPackageObject” along with an unnamed Object containing the XAdES related information. It is unnamed because the signature is only made over parts of this object, the signed parts. Signatures also have canonicalization methods, but this isn’t important for illustration.

The IDPackageObject contains references to the parts and relationships that are signed along with their hash (digest value). These files are “external” to the XML signature and require an OPC aware application to verify the hashes in the xml signature match the hashes in the actual package.

This is an important point to repeat. The signature value is calculated over the digest values inside the xml document. But,  simply conforming these is insufficient for overall FDI Package integrity.  In  a  use case where a  file is changed AFTER a signature. The application must also compare the parts to the digest value using the appropriate hashing algorithm.

However, if a digest value inside the xml document was changed AND the signature was not re-calculated, then  this WOULD cause a signature validation failure. If the signature value fails, the entire xml document is unreliable. This is a more critical failure.

The commitment type, part of the signed properties is also covered by the overall xml signature.

XAdES also contains unsigned parts, meaning that this section is NOT used in  the overall xml signature.  And, this  is necessary because timestamping must happen AFTER the overall signature is calculated. It would not be possible to sign the package with this “unsigned data” since the data is dependent on the calculated signature of the package itself!

Time stamping works by sending a hash of the calculated signature to a time server. That timeserver then takes  that data PLUS the actual time and computes a signature. This is returned to the client and then encoded in the XML signature file. This is represented as base64 encapsulated data and is not easily read by a standard xml tools.  If you are curious, you can copy this data and use of several online ASN.1 decoders to inspect the data.

Core Requirements

Overview

The core requirements for signing and validating are defined in FCG TS62769-4, 7.2. 7.3 and 7.4 and are repeated here for convenience. Unique requirement identifiers were added to enable traceability.

Signing Requirements

[REQ -SIGN 1] All signatures within the FDI Package shall be made according to the mechanism defined in ISO/IEC 29500-2.

In addition to ISO/IEC 29500-2 the signature shall fulfil the following requirements:

[REQ-SIGN-2] – The information needed to validate the signature shall be part of the digital signature, i.e. the KeyInfo element specified in XML Signature Syntax and Processing is mandatory.

[REQ-SIGN-3] – Certificates used for signing shall be rooted in a Certificate Authority which is included in the trusted CAs of the Microsoft Windows Certificate Store.

[REQ-SIGN-4] – The algorithms used in creation of the signature (for hashing and encryption/decryption) shall be from the list of NIST recommended algorithms in FIPS 140-2, Annex A (NIST).

[REQ-SIGN-5] – The signature shall include a trusted timestamp in compliance with XAdES (XML Advanced Electronic Signatures - ETSI EN 319 132-1).

[REQ-SIGN-6] – Any signature shall include a CommitmentTypeIndication according to ETSI TS 101 733. The used commitment types are specified in subclause (FCG TS62769-4) 7.3.

The FDI Package Originator and the FDI Registration Authority have the following responsibilities:

[REQ-SIGN-7] – An FDI Package originator officially publishes an FDI Package and signs it to ensure the integrity of the FDI Package. The FDI Package can be created by a device vendor or a software solution provider. The publisher of an FDI Package may be a different person. The commitment type is ProofOfOrigin.

[REQ-SIGN-8]– An FDI Registration Authority has the right and the ability to perform FDI conformance tests on FDI Packages and to issue FDI Registration Certificates, Typically interest groups representing an FDI supported communication protocol or their authorized partners. The commitment type is ProofOfApproval.

Host Behaviour Requirements

An FDI host system shall display a warning message when the FDI Package import procedure recognizes that

[REQ-VALIDATE-1] – a digital signature on the package is not present or does not include all entities (files) inside the package,

[REQ-VALIDATE-2]– the digital signature as such is not trustable,

[REQ-VALIDATE-3]– the signature is broken which indicates that the package has been modified after signing.

[REQ-VALIDATE-4] Additional security measures to be taken, if the warning message has been displayed, are in the responsibility of the FDI host system.

[REQ-VALIDATE-5] An FDI host system should display an information message showing which parts of the ones having gone into the registration have been changed when the FDI Package import procedure recognizes that

[REQ-VALIDATE-6]– the unique identifier (PackageID) and the version (as defined in (FCG TS62769-4) Annex E) of the FDI Package does not match the same information given as a part of the FDI Registration Certificate file,

[REQ-VALIDATE-7]– there is no FDI Registration Certificate present in the FDI Package,

[REQ-VALIDATE-8]– the included FDI Registration Certificate is not signed, the signature is not trustable or the signature is broken.

[REQ-VALIDATE-9] An FDI host system can check the signature and certification status by reading the FDI Registration Certificate.

[REQ-VALIDATE-10] A host shall provide a configuration, which allows to import a FDI Package, which does not include a FDI Registration Certificate. The functionality of this FDI Package shall not be limited.

Validation Basics

Key elements

Validating a signature has 2 fundamental process.

• Use the public keys to decrypt the signature value and compare it to the stored hash value. If it matches, the data integrity is good. This is straight fairly forward, though care must be taken since digest values in the xml signature are calculated over external objects. But, again, the procedures here are not hard. FDI does provide some rules based on commitment type as noted in the conformance section.
• Deciding if the certificates that are used by the signers are to  be trusted.  This is the HARD part.  It  has  lots of variables and is based on changing data that’s outside the scope of the package. Furthermore,  unlike the first, this can change over the life of the package. This presents unique challenges for disconnected clients. This topic is further described below.

Certificates

Public Key Infrastructure (PKI) was defined to a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption (Wikipedia)

The use of digital certificates to sign and ultimately trust is an involved topic and beyond the scope of this document. Only a very high-level view (perhaps a warning) is presented here. This paper, in no way, should serve as a reference to PKI.

Certificates are used to help establish trust.  Should the consumer trust the signature?  Well, this depends on  if  the consuming resource trusts the certificates that are encoded in the package.

Trust happens at the receiver An  FDI Package producer could create a  self-signed certificate and manually install  it in the root store as a trusted anchor of his/her personal machine.  On  that machine, the certificate would be  fully trusted and pass test cases. However, beyond that machine, no other machine would trust this certificate. Those same test cases would fail!

So, instead of creating own certificates, FDI package producers obtain their signing certificates from a trusted third-party Certificate Authority (CA). That CA obtains its authority by having a certificate issued to it. This  chaining happens until you get to a trust anchor, where some process, outside the “realm” of PKI, must ultimately decide to trust it. See Figure 5 to illustrate this chaining.

Part of certificate validation is building this certification path that leads to a trusted anchor. FDI relies on the Microsoft root store and Microsoft’s Trusted Root Certificate Program to establish this trust. As a consequence,  FDI does not have a set of “trusted” manufacturers.

This is worth repeating: FDI does not have a trusted set of manufacturers.

To make this more clear, consider that example of a company “ACME ABC Automation” that could exist. It could obtain a code signing certificate. Either maliciously or by accident, perhaps this company signs a package for “DEF Automation Products”. This is a certificate fully trusted by the local machine. But, should  DEF  Automation Products be signing a product from ACME ABC Automation?

This enforces the fact that the end user must ultimately trust the signing certificate. This is very similar to how Windows may prompt the user to install an application and provides the name of the signer.  The certificate may  be trusted by the root store, but ultimately user must accept the signer.

Figure 5

Trust Anchor

The Microsoft Root Store is the trust anchor for FDI Package signatures. Not all trusted root certificates are installed by default. That’s very import, so let’s repeat. Not all trusted root certificates are installed by default. Instead, these are installed on demand, assuming the client has access to the internet or the current approve list.

For example, when you launch a signed application, Microsoft installs the approved root certificate and any intermediate certificates on demand that are necessary to establish the certificate path.

This does not happen when FDI Package are consumed.

This presents a challenge to FDI Package consuming applications, as they cannot depend on the Root certificate to be installed at any given time. This is even more important for offline applications that may not be able to access the internet.

Microsoft makes the list of root certificates available from Windows Update.

More information on Microsoft’s Trusted Root Certificate Program can be found here: https://technet.microsoft.com/en-us/library/cc751157.aspx

Information on managing the root certificate store for disconnected clients is available at:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and- 2012/dn265983(v=ws.11)

It is highly recommended that FDI Packages provide a list of intermediate certificates within the signature to establish the certificate path. So, the FDI applications only need to manage trusted roots.

NOTE: While consuming FDI Packages do not for the install on demand behavior, it is possible for the FDI Application to access the complete Microsoft Root CTL using certutil -generateSSTFromWU roots.sst. This list, for example, could be administered through Group Policy.

Intermediate Certificates

Trusted root certificates rarely directly issue end user certificate. Instead, they delegate this task to intermediate Certificate Authorities. Those may be further delegated until a certificate is generated for the FDI Package producer to sign. These intermediate certificates may not be available on the end customer machine, so therefore it is always recommended that these be encoded in the FDI Package. Without these intermediate certificates, the consuming application may not be able to build the certificate trust path.

Certificate lifecycle

Certificates have a lifecycle. Certificates may need to be revoked after issuance. IMPORTANT:  When a certificate is revoked, all packages signing using that certificate are NO LONGER trusted. The private keys associated with singing certificate should always be kept secure, because a compromise could affect many packages! The author of this white paper highly recommends using signing certificates secure on hardware, such as a USB token or HSM. With these, the private key is never exposed. These are required for “EV Code Signing” keys and  provide extra layer of security. The consequence is that these tokens/modules must be physically present to sign.

Revocation Lists

To manage this, each certificate provide means to identify if their certificate is revoked:

• Certificate Revocation Lists (CRL)
• Online Certificate Status Protocol (OCSP)

Fundamentally, both do the same thing: provide means to check on the status of a certificate. CRLs are published as a list referenced by certificate. Typically, this file is hosted on a website.

OCSP is a  protocol instead of a  downloaded list, typically communicated via HTTP.  Here, the client can present  the details of the certificate and the OCSP server will return with the status.

Certificate revocation is a lifecycle concept and relies on external servers to assess certificate validity. Certificates can be revoked at any time.

FDI Applications, especially disconnected applications, need to provide means to handle revocation checks. For example, application may have out of band means to obtain CRL lists to support validation. Managing disconnected applications is beyond the scope of this paper.

In the case of standardized XAdES validation applications, failures can occur if CRL/OCSP validation is required but not available (e.g. disconnected)

Final word on certificates

Everything about certificate is about trust, and these apply to all certificates, not just the signing certificate. A signing certificate can be perfectly valid, however if an intermediate certificate has anomalies, or perhaps even revoked, this can have an impact on the ultimate validity of the signing certificate! For example, the readers can research Google’e Chrome’s distrust of Symantec Certificate as an example.

Therefore, it is important that package signing identify trusted, respected companies that issue  signing certificates. Otherwise, their failures can ultimately impact the validity of the signing certificate, even after it was produced and used!

Top Level FDI Package Signature Validation Concept

Understanding XAdES Validation concept

The model presented in this paper is based on the signature validation model defined in ETSI EN 312 102-1, 5.2, and supplemented with FDI Package requirements and constraints.

Starting the XAdES model first, the validation route is split between two parts, a signature validation application and driving application.

ETSI EN 319 102 defines a concept of validating XAdES signatures. Figure 6 illusrates this concept. The Signature Validation Application specifies different processing steps to validate a  siginature.  The processing is influenced  by a Signature Validation Policy, which establishes the contraints used by the SVA. This concept is not OPC or FDI aware.

Figure 6

The white paper builds on this concept to inject FDI and OPC processes and constraints to develop algorithms to promote interoperability. It uses the XAdES validation routines “as-is” and suppliments on FDI Package specific requirements in the conformance checker.

Extending the model for FDI Package

This paper defines a procedure for implementing FDI Package signature validation, however it is not the only way to implement this validation. For example, it may be possible to extend the XAdES signature validation to understand the external references to Open Packaging Convention parts.  All FDI specific checks are  covered in the FDI Package Signature Conformance Checker. Figure 7 illustrates how this concept is done. It is slightly  different than Figure 6, specifically, the values of the SVA are also used by the Signature Conformance Checker to compute a single FDI Package status instead of separate Conformance and Validation reports. FDI specific requirements are not introduced into the SVA to leverage available XAdES tools.

Figure 7

Constraints to Signature Validation Application (SVA)

Signature Validation Policies

These constraints serve as input to the Validation Context Initialization (ETSI EN 312 102-1, 2.3.4)

Table 1  –  CommittmentType (TODO)

Table 2 maps the commitment types defined in ETSI TS 101 903 to FCG TS62769-4.

Table 2 - FDI Package Supported Commitment Types

X.509 Certificate Validation Constraints

These constraints serve as input to the Revocation freshness checker (ETSI EN 312 102-1, 5.2.5) and X.509 certificate Validation (ETSI EN 312 102-1, 5.2.6)

Specified from ETSI TS 119 172-1 [4], clause A.4.2.1, table A.2 row m.

Table 3 defines the X.509 certificate validation constraints.

Table 3 – X.509 Certificate Validation Constraints

NOTE: Care should be taken for disconnected clients or this will result in an unexpected FAIL.

Cryptographic Constraints

Input to the X.509 certificate validation (5.2.6) and Signature acceptance validation (ETSI EN 312 102-1, 5.2.85) All valid cryptographic constraints are specified in NIST 140-2, Annex A [REQ-SIGN-4].

Cryptographic Validation Addendum

Supplements Cryptographic Validation (ETSI EN 312 102-1, 5.2.7) No additional constraints.

Signature Elements Constraints

Input to Signature acceptance validation (ETSI EN 312 102-1, 5.2.8)

ETSI TS 119 172-1 [4], clause A.4.2.1, table A.2 row b. See Table 4

Table 4 –  Signature Elements Constraints

NOTE: From the context of the digital signature, the signature must be signed as a whole.  This is  because the SVA  is not aware of the  contents of a package. Those requirements are tested elsewhere. This is NOT saying that all parts of the package must be signed.

FDI Package Signature Conformance Checker

General

ISO/IEC 29500-2, 13.4 defines that processing of XML digital signatures is based on W3C Recommendation XML Signature Syntax and Processing with some additional package-specific constructs. From this point of view, the signature is a detached signature, meaning that the signatures make references to  objects that are outside the  xml signature document.

For example, the hashes to the parts are stored in the xml signature, however the parts themselves reside in the zip container.

According to ETSI EN 319 102-1, 5.2.7.2, Table 16. Note 2, the validation of detached  signatures can  be done by the DA or the SVA. For the purposes of this white paper, the validation is done in the FDI Package Signature Conformance Checker (see block in Figure 7).

This block takes the results of one or more certificates from SVA, along with the package, to calculate the FDI Signature Validation Status. The FDI Package Signature Conformance Checker validation flow is  illustrated in Figure 8.

Signatures that fail XAdES are discarded from further processing. Following this, additional FDI x509 specific  checks are required, then the commitment types are processed. Based on commitment types, additional rules are processed that leads to a final packages status.

Figure  8

Inputs

The FDI Signature Status Calculation block takes status inputs

• Signature and Status from SVA  Application
• FDI Package (necessary for OPC  validation)

Outputs

Table 5 defines the possible verdicts for FDI Package Signature Processing. Verdicts are listed in the order evaluated, and a higher-level verdict shall always have precedence in the final FDI Package Signature processing verdict.

Table 5- FDI Package Signature Status

In addition to the sub indications supported by ETSI EN 219 201-1 as well as other tables in this paper, the following FDI specific sub indications shall be supported as specific in Table 6. The application should support reporting multiple sub indications of a given status.

Table 6 – FDI Specific Sub indications

Processing

• Overview

All processing rules that set the output status assume that the output status has NOT been set or is set to a lower priority. If an output status is one step is set to FDI-FAIL, and then evaluates to FDI-INDETEMINATE in a later step, the FDI-FAILED status shall remain. All sub-indications should be forwarded.

Once an FDI Package has been evaluated to FDI-FAILED, no further processing is required. The initial state of the output status is FDI-PASSED.

NOTE: For development purposes, further processing may be useful to troubleshoot failures.

Unsigned Packages

If the FDI Package does not include any signatures, return FDI-NOTSIGNED. No further processing is required.

NOTE: This does not include the case where an FDI Package has a signature but all result in TOTAL-FAILED. This only covers the lack of signatures

Process OPC Package Integrity

If the FDI Package contains unreferenced parts, then set the output status to FDI-FAILED/FDI_FORMAT_FAILURE. [REQ-SIGN-7]

NOTE: For example, a file was manually inserted an FDI Package that is  not  reference using  Open Packaging Conventions.  Unreferenced  parts are not covered by signature validation and could possible include malicious content.

Process TOTAL-FAILED signatures

If one or more signatures has status TOTAL-FAILED, set Output Status to FDI-INDETERMINATE/FAILED_SIGNATURE and associated sub-indications. Discard TOTAL-FAILED signatures from further processing.

NOTE:  The majority of TOTAL-FAILURE reasons are related to  overall signature integrity.   Discarded signature may  result in  fail conditions   in  subsequent rules.  Also note that up to this point, processing is only within the signature and does  not address  verifying  the hashes  to  the given parts. That processing is done later.

Process TOTAL-INDETERMINATE signatures

If one or more signatures has status TOTAL-INDETERMINATE, set the Output  status to FDI-INDETERMINATE with the associated sub-indication(s).

NOTE: The majority of TOTAL-INDETERMINATE reasons are related to establishing trust.

Process FDI Signing Certificate Requirements

For each signing certificate of the signature(s) returned from SVA, evaluate the following requirements:

• Enhanced Key Usage is Code Signing (1.3.6.1.5.5.7.3.3) [REQ-SIGN-3]
• Key  Usage is Digital Signature [REQ-SIGN-3]
• Includes XADES-T timestamp  [REQ-SIGN-5]
• Includes XADES Commitment Type [REQ-SIGN-6]

If any requirement is missing, set the Output Status to FDI-INDETERMINATE/FDI_INVALID_SIGNATURE and discard signature from further processing.

NOTE: [Req-Sign-3] requirement is derived from the requirement that signing  certificates must be rooted in the Windows Certificate Store  and parallels the requirements for code signing application.

Process Commitment Types

• Core Commitment Processing

The following commitment type rules are processed in the order listed for remaining valid signatures.

• If the FDI Package contains one or more signatures, and no signatures have commitment type #ProofOfOrigin, then set the output status to FDI-FAILED/FDI_NO_PROOF_OF_CREATION [REQ-SIGN-7].
• If the FDI Package contains more than one signature with commitment type #ProofOfOrigin, then set the output status to FDI-FAILED/FDI_MULTIPLE_PROOF_OF_CREATION. [REQ-SIGN-7]
• If the FDI Package contains a signature other than #ProofOfOrigin or #ProofOfApproval, then set the output status to FDI-INCONCLUSIVE/FDI_UNKNOWN_COMMITMENT_TYPE. [REQ-SIGN-7], [REQ-SIGN-8], [REQ- VALIDATE-2]

Process ProofOfApproval

If there is no signature with ProofOfApproval, set the output status to FDI-INDETERMINATE/FDI_NO_APPROVAL. [REQ-VALIDATE-7]

For each signature with #ProofOfApproval, verify according to IEC 29500-2 13.5, validating References, Step 1 and 2.

• For any errors detected while processing step 1 and step 2, a. through d., set output status to FDI- INDETERMINATE/FDI_APROVAL_FAILURE. [REQ-VALIDATE-8] The signature shall be discarded.
• For any invalid references as per step 2, e., set output status to FDI- INDETERMINATE/FDI_APPROVAL_INTEGRITY_FAILURE. [REQ-VALIDATE-3] Invalid parts  shall  be reported to the application. [REQ-VALIDATE-8]

For each signature of commitment type #ProofOfApproval, Identify the Registration Document associated with the signature. Set the status to FDI-INDETERMINATE/FDI_APPROVAL_FAILURE and discard the signature if any of the following conditions are true:

• Unable to find the registration document, unable to process the document or the document is not signed [REQ-SIGN-8]
• The value of the package id and package version as encoded in the signature document do not match the value in the FDI Catalog. [REQ-VALIDATE-6]

NOTE: Signatures are discarded because errors have resulted in a total integrity loss of the signature.

Process ProofOfOrigin

For the signature of commitment type #ProofOfOrigin, verify according to IEC 29500-2 13.5, validating References, Step 1 and 2.

• For any errors detected while processing step 1 and step 2, a. through d., set output status to FDI- FAILED/FDI_PACKAGE_INTEGRITY_FAILURE and discard signature. [REQ-SIGN-7] [REQ-VALIDATE-7] [REQ- VALIDATE-3]
• For any invalid references as per step 2, e., set output status to FDI-INDETERMINATE/ FDI_HASH_INTEGRITY_FAILURE. [REQ-VALIDATE-3] Invalid parts shall be reported to the application. [REQ- VALIDATE-8]
• If the package contains unsigned parts (excluding other signatures or the signature relationships), set the output status to FDI-INDETERMINATE/ FDI_PARTIAL_SIGNATURE. [REQ-SIGN-7], [REQ-VALIDATE-1]

NOTE:  The rules here are align with FCG TS62769-4, however, in  the opinion of this author, step 2  and  step 3  present serious risk  to  the  end user. [REQ-SIGN-7] requires the ProofOfOrigin to “ensure the integrity” and failures at  this  level  cannot be  traced to  either  the  package originator or  a  malicious user. The cited use  case may be  quick patching; however the author believes that digital signing should    be part of this process. This potentially trains end users to simply “ignore the warnings” and accept packages anyway.

In similar validation requirements for ProofOfApproval, those evaluate to FDI-INDETERMINATE and are reasonable so long as the ProofofOrigin is successfully validated.

Calculate FDI Package Status

Once process of all commitment types is completed, the final output status and sub-indications are now calculated.

FDI Package Signature Status Presentation

General

Once the FDI Package signature status has been calculated, it can be presented to the user. The following define recommended practices.

Bulk import of packages

A typical use case is supporting bulk importing of  packages.  Host should  consider this use case and offer means  to automatically except redundant information. For example, after a host accepts a package signed by “Acme Transmitters”, the common name of the certificate, then further packages signed by that same manufacturer may not need to be explicitly approved.

NOTE: Because FDI relies on the Microsoft root trust store,  there  is  no  explicit set  of  trusted “manufacturers”.  Registration authorities  only sign parts of the FDI package, so user should be cautioned about making decisions solely based on accepting package signed by a given Registration authority.

FDI-NOTSIGNED

When presenting an FDI Package for import that result in FDI-NOTSIGNED, the FDI Application shall display the following:

• Package Catalog Name
• Package Version
• Package Catalog Manufacturer

An optional, single icon representing the FDI-NOTSIGNED status (e.g. question mark) warning the end user that they will import an unsigned package.

The FDI Application shall require a two-step validation process before permitting the application to import the package. For example, the end user may need to select a check box “Import anyway” followed by clicking a button to import the package.

FDI-PASSED

When presenting an FDI Package for import that results in FDI-PASSED, the FDI Application shall minimally display the following information:

• Package Catalog Name
• Package Version
• Package Catalog Manufacturer
• Common Name from #ProofOfOrigin signing certificate

NOTE: Presenting both Common Name as well as Package Catalog Manufacturer is important so that the end user can accept the package based on the trusted credentials of the signer.

• An optional, single icon representing the FDI-PASS status (e.g. green checkmark)

In addition, for each signature of #ProofOfApproval, the FDI Application shall minimally display

• Attributes from XML Electronic Registrant Certificate.
• Common Name from #ProofOfApproval signing certificate

NOTE: No icon should be associated with the Proof of Approval as this may cause confusion with the overall FDI Package status.

FDI-INDETERMINATE

When presenting an FDI Package for import that results in FDI-INDETERMINATE, the FDI Application shall display any additional information to the end user.

The FDI Package shall display the following information if cryptographically validated

• Package Catalog Name
• Package Version
• Package Catalog Manufacturer
• Common Name from #ProofOfOrigin signing certificate

In addition, for each signature of #ProofOfApproval, the FDI Application shall minimally display  if cryptographically validated

• Attributes from XML Electronic Registrant Certificate.
• Common Name from #ProofOfApproval signing certificate

The application may include a single icon presenting the FDI-INDETERMINATE status (e.g. warning sign)

The FDI Application shall require a two-step validation process before permitting the application to import the package. For example, the end user may need to select a check box “I approve the import of this package” followed by clicking a button to import the package. [REQ-VALIDATE-10]

Importing of FDI-INDETERMINATE may be further restricted according to end user requirements.

FDI-FAILED

When presenting an FDI Package for import that results in FDI-FAILED, the FDI Application shall display a warning to the end use along with and additional information pertaining to the failure.

The application may include a single icon presenting the FDI-FAILED status. (e.g. red X) Importing of FDI-FAILED package shall not be permitted by the FDI Application.

Note: Developer tools may provide work arounds to support development and testing.