[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [dss] Use cases and requirements input
Robert, please find my answers below. /Gregor >-----Original Message----- >From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com] >Sent: Sunday, January 26, 2003 3:03 AM >To: Gregor Karlinger >Cc: DSS TC >Subject: RE: [dss] Use cases and requirements input > > >Some responses below: > > > >> >Just so that I am clear, the purpose of this is (assuming a >> >trustworthy signature implementation) just to prevent >> >modification or substitution of the pure XML and transform data? >> > >> >> Let's have a look at the following example: >> >> o The maschine wants the following XML form to be signed: >> >> <Data2BeSigned> >> <Name>Gregor</Name> >> <Donation>100$</Donation> >> </Data2BeSigned> >> >> o Since the human does not want to sign the pure XML (though this >> simple XML structure is understandable, but not a more complex >> structure), the XML structure is transformed into a human- >> feasable html representation using a stylesheet transform; so >> the signature created by the human will look like: >> >> <ds:Signature> >> <ds:SignedInfo> >> ... >> <ds:Reference URI="data2BeSigned.xml"> >> ... >> <ds:Transforms> >> <ds:Transform Algorithm="...stylesheet"> >> <xsl:stylesheet> >> <!-- Stylesheet for transforming XML data into >> HTML --> >> ... >> <!-- basic stylesheet imports another stylesheet >> document, let's say anotherStylesheet.xsl --> >> <xsl:import>...></xsl:import> >> ... >> </xsl:stylesheet> >> </ds:Transform> >> </ds:Transforms> >> ... >> </ds:Reference> >> </ds:SignedInfo> >> ... >> </ds:Signature> >> >> o Now, the relying party still wants to work with the XML structure >> (<DataToBeSigned>), but the human has signed its XML representa- >> tion. >> >> o This can only be achieved if all the parameters needed to compute >> the transform chain in <ds:Transforms> are covered by the signa- >> ture as well: > >Unless I am missing something, it seems to me that the relying party >can still work with the XML structure, even if it is not signed. It >seems to me that what is gained by including the XML structure in the >scope of the signature is protection from modification or substitution >of that XML structure into another structure that will give the same >result after applying the transform. That is the point. The relying party cannot rely on the XML structure since there are potentially several structures that lead to the same result after the transform(s). >This is definitely useful. I >don't disagree with that. I just want to be clear about what we >achieve by doing this. It's also not clear to me that defining the >format of the signature is necessarily within the scope of this TC. >Our deliverables include protocols for obtaining and verifying >signatures, not the signature formats themselves. However, I think it >is certainly worthwhile to include this use case at this point and see >what requirements we get from it. Agreed. Let us simply have this use case in mind. >> >> 2.2.1 Provide data actually signed >> >> >> >> For the requester it is also important to know WHAT has been >> >> signed by the signature to be validated. If the validation >> >> service does not provide this information, the requester has >> >> to process the transforms specified in the signature; but >> >> this is lots of work. >> > >> >My opinion is that in order to keep the protocol that we >> >eventually decide upon as simple as possible, the validation >> >service should only provide services directly related to >> >signature validation. I see this as more of an XML processing >> >service provided in addition to the validation service. >> >Personally, I think it would be best to assume that the client >> >will process the transforms, and would rather not see this as a >> >requirement. >> > >> >> I do not share your opinion. If the client needs to process the >> transform, this is quite painful since the client has to under- >> stand lots of different transforms (i. e. needs appropriate >> software tools); I estimate that processing of the transform >> makes about 2/3 of the overal work to validate the signature. >> >> I do not argue that the information what has been signed must >> be given to the client in any case, but it should be an optional >> feature at the client's decision. > >Perhaps. I fear however developing a protocol that has many optional >features that can be used at the client's decision and thus becomes so >complicated that interoperability is difficult and it doesn't get >used. Thus, I would like to focus as much as possible on the actual >signature validation. However, let's discuss further after all of the >use cases and requirements have been collected. I understand your arguments. However, the general aim of a simple protocol should not prevent us from presenting potential use cases. >> >> 2.2.4 Allow for configuration profiles >> >> >> >> - Trust >> >> >> >> The requester should be able to specify the trust settings >> >> (accepted root certificates, accuracy of CRL checking, ...) >> >> to be applied by the service when validating a signature. >> >> >> >> Since this trust-related information can be quite bulky, the >> >> requester should alternatively identify this information by >> >> a named profile. >> >I'm not opposed to allowing requesters to specify the trust >> >settings, but not at the expense of producing a protocol that is >> >more complicated that necessary. I'm guessing that this feature >> >would not be required in the majority of signature validation >> >server environments. The trust settings would be implicitly >> >defined by the service. At least in our first iteration I would >> >like to produce something that is simple, usable and works. We >> >can then build upon that. >> >> I think that there is not a 1:1 relation between a signature >> validation service and a trust setting in lots of cases; Different >> clients will use the same validation service, but with different >> trust settings. > >Agreed. I'm just trying to decide which of the requirements that we >come up with will be worth the added complexity in the protocol. It's >not clear to me that this one is. But I would be interested in the >opinions of others. Again, I think we should collect use cases in a first step. Let us discuss and decide which are worth to support by our service protocols in a second step.
Attachment:
smime.p7s
Description: application/pkcs7-signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC