|
||||||||||||
OASIS Technical Committees Issue Tracker | ||||||||||||
Displaying 18 issues as at 13/Mar/14 02:18 PM. | ||||||||||||
Issue Type | Key | Summary | Description | Priority | Reporter | Feedback TC DSS-X (2014-04-07) | ||||||
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 | The DSSCore allows any type of Optional Input or Optional Output. The local sig profile uses some existing definitions (such as XML DSIG or some existing DSSCore elements). At the moment there is no way to specify how these existing elements (defined elsewhere) should become part of the Optional Inputs/Outputs. We have imported the DSS schema and added documentation about the elements that are used by this profile, although we can't specify their use inside the OptionalInputs or OptionaOutputs elements. | ||||||
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 | The security section is indeed not mature. For the moment it should be treated as non-normative. (Phrase added to the section title). | ||||||
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 | Schema fragment added in
3.2.2.2.2 |
||||||
Bug | TAB-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 | Although defined in DSSCore,
it's part of the DocumentHash element, but DigestMethod itself is not defined
as an OptionalInput as such in the DSSCore. Section 3.3.1.1 adjusted by removing the word 'new'. |
||||||
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 | It's new in the sense that it is
used as an Output: DSSCore only defines it as an Input. But the element
definition as such is indeed not new. The type definition exists in the DSSCore and is 'reused'. A reference to the DocumentHash has been included in the localsig schema. |
||||||
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 | Added an entry in the Section 1.3 Normative References for the XSD of localsig profile (LocalSigXSD). Added references to it at appropriate places. Added a sentence in the namespace section "The xml schema definitions present within this document are copy of the XML schema file and must be considered as informative text, and that in case of discrepancy, definitions within the XML schema prevail." | ||||||
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 | The second paragraph of 3.2 has been removed (it was informative). The two paragraphs that follow have been adjusted to specify the two mandatory steps. | ||||||
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 | Rephrased: No new elements are defined; the <dss:SignResponse> contains (in according to the [DSSCore] specification, Section 3.2) either the electronic signature or the signed document, or an error message. The dss:SignResponse extends the dss:ResponseBaseType (clause 2.11 in the Core) which may include, among other things, an error indication; in consequence, the dss:SignResponse may, if needed, include the error indication within this inherited element. Additionally, as shown in the XML schema the SignatureObject is optional. |
||||||
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 | References (ref + section number) included. | ||||||
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 Durusau | The profile does not explore the RSCD. Text changed accordingly. | ||||||
Bug | 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 | Reference removed if it is too general (for instance the second reference in Section 2.2 is not needed because the preceding paragraph states the context of the profile.) or a reference to the specific section included. | ||||||
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 | The reference to PKCS#1 has been removed. A crossreference is made to the elements of the SignatureObject within DSS. | ||||||
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 | Corrected | ||||||
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 - 2x RFC2119 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 | The capitalized words have been
changed into lowercase. Please note that Section 1.1 states: "These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense." The last sentence, as far as I understand, allows the use of lowercase 'can', 'should', etc. without being used as a specification keyword. For convinience, the wordings have been changed to avoid confusion. (In Section 1 as well.) |
||||||
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 | The different elements, such as
ChallengeCode, are used in different scenario's but they are not used in ALL
scenario' s. This profile supports these different scenario's. Consequently,
although they are optional, depending on the scenario they has to be used in
one but not in the other scenario. This can be confusing. Parenthesis have been removed. An explicit statement added to indicated the use of the particular element in the scenrio's. |
||||||
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 Durand | It is indeed a contradiction. Reference to A-1 in A-2 removed. Wording improved. | ||||||
Improvement | 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 | Wording improved. Introduced the notion of conformance profiles. | ||||||
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 Durand | Conformance Section Updated. Four profiles have been defined. Each profile has a separate sections, one for each target. | ||||||
Generated at Thu Mar 13 14:18:06 UTC 2014 by Patrick Durusau using JIRA Enterprise Edition, Version: 3.13.5-#360. |