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

[Trevor Perrin <trevp@trevp.net>]

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