[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Outline of verification report profile
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]