Signature policy for TUPAS Witnessed Signed Document

Transcription

1 Signature policy for TUPAS Witnessed Signed Document Policy version 1.0 Document version Policy ID and location Policy ID Name URL urn:signicat:signaturepolicy:tupas wsd:1.0 Signature policy for TUPAS Witnessed Signed Document wsd Version Date Specification version Document version Change Initial version, based on existing documentation Translated to English, some non normative parts rewritten.

2 3 References Short name TUPAS Identification Principles Document TUPAS Identification Service, Identification Principles, version 2.0b, 20 January 2011 WSD 1.0 Signicat Witnessed Signed Document Format version 1.0 (in Norwegian) ETSI TS ETSI TR ETSI TR RFC 3125 ETSI TS Electronic Signature Formats ETSI TR Electronic Signatures and Infrastructures (ESI) ASN.1 format for signature policies v ETSI TR Signature policy for extended business model RFC 3125 Electronic Signature Policies

3 4 Contents 1 Policy ID and location Version References Contents Introduction General signature policy information General process requirements (normative) Signed Attributes Unsigned attributes Included certificates Sealing requirements Validation requirements Sealing requirements (normative) Appendix A (normative): Trust anchors used in validation of the seal Appendix B (informative): On the role of witnessing a signature...11

4 5 Introduction The TUPAS protocol enables banks to offer external service providers to use the internet bank login function for their own service. This way, a service provider can implement authentication using TUPAS. Signatures using the TUPAS/WSD scheme are built on top of a TUPAS authentication. 5.1 How TUPAS authentication works Authentication using TUPAS works like this: 1. The users browser is redirected from the service provider to a user chosen internet bank, where the user logs on using whatever login mechanism provided by the bank. 2. The users browser is redirected back to the service provider 3. The service provider receives an assertion from the internet bank, a TUPAS certificate, that the user was logged in. The TUPAS certificate is linked to the users browser session. 5.2 How TUPAS/WSD signatures works Signature using TUPAS/WSD works like this: 1. The user authenticates using TUPAS (described above) 2. A Trusted Service Provider (TSP) arranges a signing ceremony: Presents the document to be signed, and collects the users explicit consent. 3. The TSP collects traces and contex in audit logs. 4. The TSP assembles the original document, the audit logs into a Witnessed Signed Document (WSD) 5. The TSP seals (signs) the WSD using PKI merchant signature. 6. The sealed WSD is used as the e signature, or Signed Document Object (SDO) 5.3 On the foundation and strength of TUPAS/WSD signatures The TUPAS standard does not offer any e signature function, only authentication. The document TUPAS Identification Principles describes the possibility for building an e signatures function on top of TUPAS is described: The service provider and the customer can agree on the use of the Tupas certificate as part of the electronic signature 4 in the legal transaction between the customer and the service provider, which enables the reception of various applications and the signing of contracts through the Internet. The service provider is responsible for the other requirements of the electronic signature, such as managing all of the data and ensuring its integrity and indisputability, and for storing the response message. Use of the Tupas certificate as an electronic signature is supported by the timestamped response messages and the banks' log files. [TUPAS Identification

5 Principles:1.1] In the TUPAS/WSD scheme for e signature the management of data and handling of integrity and indisputablility is done through the Witnessed Signed Document container including all neccesary data, with a PKI signature (seal) on the WSD made by a Trusted Service Provider ensuring integrity and non repudation properties. The same document also states that the initial identification in TUPAS is sufficient for an e ID used in strong e signatures. Since 1 March 2010, initial identification in the Tupas identification service follows the Act on Strong Electronic Identification and Electronic Signatures (617/2009). [TUPAS Identification Principles:Appendix 2] 5.4 Validation of TUPAS/WSD signatures A TUPAS/WSD signature builds on trust to the Internet Bank authentication. There is no function in TUPAS making it possible to validate the authentication that was done at a later time. The TUPAS certificate sent from an internet bank is included in the WSD. During TUPAS authentication it is authenticated and integrity protected through Message Authentication Codes. This technique presupposes the existence of a shared secret between the Service Provider and the Internet Bank, the MAC Key. To recreate the validation of the TUPAS certificate we would have to use the MAC key as validation data. This is not practical, because it conflicts with the confidentiality requirements of the MAC key. Therefore, trust to the WSD signatures will build on trust to the full TUPAS authentication process performed at the time when the signature was created. The WSD format includes traces that supports this trust. The general steps for validating a TUPAS/WSD signature is therefore 1. Verify the WSD format. 2. Verify the seal, and that it is created by a trusted TSP. 3. Verify that the signature was created under this policy's working period 5.5 Secure time A essential step in e signature validation is to obtain a secure time for the e signature. There are some sources of time from the TUPAS authentication, that could be useful. As stated in [TUPAS Identification principles:1.1]: Use of the Tupas certificate as an electronic signature is supported by the timestamped response messages and the banks' log files.. There are, however, some limitations to the use of the time stamp in the response messages as a secure time for validation of e signatures: 1) The time stamp in the TUPAS certificate can not be validated without the MAC Key. Without this, the time stamp could be tampered with. 2) Even if you validate the TUPAS certificate and/or establish time through the banks logs, the relation between the signature and the Document, and signing ceremony is dependent on the TSP seal and TSP trust. The signature could have been forged using a valid TUPAS certificate from for example an authentication. E signature users should therefore add a proper time stamp on the e signature to ensure secure signing time as a basis for later validation.

6 5.6 About Signature Policies The purpose of a signature policy is to guide signature users in assessing the signatures application, and to enable verification of the signatures. To this end, the signature policy document requirements for the signature process. The primary users of this policy will be e signature users (relying parties). The policy will help e signature users to better understand the information contained in a signature, and on what basis it can be trusted and used. The policy will also be useful for implementers of the signature service. 5.7 Structure The normative parts of the policy are summarized below. 1. General signature policy information defines ID, date of applicability and so on. 2. General process requirement defines high level requirements for the overall packaging process. 3. Signature creation requirement defines requirements for the creation of the packaged signature (the native signature). 4. Signature verification requirements verification defines requirements for the verification of the native signature. 5.8 Terms and acronyms Term TSP Long term validation Seal Explanation Trusted Service Provider the entity implementing this policy by packaging the signature. The concept of validating an e signature long time (months, and some times years) after it was created. This is the Trusted Service Providers signature on the WSD. It is commonly referred to as the Seal. 6 General signature policy information Policy ID: urn:signicat:signaturepolicy:tupas wsd:1.0 Policy Issuer: Signicat Date of issue: Working period: > Field of application: Not specified

7 7 General process requirements (normative) 1. The signer shall authenticate using TUPAS (which typically includes his/her internet bank authentication). This may be done before or after the document presentation. 2. The TSP shall present the document to be signed. 3. The TSP shall present a clear signing dialog, collecting the signers explicit consent to the document. 4. The TSP shall produce a Signed Document Object on the form Witnessed Signed Document. 8 Signed Attributes All attributes defined in the WSD format are mandatory, and all will be signed by the TSP. In addition, the following requirements apply to attribute values: 1. The element Signer/NameID shall have an attribute Format with value "urn:kantega:ksi:3.0:nameid format:fnr", containing the signers henkilötunnus 2. The element Witness/NameID shall have a Format attribute with value "urn:kantega:ksi:3.0:nameid format:orgnr", and contain the TSP organisation ID number. 3. The element AuthenticationContext shall have the value "rn:ksi:names:saml:2.0:ac:tupas" 4. The element AuthenticationData's type attributes shall have value"tupas", contain elements AuthenticationAuthority og TupasCertificate 9 Unsigned attributes There are no reauirement to unsigned attributes 10 Included certificates The WSD shall include the TSP signatures certificate chain up to, but not including, the trust anchor. 11 Sealing requirements Requirements for the TSP signing certificate Certificate type The TSP signing certificate shall be of type X.509 v3, and be valid (not expired) and not revoked according to RFC 3280 on the time of signing. An exception is made for signatures created in the period to by certificate issued by C=NO, O=Buypass AS , CN=Buypass Class 3 CA 1 with serial These signatures are considered as conforming to this policy even if the certificate was expired in the period.

8 11.2 Trust points The TSP signing certificate shall be anchored to one of the trust points in appendix A 11.3 Algorithm constraints The seal shall be created using: sha Rules for time stamping/marking The TSP shall put a time stamp in the field SigningInstant in the WSD. This shall be a time from a secure time source. There is no requirement for a time stamp from from a Time Stamp Authority. There also exists a time stamp in the included TUPAS certificate, and there may be relevant traces in the banks logs. See section in introductory chapters for notes on the limitations of the applicability of those. 12 Validation requirements 12.1 Revocation check The TSP certificate validation should include a revocation check. This may be done using ths OCSP/CRL services pointed to in the certificates Authority Information Access, or using stored signed OCSP/CRL responses. 13 Sealing requirements (normative) This section contains requirements to the TSP signature on the WSD, also called the seal. 1. The seal covers the complete package, such that all information in the package is protected by the signature. 2. The seal is a XAdES signature. 3. The signature is verified immediately following signature creation. 4. Signature verification is done according to XMLDSig Core Validation [XMLDSIG] 5. Verification includes certificate validation of the signing certificate, including revocation check. Trust anchors used in certificate validation are listed in Appendix B. 6. All certificates and revocation values used in the initial verification of the signature are included in the XAdES structure. 7. The signature does not include time stamps. 8. The package is signed according to an explicit signature policy which is available together with this policy.

9 14 Appendix A (normative): Trust anchors used in validation of the seal The following certificates are used as trust anchor in Certificate Path Validation and OCSP Response validation when validating the seal (the TSP signature) Buypass Class 3 CA 1 BEGIN CERTIFICATE MIIDUzCCAjugAwIBAgIBAjANBgkqhkiG9w0BAQUFADBLMQswCQYDVQQGEwJOTzEd MBsGA1UECgwUQnV5cGFzcyBBUy05ODMxNjMzMjcxHTAbBgNVBAMMFEJ1eXBhc3Mg Q2xhc3MgMyBDQSAxMB4XDTA1MDUwOTE0MTMwM1oXDTE1MDUwOTE0MTMwM1owSzEL MAkGA1UEBhMCTk8xHTAbBgNVBAoMFEJ1eXBhc3MgQVMtOTgzMTYzMzI3MR0wGwYD VQQDDBRCdXlwYXNzIENsYXNzIDMgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKSO13TZKWTeXx+HgJHqTjnmGcZEC4DVC69TB4sSveZn8AKxifZg isrbselrwcgoy+gb72rrtqfpffv0gggekkbyouz0plntvuhjp5jw3srojvi6k//z NIqeKNc0n6wv1g/xpC+9UrJJhW05NfBEMJNGJPO251P7vGGvqaMU+8IXF4Rs4HyI +MkcVyzwPX6UvCWThOiaAJpFBUJXgPROztmuOfbIUxAMZTpHe2DC1vqRycZxbL2R hzyrhkmr8w+gbcz2xhysm3hljbybir6c1jh+jiavmykwsuntyjdbiawkyjt+p0h+ mbewi5a3lryoh6usjfrvynvdwqrcrxig9iscaweaaancmeawdwydvr0taqh/bauw AwEB/zAdBgNVHQ4EFgQUOBTmyPCppAP0Tj4io1vy1uCtQHQwDgYDVR0PAQH/BAQD AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQABZ6OMySU9E2NdFm/soT4JXJEVKirZgCFP Bdy7pYmrEzMqnji3jG8CcmPHc3ceCQa6Oyh7pEfJYWsICCD8igWKH7y6xsL+z27s EzNxZy5p+qksP2bAEllNC1QCkoS72xLvg3BweMhT+t/Gxv/ciC8HwEmdMldg0/L2 mslf56obzkwzqbwku5hea6bvtjt5htozdlsy9eqbs1odtuds5xctra9bqh/yl0yc e/4qxfi7t/ye/qnlgioow6ugfprreaaiers7gqqjel/wroqk5pmr+4okoyeyzdow dxb8gzho2+ubpzk/qjchjrrm85sfsnonk8+qqts4wxam58taa915 END CERTIFICATE

10 15 Appendix B (informative): On the role of witnessing a signature The concept of witnessing a signature is a very old concept dating back to the Middle Ages. In those days, to sign meant to make the sign of the cross, not to write one's name. It was a mark of solemnity, to draw the signer's attention to the importance of the commitment he was making. The witness, usually a scribe wrote the name of the signer next to the cross (signature). From this developed the concept of witnessing. However, in modern law, and contrary to popular opinion, a witness is not required to validate the identity of the signer, only to attest to the fact that he saw a person whom he recognizes as having made the signature in question. He also has no interest in the semantics of the data to which the primary signature is attached. In the virtual world, the role of the witness could be to ensure that the person applying the signature is indeed the right one. This mandates that the witness is able to verify that the name included in the certificate (that is itself included in the signed data) indeed corresponds to the person applying the signature. However, it should be observed that the physical presence of both the signer and the witness at the time of the signature may not be mandatory. The witnessing could be done after the signature has been applied. This is a major difference with the paper world situation, where the witness must actually see the person signing. I ETSI TR Signature Policy for Extended Business Model,