Re: [dss-x-comment] INDIVIDUAL comments to dss-core-v2.0-csprd02

[Andreas Kuehne <kuehne@trustable.de>]

Hi Juan Carlos,

I filed your comments as DSSX-52 (https://issues.oasis-open.org/browse/DSSX-52) and DSSX-53
 (https://issues.oasis-open.org/browse/DSSX-53). See the comments of the TC below.

Greetings,

Andreas


regarding Comment 1:

Thanks again for all your important comments on public draft version 1. Your set 
is the biggest and most valuable set of responses we received!


regarding Comment 2:


I completely agree with your design baseline 'keep the core simple'! And 'don't 
change a running system (standard)' is also an important guideline. Therefore 
the version 2.0 is, in terms of functionality, as close as possible at version 
1.0.  That's why we moved section 4.3.1 ('Multi-Signature Verification') of DSS 
core 1.0 to the version 2.0, more or less unchanged as chapter 6.3.1.

The complexity introduced by multi-signature verification is significant and it 
should be isolated into specific profiles. And due to my opinion this is the 
intention of 4.3.1: One single signature per verification request is the use 
case handled by the core, the handling of multiple signatures is beyond its 
scope of the core. The same applies to multi-document signing.

Due to my understanding section 4.3.1 opens the door for the processing of 
multiple verifications per request. And limiting this option only to formats 
that allow multiple signature per file is hard / impossible to comprehend! So 
extending the cardinality of SignatureObject to 'unbounded' for specific 
profiles is just applying the intention of section 4.3.1 to all signature 
formats! Or as Detlef once expressed it 'the core should be a foundation for 
profiles, not a limitation to profiles!'

The SigningTimeInfo element and its cardinality is a good example of the core's 
intention to support just ONE verification at a time! But I agree that the 
documentation of this element should be more detailed, especially as it makes 
sense in a single-signature scenario. Nevertheless I would reject your request 
to limit the cardinality of signatures per requests. It would break backward 
compatibility. Some additional clarifiying sentences  regarding SigningTimeInfo 
are on my list for an Errata document.



> Dear DSS-X TC
>
> Thank you very much for the new draft version of the DSS-X core
> document and your work for updating it.
>
> I have started to read it. Below follow some few comments (other could
> come as I progress my reading of the document).
>
> COMMENT 1. I am glad to notice that the bugs in the XML schema that
> avoided to incorporate more than one optional input in requests and
> more than one optional output in responses, are fixed. Thank you very
> much.
>
> COMMENT 2. I am concerned about the change in the VerifyRequest,
> which allows now to include more than one signature, if it works as I
> think it works. I have understood that this allows a client to
> explicitly list more than one signature in a VerifyRequest. I
> understand that then the core mandates that the server validates all
> the listed signatures, and that also mandates that the server
> generates the corresponding optional outputs generated during the
> validation, following the rules mandated by the XML schema.
>
> If this is what this version of the core states, below follows the
> rationale for my concerns:
>
> RATIONALE. A. This change breaks a long tradition of "keep the core as
> simple as possible and leave special things for profiles/extensions",
> which was the followed approach since the very beginning of DSS TC. I
> was the co-chair of the TC which generated the first version of the
> core. This topic, i.e., the possibility of dealing with more than one
> signature in one validation request, was discussed in depth within the
> DSS-TC, and the unanimous view of the members was NOT to allow the
> possibility of including more than one SignatureObject in the
> validation request. As certainly a document could contain more than
> one signature, the final decission adopted by the TC was allow that a
> server could validate all the signatures present in that document
> under certain circumstances, and generate a global result notifying
> whether all the validated signatures were valid or not, and then
> provide, within the individual optional outputs, details of the
> validation of *the* signature explicitly mentioned in the
> SignatureObject of the request. RATIONALE: nobody wanted to create, at
> that time, a core protocol that should have to deal with linking each
> optional output to the signature whose validation generated such output.
>
> During years the community has used this protocol, and, indeed, is now
> requesting more features, among which, the capability for indicating,
> within a request, which signatures the client requests
> validation....BUT IÂ disagree with the adoption the DSS-X has taken,
> which is just to complicate the core. Instead, I am in favour of
> having an extension of the core that allows this.
>
> This was exactly the decision ETSI ESI TC took when facing this
> situation in a workshop for dealing with standardization in the area
> of validation services. ESI produced a profile/extension of the OASIS
> core which incorporated:
>
> ÂÂÂ i. Mechanisms, in the request, for identifying which signatures
> the client wants the server tries to verify among all the ones present
> in the document(s) submitted.
>
> ÂÂÂ ii. Mechanisms, in the response, for linking each optional output
> generated during the validation of ONE signature, TO THAT SIGNATURE,
> so that, if the request mandates to validate two signatures and
> requests to return the SigningTimeInfo, the response *CARRIES TWO
> SigningTimeInfo* and *EACH ONE IS CLEARLY LINKED TO THE CORRESPONDING
> SIGNATURE*. This is what the stakeholders requested, a clean way of
> requesting validation of several signatures, and a clean response for
> the validation details (i.e. optional outputs) are grouped in elements
> that correspond to each of the signatures validated. And all this done
> without perturbing the core.
>
> RATIONALE. B. The potential presence of several SignatureObject
> elements in the VerifyRequest generates something extrange. In fact,
> it could even be considered a standardization flaw, or at least an
> ambiguity. According to the XML schema and the written specs, If I
> correctly understand them, only one SigningTimeInfo can be present in
> a VerifyResponse. Now, imagine that the VerifyRequest has 4
> SignatureObject, and the optional input ReturnSigningTimeInfo. The
> request is requesting to validate 4 signatures. The request is
> requesting to return the signing time info......*AND THE RESPONSE ONLY
> HAS THE POSSIBILITY OF RETURNING ONE SigningTimeInfo*. You could say,
> "well, in core version 1.0, the VerifyResponse also usually contained
> only ONE SigningTimeInfo"; true, but the key point is that in core
> v1.0 it was pretty clear that the SigningTimeInfo was the signing time
> *OF THE SIGNATURE within the SignatureObject*, so the response did not
> have any ambiguity at all: the server accepted to validate N
> signatures, and provided: full details of 1 signature (the one in
> SignatureObject) and just a yes/no for the rest -or even less than
> that, if some failed-). IF YOU CHANGE THE CORE TO ADMIT MORE THAN ONE
> SignatureObject, the SigningTimeInfo is the signing time of which
> signature of the N signatures present in SignatureObject and
> validated? This is not indicated anywhere in the document. And to me
> this seems quite a flaw (or at least an ambiguity) that should not be
> kept in a standard. And the same happens with every optional output
> that reports on certain aspect of the validation of one signature.
>
> I see several options:
>
> 1. Remove the possibility of several SignatureObject, because there is
> a profile/extension of the OASIS core developed by ETSI ESI which
> already satisfies the requirements expressed by stakeholders on the
> need to be able to request to the server the validation of several
> signatures. This is to me the most reasonable solution.
>
> 2. Persist in keepting the possibility of having more than one
> SignatureObject. In this case you will have either:
>
> ÂÂÂ 2.1 To allow more than one instance of optional outputs like
> SignatureObject in VerifyRequest (change in your XML schema), and add
> a mechanism for linking each optional output to the signature whose
> validation has generated it. If you go in this direction you will be
> generating a protocol that offers a feature that ESI profile/extension
> of DSS OASIS protocol already offers: I do not see any benefit neither
> for OASIS, nor for ESI, and what is more important, nor for
> stakeholders. At present the situation is clean and easy to
> understand: if you have enough with the OASIS core protocol, use it;
> if you need to be able to identify a subset of signatures for
> validating, and that the server returns details of *all the signatures
> in the subset*, use the ESI profile/extension of the OASIS
> protocol....everyone wins.
>
> ÂÂÂ 2.2 To just circumvent the problem saying something like: well,
> there will be only one SigningTimeInfo, and this will be the signing
> time of the *first* signature within the SignatureObject. To me this
> is a completely unsatisfactory situation: you would have changed the
> XML schema of the core just for allowing to identify some signatures,
> and the rest would have remain the same as in core v1.0....what would
> be the benefit of this?
>
>
> I consequently kindly request that you drop the possibility of
> including more than one SignatureObject in the Requests of the core
> protocol.
>
>
> Best regards
>
> Juan Carlos Cruellas.
>
>
>
> -- 
> This publicly archived list offers a means to provide input to the
> OASIS Digital Signature Services eXtended (DSS-X) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: dss-x-comment-subscribe@lists.oasis-open.org
> Unsubscribe: dss-x-comment-unsubscribe@lists.oasis-open.org
> List help: dss-x-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/dss-x-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee:
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x
> Join OASIS: http://www.oasis-open.org/join/
>

-- 
Andreas KÃhne 

Chair of OASIS DSS-X
 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas KÃhne

Company UK Company No: 5218868 Registered in England and Wales