[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x-comment] TAB comments on: DSS Extension for Local Signature Computation Version 1.0
Hi Patrick, Thank you for the comments!The DSS-X Technical Committee will process these comments and we will respond back to you soon.
Details: Transcoded for ease of accesibility: # ----- Displaying 18 issues as at 13/Mar/14 02:18 PM. Issue Type Key Summary Description Priority Reporter Bug TAB-834 Schema - general comment"I understand the need to be able to declare profiles of schemas but what I fail to understand is why those modifications are not reflected in your schema?
That is DSSCore defines the elements you profile with a schema, yet for processing purposes, neither then DDSCore or this profile schema define the modifications you have made in prose.
Doable certainly but not exactly efficient use of XML technology to have some requirements in DSSCore schema, some in the Profile schema and some written down."
Major Patrick Durusau Bug TAB-833 4.2.1 Security Considerations "Section 4.2.1 Security Considerations reads in part: *****As the OASIS DSS protocol defined in this document is similar to the SAML protocol most of the security considerations defined in [SAMLCore] also apply to the OASIS DSS protocol.
*****Phrases of ""is similar to"" and ""most of the"" mark this section as non-normative. There is no conformance test possible for ""most of the"", etc.
" Major Patrick Durusau Bug TAB-832 3.2.2.2.2 <localsig:CorrelationID> schema fragments "3.2.2.2.2 <localsig:CorrelationID> omits a schema fragment, 3.3.1.1.3 Element <localsig:ChallengeCode> includes a schema fragment, 3.3.1.1.4 Element <localsig:ResponseCode> includes a schema fragment.See my comments in TAB-829 with regard to referencing an external schema as normative."
Major Patrick Durusau BugTAB-831 3.3.1.1 Element <dss:OptionalInputs> "new"? "3.3.1.1 Element <dss:OptionalInputs> reads in part:
***** This clause profiles the (new) elements for the OptionalInputs. ***** and, 3.3.1.1.2 Element <ds:DigestMethod> reads in part: *****The new element <ds:DigestMethod> MAY be present to specify which digest method has to be used by the Digital Signature Service.
*****But <ds:DigestMethod> occurs in DSSCore as: ""[Required on a SignRequest] [Optional on VerifyRequest]"" at 2.4.4.
The draft is using ""new"" is some sense unknown to me. Nor it is clear how this example in particular, profiles the element defined at 2.4.4 of DSSCore." Major Patrick Durusau Bug TAB-830 3.2.2.2.1 Element <dss:DocumentHash> new element? "3.2.2.2.1 Element <dss:DocumentHash> reads in part:
*****The new element <dss:DocumentHash> MUST be returned in response to a <dss:SignRequest> that specified the element <localsig:ReturnDocumentHash>.
This element uses the existing [DSSCore] type definition of <dss:DocumentHash>.
*****I looked in vain for this ""new"" element in the schema for this profile. Then I discovered it in DSSCore.
So, which is it? A new element or are you re-using DSSCore?If it is a new element, you need to either define it in the schema or incorporate it specifically from DSSCore.
Assuming use of DSSCore is a requirement for this profile, why not simply define further processing for <dss:DocumentHash> since it is already present?" Minor Patrick Durusau Bug TAB-829 3.2.1.1.2 Element <localsig:RequestDocumentHash> schema fragment - non-normative "3.2.1.1.2 restates an element definition from the schema. Under the OASIS TC Process, 2.18 (7a), external file definitions prevail over other definitions.
While I think the definition is the same in both places, it is a better practice to repeat the material as ""non-normative"" and refer the reader to the schema for the normative definition." Major Patrick Durusau Bug TAB-828 3.2 Two-Step Approach "When I read 3.2 Two-Step Approach, is it fair to say that the material immediately following 3.2 is non-normative?
That is it is a general statement or introduction to the more precise language that follows?
That is in part responsible for my error on 3.1.2 because I was assuming the text to be normative, which it wasn't.
Not a bad idea to use introductions to more technical material but it should also be labeled either as ""Introduction"" and elsewhere declare all introductions to be non-normative or eliminate the hanging paragraph (that is give this text a subsection number and declare it to be non-normative).
It is confusing when the text switches without warning between normative and non-normative text." Minor Patrick Durusau Bug TAB-827 3.1.2 Element <dss:SignResponse> ambiguity? - Please ignore, my mis-reading, answered in 3.1.2.1 "3.1.2 Element <dss:SignResponse> reads in part:
*****No new elements are defined; the <dss:SignResponse> contains either the electronic signature or the signed document according to the [DSSCore], or an error message.
*****It may be my lack of familiarity with DSSCore but when I read 3.2 Element <SignResponse> (DSSCore) I see (in part):
***** <SignatureObject>[Optional]The result signature or timestamp or, in the case of a signature being enveloped in an output document (see section 3.5.8), a pointer to the signature.
*****So does <SignatureObject> become a mandatory child element of <dss:SignResponse> in the event of an error message?
Does <SignatureObject> contain the error message? If not, where does the error message go?
BTW, ""error message"" isn't defined in this draft. This is the only reference to error message." Major Patrick Durusau Bug TAB-826 3.1.1 Element <dss:SignRequest> no reference "3.1.1 Element <dss:SignRequest> reads in part:
***** This clause profiles the <dss:SignRequest> element. *****It would be clearer to insert your DSSCore followed by a section reference, which as I noted in another issue, you do elsewhere.
The same is true for other elements you specifically profile from DSSCore so I won't repeat this comment but they too need to be fixed." Minor Patrick Durusau
Bug TAB-825 2.2 Ambiguous wording "The second paragraph of 2.2 reads: *****This profile does not fully explore the use of a RSCD (see Figure 2, ""Local and remote device for signature creation""); only the third-party solution MAY support the use of a RSCD.
*****The first part seems to say that some use of a RSCD is explored but then says only a third-party solution MAY support the use of [an] RSCD?
If this draft does not support an RSCD, then say so. It is unnecessary to speak of what third party applications may or may not do.
" Minor Patrick DurusauBug TAB-824 Citing DSSCore "When citing DSSCore, the draft sometimes specifies a specific section, 4, 4.2.2, 4.2.3, which is the preferred method because it directs the reader to a specific part of DSSCore for conformance.
However, that is not done at sections, 3.2.2.2.1, 3.2.2.1, 3.2.1.1.3, 3.1.2, 2.3 (second reference, first one truly a general reference), 2.2 (isn't that a specific section?)" Minor Patrick Durusau Bug TAB-823 Digital signature format definition unclear "1.1 Terminology reads in part:
*****A digital signature value is a basic form of a signature, usually in the form of a PKCS#1 format ([PKCS#1 version 2.1] or [PKCS#1 version 2.2]).
***** The term ""usually"" is troubling.Did you mean to say that a digital signature always has the format specified by PKCS#1 format ([PKCS#1 version 2.1] or [PKCS#1 version 2.2]) or that the format of a digital signature is not specified by this protocol?
I think it needs to be one or the other. Otherwise, interoperability will suffer." Major Patrick Durusau Bug TAB-822 Spelling - functionalitity "In Section 2.2 Scope, first sentence,
""This profile extends the OASIS DSS signing functionalitiy(sic)"" Should read:""This profile extends the OASIS DSS signing functionality""" Trivial Patrick Durusau Bug TAB-821 RFC219 keywords in non-normative text "In sections 1.6 and 1.7, both marked as ""(non-normative)"", RFC2119 keywords appear as follows:
MUST - 4x must - 4x (not in uppercase but appear to be used as keywords) should - 2x (not in uppercase but appear to be used as keywords) MAY - 2xRFC2119 keywords, since they signal requirements for implementers, MUST NOT occur in non-normative text. The reason for labeling text as ""non-normative"" is to signal the reader what follows is not meant to be a constraint on an implementation but for further explanation or illustration.
PS: When I reviewed keyword usage in the normative portion of the text, kudos for not uppercasing some cases and lowercasing others. Very clean use of keywords in the normative sections. I haven't reviewed those usages for substance but consistent usage will that task easier." Major Patrick Durusau Improvement TAB-820 There seems to be inconsistency about the mandatory / optional status of some feature. "There seems to be inconsistency about the mandatory / optional status of some feature.
In 1.7.3.3, ""An optional input <localsig:ChallengeCode> element in the SignRequest."" In some conformance levels, we also see:""(The elements <localsig:ChallengeCode> or <localsig:ResponseCode> MUST NOT be used in the OptionalInputs.)"" (By the way, parenthesis should not be used in a conformance clause: seems to imply this is not important.)
But In 3.3.1, it is said that localsig:ChallengeCode presence is MANDATORY in a sign request: ""The new element <localsig:ChallengeCode> MUST be present in the request...""
Because it seems the presence of this element depends on the conformance level/profile, the place that describes it in the specification should remain neutral (just don't use any RFC2119 keywords , or else use the most encompassing one: MAY be present...). Then in a conformance clause it is always OK to strengthen the requirement level to say MUST. But you cannot do the opposite (have a MUST in the spec body that you relax in a MAY in the conformance clause.) Now I just realize you have a MUST NOT for this feature in some conformance level. Then you cannot use even MAY in the specification body (say jin 3.3.1) because MUST NOT would violate this. So just describes the feature without any keyword in the specification body ." Major Jacques Durand Improvement TAB-819 clumsy definitions of conformance levels A-1 and A-2 "The conformance level A-1 ""stateless"" says: ""The conformance level 'Stateless' states that the Digital Signature Service cannot maintain state
information between requests.""Now, we define ""stateful"" as a level above A-1, which means it satisfies A-1 requirements. ""The conformance level 'Stateful' comprises all requirements of conformance Level A-1. In addition, the conformance level states that the Digital Signature Service is able to maintain the state between two
subsequent requests.""So it is clumsy to define A-1 using terms that will be contradicted in A-2: if A-1 ""states that the Digital Signature Service cannot maintain state"", then A-2 which includes A-1 should not contradict that statement.
I suggest to reword the definition of A-1 along:""The conformance level 'Stateless' states that the Digital Signature Service can function in a way that does not require maintaining state...""
" Minor Jacques DurandImprovement TAB-818 Notion of "conformance level" is inappropriate here, and possible combinations are unclear. "Notion of ""conformance level"" is inappropriate here, and possible combinations are unclear.
The notion of ""level"" implies some ordering, and often come containment (level 2 includes level 1, etc.). What we have here is more like ""conformance profiles"", at least between A-n, B and C.
Also the conformance clause is unclear about what are the possible combinations. It says "" A, B and C are independent of each other"". Does that imply we can have B + C? (I assume yes). But what is ""A"" since we have A-1 and A-2? Does that mean that {A-1 and A-2} are also independent from each other? (intuitively, not! but we don't know: apparently an implementation could support both stateful and stateless. So if it supports A-2 apparently is also supports A-1, so we can't really say that A-1 and A-2 are independent. The term ""A"" should not be used if all you have is A-1 and A-2. Unless you call ""A"" a conformance profile, that has several levels (1,2). The possible combinations should be give explicitly e.g. in a table (only 16 rows max...)" Major Jacques Durand Improvement TAB-817 The implementation(s) subject to the Conformance clauses (i.e. the conformance targets) are not identified. "The implementation(s) subject to the Conformance clauses (i.e. the conformance targets) are not identified. Each level of conformance seems to mix requirements for both Client and Server, and maybe for Signature-Creating Device(s). We do not know what should conform. Each conformance clause (or level) should address just one conformance target. Assuming your targets are CLient and Server, we should have one conformance clause for Client (with 4 levels, or maybe less) and one conformance clause for Server (with 4 levels, or maybe less).
" Major Jacques DurandGenerated at Thu Mar 13 14:18:06 UTC 2014 by Patrick Durusau using JIRA Enterprise Edition, Version: 3.13.5-#360.
# ----- All the best, Stefan Drees, Co-Chair of DSS-X Am 13.03.14 15:26, schrieb Patrick Durusau:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! (Entirely my fault for these comments being outside the 30 day public comment window. Apologies for the untimely submission. However, I would appreciate the TC taking them into account when preparing its next draft. Thanks!) Members of the Technical Advisory Board endeavour to comment on all 30 day public review drafts. Comments on: DSS Extension for Local Signature Computation Version 1.0 are attached. It isn't necessary to acknowledge each comment separately. A single email acknowledging this email will be sufficient. If the TC chooses to “defer” resolution of an issue to a later version, please choose Defer Issue under Available Workflow Actions (after opening the issue). When the TC has acted on these issues, I would appreciate a pointer to the TCs resolution as the TAB is tracking the resolution of comments from TAB members. Hope everyone is having a great week! Patrick - -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Co-Chair, OpenDocument Format TC (OASIS) Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300 Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIcAUAAoJEAudyeI2QFGoqGcQAK04A5wHZr51uST4D7H0LV8W Ay5W58EGu1cSWAX4bVWAqHp0ejNWSmF6pw5L/FD1SitvpFt1+XN0OODwrFPCI/tp 86N+lECIuyC7akHe877Mdx0hV6kZIJbftGlqLarox8XXJOoEOG1xI43QaNkD8Nfd Km0G45VZKmMvFmnJgJWbHjRHwNDoib7vvG4PDBdzY72iZG9job1JXn16vt+HB2+b tMXaMCfECf5oG7LUQe6oahFkgPrg2hLkjfWdHp/Ec+q+yfv/LcX5CmO8AGNCgC5R dtVXRq4eLw0YP26UXdqUvNNuvC1tod4sQM7cgkZ8LGitD+Azx2y0srtLRxKf3ZMk izyfq6KV7JDqM04O5LYcKqw7KoH1NCMgy9wCtVVfrHPje9NkzF84iMn/xeHqLaU1 SHgIk8iou2z9KyFEm7LHjUrxrwsDkBexVAaWXbkZlr9P0Vw8ULnZ1NDNqBzjpR2U gxi6a9w4gGRYu0OfrUAPioGdR1eYJcrvHkTZL9K7Jx4TuXD8oZGZCqkYKA1xgoVj rJ2dPoOVOWJ2xfIUUsi2tCnisS0uba9oGSrfFWuHXGfJPopcw0oZgioOwki4QILx YtYZqS24GQHg0pgfQ4ZS5ZPOu4wjMbR86p4DyFqB3QmxpB0Hd72WRSwOFeoSggw4 pMbPxmqTFLy/XuzrpiKe =2Id8 -----END PGP SIGNATURE----- -- 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]