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,

>> 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.
as an implementor I would also complain about the additional burden. I
do remember a dear colleague and his reliable answer '... this is far
too complex!' after reading through the first five pages of any
specification ;-)
But take a look. In your Java object model it is just about adding _one_
line for each element:

    @XmlAttribute(name = "Algorithm", required = true)
    @XmlSchemaType(name = "anyURI")
    @JsonProperty("alg")                               // That's it! No
additional 'JSON' object model required, the request or response can be
processed syntax-independently
    protected String algorithm;

I would consider it a much more challenging task to setup a REST-alike
environment, to get a solid test coverage  and to take care for the
security-mechanisms in this non-SOAP environment (e.g. Web Service
Security vs. OpenID connect). But sure, there is a price to pay for an
additional syntax. And once we decide to do so, we MUST NOT take
shortcuts that prevent our JSON support from being accepted by the
users. So let us try to adopt the laws of the JSON world. I would guess
you wouldn't be happy if someone comes up with an XML schema using ASN.1
tag numbers as types ... just because it's easy!

In addition to XML and JSON schema we also provide SwaggerDoc /
OAS-compliant interface description files to enable any developer to
generate code for any host language easily.  Moreover I'm working with
Stefan to convince OASIS to open a 'specification outlet store' at
SwaggerHub, which would enable to test-drive the specification online,
without dealing with compilers and bindings.

>>> 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?
Sorry, obviously I didn't get the correct understanding of the problem.

Looking at the verification case: I assume a given XMLDSig having a manifest
- pointing to documents somewhere with an absolute path
(http://etsi.org/policy123) : no problem
- pointing to a tree fragment within the same document: no problem
- pointing to a document using relative path ( e.g. ./localPolicy.xml):
transferring just the signature breaks the relation. This is a golden
use case for ASiC.

The same applies to signature creation. The loosely coupled relationship
via a relative path should better be wrapped in a zip container. I don't
think that any 'other' input documents should be assumed to reside in
the same directory using a relative path.

Does this answer matches your question somehow?


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

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]