|
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.
True!
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".
Fixed.
4.Clause 2.4
• The prefix dsb: stands for the DSS core namespace
[DSS2XSD].
I guess that dsb stands for the DSS base namespace
Fixed.
Juan Carlos, you must admit that the quality of the TC's documents
is degrading rapidly since you left ;-)
5. Clause 4.2.3.2
<xs:complexType name="DocumentType">
<xs:complexContent>
<xs:extension base="dss2:DocumentBaseType">
<xs:choice>
<xs:element name="Base64Data"
type="dsb:Base64DataType"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
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 4.3.5.2.
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,
Andreas
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
|