130 likes | 258 Views
Presented by : Piero Milani ( InfoCamere - Italy ). VCD Signature & VCD Verification strategy as seen by InfoCamere ( WP1 member ) Malmö 2010 February 10 th. Short introduction of the VCD. The Virtual Company Dossier builds over four physical levels
E N D
Presented by : Piero Milani(InfoCamere - Italy) VCD Signature & VCD Verification strategyas seen by InfoCamere (WP1 member) Malmö 2010 February 10th
Short introduction of the VCD • The Virtual Company Dossier builds over four physical levels • The VCD Archive = The physical container • The VCD Package = The Master (XML) document • The VCD = the metadata collector • The attestations = the information and content base (any electronic document) • Digital Signatures can be found or applied at any level
InfoCamere for Italy participation • InfoCamere will establish the necessary infrastructure to run the WP1 phases 2, 3 and 4. They include: • XKMS Client application • the activation of the PEPPOL XKMS Responder and • the presence within the PEPPOL Public Registry Service (PPRS) • InfoCamere will also set up a specific use case for test purposes. The case will serve to the WP1 infrastructure a specific business document created within Peppol WP2, i.e. The “VCD – Virtual Company Dossier” carrying on board a large set of “digital signatures” conforming to the standards CAdES, XAdES, PAdES. The case gets better description on following slides.
XKMS: InfoCamere implementation • XKMS Client application: invokes remote validation to the Central XKMS Responder • XKMS Request preparation, Submission into the Central XKMS Responder, preparation for receiving and interpreting the reply from the server • Activation and handling of the synchronous operation mode • Activation of SOAP protocol 1.2 • Signed Message • The X509 must be in the Message • Making of a JAVA Library (web interface / java-application) for reuse by organizations interested into the validation system • Local activation of a XKMS Responder system, that can be invoke by the Central XKMS ( in phase#2)
InfoCamere’s Use Case goal 1 • Assuring the integrityforall the documentspresent or referencedby the Virtual Company Dossier, (the wholeprocessdepicted on previousimages) • And it will be achieved if: • Every signed document can be verified when conformant to : CAdES-XAdES-PAdES • [Ref: S 101 703 – TS 101 903 –TS 102 778] • Every document is hashed before sending and the hash verified by the receiver
InfoCamere’s Use Case goal 2 • Assuring • The integrity, • the autenticity, • the paternity • of the Virtual Company Dossier metadata, • And itwillbeachievedif: • The VCD istanceissignedafter the compilation
Signing the VCD Metadata file • The VCD MetaData file isan UBL document; • The signature format isconformantwith”UBL XAdES Profile Version 1.0” with the benefits describe below • Compliance with EC Directives • A signed UBL document should be parsed correctly by an UBL parser (not XAdES aware) and by a XAdES verification software (not UBL aware) • No change required for UBL nor XAdES. • Support any XAdES form leaving to the specific user context the choice and avoiding any overlap with the work of other body: i.e. CEN CWA’s, Service Directive,… (from the draft….)
Human readable VCD Instance • The visual representation of a VCD instance is a prerequisite to a signing activity bearing legal effect, we propose three initial options: • transformation into an XHTML representation by using a specific stylesheet; • transformation into a PDF document that’s embedding the original VCD(XML) • transformation into a PDF document (no embedding). The VCD(XML) and the PDF document exists as separated documents and get separated signatures.
VCD validation service • A web based service (implementing the VerifyVCD) to: • Verify the VCD signature and validate it according to the signature profile: • Open service to all qualified users, i.e., the economic operators, the service providers and the contracting authorities; • Perform integrity check: • On documents hosted in a VCD instance by comparing the evidence hash with corresponding binary strings, i.e., the “EvidenceHash” stored on metadata files