gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: ebics crypto


From: gnunet
Subject: [taler-docs] branch master updated: ebics crypto
Date: Mon, 28 Oct 2019 15:05:31 +0100

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 009aa08  ebics crypto
009aa08 is described below

commit 009aa08ad528ae40e5878126c7df16827cba6f8d
Author: Florian Dold <address@hidden>
AuthorDate: Mon Oct 28 15:05:19 2019 +0100

    ebics crypto
---
 libeufin/ebics.rst | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/libeufin/ebics.rst b/libeufin/ebics.rst
index 605bd97..731882f 100644
--- a/libeufin/ebics.rst
+++ b/libeufin/ebics.rst
@@ -342,6 +342,21 @@ The following order types are, for now, not relevant for 
LibEuFin:
     HAC order type.
 
 
+EBICS Message Format
+====================
+
+The following elements are the allowed root elements of EBICS request/response 
messages:
+
+* ``ebicsHEVRequest`` / ``ebicsHEVResponse``:  Always unauthenticated and 
unencrypted.  Used
+  **only** for query/response of the host's EBICS version.
+* ``ebicsKeyManagementResponse``:  Unauthenticated response.  Used for key 
management responses and
+  sometimes **also** to deliver error messages that are not signed by the bank 
(such as "invalid request").
+* ``ebicsNoPubKeyDigestsRequest``: Signed request that *does not* contain the 
hash of the bank's
+  public key that the client expects.  Used for key management, specifically 
only the HPB order type.
+* ``ebicsRequest`` / ``ebicsResponse``
+
+
+
 EBICS Transaction
 =================
 
@@ -491,6 +506,43 @@ HypoVereinsbank
 
 See `this document 
<https://www.hypovereinsbank.de/content/dam/hypovereinsbank/shared/pdf/Auftragsarten_Internet_Nov2018_181118.pdf>`__.
 
+
+Cryptography
+============
+
+EBICS uses the XML Signature standard for signatures.  It does *not* use XML 
encryption.
+
+The EBICS specification doesn't directly reference the standardized URIs for 
the various
+signing algorithms.  Some of these URIs are defined in 
`<https://tools.ietf.org/html/rfc6931>`__.
+
+* A005 is http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
+
+  * the ``RSASSA-PKCS1-v1_5`` signature scheme contains the 
``EMSA-PKCS1-v1_5`` encoding scheme
+    mentioned in the EBICS spec.
+
+* A006 is `<http://www.w3.org/2007/05/xmldsig-more#rsa-pss>`__ as defined in 
RFC 6931.
+
+XML Signatures
+--------------
+
+XML Signatures can be a combination of:
+
+* detached (referencing another document)
+* enveloping (signs over ``Object`` tags *within* the ``Signature`` elements)
+* enveloped (signs over arbitrary data (via XPath expression) in other parts 
of the document
+  that contains the signature).
+
+In EBICS, only **enveloped** signatures are used.
+
+In the XML Signature standard, the element for a signature is ``Signature``.  
EBICS violates this
+standard by always mandating ``AuthSignature`` as the name.  ``AuthSignature`` 
is an alias to
+the ``SignatureType`` xsd type in the XML Schema.
+
+Canonicalization vs transforms:
+ * Canonicalization refers to the processing of the ``SignedInfo`` element.
+ * Transformations apply to the data that ``Reference`` elements reference.  
Canonicalization
+   algorithms can be used as a transformation on referenced data.
+
 Standards and Resources
 =======================
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]