Re: [dss-x] Outline of verification report profile

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Thank you Detlef,

I have not had time to go through the whole schema, but  I would like to 
mention just one issue: the identification of the signature on which a 
validation report is produced.

My general view is that the mechanisms used in the <dss:SignRequest> for 
pointing to a certain signature depend on the SignatureRequest 
structure. I will go through the different mechanisms mentioned by 
Konrad in the last conf call:


SignaturePtr has the whichDocument that is a IDREF pointing to a 
document within the SignRequest...this woudl imply to have to use the 
SignRequest structure for identifying the signature....

SignaturePlacement: uses the SignaturePtr as above.


ReferenceXPath is used in an element dealing with Verification of Maifest


My personal feeling is that we could provide a mechanism identifying the 
signature not linked to the SignRequest structure of the message...or at 
least two choices: one relaying on the SignRequest (SignaturePtr) AND 
something not linked to that.

This second mechanism could include data that actually could serve to 
identify the signature:

Certificate identifier of the Signer
the signature value
....maybe other additional data (digest of objects in ds:Refernce for 
ds:Signature?)

This structure would allow to keep a one-to-one relationship between the 
signature or the signed document with the report even whent the client 
has lost the SignRequest structure....

Regards

Juan Carlos.
Huehnlein, Detlef escribió:
> 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. 
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php