Transcript Exchange of digitally signed SPSCertificate messages Overview of prototype of digital signature applied to SPSCertificate message between national systems and TRACES UN/CEFACT Forum Geneve, April.

Exchange of digitally signed
SPSCertificate messages
Overview of prototype of digital signature applied to
SPSCertificate message between national systems and
TRACES
UN/CEFACT Forum Geneve, April 7-11 2014
What do we currently have?
• SPSCertificate based message exchange with
TRACES is available
• New Zealand is getting ready to exchange on
large scale:
• Fishery products
• Meat of bovine and ovine animals
• Target is to make exchanges with nonrepudiation to enable the paperless exchange
• Digital signature will enable this
Digital Signature overview
Message
Digest
Algorithm
Hash Function
Digest
Private Key
of sender
Encryption
Signature
Message
Digest
Algorithm
Hash Function
Public Key
of sender
Decryption
Actual
Digest
Expected
Digest
Compare
How will we apply digital signature?
• On the incoming messages (SPSCertificate)
• Signed by sending authority
• On the reply (SPSAcknowledge)
• Signed by TRACES
• Based on our recommendations made in analysis
presented in Geneva in April 2013:
• Enveloping signature
• XML-based (XAdES)
• Timestamp froml trusted time stamp authority
(TSA) for archival purposes
Example of
signed
SPSCertificate
message
Enveloping Signature
SPSCertificate
enveloped in the
Signature
Architecture Overview
Client
XMLGate
TRACES
• Signed SPSCertificate message
• Signed SPSCertificate message forwarded
• Signature validated
• Certificate data validated, stored
• SPSAcknowledgement created, signed
• SPSAcknowledgement returned
ESSI
First use-case: New Zealand
exports to EU
• Meat products, fishery products
• 15000 – 20000 documents per year
• Digitally signed health certificates for export to
the EU from NZ eCert system
• Digitally signed acknowledge messages from
TRACES
• Machine-to-machine signature (eCert / TRACES)
Certificates to use
• TRACES will use certificate provided by ESSI
(Commission as Legal Entity)
• New Zealand certificate provider (probably) not
on EU trusted list
• No global solution in sight for this problem:
• Bilateral agreement on technologies and profiles
• Both sides must test each other's signed messages
for interoperability
• We may need to define a "SANCO TLS" to add the
CSP used in New Zealand to ESSI infrastructure
The steps ahead
• Agree on CSP on both sides
• Agree on technical details for interoperability
(XAdES level, profile…)
• If necessary, define a "SANCO TLS"
• Off-line verification of signed messages from both
sides
• Integrate to trust services on both sides
• Start the exchange
• Electronic "vault" needed – legal requirements?