Outline of verification report profile

["Huehnlein, Detlef" <Detlef.Huehnlein@secunet.com>]

Dear collegues,

in order to support a first discussion for the planned
verification report profile, I would like to outline
how this profile and the corresponding verification report
may be structured and point out some issues, which should
be discussed in our telco today.

I. Outline of profile
=====================
1. <ReturnVerificationReport> / <VerificationReport> as optional input/output
------------------------------------------------------------------------
  In order to request some (basic individual or full) signature verification report 
  the client will send a <ReturnVerificationReport>-element in <dss:OptionalInputs>. 
  The server will return an element <VerificationReport> in <dss:OptionalOutputs>.
  The <ReturnVerificationReport>-element may contain information which controls
  what checks are performed during verification (e.g. whether certificate path's 
  and algorithms shall be checked) and how the <VerificationReport>-element
  will look like (e.g. whether the returned report should be a basic or full report).

2. <VerificationReport> contains sequence of <IndividualSignatureReport>
------------------------------------------------------------------------
  Besides general information concerning the verification (e.g. VerifierIdentity, 
  CurrentTime, VerificationTime etc.) the <VerificationReport> contains
  a <IndividualSignatureReport>-element for each signature occuring in the request.

3. Structure of <IndividualSignatureReport> 
-------------------------------------------
  The <IndividualSignatureReport>-element contains 
  - a pointer to the specific signature (Details to be discussed, see question II.2. below)
  - a <dss:Result>-element
  - an optional <Details>-element, which structure depends on 
    the <ReturnVerificationReport>-element and/or other elements in <dss:OptionalInputs>
    (see 4a) and 4b) below)

4. Structure of <Details>
-------------------------
  a) Basic individual verification report
  ---------------------------------------
  If the <ReturnVerificationReport>-element indicates that only the basic
  individual verification report is requested, this element may contain all 
  signature-specific elements defined in the DSS-core. This may include
  - <VerifyManifestResults> (§4.5.1 of DSS-core)
  - <ProcessingDetails> (§4.5.5 of DSS-core) 
  - <SigningTimeInfo> (§4.5.6 of DSS-core) 
  - <SignerIdentity> (§4.5.7 of DSS-core) 
  - <DocumentWithSignature>, <UpdatedSignature> (§4.5.8 of DSS-core) 
  - <TransformedDocument> (§4.5.9 of DSS-core)                                   
  - <DocumentWithSignature>, <TimestampedSignature> (§4.5.10 of DSS-core)
  
  b) Full individual verification report
  --------------------------------------
  If the <ReturnVerificationReport>-element indicates that a full 
  individual verification report is requested, this element contains 
  a <DetailedReport>-element, which details are controlled by the 
  <ReturnVerificationReport>-element. It may contain information about
  the verification of  
  - the format and the correctness of the primary digital signature
  - secondory signatures within signed and unsigned Properties (other signatures, time stamps,
    certificates, revocation evidence etc.) (Details to be discussed, see question II.3. below)
  - existing manifests
  - the certificate paths upon which the primary signature rests

II. Main points for discussion
------------------------------
As a first step, it should be discussed 
1. whether the general outline is ok or how it should be adapted
2. how the <dss:SignaturePtr>-element should be generalized such that it 
   can unambigiously point to non-XML-signatures as well
3. whether Properties-part of the <DetailedReport>-element should be 
   a) tailored for XAdES / CAdES and only leave the open part for other
      properties or 
   b) whether the properties should completely be left open as in 
      the DSS core.

You may have a look a the attached draft (version 0.1) of the related schema
definition. 

I'm looking forward to talking to you during our telco today.

Best regards,
   Detlef 

  
--
Dipl. Inform. (FH)
Dr. rer. nat. Detlef Hühnlein
Partner
secunet Security Networks AG
Sudetenstraße 16
96247 Michelau
Telefon +49 9571 896479
Mobil   +49 171  9754980
detlef.huehnlein@secunet.com
www.secunet.com
======================
Besuchen Sie uns auf der CeBIT 2008, 
4. - 9. März 2008, Halle 6 Stand J36
(www.cebit.de)
----------------------
und auf dem Managed Security Forum 2008
2. April in Frankfurt am Main
7. Mai in Düsseldorf
29. Mai in Hamburg
16. Juni in München
(www.managed-security-forum.org) 
Wir freuen uns auf interessante Gespräche mit Ihnen. 
======================
secunet Security Networks AG
Kronprinzenstr. 30
45128 Essen
Amtsgericht Essen HRB 13615

Vorstand:
Dr. Rainer Baumgart
Thomas Koelzer
Thomas Pleines

Aufsichtsratsvorsitzender:
Dr. Karsten Ottenberg

Diese E-mail kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte unverzüglich den Absender und löschen Sie diese E-Mail von jedem Rechner, auch von den Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung, ist in diesem Fall untersagt. Außer bei Vorsatz oder grober Fahrlässigkeit schließen wir jegliche Haftung für Verluste oder Schäden aus, die durch Viren befallene Software oder E-Mails verursacht werden.

This e-mail may contain strictly confidential information and is intended for the person to which it is addressed only. Any dissemination, even partly, is prohibited. If you receive this e-mail by mistake, please contact the sender and delete this e-mail from your computer, including your mailserver.
Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses.

VerificationReport-v0-1.xsd