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] One comment and one question

Hi Andreas,

Thanks for your feedback,

See below intermixed.

Best regards
Juan Carlos.
El 21/5/18 a las 20:55, Andreas Kuehne escribió:
Hi Juan Carlos,
1. I would like to pass you a comment received to the ETSI TS 119 442 draft that was put in public domain for getting comments of stakeholders. Despite the fact the comment was raised for this document, I think that it actually is a comment for DSS-X core v2.0. The comment was as follows:

"XML elements are named as follows:
-    InputDocuments
-    SignatureObject
-    DocumentWithSignature
JSON elements are named as follows:
-    inDocs
-    sigObj
-    docWithSignature

Why are the names different, regardless of the format used? If the names are the same, this will make the data more easily machine-processable.    For all elements, use the same name.
For example:
-    XML: InputDocuments
-    JSON: inputDocuments"

The ETSI TS 119 442 just re-uses as much as possible the components specified in DSS-X core v2.0, so their names in XML and JSON are the same as the names in this document. That is why I consider that this is more a comment for DSS-X than for ETSI ESI. I understand that the rationale for making the names different has been the somehow implicit tendency within JSON to use shorter names than in XML. I ignore, though, whether you have made any trade-off between this implicit tendency and the potential burden that different names could put on developers according to the received comment. Could you please let us know your views on this particular issue?

here we try to be in line with the definitions made in RFC 7519 and to use the given abbreviations and to define short descriptor in the way that it's common in the JSON world. We had no intention to be 'creative' but to align with given use.

I understood that; the issue is that there are implementers out there that, facing the situation of having to implement two bindings for a protocol, one in XML and another in JSON, claim that making the names of the components the same in both bindings, makes their lives easier, and that the price payed for not using abbreviations in the names is much less that the price payed by the burden of having two different sets of names for the two bindings. In other words, not being an evangelist under certain circumstances is a good thing, and they say that this is one of these circumstances.

2. I would like also to ask you a question, also related with a comment received. The comment was the following one:

"If the signature contains a ds:Manifest, and if the user wants to validate some documents from the ds:Manifest, in which element the associated documents should be included ?

Maybe those documents could be included into InputDocuments."

My understanding that anything referenced within a signed ds:Manifest, within the VerifyRequest message should be passed to the server within a sub-component of dss2:InputDocuments. Could you please confirm this point?

Hmm, due to my understanding the Manifest is not an element of DSS but of XMLDSig. If a given XML signature includes a reference (in a Manifest or elsewhere) the verification server should be able verify it. From the DSS point of view I would not limit the set of verifiable signatures to those with references to local documents.

A server may reject to follow a given reference due to security reasons (e.g. amplification attacks). But that's beyond the scope of DSS.


Indeed, ds:Manifest is NOT an element of DSS. This was not the question. The question was, where the documents REFERENCED within the ds:Manifest are trasnported in the DSS message?. Actually, anything referenced within a signed ds:Manifest, is a document also signed by the signature, and consequently, if all the signed documents, or their digests or their transformed versions have to be submitted to the server, also the documents indirectly signed through a signed ds:Manifest have to be sent to the server. The question was where? and my initial assumption was that in the inputDocuments, as they are also signed documents, even if they are signed through a signed ds:Manifest. Do you agree with my assumption?


Thank you very much indeed for your feedback

Best regards

Juan Carlos Cruellas.

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]