[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Further - Request for inclussion to the requirementsdocument
Trevor, I believe we agree on the organisation of the work. Maybe the terms used could better: Work area 1 is: - request / response protocol - "core" elements of a signature which are additions to those already specified: * XML Time-stamp and time-mark elements * XML requestor identity elements Work Area 2 is bringing together signature elements and request / response for a certain "class" of DSS service. This will include classes of service based on: - XAdES - CMS - XMLDSIG For work area 2, I (Nick) personally do not like the term "profile" as to me this implies something targetted at interworking for an application. What about support for time-stamping? Is this another activity under work area 2? Nick & Juan Carlos > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: 14 May 2003 19:57 > To: Juan Carlos Cruellas; dss@lists.oasis-open.org > Subject: RE: [dss] Further - Request for inclussion to the > requirementsdocument > > > > responses inline- > > At 02:43 PM 5/14/2003 +0200, Juan Carlos Cruellas wrote: > > >At 09:41 13/05/2003 -0700, Trevor Perrin wrote: > > >At 03:02 PM 5/13/2003 +0200, Juan Carlos Cruellas wrote: > > > > > >>I think that we should try to get a consensus on the roadmap defining > > >>the scope of what we would like to produce and if possible on the > >terminology. > > >> > > >>As I see the messages going back and forward, I think that there is > > >>quite a lot of common in both views as Trevor says. > > >> > > >>I would suggest then, based on Trevor's roadmap and on our proposal: > > >> > > >>1. Core Protocol. This would include to specify: > > >> > > >> - request/response protocol for getting and verifying > signatures. > > >> > > >> - Format of the signature: XMLDSIG plus three elements: > > >> - XML simple (but extensible) time-stamp and > time-mark elements > > >> - XML requestor identity element > > >> -XAdES Signature Policy Identifier > > >> > > >>2. Extensions to the protocol for managing additional > signature elements > > >>(and here I propose to substitute the term "profile" and use the term > > >>"extension" > > >>as a way to try to overcome the problems that seem to be with > that term). > > >> -XAdES elements > > >> -CMS elements > > >> -Other parts of other specifications?. (the "bindings" that Trevor > > >>mentions, and > > >>that are not very clear for me.. perhaps you could explain Trevor?).. > > > > > >How do you think this should be broken into documents? I'd > like to get to > > >that level of concreteness. For our "normative" work, I was > suggesting the > > >things you mention in 1. (minus the Policy Identifier) be made into a > > >"Protocol and Core Elements" doc: > > > - request/response protocol > > > - XML simple (but extensible) time-stamp and time-mark elements > > > - XML requestor identity element > > >I would call the latter 2 bullets "core elements" instead of > part of the > > >"core protocol". > > > >Two comments on that: > > > > > >1. I do not have problem in calling them core elements. > > > >2. I think that we all understand that when speaking about this > core protocol > >we are assuming that the signature will be XMLDSIG plus these three core > >elements don't we? > > Could you clarify what you mean by "core protocol"? If you mean just the > "request/response protocol", then we shouldn't assume the signature > produced is XML-DSIG (it might be CMS, or even something else). > Even if it > is a DSIG, it may be an XAdES or not, and it may have a timestamp or > requestor identity or not (in some use cases these aren't important). > > > >3. Is there any reason why you would not add the signaturePolicy > to this list? > > I was thinking the "Protocol and Core Elements" doc would only > present new > things we were defining, like the timestamp and requestor identity > elements. Then the "Signature Profiles and Protocol Bindings" doc would > include an XAdES profile that discusses how to incorporate the timestamp > and requestor identity into the XAdES structure (for example, by > including > the timestamp within XAdES's <SignatureTimeStamp>, and including the > requestor identity within XAdES's <SignerRole> or something). > > So I wouldn't include the XAdES SignaturePolicyIdentifier in the > first doc > because: > - it already exists, so we don't need to define it > - it would be implicitly included as part of the XAdES > signature profile > in the second doc > > But are you suggesting that we take the SignaturePolicyIdentifier as a > standalone element that can be used without XAdES? > > > > > >Then I was suggesting a "Signature Profiles and Protocol > Bindings" doc that > > >would include: > > > - XAdES and CMS signature profiles. I think these are > better viewed as > > >"signature profiles" than just collections of elements, > because if you're > > >using XAdES there's a whole structure of where you put the > signed/unsigned > > >attributes that you have to use, so this is more than just a > collection of > > >elements that you can pick and choose from. > > > >Well, the issue is that XAdES only defines a small number of elements as > >mandatory, > >which means that in fact, you can profile it depending on the > elements you > >want to use!!. > > > >It is true that if you want to get a long term signature, the document > >specifies a number > >of elements that you MUST put there, but still there are others that you > >can or can not > >add. And some of these conditional elements are strongly related with > >business > >applications (signerRole, CommitmentTypeIndication, etc...). So, > you could > >have a long > >term signature with an element containing the information of the role > >played by the > >signer or other long term signature without that information....And this > >would depend of > >the requirements on the domain. Which means that applications > could require > >a profile > >of XAdES!!!, that is why we do not feel very confortable with the term > >"profile": in the end > >we could face profiles of a profile!!... > > I don't see anything wrong with that - XAdES profiles DSIG, we profile > XAdES, someone else profiles us.. it's just a big stack of layers that > each adds some constraints or extensions to the layer beneath it. > > >Don't you think that if we speak > >about "Signature > >extensions", then it is clearly reflected the fact that XAdES provides > >extension mechanisms > >for the Signature (instructing, of course about how to add these > extensions > >in the signature), > >but that it still allows you to select certain elements depending of the > >business requirements? > > Are you suggesting we call the second doc "Signature Extensions and > Protocol Bindings"? I like "Signature Profiles" better, it seems > more apt, > and if we add both a timestamp and requestor identity into XAdES, it's > clear that's a single XAdES profile, but not so clear whether > those are two > separate XAdES extensions or a single one. But that's a minor point, I'm > fine either way. > > > Trevor > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]