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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)


> >   - "selection transforms" A -> B, and the
> >   - "signature transforms" A -> C, B -> C

Shouldn't the reciever be able to reapply the mentioned 'signature transform' using the enveloped data ? It doesn't make sense for me to envelope some data which you could NOT use as a starting point for the 'signature transform'. You couldn't verify this signature without additional access to the original data. This would proof the enveloped data as redundant.

I would prefer to allow only B -> C signature tranformations. The A -> B tranformation would degrade to be friendly service for the user.

Or do I have missed an important aspect (again ) ? 

Greetings 

Andreas

--- Nick Pope <pope@secstan.com> wrote:
> What is there a difference between selection transforms and other transforms
> (e.g XSLT).  I can see uses in having enveloped documents that includes the
> post transformed document being enveloped after the style sheet has been
> applied.  Something like this cam up in earlier discussions in this area,
> although I am not sure of the outcome.
> 
> I would be concerned about not allowing enveloping of documents after
> transform.
> 
> Nick
> 
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 12 September 2003 21:52
> > To: Juan Carlos Cruellas; dss@lists.oasis-open.org
> > Cc: ed.shallow@rogers.com
> > Subject: Re: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST
> > DISCUSSION)
> >
> >
> > At 02:08 PM 9/12/2003 +0200, Juan Carlos Cruellas wrote:
> >
> >
> > >COMMENT: For me this means that the text says that it may be the
> > case that
> > >a requester
> > >sends an Input document, A. He has to send in fact two
> > informations to the
> > >server:
> > >         1. Information on what elements of the input document A have to
> > > be signed.
> > >         2. Information of the additional transformations that
> > the server
> > > has to
> > >apply to these elements.
> > >Now the server does the following:
> > >
> > >1. It builds up B (set of elements that will eventually be
> > signed) from the
> > >information in 1. This information
> > >sent by the requester can be a XSLT transformation or a XPath expression.
> > >
> > >2. It builds up C by transforming B according the indications in
> > additional
> > >transformations.
> > >
> > >3. It envelopes B!!! in the signature. At least this is what I understand
> > >from the text.
> >
> > Hmm.  So you're saying there's the:
> >   - "selection transforms" A -> B, and the
> >   - "signature transforms" A -> C, B -> C
> >
> > A = input documents
> > B = enveloped or enveloping documents
> > C = the final post-transformed data that's actually signed
> >
> > You're right, that's what 3.5.1 in the requirements doc appears to say.
> > I'd say that's the most complex of 3 choices:
> >
> > 1) selection transforms can produce enveloped or enveloping docs
> > 2) selection transforms can produce only enveloped docs
> > 3) no selection transforms
> >
> > Perhaps we can revisit the requirement.  I'm not sure it's
> > important to be
> > able to select particular parts of Input Documents.  Doing (3) would make
> > things easier.
> >
> > I'll try to get list feedback on this.
> >
> >
> > >So, you seem to say that the meaning of the text in the req. doc
> > is the one
> > >you mentioned?
> >
> > No, I think your reading is correct.  But I'm wondering if we can revisit
> > this and cut out the words "particular parts" from 3.5.1.
> >
> > Trevor
> >

______________________________________________________________________________
38xTestsieger - WEB.DE FreeMail - Deutschlands beste E-Mail
Design-Mails - einfach schoenere E-Mails - http://f.web.de/?mc=021129



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