Digital Signature Guidelines - Royal Bank of Scotland...in whole or in part any such content without the prior written consent of The Royal Bank of Scotland Group plc. Commercial Con

Bankline DirectDigital Signature Guidelines

90079499.indd 1 20/06/2011 14:26Generated at: Mon Jun 20 14:28:52 2011

2

Important NoticeNothing contained in this document or any other communication made between RBS or its representatives and any party shall constitute an agreement, contract or representation between RBS and any other party. Receipt by the recipient of this document does not imply the existence of a contract or commitment by or with RBS for any purpose.

This document has been produced during the development phase of the RBS 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 RBS 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, RBS 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 RBS, including that contained in this document, is subject to any final agreement reached between RBS and the recipient. RBS 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 RBS prior to making any decision on the basis of this current version of the document.

Copyright

The contents of this document are copyright of The Royal Bank of Scotland Group plc or its related companies or their licensors. 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 The Royal Bank of Scotland Group plc.

Commercial Confidentiality

This document is provided for customers of RBS 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 RBS Relationship Manager.


3

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 RBS’ 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 RBS Bankline Direct service and onto the receiving member.

Document History

Version Date Notes

0.1 05 Aug 2010 Converted from Bankline Exchange version

0.2 28 Aug 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 smart card section

0.43 05 May 2011 Included high level description/introduction to S/MIME


4

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

Contents


5

1.1 Introduction to Bankline Direct

Bankline Direct provides a transactional gateway between RBS and those customers who require the facility to make payments and receive account information reports. The service supports a varied array of industry and RBS 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 RBS 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 RBS 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

1. Introduction


6

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 set up of the communication channels including delivering file signing.

You should also read the eSigner Integration Guide before reading this document.


7

2. Overview of Digital Signing SolutionsAll 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 RBS 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 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.


8

3. S/MIME Digital SignaturesS/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 HSM’s 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

For files with only one MIME Part, the boundary is not necessary:

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.

MIME Header Describes the MIME file

MIME Boundary Text delimiter

MIME Part N MIME Part 1


MIME Part N+1 MIME Part 2


MIME Part N+2 MIME Part 3


MIME Header Describes the MIME file

MIME Part MIME Part 1


9

Detached Signatures

A detached signature is where the signature is a separate structure to the signed data.

This can be represented as follows:

MIME Header

MIME Boundary

MIME Part 1 Signed Data

MIME Boundary

MIME Part 2 The digital signature (CMS format)

MIME Boundary

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


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



10

Placeholder Description

{boundary text} Any alpha-numeric text. Preferably unique per file

{CRLF} Carriage Return Line Feed – 0x0D 0x0A

{signature} The CMS {pkcs7) object returned from signing application

{content type/ content sub-type} MIME media type describing the raw data. E.g. “text/plain”, “text/xml” or “application/octet-stream”

{raw data} 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--

Placeholder Value

{boundary text} mybound123

{content type/content sub-type} text/plain

{raw data} Field1A,Field2A,Field3A{LF} Field1B,Field2B,Field3B{LF}


11

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:

For example

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.

This can be represented as follows:

MIME Part 1

Content-Type: {content type/ content sub-type}{CRLF}{CRLF}{raw data}{CRLF}

Content-Type: text/plain


MIME Header

MIME Part Signed Data and Signature – CMS format

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}


12

Placeholder Description

{CRLF} Carriage Return Line Feed – 0x0D 0x0A

{pkcs7 signature} The pkcs7 object returned from signing application

{CMS object with Data and Signature} CMS object containing original data to be signed and the signature

An example of an S/MIME embedded signature file is:

In this case, only the raw data need be sent to the signing application:

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.

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=



13

4. Use of File Signing4.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.


14

5. Bankline Direct TransmissionsAll 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 Set up

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)

• RBSSigner1.cer (this is the certificate used for RBS 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 Detached Signed Only

MIME Type Application

MIME Sub-Type octet-stream

Content Transfer Encoding Base64

Apply Content Transfer Encoding on Detached Document

No

Signing Option Single Signature

Signing Algorithm SHA-1

Message Syntax CMS

Message Output Format S/MIME


15

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 RBS 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 RBS

• separate the main file content from the signature for onward processing


16

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.

Content-Type: multipart/signed; micalg=SHA1; protocol=”application/pkcs7-signature”; boundary=”_=8054618849605373Sterling8054618849605373MOKO”

--_=8054618849605373Sterling8054618849605373MOKOContent-Type: application/octet-stream

{1:F99NWBKGB2LXGPL0000000000}{2:I198499013 N}{4::20:FSN15602:12:198:77E:GPL.MT103.106033AX.PM2010-11-20/14:24:12File accepted for further processing-}--_=8054618849605373Sterling8054618849605373MOKOContent-Type: application/pkcs7-signature; name=dsig.p7sContent-Transfer-Encoding: base64

MIIN/gYJKoZIhvcNAQcCoIIN7zCCDesCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDAQwggX+MIIE5qADAgECAhAKAUE[truncation]02Bp4FL19ANn8g==--_=8054618849605373Sterling8054618849605373MOKO—

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


17

6. Smartcard File Signing6.1 Smartcard Signing Overview

The steps required to construct and sign payment files are illustrated in 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


18

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


19

6.2 Set up Instructions

The following instructions provide some guidance on how to set up 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.

<embed EXPECTEDVERSION=”100” TYPE=”application/x-identrus-signing-plug-in” DataToBeSigned=”Content-Type: text/plain{CRLF}{CRLF}The data to be signed will be displayed here” PostURL=”Post.aspx” Height=”500” Width=”500” Mime-type=”text/plain”></embed>


20

The table below provides an explanation of the parameters you should use to configure the eSigner application.

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.

Parameter Date Type/Field Length

EXPECTEDVERSION Leave this as the default value 100

TYPE This tells the web browser what to load for the embed plugin

DataToBeSigned This should contain the data you wish to sign

PostURL The eSigner plugin will post the signature to this page

Height 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

Width 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

Mime-type The mime-type of the data in the DataToBeSigned field

/// <summary>/// Handles the Load event of the Page control./// </summary>/// <param name=”sender”>The source of the event.</param>/// <param name=”e”>The <see cref=”System.EventArgs”/> instance containing the event data.</par-am>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); }}


21

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.0Content-Type: multipart/signed; protocol=”application/x-pkcs7-signature”; micalg=sha1; boundary=”----261FEEA5CDD648E5A546D076DE289589”

This is an S/MIME signed message

------261FEEA5CDD648E5A546D076DE289589Content-Type: text/plain

Data to be signed to be signed will be displayed here------261FEEA5CDD648E5A546D076DE289589Content-Type: application/x-pkcs7-signature; name=”smime.p7s”Content-Transfer-Encoding: base64Content-Disposition: attachment; filename=”smime.p7s”

MIINogYJKoZIhvcNAQcCoIINkzCCDY8CA==

------261FEEA5CDD648E5A546D076DE289589--


22

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:


23

7. Hardware Security ModuleCustomers 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) can not be completed until the details have been supplied.

7.1 HSM Requirements

The Bankline Direct service requires HSM’s 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 RBS 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 RBS (details outlined in the letter). Once the Certificate Request has been received by RBS, a customer specific Certificate will be generated by TrustAssured (who are the RBS 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)

• <customer name>.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

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.


The Royal Bank of Scotland plc. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Registered in Scotland No. 90312. 90079499


Documents

Digital Signature Guidelines - Royal Bank of Scotland...in whole or in part any such content without the prior written consent of The Royal Bank of Scotland Group plc. Commercial Con