RE: [dss] Further - Request for inclussion to the requirementsdocument

["Nick Pope" <pope@secstan.com>]

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
>
>
>