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] Some comments on dss core v2 draft 5.0

Thank you very much for this Andreas....and glad to hear that Germany is sunny this period of the year :-)

Regarding the update vs augmentation, actually I had forgotten the case "or additional information for use in verification), or the updated signature could be an entirely new signature calculated on the same input documents as the input signature", but thinking again seems a bit extrange to call "updated signature" to an entierly new signature that does not have any relationship with the former one, so I personally would say that even this case is quite controversial. In addition to that the actual truth is that there is not any formal definition for signature update, which is the minimum requirement for unambiguosly scoping what we are talking about when speaking of updating a signature, and the text that you point out can not be considered a formal definition.

However, for augmentation, ESI has actually defined the term as follows in its ETSI TR 119 001:
"signature augmentation: process of incorporating to a digital signature information aiming to maintain the validity of that signature over the long term"

Best regards
Juan Carlos.
El 9/5/18 a las 17:56, Andreas Kuehne escribió:
Hi Juan Carlos,

thank you for you your time and effort to review the core! See my comment inline ...

Below follow some few comments on core v2 draft 5.0:

1.Is there any relationship between the notice at the beginning of the document identifying the number of WD ( WD 03) and the identifier in the document name (05)?  Maybe they should be the same?

The numbering and date entries are on still my automation list. I'll setup a manual pre-upload checklist for the meantime.

2. An indication of the day/month/year would also be good.

3. In the text "Using the first protocol a client can end documents (or document hashes) to a server and receive back a signature on the documents. Using the second protocol a client can end documents", I guess that the two instances of "end" should be converted to "send".


4.Clause 2.4

•    The prefix dsb: stands for the DSS core namespace [DSS2XSD].
I guess that dsb stands for the DSS base namespace

Juan Carlos, you must admit that the quality of the TC's documents is degrading rapidly since you left ;-)

5. Clause

<xs:complexType name="DocumentType">
    <xs:extension base="dss2:DocumentBaseType">
        <xs:element name="Base64Data" type="dsb:Base64DataType"/>

Not sure about the choice having only one child element. It is used normally for making it clear that one among different options must be present. However there is only one option here: the Base64Data element. Wouldn't it be more appropriate to use a sequence (minOccurs="1" and maxOccurs="1")?

Yes, the sequence version expresses the intended structure more obviously. And my test cases don't complain, so I changes the core schema accordingly.

6. Clause

This clause reuses the element ReturnUpdatedSignature. This element was defined years ago and was mostly related to AdES signatures which could be added unsigned attributes/properties. Since then, ETSI ESI TC has coined a term for the process of incorporating unsigned properties/attributes to an AdES signature: AUGMENTATION. That was the result of lengthy discussions within the committee, which also assessed other terms (update, upgrade, etc). Nobody now, within the AdES world, speaks about updating a signature for incorporating unsigned properties/attributes; instead everybody speaks of augmenting the signature.

The DSS-X core v2.0 should align the names of the components related with the augmentation of signatures with the terminology that the standardization organization that defined the process has adopted. Consequently, the name of the element should be moved to ReturnAugmentedSignature.

The argument of keeping backwards compatibility should not apply here: as the document states, a good number of decissions have been made that make v2.0 incompatible with v1.0. The adherence to the globally accepted terminology coined by ETSI is a reason good enough to make the movement, which would avoid missunderstandings and confussion among developers and users.

Please note that ETSI, in its profile of the dss core v2.0 deprecates the usage of ReturnUpdatedSignature and uses its own ReturnAugmentedSignature for being fully coherent with the terminology used in all its standards (those ones on signature formats, signature validation and signature policy, among others). The movement from DSS-X to this component would benefit alignment of both specifications.

Interesting point! And I would always support alignment of wording. But as read in core 1.0 the idea of 'upgrading' was defined a much broader way than just augmentation: "[...] the updated signature may be the original signature with some additional unsigned signature properties added to it (such as timestamps, counter-signatures, or additional information for use in verification), or the updated signature could be an entirely new signature calculated on the same input documents as the input signature."

So if we move to 'augmentation' we would limit the functionality here. On the other hand I would agree that the augmentation is the major use case. I'll check back with the TC regarding their view.

Greetings from sunny Germany,


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

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