Re: [dss-x-comment] Questions about DSS-X Local Signature Computation Version 1.0

[Ernst Jan van Nigtevecht <ejvn@sonnenglanz.net>]

Dear Aron,

We have discussed your feedback; below our reply.

Regarding the use of the Profile attribute:
-------------------------------------------
We understand that the Profile attribute is normally used the specifion
of the type of document that is requested, such as
"urn:oasis:names:tc:dss:1.0:profiles:XAdES" in case of XAdES.

But the use of (for instance)
"urn:oasis:names:tc:dss:1.0:profiles:XAdES" as a Profile attribute would
indicate that it is not a local signature profile, so it cannot be a
SECOND SignRequest as specified by the local signature profile.

The SECOND SignRequest has some addional elements which are not present
in the DSS-core specification (not as an optional input), such as the
element SignatureObject, and it may assume a certain state of the
Digital Signature Service (for instance if the document is temporarily
stored in the Digital Signature Service, obtained during the FIRST
SignRequest). The use of these elements and the expected behavior of the
Digital Signature Service apply only to the local signature profile.

To indicate this ‘different’ setup of the (second) SignRequest, a proper
value for the Profile attribute is needed: in this case
"http://docs.oasis-open.org/dss-x/ns/localsig";.

Fortunately, the DSS-core specification allows for the use of additional
profiles:

--
2.8.4 Optional Input <AdditionalProfile>
The <AdditionalProfile> element can appear multiple times in a request.
It indicates additional profiles which modify the main profile specified
by the Profile attribute (thus the Profile attribute MUST be present;
see sections 3.1 and 4.1 for details of this attribute). The
interpretation of additional profiles is determined by the main profile.
--

We therefore propose to add an additional description/indication for the
use of the AdditionalProfile element.

This way, it should be possible to specify a second profile, such as:
<AdditionalProfile>urn:oasis:names:tc:dss:1.0:profiles:XAdES</AdditionalProfile>
in case of XAdES documents.

As mentioned earlier (and included for completeness):

Regarding the XSD
------------------
The XSD was not updated to the changes in the document, unfortunately
(the reference [LocalSigXSD] as found in the document, was also not
correct).

The element "RequestDocumentHash" has to be used, as presented in the
document. The XSD will be corrected as well as the reference
[LocalSigXSD] in the document.


With kind regards,

Ernst Jan



Szabó Áron wrote:
> Dear Ernst,
> 
> thanks for your quick answer. Beyond XSD modification, could you also explain the Profile-issue? I mean, as I understand the described workflow, in two-step-approach case, the result of SECOND SignRequest (identified by Profile attribute) should be XAdES, PAdES, CAdES etc. structure into which the posted PKCS#1 encoded hash (e.g. SignatureValue element of XMLDSIG/XAdES) shall be embedded.
> 
> BR, Aron
> 
> ---
> 
> Dear Aron,
> 
> Thank you very much for your comments.
> 
> A quick look at the XSD made it clear to me that the XSD was unfortunately not updated with the change regarding the use of RequestDocumentHash (which should be in the XSD).
> 
> We will discuss your remarks in our team and will provide a detailed response as soon as possible.
> 
> With kind regards
> 
> Ernst Jan van Nigtevecht
> 
> 
> Szabó Áron wrote:
>> Dear Members,
>>
>> I am writing in connection with Local Signature Computation Version 1.0 specification.
>>
>> I have seen the e-mail sent on 2015-08-25 about the announcement of publication the specification Version 1.0. I looked through the related descriptions and schemas and I found that somehow the "final" version of XML schema does not correspond to "final" version of specification. I could perform XML schema validations on sample XML files by using "csprd02". E.g. from "final" XML schema the "RequestDocumentHash" is missing, it contains "ReturnDocumentHash". Also there was a comment about this in "Appendix E" but it is not clear which version may be the last: 'Processed the comments on CSD 01; see "https://www.oasis-open.org/committees/document.php?document_id=53473&wg_abbrev=dss-x";. Renamed localsig:ReturnDocumentHash into localsig:RequestDocumentHash (in Section 3.2.1.1.2 in the code).' So, shall I use "RequestDocumentHash" or "ReturnDocumentHash" in SignRequest messages?
>>
>> The other thing that was interesting that at Two-Step Approach operation mode (identified by: "http://docs.oasis-open.org/dss-x/ns/localsig/two-step-approach";), the "Profile" attribute at the SECOND SignRequest MUST also be "http://docs.oasis-open.org/dss-x/ns/localsig";. For the FIRST SignRequest, it is clear, that this identifies that returned value shall be just a simple hash, but at the SECOND SignRequest the client shall identify the finalized type of the result Signature structure which should be e.g. "urn:oasis:names:tc:dss:1.0:profiles:XAdES" in case of XAdES, isn't it?!
>>
>> Anyway, just in general, I can say, that I liked the descriptions of all uses cases in this document. They are all in conformance with NPAPI-free operation modes that are supported by recently used, eIDAS-conform eID systems such as German or Hungarian national eID cards.
>>
>> BR, Aron