[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Signature Augmentation vs. Update
|
Hi folks,
I received a bunch of comments for the current draft of the core
document from Juan Carlos. As expected this is quite valuable
input and most of it will be incorporated in the version of the
core draft. But for one topic I like to gather the view of the TC
(see point 6 below): The term 'Update Signature' as used e.g. in
element 'ReturnUpdatedSignature' is replaced within ETSI with the
term 'Augment Signature' to explicitly state the addition of
unsigned properties. In addition to this augmentation the DSS version 1.0 of the core
explicitly mentions the producing a new signature on the same
documents as an 'update'. I would consider this an outlandish use
case and would propose to use the term 'augmentation' and narrow
it's functionality down to adding unsigned properties. What's your view on this?
Greetings,
Andreas -------- Weitergeleitete Nachricht --------
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]