Electronic Bank Account Management - EBAM

Transcription

1 Electronic Bank Account Management - EBAM EBAM and Digital Signature This guide provides an overview of how to use a digital signature in the EBAM solution to sign the XML messages and the potential attachments. The construction of the file containing the XML message and attachments is included. 15 July 2012

2 Table of Contents Preface Introduction Purpose and Scope Digital signature - Business requirements Recommendations Transporting the "Signature Card" Applying and verifying signatures in XML messages Applying and verifying signatures in XML messages with attached documents Multiple Signatures Approaches for multiple signing Implementation of multiple signatures Legal Notices EBAM and Digital Signature

3 Preface Preface Purpose of this document This document describes the signing of a file containing an Electronic Bank Account Management (EBAM) XML message and related attachments. The conventions used in digitally signing such files are discussed. Intended audience Chapter 1 introduces EBAM messages, the use of signing and the signature card. Chapter 2 provides recommendations how to sign and how to transport a signed message and attachments Chapter 3 explains how to combine multiple signatures on a single file This document is for the following audience: Banks receiving or creating such files Vendors receiving or creating such files SWIFT staff who support FileAct solutions using such files Document conventions This document uses the following typographical conventions: Bold Italics Courier Names of files, parameters, API calls, user logon, and logon groups References to a directory or a menu GUI elements and command names Important information and document names User input, directory paths, parameter values, place holders, and system output examples Significant changes from the previous version January 2010 New information The support of multiple Signatures within an EBAM message. Location See Multiple Signatures on page 18 Updated information The signing of individual attachments to an EBAM message Location See under electronic format on page 5 15 July

4 1 Introduction 1.1 Purpose and Scope EBAM Solution The EBAM Solution captures within ISO XML messages some key information that is today exchanged on paper between banks and corporates when they manage bank accounts. The process steps in scope include: Bank account opening Bank account maintenance, including the management of the mandates on the bank accounts Bank account closing Reporting of bank account features (e.g. ownership, mandates) The main benefits for both banks and corporates are a reduced total elapse time, an increased corporate customer satisfaction, reduced cost and risk and an improved STP and traceability. The EBAM solution only addresses bank account management activities for customers that already have a relationship with a bank or for a new legal entity of this customer. 1.2 Digital signature - Business requirements Signature card Definition Managing bank accounts involves the exchange of information on individuals authorised to perform financial transactions from the designated bank account(s). This information commonly known as bank mandates - includes: Name Function Financial limits up to which the individual is authorised to perform transactions (e.g. treasury payment up to KEUR 10,000) The wet signature of the individual Currently, this information is captured on paper on a signature card ( carton de signature ). As the below illustration indicates, wet signatures of authorised individuals are documented as well as the signature of the main mandator. The main mandator's signature is mandatory as it officially delegates authority to the authorised individuals registered on the signature card. carton de signature Signature card KEUR Mr X 10,000 Mr Y 8,000 Ms Z 5,000 CFO Treasurer GL accountant Main mandator Figure - Signature Card 4 EBAM and Digital Signature

5 Introduction Requirement In the context of the EBAM solution, the signature card is no longer needed because the related info may be captured within the XML message. Therefore, two business needs have been identified: 1. transport personal digital certificates of authorised individuals (e.g. CFO, Treasurer, GL Accountant) to enable them to digitally sign transactions on the account in the future. 2. digitally sign the EBAM XML message containing the information on authorised individuals. This signature will replace today s wet signature of the main mandator. It is to be noted that this signature is at the individual vs. the corporate level EBAM instructions Requirement to sign EBAM instructions Just like for the mandate management instructions in item 1.2.1, there is a need for the legal representatives of an organisation to personally and digitally sign the EBAM instructions when opening, maintaining or closing an account. An instruction might have to be signed by one or more individuals. Depending on the business scenario, these signatures might have to be in a specific, pre-defined order or the sequence of signing might be irrelevant under electronic format Need for signing attachments Although the developed XML messages capture the core of the information needed to manage bank accounts, it is impossible to replace the entire set of paper documents that is used today. Main reasons for that are: Lack of harmonisation between/within banking groups Lack of harmonisation between countries/regions Legal constraints As a result, banks and corporates may have to complement the XML messages with these paper documents under electronic format, in which case: 1. these attached documents are considered a genuine part of the EBAM instructions and therefore will have to be part of the digitally signed XML instruction to comply with security requirements as per When the EBAM instructions arrives at the bank, the attached documents are typically detached from the EBAM XML message, duplicated, re-routed, re-used for future transactions, etc The link with the EBAM instruction is then the file name of the document and the secure digest. There is a business requirement to optionally protect the document itself by a digital signature stored within the file using available technology. The individual attachments with a personal digital signature thus become self-standing when detached from their EBAM XML instruction. These two requirements may be combined. Even when the attached documents are individually signed with one or more digital signatures, the EBAM XML instruction with its respective attachment(s) may need (an) additional signature(s) to secure it as instruction from the account owner to its bank. The attachments may be in any electronic format such as pdf, doc, jpg, xls, July

6 2 Recommendations Introduction The below section describes the recommended options that have been identified to address the above business requirements. They are based on consultation work with banks, corporates and application vendors. The SWIFT offering for EBAM allows for multibank personal digital signature and identity and is compliant with the below recommendations. 2.1 Transporting the "Signature Card" Overview Example The "Signature Card" provides a way to authenticate who signs. For digital signatures using a Public Key Infrastructure, the X509 certificate issued by a Certificate Authority is used to authenticate what is signed by whom. That means that with digital signatures the X509 certificate is used to represent the wet signature on the "Signature Card". The X509v3 certificate is added in the appropriate element using the built in xs:base64binary schema data type, where the xs namespace is defined as xmlns:xs=" There are no constraining facets such as maxlength. The size of the certificate depends on the attributes that are registered and the size of the keys used. The size is typically less than 2000 characters. The certificate is "known" by the receiver, so that the application can check whether a given certificate identifies the person described within other fields of the message. As an example, the acmt Account Mandate Maintenance Request contains the certificate within an element. <Doc:Document xmlns:doc="urn:iso:..."> <Doc:acmt >... <Doc:Cert>MII4diDF5FE52d5...</Doc:Cert>... </Doc:acmt > </Doc:Document> 2.2 Applying and verifying signatures in XML messages Overview The recommended option for digitally signing XML messages is to use the existing standard DSIG and to embed the signature within the XML message. The DSIG standard is documented in the XML - Signature Syntax and Processing (Second Edition) - W3C Recommendation. This document is public available on The recommendation defines the syntax and processing rules of XML digital signatures. Note that the DSIG standard is in a second edition, but that the features used in EBAM were already available in the first edition that was finalised in Signing parameters EBAM parameters Not all features of the DSIG standard are needed. DSIG specifies a number of algorithms and is extensible. EBAM will use the following setup and algorithms for signing the XML messages: What is signed is always the ISO Document element without the embedded Signature element. If documents are attached, the recommendations are described in chapter Applying and verifying signatures in XML messages with attached documents. If multiple signatures are applied, what is signed depends on the use case as per chapter Approaches for Multiple signing. 6 EBAM and Digital Signature

7 Recommendations Scope of the digital signature Signer signs colored part: (<Refs>, <Acct>, <Org>, <Mndt> ) Since the Signature only covers data that is part of the message that includes the Signature, the Manifest construct is not required. In this case the SignedInfo includes the reference(s) to the data to be signed. The canonicalization algorithm is the Canonical XML 1.0 omitting comments. The recommended digesting algorithm is SHA256 The recommended signing algorithm is RSA-SHA256. Allowed is RSA-SHA1 A transform algorithm to remove whitespace is added as described in Whitespace handling on page 7 The KeyInfo contains the certificates required to validate the SignatureValue element. These certificates can be compared with the deposited certificates in order to identify the signer of the message. By adding the certificate within the KeyInfo, the receiving application can use the certificate as such to find back in its database who actually signed it and whether this person had the entitlement to sign this message. The SignatureValue contains the result of the signing algorithm in base64. This result is the PKCS1 as described in DSIG standard for RSA-SHA1 and as described in RFC4051 for RSA- SHA Whitespace handling Description The ISO EBAM messages do not contain mixed content that is signed. That means that whitespace between elements is meaningless. Because of this, the processing of ISO messages may be aware of this fact, so that whitespace is not always treated as signed data. In order to exclude this whitespace from the data signed, it should first be removed. To make this explicit in the Signature, a transformation algorithm is specified. The algorithm is identified with a specific URI urn:swift:transform:remove-whitespace-between-elements An example of a Transform is thus: <ds:transform ds:algorithm= "urn:swift:transform:remove-whitespace-between-elements"/> The algorithm may be implemented using an XSLT stylesheet. The stylesheet element is simply: <xsl:stylesheet version="1.0" xmlns:xsl=" 15 July

8 <xsl:output encoding="utf-8" /> <xsl:strip-space elements="*" /> <xsl:template node()"> <xsl:copy> <xsl:apply-templates node()" /> </xsl:copy> </xsl:template> </xsl:stylesheet> The use of an XSLT transform within the Signature itself is not allowed. The processing is to strip whitespace between elements. It is not required to use an XSLT processor to perform this job. Note Security concerns are important in a proper implementation of this specification. See the XML Signature Best Practices issued by W3C for more information. The XML Signature Best Practices is currently a working draft Scope of the canonicalization Document as root element The Signature is part of the ISO message. The message itself is signed. The Signature is always transported together with the ISO message. The application signs and verifies the Signature in the context of the ISO message. Therefore, the application always parses the Document element as root element. Namespaces in scope The Canonical XML 1.0 omitting comments is identified by the ds:algorithm=" within the Signature. This algorithm will include all namespace declarations in scope of the element that is canonicalized, which are derived from all ancestor nodes up to the Document root node. For further information see Availability of the documents signed when verifying the Signature on page Verifying the Signature Purpose The verification of the Signature will check that the SignatureValue matches with the SignedInfo and that the DigestValue within the SignedInfo matches with message data after applying the canonicalization algorithm and the Signature element is removed. Parameters The SignedInfo includes the reference(s) to the data to be signed. The KeyInfo contains the certificates required to validate the SignatureValue element. The SignatureValue contains the result of the signing algorithm in base64. This result is the PKCS1 as described in DSIG standard for RSA-SHA1 and as described in RFC4051 for RSA-SHA Example Introduction Example We take as example the Account Opening Request message acmt This message contains in element 9.34 the Signature that covers the message signed by the requestor of the account. <Doc:Document xmlns:doc="urn:iso:..."> <Doc:acmt >... <ds:signature xmlns:ds=" 8 EBAM and Digital Signature

9 Recommendations... </ds:signature>... </Doc:acmt > </Doc:Document> The Signature is signing the complete ISO Document except the Signature element itself. The Signature element looks like: <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod ds:algorithm=" <ds:signaturemethod ds:algorithm=" <ds:reference URI=""> <ds:transforms> <ds:transform ds:algorithm=" <ds:transform ds:algorithm="urn:swift:transform:remove-whitespace-between-elements"/> <ds:transform ds:algorithm=" </ds:transforms> <ds:digestmethod ds:algorithm=" <ds:digestvalue>fji4f1v5dt581sd55dk...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>o834b89ygbrtoosfdyi87r8gty48t46...</ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate> MII4ybroe8... <ds:/x509certificate> <ds:x509certificate> MIIqvnippi... </ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> The SignedInfo element contains one Reference element. This Reference element is pointing to the XML document that contains the Signature. As specified, this is the ISO message itself. The ISO Document is canonicalized using the same canonicalization algorithm and the Signature element is removed from the digested content. The result of the SHA256 digest is put in the DigestValue as a 44 byte base64 encoded string. 2.3 Applying and verifying signatures in XML messages with attached documents Overview Signing attachments is done by signing a digest that corresponds to the content of the attachment when it is stored as a file on a disk. The attached document has a file name. This file name is used to identify the file. It is recommended to apply the agreed file naming convention as described in Naming convention for EBAM attachments. The signing of the attachments is always done using the Manifest element that is part of the DSIG standard. The Manifest is put within the Signature itself. 15 July

10 2.3.1 Signing parameters EBAM parameters The signing parameters are the same as when signing an XML message without attached documents. For more see Signing parameters on page 6. Scope of the digital signature Signer signs colored part: (<Refs>, <Acct>, <Org>, <Mndt> ) The only difference is the use of the Manifest. This approach allows to verify a signature also when not all documents signed are transmitted together with the EBAM message, as discussed in Availability of the documents signed when verifying the Signature on page Example of signing attachments Example Assume that the Account Opening Request requires that the signer also signs two documents that contain contractual rules about the usage of the account. Assume these two documents are available on both sides. The file "CORPUS33_ _0002_TERMS AND CONDITIONS.PDF" and the file "CORPUS66_ _0005_SERVICE DESCRIPTION.PDF" are to be signed. The application creating the message also creates the Signature. The algorithm to digest the file is identified within the Reference in the Manifest. <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod ds:algorithm=" <ds:signaturemethod ds:algorithm=" <ds:reference URI="#Manifest"> <ds:transforms> <ds:transform ds:algorithm="urn:swift:transform:remove-whitespace-between-elements"/> <ds:transform ds:algorithm=" <ds:transform ds:algorithm=" 10 EBAM and Digital Signature

11 Recommendations </ds:transforms> <ds:digestmethod ds:algorithm=" <ds:digestvalue>vg4kjfgjkf545rtr5...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>o834b89ygbrtoosfdyi87r8gty48t46...</ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate> MII4ybroe8... <ds:/x509certificate> <ds:x509certificate> MIIqvnippi... </ds:x509certificate> </ds:x509data> </ds:keyinfo> <ds:object> <ds:manifest Id="Manifest"> <ds:reference URI=""> <ds:transforms> <ds:transform ds:algorithm=" <ds:transform ds:algorithm="urn:swift:transform:remove-whitespace-between-elements"/> <ds:transform ds:algorithm=" </ds:transforms> <ds:digestmethod ds:algorithm=" <ds:digestvalue>fji4f1v5dt581sd55dk...</ds:digestvalue> </ds:reference> <ds:reference URI="CORPUS33_ _0002_Terms%20and %20Conditions.pdf"> <ds:digestmethod ds:algorithm=" <ds:digestvalue>fji4f1v5dt581sd55dk...</ds:digestvalue> </ds:reference> <ds:reference URI="CORPUS66_ _0005_Service%20 Description.pdf"> <ds:digestmethod ds:algorithm=" <ds:digestvalue>fg555n1yy1fg5h57j6uk...</ds:digestvalue> </ds:reference> </ds:manifest> </ds:object> </ds:signature> Some remarks about the example. The first Reference in the Manifest is the ISO message itself. Exactly the same process is executed as in the previous section. The DigestValue of this Reference must be verified against the message itself. The Manifest contains a Reference element for each document that is to be signed. The identification of the document is done through a relative URI. The value of the URI is the file name of the document. The digest is calculated on the file content. The name of the document in the URI and the value of the digest identify uniquely the document that is signed. The processing of the Signature verification is done in two steps. The first step is to verify the SignatureValue. This verification will validate that the SignedInfo is correct and that the DigestValue within the Reference element in the SignedInfo is correct as well. In our case it validates that the Manifest element is not changed. 15 July

12 The second step is to validate the Reference elements in the Manifest itself. As already indicated, the Reference of the message must be validated. For the Reference elements related to the attachments, this can be done by comparing the DigestValue against the expected value or by calculating a digest on the file that is covered by the signing and to check that it is the same as put in the Manifest Availability of the documents signed when verifying the Signature Overview The documents that are signed can be sent in the same message as the one containing the Signature. It is also possible that the documents are already available, for instance because these are exchanged prior to the message. How the documents are exchanged is less relevant for the Signature processing. Recommendation The availability of the documents is not required for the first step in the verification of the Signature itself, as discussed in previous section. It remains important to verify what documents are signed. For documents that do not change, this can be done by comparing the DigestValue and file name with the expected DigestValue. When it concerns documents that are changed by the corporate and afterwards forwarded to the bank, at least two steps are to be executed. A first step requires to calculate a digest on the file and to compare it with the digest signed. A second step is to check the content of the document signed to determine if it is acceptable Combining the EBAM message and attachments Overview The purpose of combining the EBAM message and attachments is to keep them together when sending them for further processing. This is done by packaging them into one file. When combining, the XML message and the attachments it refers to are ready for packaging into a file. The signature within the XML message signs the attachments and the message itself as described above. The packaging uses a MIME based encoding. The signed file is a MIME multipart/mixed message. The first part is the ISO20022 message. Each attachment is a subsequent part of the MIME multipart/mixed message. The order of the subsequent parts is not important and left to the implementation. Note Some implementations may always use a MIME based encoding even when there is only one part containing the ISO message Example of an EBAM message combined with an attachment Overview The following example shows an Account opening request that refers to one attachment. The first part of the MIME structure is the XML message, the second part is the attachment. The XML message contains an element AttchdDocNm that contains the filename of the document that is attached. The same name is found in the Reference in the Manifest element in the Signature. To be able to identify the attachment within the MIME structure, the same filename is specified as a parameter on the Content-Type and/or the Content-Disposition of the appropriate part of the multipart/mixed MIME message. Both items should be provided. Note The white space within the XML document between elements and sometimes in the content of elements is added for readability purposes only. Whitespace should not be provided by an implementation. 12 EBAM and Digital Signature

13 Recommendations The Signature element will pass the schema validation, but all the DigestValue, X509Certificate, and the SignatureValue are examples only. These values have to be replaced by the calculated values. The attachment is an image. The Content-Type is therefore image/jpeg. The Content- Transfer-Encoding in this example is base64. However, this can also be binary, in which case the raw file data is present. The DigestValue is calculated on the binary data. Example, including white spaces for readability MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_0049_01CBFB " =_NextPart_000_0049_01CBFB Content-Type: text/xml; charset=utf-8 Content-Transfer-Encoding: binary <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:acmt "> <AcctOpngReq> <Refs> <MsgId> <Id>ABC/090928/CCT001</Id> <CreDtTm> T14:07:00</CreDtTm> </MsgId> <PrcId> <Id>ABC/090928/CCT001</Id> <CreDtTm> T14:07:00</CreDtTm> </PrcId> <AttchdDocNm>SWHQBEBB_ _5233_CARLO.jpg</AttchdDocNm> </Refs> <Acct> <Id> <Othr> <Id>NOREF</Id> </Othr> </Id> <Tp> <Cd>CASH</Cd> </Tp> <Ccy>USD</Ccy> <MnthlyRcvdVal>200000</MnthlyRcvdVal> <MnthlyTxNb>100</MnthlyTxNb> <AvrgBal>10000</AvrgBal> <StmtCycl>WEEK</StmtCycl> </Acct> <CtrctDts> <TrgtGoLiveDt> </TrgtGoLiveDt> </CtrctDts> <UndrlygMstrAgrmt> <Ref>ABC/Acct/BBBBUS33</Ref> <Vrsn>1.0</Vrsn> </UndrlygMstrAgrmt> <AcctSvcrId> <FinInstnId> <BIC>BBBBUS33</BIC> </FinInstnId> </AcctSvcrId> <Org> <FullLglNm>ABC Corporation</FullLglNm> <CtryOfOpr>US</CtryOfOpr> <RegnDt> </RegnDt> <LglAdr> 15 July

14 <StrtNm>Times Square</StrtNm> <BldgNb>7</BldgNb> <PstCd>NY 10036</PstCd> <TwnNm>New York</TwnNm> <Ctry>US</Ctry> </LglAdr> <OrgId> <Othr> <Id> </Id> <SchmeNm> <Prtry>TAX</Prtry> </SchmeNm> </Othr> </OrgId> <MainMndtHldr> <Nm>Richard Jones</Nm> <PstlAdr> <AdrTp>HOME</AdrTp> <StrtNm>La Guardia Drive</StrtNm> <BldgNb>12</BldgNb> <PstCd>NJ 07054</PstCd> <TwnNm>Parsippany</TwnNm> <Ctry>US</Ctry> </PstlAdr> <Id> <DtAndPlcOfBirth> <BirthDt> </BirthDt> <CityOfBirth>New york</cityofbirth> <CtryOfBirth>US</CtryOfBirth> </DtAndPlcOfBirth> </Id> </MainMndtHldr> </Org> <Pty> <Nm>Carlo</Nm> </Pty> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#Manifest"> <ds:transforms> <ds:transform ds:algorithm= "urn:swift:transform:remove-whitespace-between-elements"/> <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue> us8gkplhcarvyzbkvxsbszoaxk0ksreqauginegtcx8= </ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> o834b89ygbrtoosfdyi87r8gty48t46...</ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>mii </ds:x509certificate> <ds:x509certificate>mii2qwerqwer</ds:x509certificate> 14 EBAM and Digital Signature

15 Recommendations </ds:x509data> </ds:keyinfo> <ds:object> <ds:manifest Id="Manifest"> <ds:reference URI=""> <ds:transforms> <ds:transform Algorithm=" <ds:transform ds:algorithm= "urn:swift:transform:remove-whitespace-between-elements"/> <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue> CefaU61LLHSj6WlDNRgQBPGgNL1mgIhO8LQ1SodHHas=</ds:DigestValue> </ds:reference> <ds:reference URI="SWHQBEBB_ _5233_CARLO.jpg"> <ds:digestmethod Algorithm=" <ds:digestvalue> FMydc5bLVo2hapi3ciK4RGZ0FNKfPCWj6gYi+aR6TMQ=</ds:DigestValue> </ds:reference> </ds:manifest> </ds:object> </ds:signature> </Sgntr> </DgtlSgntr> </AcctOpngReq> </Document> =_NextPart_000_0049_01CBFB Content-Type: image/jpeg; name="swhqbebb_ _5233_carlo.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="swhqbebb_ _5233_carlo.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/7RfWUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAC ADhCSU0EJQAAAAAAEEYM8okmuFbasJwBobCnkHc4QklNA+0AAAAAABAA8AAAAAEAAgDwAAAAAQAC OEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAAeOEJJTQQZAAAAAAAEAAAA... nr6etffdeiosvk2gy6zooopdp//z =_NextPart_000_0049_01CBFB Implementation example The whitespace shown in the previous example was for readability purposes. The same example is shown like the implementation should implement: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_0049_01CBFB " =_NextPart_000_0049_01CBFB Content-Type: text/xml; charset=utf-8 Content-Transfer-Encoding: binary <?xml version="1.0" encoding="utf-8"?><document xmlns="urn:iso:std:iso:20022:te ch:xsd:acmt "><acctopngreq><refs><msgid><id>abc/090928/cct001</id><cr edttm> t14:07:00</credttm></msgid><prcid><id>abc/090928/cct001</id><cr edttm> t14:07:00</credttm></prcid><attchddocnm>swhqbebb_ _5233_CARLO.jpg</AttchdDocNm></Refs><Acct><Id><Othr><Id>NOREF</Id></Othr></Id>< Tp><Cd>CASH</Cd></Tp><Ccy>USD</Ccy><MnthlyRcvdVal>200000</MnthlyRcvdVal><Mnthly TxNb>100</MnthlyTxNb><AvrgBal>10000</AvrgBal><StmtCycl>WEEK</StmtCycl></Acct><C 15 July

16 trctdts><trgtgolivedt> </trgtgolivedt></ctrctdts><undrlygmstragrmt><re f>abc/acct/bbbbus33</ref><vrsn>1.0</vrsn></undrlygmstragrmt><acctsvcrid><finins tnid><bic>bbbbus33</bic></fininstnid></acctsvcrid><org><fulllglnm>abc Corporati on</fulllglnm><ctryofopr>us</ctryofopr><regndt> </regndt><lgladr><strt Nm>Times Square</StrtNm><BldgNb>7</BldgNb><PstCd>NY 10036</PstCd><TwnNm>New Yor k</twnnm><ctry>us</ctry></lgladr><orgid><othr><id> </id><schmenm><prt ry>tax</prtry></schmenm></othr></orgid><mainmndthldr><nm>richard Jones</Nm><Pst ladr><adrtp>home</adrtp><strtnm>la Guardia Drive</StrtNm><BldgNb>12</BldgNb><Ps tcd>nj 07054</PstCd><TwnNm>Parsippany</TwnNm><Ctry>US</Ctry></PstlAdr><Id><DtAn dplcofbirth><birthdt> </birthdt><cityofbirth>new york</cityofbirth><ct ryofbirth>us</ctryofbirth></dtandplcofbirth></id></mainmndthldr></org><dgtlsgnt r><pty><nm>carlo</nm></pty><ds:signature xmlns:ds=" 0/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm=" w3.org/tr/2001/12/rec-xml-c14n "/><ds:signaturemethod Algorithm=" / URI="#Manifest"><ds :Transforms> <ds:transform ds:algorithm="urn:swift:transform:remove-whitespacebetween-elements"/><ds:transform Algorithm=" l-c14n "/></ds:transforms><ds:digestmethodalgorithm=" 2001/04/xmlenc#sha256"/><ds:DigestValue>uS8GkPLHCArvyzbkvxsBSZOAXK0KSrEQauGINEg tcx8=</ds:digestvalue></ds:reference></ds:signedinfo><ds:signaturevalue>o834b89 ygbrtoosfdyi87r8gty48t46...</ds:signaturevalue><ds:keyinfo><ds:x509data><ds:x50 9Certificate>MII </ds:X509Certificate><ds:X509Certificate>MII2qwerq wer</ds:x509certificate></ds:x509data></ds:keyinfo><ds:object><ds:manifest Id=" Manifest"><ds:Reference URI=""><ds:Transforms><ds:TransformAlgorithm=" w.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:transform ds:algorithm="urn :swift:transform:remove-whitespace-between-elements"/><ds:transform Algorithm=" Method Algorithm=" au61llhsj6wldnrgqbpggnl1mgiho8lq1sodhhas=</ds:digestvalue></ds:reference><ds:re ference URI="SWHQBEBB_ _5233_CARLO.jpg"><ds:DigestMethod Algorithm =" 4RGZ0FNKfPCWj6gYi+aR6TMQ=</ds:DigestValue></ds:Reference></ds:Manifest></ds:Obj ect></ds:signature></sgntr></dgtlsgntr></acctopngreq></document> =_NextPart_000_0049_01CBFB Content-Type: image/jpeg; name="swhqbebb_ _5233_carlo.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="swhqbebb_ _5233_carlo.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/7RfWUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAC ADhCSU0EJQAAAAAAEEYM8okmuFbasJwBobCnkHc4QklNA+0AAAAAABAA8AAAAAEAAgDwAAAAAQAC OEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAAeOEJJTQQZAAAAAAAEAAAA... nr6etffdeiosvk2gy6zooopdp//z =_NextPart_000_0049_01CBFB Canonicalization and namespaces The result of the canonicalization will add the namespace declarations in scope within the SignedInfo and Manifest. In our example, the start tag of the SignedInfo and Manifest that will be digested will therefore be: <ds:signedinfo xmlns="urn:iso:std:iso:20022:tech:xsd:acmt " xmlns:ds= " <ds:manifest xmlns="urn:iso:std:iso:20022:tech:xsd:acmt " xmlns:ds=ht tp:// Id="Manifest"> Digitally signing the individual attachments The SWIFT Solution addresses the requirement to sign the XML-instruction together with its attached documents as per the recommendations in this chapter. For the personal digital signatures on individual attachments, SWIFT recommends to use the signing capabilities of the respective document format (Adobe for.pdf, Microsoft for.docx, etc ). 16 EBAM and Digital Signature

17 Recommendations Handling attached documents and their signatures Overview The way attached documents and their signatures can be handled depends on the way a signature can be associated with the document. For some type of documents the signature can be embedded within the document itself (eg, a.pdf -file from Adobe). For some other type of documents this is not possible, simply because there is no support for this (eg,.jpg -files). It is also possible that the signature is an image of the wet signature made by the person signing the document, such as a scanned passport image. For the way signatures are performed in this specification, no difference is made between documents that have an embedded signature and documents that have no such embedded signature. The signature within the EBAM message is actually done on the secure digest of the file itself, which treats the file as an opaque sequence of bytes. 15 July

18 3 Multiple Signatures Introduction When more than one person has to sign a message, more than one DigitalSignature block will be present. 3.1 Approaches for multiple signing Introduction This section discusses several approaches on the signing when multiple signatures are in place and how these approaches are handled. Some typical workflow of the message construction and the corresponding signing are explained. For the receiver of the message, who will verify all signatures, there is no particular requirement on the order of verification, so it is expected that this will be done in document order. The EBAM usage is also discussed Last signature - sign complete message Overview This approach consists of signing the document in which the signature is present, except for the Signature element ("") itself. There can only be one signature of this type in a message. Scenario of use "Last signature" type is used when a single Signature is required, or when this is the last Signature and all previous signatures have been incorporated within the document. This type of signature is only used in EBAM when there is only one Signature in the message, i.e. a single Signature see chapter 2.2 Single Signature / Last Signature Signer signs colored part: 3 Workflow considerations for the signer For the single Signature, the complete document is prepared and then signed. For the last Signature, first all other Signatures have to be calculated and inserted in the document. These other Signatures cannot be a "Last signature" type. Then the final signing can take place. Note that the order of the other signatures within the message depends on the type of signature. 18 EBAM and Digital Signature

19 Multiple Signatures Signers known upfront - sign excluding any Signature element Overview This approach consists of signing the document in which the Signatures are present, except for the Signature elements ("") themselves. There can be many Signatures of this type in a message. Scenario of use This type of signature is used in EBAM when there are several Signatures in the message and it is well known who will sign at the moment the message is constructed. Eg, the CEO and the CFO will have to sign an Open Account Request message. The order of signing is not important, but both signers are identified within the EBAM instruction (in the blocks) before either of them starts the signing process. Since the content of the DgtlSgntr blocks (ie, the identification of the signers) is known and present within the message, each Signature will sign that information as well. However it is not possible to change anything in the message once signing of this type of Signature has started. In particular it is not possible to add a new signer, or change one of the signers. All signer-related information (ie, the blocks) of all signers - except their Signatures themselves (ie, the elements) - is signed by all signers. For 2 signers, the use case can be presented as: 2 Signatures Signers known upfront, order is unimportant signs: signs: 4 For many signers, the same principle is used: 15 July

20 Multiple Signatures Signers known upfront, order is unimportant signs: Signer n signs: Signer n Signer n signs: Signer n 7 Workflow considerations for the signer The order of signing is not important. The message can be forwarded in several steps to each signer, who can then add their signature within the appropriate signature, or all signatures can be done within the same process step in any order, even in parallel Signers not known upfront - sign excluding Signature element and other DigitalSignature blocks Overview This approach consists of signing the whole document in which the Signatures are present, except for the Signature element ("") for the respective signer itself and except for the DigitalSignature blocks ("") identifying the other signers in the document. There can be many Signatures of this type in a message. Scenario of use This type of signature is used in EBAM when there are several Signatures in the message and it is not known upfront who has to sign. Eg, an Open Account Request message requires a signature from somebody of group A and a signature from somebody of group B, but which individual of each group will actually sign is irrelevant and will depend on their availability. Only at the moment of signing, the block is completed with the individual's identification and the signature is calculated and added in the element. Each signer will sign the full document, including its own DigitalSignature block without the Signature element, and excluding any other DigitalSignature block. It is possible in this case to add a new signer when the signing process has started. For 2 signers, the use case can be presented as: 20 EBAM and Digital Signature

21 Multiple Signatures 2 Signatures Signers not known upfront, order is unimportant signs: signs: 5 For many signers, the same principle is used: Multiple Signatures Signers not known upfront, order is unimportant signs: Signer n signs: Signer n Signer n signs: Signer n Workflow considerations for the signer The order of signing is not important. The message can be forwarded in several steps to each signer, who can then add their signature within the appropriate signature block, or all signatures can be done within the same process step in any order. 15 July

22 3.1.4 Sequence of signatures is relevant - sign preceding DigitalSignature blocks Overview This approach signs the document, including all DigitalSignature blocks with their Signature element preceding the respective signature, and excluding the Signature element of the respective signature itself. It does not sign any DigitalSignature block that follows the Signature element. Scenario of use This type of signature is used in EBAM when there are several Signatures in the message and the order of signing is fixed (eg, hierarchically imposed) and known at the moment the XML message is constructed. Eg, a CEO and a CFO need to sign an Open Account Request message, but the CEO only signs after the CFO. The subsequent signers are always added after the already signed DigitalSignature blocks. For 2 signers, the use case can be presented as: 2 Signatures Order is important signs: signs: 6 For many signers, the same principle is used: 22 EBAM and Digital Signature

23 Multiple Signatures Multiple Signatures Order is important signs: Signer n signs: Signer n Signer n signs: Signer n Workflow considerations for the signer By definition, the signing of the message happens in several steps. The identification of who signs the message next is pre-defined, and each signer's identification is always added as last DigitalSignature block in the message. 3.2 Implementation of multiple signatures Introduction The different approaches are implemented using four different transform algorithms. These are Enveloped signature used when the complete message is signed Sign excluding any Sgntr element Sign excluding own Sgntr element and other DgtlSgntr blocks Sign preceding DgtlSgntr blocks The following paragraphs describe what to do for each algorithm Applying multiple signatures Enveloped signature This is explained in Applying and verifying signatures in XML messages on page 6 and when signing attached documents in Applying and verifying signatures in XML messages with attached documents on page 9. The Transform algorithm is Sign excluding any Sgntr element This is done by replacing the Transform algorithm within Applying and verifying signatures in XML messages on page 6 and when signing attached documents in Applying and verifying signatures in XML messages with attached documents on page 9 with the Transform algorithm urn:swift:transform:remove-sgntr. The algorithm itself can be implemented as an XSLT transform using the following stylesheet: <xsl:stylesheet version="2.0" xmlns:xsl=" <xsl:output encoding="utf-8" method="xml"/> 15 July

24 <xsl:preserve-space elements="*"/> <xsl:template * comment() processing-instruction() text()"> <xsl:copy> <xsl:apply-templates * comment() processinginstruction() text()"/> </xsl:copy> </xsl:template> <xsl:template match='*[local-name() = "DgtlSgntr" ]/*[local-name() = "Sgntr" ]'> </xsl:template> </xsl:stylesheet> Note The use of an XSLT processor is optional. The same algorithm can be implemented using other technologies as well. Sign excluding own Sgntr element and other DgtlSgntr blocks This is done by replacing the Transform algorithm within Applying and verifying signatures in XML messages on page 6 and when signing attached documents in Applying and verifying signatures in XML messages with attached documents on page 9 with the Transform algorithm urn:swift:transform:remove-sgntr-other-dgtlsgntr. The algorithm itself can be implemented using a XSLT transform with the following stylesheet where a parameter is provided with the occurrence number of the DgtlSgntr block: <xsl:stylesheet version="2.0" xmlns:xsl=" <xsl:output encoding="utf-8" method="xml"/> <xsl:param name="signum" /> <xsl:preserve-space elements="*"/> <xsl:template match="@* * comment() processing-instruction() text()"> <xsl:copy> <xsl:apply-templates select="@* * comment() processinginstruction() text()"/> </xsl:copy> </xsl:template> <xsl:template match='*[local-name() = "DgtlSgntr" ][$signum]/*[local-name() = "Sgntr" ]'> </xsl:template> <xsl:template match='*[local-name() = "DgtlSgntr" ][position()!= $signum]'> </xsl:template> </xsl:stylesheet> The signum is the occurrence of the DgtlSgntr within the message for which the algorithm is invoked. Note The use of an XSLT processor is optional. The same algorithm can be implemented using other technologies as well. Sign preceding DgtlSgntr blocks This is done by replacing the Transform algorithm within Applying and verifying signatures in XML messages on page 6 and when signing attached documents in Applying and verifying signatures in XML messages with attached documents on page 9 with the Transform algorithm urn:swift:transform:remove-sgntr-following-dgtlsgntr. The algorithm itself can be implemented using a XSLT transform with the following stylesheet: <xsl:stylesheet version="2.0" xmlns:xsl=" xmlns:xs=" xmlns:ds=" <xsl:output encoding="utf-8" method="xml"/> <xsl:param name="signum" /> <xsl:preserve-space elements="*"/> <xsl:template match="@* * comment() processing-instruction() text()"> <xsl:copy> 24 EBAM and Digital Signature

25 Multiple Signatures <xsl:apply-templates * comment() processing-instruction() text()"/> </xsl:copy> </xsl:template> <xsl:template match='*[local-name() = "DgtlSgntr" ][position() = $signum]/*[local-name() = "Sgntr" ]'> </xsl:template> <xsl:template match='*[local-name() = "DgtlSgntr" ][position() > $signum]'> </xsl:template> </xsl:stylesheet>the signum is the occurrence of the DgtlSgntr within the message for which the algorithm is invoked. Note The use of an XSLT processor is optional. The same algorithm can be implemented using other technologies as well Verifying multiple signatures Overview The verification of multiple signatures occurs on a message that is received. It is not important for the receiver of the message what workflow approach has been chosen by the sender of the message. Indeed, whatever approach selected by the sender, the signatures can be verified in the same way. The verification process is the same for each approach. The DgtlSgntr blocks are handled in the order found within the message. The Signature within the DgtsSgntr block is verified according to the algorithm that is specified within the Transform that is present within the Signature itself. The implementation of the Transform algorithm is exactly the same as for the signer. Implementing all Transform algorithms The receiver of a message must be able to verify all possible approaches that can be selected by the sender of the message. This only implies that the possible Transform algorithms are implemented. It does not imply that all workflows for signing have to be implemented by the receiver when sending and signing EBAM messages. 15 July

26 Legal Notices Copyright SWIFT All rights reserved. You may copy this publication within your organisation. Any such copy must include these legal notices. Confidentiality This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT. Disclaimer The information in this publication may change from time to time. You must always refer to the latest available version on " Translations The English version of SWIFT documentation is the only official and binding version. Trademarks SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners. 26 EBAM and Digital Signature