|
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.
Greetings,
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?
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
|