Digital Signing guidelines - NatWest

Bankline Direct
Digital Signature Guidelines

Important Notice
Nothing contained in this document or any other communication made between NatWest or its representatives
and any party shall constitute an agreement, contract or representation between NatWest and any other party.
Receipt by the recipient of this document does not imply the existence of a contract or commitment by or with
NatWest for any purpose.
This document has been produced during the development phase of the NatWest Bankline Direct solution. Every
effort has been made to ensure that the contents of this document are correct and accurately reflect the way the
product will operate. However, the functionality of the proposed service is not yet fully implemented and tested
and therefore the information given here may be subject to change. Furthermore it may not be technically possible
to implement some functionality described herein or it may not be available at the initial release of the product.
The information contained in this document is subject to constant updating and amendment in the future and is
necessarily selective. It does not purport to contain all of the information which the recipient may require. While
NatWest has taken all reasonable steps to ensure, as at the date of this document, that the facts which are
contained in this document are materially correct and accurate, NatWest does not make any representation or
warranty as to the accuracy or completeness or otherwise of this document, or the reasonableness of any
assumptions on which this document may be based. All information supplied by NatWest, including that contained
in this document, is subject to any final agreement reached between NatWest and the recipient. NatWest accepts
no liability to recipients whatsoever and however arising and whether resulting from the use of this document, or
any omissions from or deficiencies in this document.
The details contained in this document may be subject to change until such time as a final version is published.
Customers should therefore seek further guidance from NatWest prior to making any decision on the basis of this
current version of the document.
Copyright
The contents of this document are copyright of NatWest. Unless otherwise indicated you may not use, sell,
licence, copy or reproduce in whole or in part any such content without the prior written consent of NatWest.
Commercial Confidentiality
This document is provided for customers of NatWest use only, under the terms of a non-disclosure agreement.
The recipient of any copies of this document is bound by the terms of the non-disclosure agreement.
Contact
For further details, please contact your NatWest Relationship Manager.
2

Terminology Used
For ease of reference and reading of this document, the following terms are used to indicate the meaning
described. A full glossary, describing all other terms used can be found at the end of this document.
Bankline Direct
Is the term used to refer to NatWests’ various interfaces, network connections, systems and operational activities
that collectively provide the functionality described in this document.
Outbound/Outward/Sending
This refers to the direction of a payment from a customer via the NatWest Bankline Direct service and onto the
receiving member.
Document History
Version Date Notes
0.1 05 August 2010 Converted from Bankline Exchange version
0.2 28 August 2010 Cosmetic Changes
0.3 30 March 2011 Converted to new template
0.4 20 April 2011 Included Bankline Direct Transmissions and other introductory sections
0.41 20 April 2011 Minor cosmetic changes
0.42 21 April 2011 Improvements arising from feedback on Smartcard section
0.43 05 May 2011 Included high level description/introduction to S/MIME
3

Contents
1. Introduction 5
1.1 Introduction to Bankline Direct 5
1.2 Purpose of Technical Specifications 5
1.3 Purpose of Digital Signature Guidelines 6
1.4 Use of Digital Signature Guidelines 6
2. Overview of Digital Signing Solutions 7
3. S/MIME Digital Signatures 8
3.1 MIME 8
3.2 S/MIME Digital Signatures 8
4. Use of File Signing 13
4.1 Typical Use of an HSM 13
4.2 Typical Use of Smartcards 13
5. Bankline Direct Transmissions 14
5.1 Setup 14
5.2 Integration 14
5.3 Signature Validation 15
5.4 Signed File Example 16
6. Smartcard File Signing 17
6.1 Smartcard Signing Overview 17
6.2 Setup Instructions 19
6.3 “PostURL” page 20
6.4 S/MIME Output File 21
6.5 Troubleshooting Tips 22
7. Hardware Security Module 23
7.1 HSM Requirements 23
7.2 HSM Setup 23
7.3 Integration 23
4

Introduction
1.1 Introduction to Bankline Direct
Bankline Direct provides a transactional gateway between NatWest and those customers who require the facility
to make payments and receive account information reports. The service supports a varied array of industry and
NatWest formats to enable simple integration into customers’ own systems.
The Bankline Direct service is scalable and flexible to meet the need of customers who wish to make single
payments transactions or multi-payment files. An extensive number of different account information reports and
payment advice notices are available, along with reconciliation and activity reporting. All reports are published
at a frequency that suits the needs of the customer.
All data exchanged between the customer and the Bankline Direct service is secure, adhering to industry
security standards.
1.2 Purpose of Technical Specifications
The purpose of this document is to provide NatWest customers with the required technical specifications to build
and use the relevant connectivity channels to communicate with the Bankline Direct service.
The following are the different types of Bankline Direct technical specification documents available
Channel Build Guidelines
Technical specifications and setup instructions for the connectivity channel between NatWest and
its customer
Digital Signature Guidelines
Technical specifications outlining the structure and format of digital signatures applied to files sent
by Bankline Direct and also the requirements for signing payment files to the service
Outward Payment Files and Messages
Technical specifications for the content and format of payment instructions; either for individual
payment messages or files containing multiple payment messages
Acknowledgements
Technical specifications for the content and format of acknowledgements sent to the customer from
the Bankline Direct service
Reports
Technical specifications for the content and format of reports and statements sent to the customer
from the Bankline Direct service
5

1.3 Purpose of Digital Signature Guidelines
The purpose of this document is to provide Bankline Direct customers with the instructions on how to apply a
digital signature to payment files.
This document describes how to sign files using Smartcards utilising eSigner application, which is supplied on
CD along with the Smartcards.
This document also outlines the use of Hardware Security Module (HSM) solution for file signing.
1.4 Use of Digital Signature Guidelines
This document should be used alongside the Bankline Direct Channel Build Guidelines (Ref: BD-31.01) which
describe the overall setup of the communication channels including delivering file signing.
You should also read the eSigner Integration Guide before reading this document.
6

2. Overview of Digital Signing Solutions
All communications between the customer and the Bankline Direct service in either direction must be secure.
All transmissions generated by the service will be digitally signed; likewise any payment messages or files sent
to the Bankline Direct service must be signed with a digital certificate.
Section 5 details the security configuration applied to reports and acknowledgements generated by the Bankline
Direct service.
Customer utilising the payment submission service must send messages and files complying with the prescribed
NatWest security and industry standards. There are two options for applying a digital signature to payment
transmissions, Smartcards and Hardware Security Module (HSM), please refer to sections 6 and 7 respectively.
An HSM solution offers an unattended solution for straight through processing and may be attractive to customers
who process large volumes of payments. An HSM solution reduces the administrative overhead and associated
staffing needs but is a more expensive option. It is the customer’s responsibility to procure and install an
HSM module.
A Smartcard solution is a secure, but manual process requiring intervention from staff members, by entering a
PIN number using a card reader and individual card credentials. This Smartcard option is considerably cheaper.
Bankline Direct transmissions are digitally signed using an HSM.
Digitally signed communications that travel in both directions adhere to the S/MIME standard.
Section 3 provides a high level description of S/MIME.
7

3. S/MIME Digital Signatures
S/MIME is the standard used to sign files that are sent to the customer. All payment files must also be signed using
S/MIME. Signing of all payment files must adhere to the S/MIME standard regardless of whether Smartcards or
HSMs are used to provide the signature. As S/MIME is a complex standard this section is included as a ‘primer’ for
customers who have no familiarity or experience with S/MIME.
It is not meant to cover all areas of the (S)MIME standard. It is meant only to give a high-level overview of how
S/MIME files are constructed, for use with Bankline Direct.
3.1 MIME
Bankline Direct requires that digitally signed files are submitted using the S/MIME format. S/MIME is an extension
of the MIME standard and is used to describe how to deliver signed and encrypted files.
Simply, MIME is formed of the following entities:
MIME Header – description of the MIME file contents
MIME Boundary – text delimiter to separate entities
MIME Part – a MIME file can have one or more MIME parts, each separated by a MIME boundary.
Each part will have headers describing the MIME part content
MIME Header
MIME Boundary
Describes the MIME file
Text delimiter
MIME Part N MIME Part 1
MIME Boundary
Text delimiter
MIME Part N+1 MIME Part 2
MIME Boundary
Text delimiter
MIME Part N+2 MIME Part 3
MIME Boundary
Text delimiter
For files with only one MIME Part, the boundary is not necessary:
MIME Header
Describes the MIME file
MIME Part MIME Part 1
3.2 S/MIME Digital Signatures
Digitally signed files can be submitted to Bankline Direct with detached or embedded (opaque) signatures.
Bankline only creates files with detached signatures.
8

Detached Signatures
A detached signature is where the signature is a separate structure to the signed data.
MIME Header
MIME Boundary
MIME Part 1
Signed Data
MIME Boundary
MIME Part 2
The digital signature (CMS format)
MIME Boundary
This can be represented as follows:
MIME Header
MIME-Version: 1.0{CRLF}
Content-Type: multipart/signed;
{optional CRLF}{SPACE}protocol=”application/x-pkcs7-signature”;
{optional CRLF}{SPACE}micalg=sha1;
{optional CRLF}{SPACE}boundary=”{boundary text}”{CRLF}
{CRLF}
{optional message with CRLF}
MIME Boundary
--{boundary text}{CRLF}
MIME Part 1
Content-Type: {content type/content sub-type}{CRLF}
{CRLF}
{raw data}{CRLF}
MIME Boundary
--{boundary text}{CRLF}
MIME Part 2
Content-Type:application/x-pkcs7-signature; {optional
CRLF}{SPACE}name=”smime.p7s”{CRLF}
Content-Transfer-Encoding: base64{CRLF}
Content-Disposition: attachment; filename=”smime.p7s”{CRLF}
{CRLF}
{signature}{CRLF}
MIME Boundary
--{boundary text}--
9

Placeholder
{boundary text}
{CRLF}
{signature}
{content type/content sub-type}
{raw data}
Description
Any alpha-numeric text. Preferably unique per file
Carriage Return Line Feed – 0x0D 0x0A
The CMS {pkcs7) object returned from
signing application
MIME media type describing the raw data. E.g.
“text/plain”, “text/xml” or “application/octet-stream”
The original data required to be processed by
Bankline Direct
An example of an S/MIME detached signature file is:
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol=”application/x-pkcs7-signature”; micalg=sha1;
boundary=”myboundary123”
S/MIME signed file
--myboundary123
Content-Type: text/plain
Field1A,Field2A,Field3A
Field1B,Field2B,Field3B
--myboundary123
Content-Type: application/x-pkcs7-signature; name=”smime.p7s”
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=”smime.p7s”
MIIFDgYJKoZIhvcNAQcCoIIE/zCCBPsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
DQEHAaCCA54wggHLMIIBNAIBBDANBgkqhkiG9w0BAQUFADAuMQwwCgYDVQQDDANC
MkIxETAPBgNVBAoMCFN0ZXJsaW5nMQswCQYDVQQGEwJVUzAeFw0wOTA2MzAxMDU1
MTBaFw0xMTA2MzAxMDU1MTBaMC4xDDAKBgNVBAMMA0IyQjERMA8GA1UECgwIU3Rx
................................................................
...........C3v2QmT8zwqHihIHxMHLrCTZmXMM=
--myboundary123--
10
Placeholder
{boundary text}
{content type/content sub-type}
{raw data}
Value
mybound123
text/plain
Field1A,Field2A,Field3A{LF}
Field1B,Field2B,Field3B{LF}

Bankline Direct will use whatever data is between the MIME Part 1 start and end boundaries to verify the
signature. Therefore, the data that needs to be signed must include all data from MIME Part 1.
All this must be sent to the signing application:
MIME Part 1
Content-Type: {content type/content sub-type}{CRLF}
{CRLF}
{raw data}{CRLF}
For example
Content-Type: text/plain
Field1A,Field2A,Field3A
Field1B,Field2B,Field3B
Embedded Signatures
An embedded signature is where the signature and data are combined within a single (Cryptographic Message
Syntax) CMS structure. These are also known as Opaque signatures.
MIME Header
MIME Part
Signed Data and Signature – CMS format
This can be represented as follows:
MIME Header
MIME-Version: 1.0{CRLF}
Content-Disposition: attachment;
{optional CRLF}{SPACE}filename=”smime.p7m”{CRLF}
Content-Type: application/x-pkcs7-mime;
{optional CRLF}{SPACE}smime-type=signed-data;
{optional CRLF}{SPACE}name=”smime.p7m”{CRLF}
Content-Transfer-Encoding: base64{CRLF}
{CRLF}
MIME Part
{CMS object with Data and Signature}
11

Placeholder
{CRLF}
{pkcs7 signature}
{CMS object with Data and Signature}
Description
Carriage Return Line Feed – 0x0D 0x0A
The pkcs7 object returned from signing application
CMS object containing original data to be signed and
the signature
An example of an S/MIME embedded signature file is:
MIME-Version: 1.0
Content-Disposition: attachment; filename=”smime.p7m”
Content-Type: application/x-pkcs7-mime; smime-type=signed-data;
name=”smime.p7m”
Content-Transfer-Encoding: base64
MIIFDgYJKoZIhvcNAQcCoIIE/zCCBPsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
DQEHAaCCA54wggHLMIIBNAIBBDANBgkqhkiG9w0BAQUFADAuMQwwCgYDVQQDDANC
MkIxETAPBgNVBAoMCFN0ZXJsaW5nMQswCQYDVQQGEwJVUzAeFw0wOTA2MzAxMDU1
MTBaFw0xMTA2MzAxMDU1MTBaMC4xDDAKBgNVBAMMA0IyQjERMA8GA1UECgwIU3Rx
................................................................
...........C3v2QmT8zwqHihIHxMHLrCTZmXMM=
In this case, only the raw data need be sent to the signing application:
Field1A,Field2A,Field3A
Field1B,Field2B,Field3B
The signing application must be instructed to return the CMS object with the signed data included. This can be
then used to populate MIME Part
12

4. Use of File Signing
4.1 Typical Use of an HSM
A Hardware Security Module (HSM) can be used to apply a digital signature to a payment file before it is sent onto
the Bankline Direct service. The HSM stores the certificates and signing keys.
A typical use of an HSM solution is for a payment file to be generated and presented to the HSM in order to apply
a digital signature automatically to the file before being sent to the Bankline Direct service.
HSMs also have the capability to store the Bankline Direct certificate details to validate files being sent to the
customer from the service.
Please refer to section 7 for configuration details for HSM.
4.2 Typical Use of Smartcards
Smartcards and card readers provide a manual approach to apply digital signatures to payment files. The card
readers are connected to a local computer using specific signing software. Smartcards are assigned to individuals
and must be combined with a user passcode to sanction the digital signing.
A typical use of a Smartcard solution is for a payment file to be generated and presented to the signing software,
where the operator can sign the file (using the eSigner software provided) using their individual Smartcard and
passcode before they submit the files onto the Bankline Direct service.
13

5. Bankline Direct Transmissions
All communications from the Bankline Direct service to a customer will be digitally signed using an HSM.
In order to receive these signed transmissions from the Bankline Direct service, the customer must check that the
signature is one from the Bankline Direct service. The customer will need to extract the data from the file for
processing by their systems whether that is an automated or manual process.
Please refer to section 5.4 for an example of a signed file. The following sections describe how that will
be achieved.
5.1 Setup
During the registration process, the customer will be sent certificate details which will enable them to authenticate
files received from the Bankline Direct service.
The following details will be provided to the customer;
Production root.cer
Production Sub CA.cer (this is the certificate authority used by the Bankline Direct service)
NWBSigner1.cer (this is the certificate used for Natwest customers)
In order for the Bankline Direct digital signature to be validated by the customer, the certificates must be loaded
into the customer’s HSM module or within any other system being used to check files. Section 5.2 will outline the
standards that the Bankline Direct signed files will comply with.
5.2 Integration
Transmissions sent by the Bankline Direct service will be signed using an S/MIME standard, with the following
options applied.
Security Type
MIME Type
MIME Sub-Type
Content Transfer Encoding
Apply Content Transfer Encoding on
Detached Document
Signing Option
Signing Algorithm
Message Syntax
Message Output Format
Detached Signed Only
Application
octet-stream
Base64
No
Single Signature
SHA-1
CMS
S/MIME
14

5.3 Signature Validation
There are two well known methods for checking the validity of the digital signature, i.e. to check whether the
certificate has been revoked. These are;
Online Certificate Status Protocol (OCSP)
This allows the revocation status of a certificate to be determined at the time the file is received
Certificate Revocation List (CRL)
This is a list of all certificates that have been revoked. It will need to be refreshed at ‘regular’ intervals
(e.g. 24 hours). This approach is not perfect as the certificate could have been revoked between the time
a file is received from NatWest and the last time the certificate was published.
Customers using an HSM solution may find their supplier provides software with the ability to validate signatures
applied to files.
The customer’s system must extract the signature from the file in order to;
check the signature is valid
check the file has been supplied by NatWest
separate the main file content from the signature for onward processing
15

5.4 Signed File Example
The following is an example of a digitally signed file that would be sent from the Bankline Direct service.
The example used here is a positive File Status Notification.
In the example below, the content transfer encoding has been truncated, but the signature header and message
content is displayed.
S/MIME
Header and
boundary
Message/File
Data
Refer to Tech
Specs for each
format
S/MIME
boundary and
base 64
encoding
Truncated for
display
Content-Type: multipart/signed; micalg=SHA1; protocol=”application/pkcs7-signature”;
boundary=”_=8054618849605373Sterling8054618849605373MOKO”
--_=8054618849605373Sterling8054618849605373MOKO
Content-Type: application/octet-stream
{1:F99NWBKGB2LXGPL0000000000}{2:I198499013 N}{4:
:20:FSN15602
:12:198
:77E:
GPL.MT103.106033AX.PM
2010-11-20/14:24:12
File accepted for further processing
-}
--_=8054618849605373Sterling8054618849605373MOKO
Content-Type: application/pkcs7-signature; name=dsig.p7s
Content-Transfer-Encoding: base64
MIIN/gYJKoZIhvcNAQcCoIIN7zCCDesCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDAQw
ggX+MIIE5qADAgECAhAKAUE[truncation]02Bp4FL19ANn8g==
--_=8054618849605373Sterling8054618849605373MOKO—
16

6. Smartcard File Signing
6.1 Smartcard Signing Overview
The steps required to construct and sign payment files are illustrated in the following diagram. The top half of the
diagram outlines how the solution operates, whilst the second half details the implementation steps.
Smartcards are distributed with a CD incorporating:
Gemalto Classic Client for certificate administration
eSigner to facilitate generation of the digital signature required by Bankline Direct
17

An Integration Guide will also be sent separately to the Smartcards.
These are the OS supported by eSigner 4.1.9 – 001:
Windows XP Home (SP2) – 32-bit only
Windows XP Home (SP3) – 32-bit only
Windows XP Pro (SP2 and SP3) – 32-bit only
Windows Server 2003 R2 SP2 (only with Citrix Metaframe Presentation Server 4.5 or with Terminal Services)
Windows Vista SP1 – 32-bit and 64-bit
Windows Vista SP2 – 32-bit and 64-bit
Windows Server 2008 – SP2 32-bit and 64-bit
Windows 7 – 32-bit and 64-bit
Windows Server 2008 R2 - 32-bit and 64-bit
These are the supported browsers:
Internet Explorer 6, 7 and 8 (32-bit versions of IE only)
Mozilla Firefox 3.6 (32-bit version of Firefox only)
All payment files must be signed to an S/MIME v3.1 standard, with the following options applied:
The message syntax can be PKCS7 or CMS
The algorithm must be SHA-1
The signature can be detached (original data not included) or embedded (original data included)
The Content Transfer Encoding can be None or Base64
18

6.2 Setup Instructions
The following instructions provide some guidance on how to setup your systems to sign payment files using eSigner
prior to submission to Bankline Direct:
Install the eSigner application. This must be installed on all clients who will be signing files.
The eSigner plugin is a Java plugin for Internet Explorer. The HTML code which is generated when a user browses
to the internal file signing page is as follows:
The image below shows the eSigner plugin as it will be displayed to the user.
19

The table below provides an explanation of the parameters you should use to configure the eSigner application.
Parameter
Date Type/Field Length
EXPECTEDVERSION Leave this as the default value 100
TYPE
DataToBeSigned
PostURL
Height
Width
Mime-type
This tells the web browser what to load for the embed plugin
This should contain the data you wish to sign
The eSigner plugin will post the signature to this page
The height of the plugin as it will be displayed on the page. Use 500 as less than this
value will cause the plugin to be displayed in a popup window
The width of the plugin as it will be displayed on the page. Use 500 as less than this
value will cause the plugin to be displayed in a popup window
The mime-type of the data in the DataToBeSigned field
6.3 “PostURL” page
This page will be used by the eSigner plugin to send the signature to.
The signature will be sent as HTTP POST data.
Below is an example of an ASP.net page which will get the signature and the original file and save it to a file.
///
/// Handles the Load event of the Page control.
///
/// The source of the event.
/// The instance containing the event data.
protected void Page_Load(object sender, EventArgs e)
{
string signature = (string)Request.Form[“Signature”];
string rawFileName = (string)Session[“RawFileName”];
string rawFileContent = (string)Session[“RawFileContent”];
if (Request.Form[“SigningInterfaceException”] != null)
{
string errorType = Request.Form[“SigningInterfaceException”];
// Handle the error
}
else
{
this.SaveSignedFile(rawFileName, rawFileContent, signature);
}
}
20

The code extract overleaf shows that the signature is stored in the HTTP POST variable called “Signature”.
The code first checks the “SigningInterfaceException” post data. If this exists an error has occurred and will need
to be handled.
The method “SaveSignedFile” you will need to implement yourself. This saves the original file data and signature to
an S/MIME file
6.4 S/MIME Output File
S/MIME files allow you to save the original file data and the signature in a file which can be easily sent
to a destination.
The SMIME RFC 2633 will give you a detailed explanation of the SMIME format.
Shown below is an example of an SMIME file. This can be used this as a template for generating files of this type.
Ensure you pass the “Content-Type: text/plain” data to the eSigner plugin as well the data to sign in order for it be
validated correctly.
MIME-Version: 1.0
Content-Type: multipart/signed; protocol=”application/x-pkcs7-signature”; micalg=sha1; boundary=
”----261FEEA5CDD648E5A546D076DE289589”
This is an S/MIME signed message
------261FEEA5CDD648E5A546D076DE289589
Content-Type: text/plain
Data to be signed to be signed will be displayed here
------261FEEA5CDD648E5A546D076DE289589
Content-Type: application/x-pkcs7-signature; name=”smime.p7s”
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=”smime.p7s”
MIINogYJKoZIhvcNAQcCoIINkzCCDY8CA==
------261FEEA5CDD648E5A546D076DE289589--
21

6.5 Troubleshooting Tips
The eSigner plugin will post the signature to the page configured by the “PostURL” parameter. You will need to
save this as required.
The eSigner plugin only sends the signature to the “PostURL” page. In order to create an S/MIME file you will also
need the original file data. Save a reference to this as a session variable so it can be retrieved by the “PostURL” page.
You will need to have your card inserted into the card reader before you click the Sign button. If it is not inserted
you will be presented with the following error:
22

7. Hardware Security Module
Customers opting for a Hardware Security Module (HSM) solution should look to have this device installed and
part-configured* ahead of submitting the Bankline Direct registration mandate.
Bankline Direct certificates will be supplied as part of service registration process and are chargeable with a lifespan of
three years. Please refer to your Relationship Manager or Implementation Manager for more details.
*pre-configuration of Bankline Direct transmissions security (as outlined in section 5) cannot be completed until
the details have been supplied.
7.1 HSM Requirements
The Bankline Direct service requires HSMs to conform to the FIPS 140-2, Level 2 standard. Please consult your
HSM supplier for more information.
7.2 HSM Setup
During the registration process, the customer will receive a letter and a form from NatWest containing details on
how to generate a Certificate Request.
The Certificate Request must be generated from the HSM module and copied to a CD. The CD must be posted to
NatWest (details outlined in the letter). Once the Certificate Request has been received by NatWest,
a customer specific Certificate will be generated by TrustAssured (who are the NatWest certificate authority).
The customer specific Certificate will be emailed in a zip file back to the requester for uploading into the HSM
module. The following details will be sent to the customer:
Production root.cer
Production Sub CA.cer (This is the issue certificate of the Certificate Authority that signed the customer’s
Certificate Signing Request)
.cer (this is the uploaded into the HSM)
7.3 Integration
The HSM module must be configured to apply a digital certificate to payment files to an S/MIME standard.
The following S/MIME file signing options must be enabled:
the message syntax can be PKCS7 or CMS
the algorithm must be SHA-1
the signature can be detached (original data not included) or embedded (original data included)
the Content Transfer Encoding can be None or Base64
23
The signing certificate can be included but it is not used. The customer’s public certificate(s) will already have
been registered on Bankline Direct as part of the registration process.

National Westminster Bank Plc.
Registered in England No 929027.
Registered Office: 135 Bishopsgate, London EC2M 3UR. 90079500