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

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Trevor,

see below


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?

3. Is there any reason why you would not add the signaturePolicy to this list?

>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!!... 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?

I see and agree what you say about protocol bindings....

Regards

Juan Carlos.


>  - protocol bindings - these define how to use the request/response 
>protocol messages over layers like WS-Security, or HTTP/TLS, or BEEP, or 
>etc..  These layers have to provide transport, authentication, and 
>confidentiality and integrity.
>
>Does this make sense?
>


>Trevor 
>