OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Andreas,
See below my comments intermixed.

Just one immediate remark: I still think that increasing the number of SignatureObject to unbounded without working deeper the contents so that it can effectively point to any signature that may contain any signed data object in the request is essentially a bug in the core (for instance, how SignatureObject can point to one of the parallel signatures that can come within a CMS structure? currently SIgnatureObject can not. The problem is that you have opened the possibility of using, for identifying any signature in any signed document, an object that can NOT DO IT in any situation (the CMS case is clear). This to me, is just an error. If you want to do it, you should rework SignatureObject for ensuring that it is able to identify any signature in any signed document.

Obviously you are the ones in charge of the document....but whoever is responsible of generating profiles is free to act as it considers worth. I am sorry to say that under these circumstances and with the solution that you propose, I will recommend to ESI either not to use this feature in its profile or extend the SignatureObject from OASIS to incorporate means for pointing to any signature in any signed document.

Juan Carlos.

El 15/4/19 a las 23:06, Andreas Kuehne escribiÃ:
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.



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:

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.
The problem is that the text does not make this clear statement. Nowhere in the text there is any limitation to the number of SignatureObject instances treated in the core. And it is suppossed that readers should not guess it.

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

With all the respect: this is not about your understanding. It is about what is written and what is not written. As I said, I did not find anywhere in the text a clear statement saying: the VerifyRequest element shall contain 0 or one SignatureObject.

With this clear statment, some notes spread here and there, and a sentence similar to the previous version of the core on what happens if the server decides to validate all the signatures it finds, readers would clearly see that in fact, at the level of the core, they should not worry about the maxOccurs attribute in SignatureObject...but nothing of this is present in the text, leaving readers on their own supositions, which is a clear indication of an ambiguous standard.

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.
Once again, we completely disagree. In the current status the cardinality of SigningTimeInfo is a good example of a badly solved issue in a standard. A standard never has to leave readers to guess or to assume its intentions: a good standard simply has to EXPLICITLY DECLARE THEM and has to unambiguously to provide mechanisms to achieve them.


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

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

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
Join OASIS: http://www.oasis-open.org/join/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]