OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [dss-x] Proposal for SignatureIdentifier-structure


Hallo Juan Carlos,

thanks for your mail. I briefly included some remarks below.

> Thanks for the message and sorry for not reacting before.
> I essentially agree in the principles that lead your 
> proposal, ie to define mechanisms that allow for identifying 
> signatures in the two group of situations we mentioned in our 
> conf call....
> 
> Looking at the specific proposal I would like to make some comments:
> 
> 1. I agree that the signed properties are worth for 
> identifying signatures when the relationships in 
> dss:VerificationRequest have been lost. We could discuss 
> whether the signing certificate information could be 
> mandatory in that case, so that we identify the signature by 
> its value and its generator.

Yes, the signing certificate should be included - at least 
in all cases in which there is a signing certificate. As this 
would not work for all PGP-signatures for example it might be
a problem to make this requirement strictly mandatory. 

In the end the signed properties, which are included should
be sufficient to identify the signature unambigiously. Hence
another good candidate might be the SigningTime (again, if it is 
included in the signature).

As we can not impose requirements with respect to the existence of
certain properties, the mechanism should allow to include any signed 
property and we should only provide recommendations, which signed properties
SHOULD be used if they are existing. 


> In addition I miss what the vr: 
> prefix stands for?

vr is simply the abbreviation for Verification Report. 

> 
> 2. Just making a kind of brainstorming, could we optionally 
> include also the digest of the document where the signature 
> is? in the case of multiple documents and multiple enveloped 
> signatures this would avoid to dig in the bytes of the 
> documents until finding the pointed signature...just 
> computing the digest of the documents we could identify 
> it....Just a first idea that has come into my mind when 
> reading your proposal.

Good idea.

> 
> 2. As for the attributes, I agree that we should provide also 
> mechanisms for pointing at a signature within a binary document....

OK. 

BR,
  Detlef 
> 
> Regards
> 
> Juan Carlos.
> Huehnlein, Detlef escribió:
> > Hallo all,
> > 
> > as briefly discussed during our last phone call, we need to define 
> > some generalization of the <dss:SignaturePtr>-element, 
> which allows to 
> > identify a given signature in the verification report - even if
> > a) the <dss:InputDocuments>-element is not available anymore and/or
> > b) the signature is not based on XML-DSig. 
> > 
> > For this purpose I would propose - similar to the (certificate-) 
> > references defined in XAdES - a SignatureIdentifierType-structure, 
> > which
> > - MUST contain the digest of the referenced signature (i.e. 
> the <Signature>-element 
> >   or the SignerInfo-structure within some CMS-container 
> (which in turn may be
> >   embedded in some pdf-document, etc.) and
> > - MAY contain further information, which eases the 
> identification of the
> >   signature by human users (=> SignedProperties element) or 
> automated systems
> >   (=> WhichDocument, XPath, Offset attributes).
> > 
> > The SignedProperties-element SHOULD contain the SigningTime- and 
> > SigningCertificate-properties, if available and MAY contain 
> other properties, which aid identification.
> > The WhichDocument-attribute is useful as long as the 
> > <dss:InputDocuments> is available. The XPath-attribute 
> identifies the
> 
>   signature within an XML-document.
> > The Offset-attribute points to the first byte of the 
> signature within 
> > a binary document and hence MAY facilitate the processing 
> of non-XML-documents.
> > 
> > The entire structure would look as follows:
> > 
> > <complexType name="SignatureIdentifierType">
> > 	<sequence>
> > 		<element name="DigestAlgAndValue" 
> type="XAdES:DigestAlgAndValueType" />
> > 		<element name="SignedProperties" 
> type="vr:SignedPropertiesType" maxOccurs="1" minOccurs="0" />
> > 	</sequence>
> > 	<attribute name="WhichDocument" type="IDREF" use="optional"/>
> > 	<attribute name="XPath" type="string" use="optional"/>
> > 	<attribute name="Offset" type="integer" use="optional"/> 
> > </complexType>
> > 
> > 
> > Please let me know what you think about this proposal.
> > 
> > BR,
> >   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
> > 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]