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


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.

Greetings,

Andreas


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]