|
Dear Stefan,
Thank you very much indeed for your message.
After sending my comments, I noticed that the core v2.0 actually
includes the ResultMinor URIs with a short explanation in a
different clause than the one where the Result component is
specified. I guess that this is the reason why I did not notice
their inclusion...maybe you could consider inserting a reference
to clause 9.2 within 4.1.7. Something like:
The optional ResultMinorÂelement MUST
contain a URI.ÂÂÂ[DSS-4.1.7-2]
. Clause 9.2 lists the set of values that are used in this
document.
Best regards
Juan Carlos.
El 2/11/18 a las 17:41, Stefan Hagen
escribiÃ:
Dear
Juan Carlos,
the TC has received your comment and will kindly consider them.
Thank you for taking the time to proide the feedback.
On behalf of the OASIS DSS-X TC
Stefan Hagen, Co-Chair
Am 25.10.18 um 11:52 schrieb Juan Carlos Cruellas:
Dear DSS-X TC,
While re-reading DSS-X core v2.0 I have hit a couple of issues
that I
would like to share with you.
1. Clause 4.1.7. Component Result.
URIs for result major are given without a single explanation.
Additionally, no URNs are given for result minor. This clause
seems to
underspecify the Result component. Could you please consider the
possibility of incorporating in this clause all the contents
related to
URNs for result major and result minor present in DSS core v1.0?
I do
not see any reason for dropping them, as this could be
interpreted as a
voluntary wish of the committee to deprecate the aforementioned
URNs
and/or change their semantics, giving place to a backwards
compatibility
problem.
2. Clauses 4.3.28.2 and 4.3.28.1 XML and JSON of
AdditionalKeyInfo.
Several comments here.
a. There seems to be a mismatch between the XML and JSON schema
pieces
in these clauses and the contents of the XML and JSON schema
files
provided separatedly. In these files, both the XML and the JSON
types
contain components for including OCSP responses. However in the
pieces
in the word document, such components do not appear.
b. In the JSON schema dss2-AdditionalKeyInfoType contains two
components
that seem to be related with OCSP somehow, namely:
"ocspresponse" and
"ocsp", both of base64 data type....as there is not any further
explanation, it is difficult to conclude what must placed within
each
component. In addition to that, the XML schema only provides one
component for carrying OCSP related material, the OCSPResponse.
This
leads me to think that maybe in the JSON schema there is a
duplication
of components and only one of the aforementioned should be kept.
c. Clause 4.3.28 does not mention neither any component for
transporting
OCSP responses nor component for POEs. I think that an
specification of
the contents of the component for OCSP responses, and also for
the POEs
should be added.
Best regards
Juan Carlos Cruellas.
--
This publicly archived list offers a means to provide input to
the
OASIS Digital Signature Services eXtended (DSS-X) TC.
In order to verify user consent to the Feedback License terms
and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: dss-x-comment-subscribe@lists.oasis-open.org
Unsubscribe: dss-x-comment-unsubscribe@lists.oasis-open.org
List help: dss-x-comment-help@lists.oasis-open.org
List archive:
http://lists.oasis-open.org/archives/dss-x-comment/
Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x
Join OASIS: http://www.oasis-open.org/join/
|