1. I have been mulling on these and there are a couple of cases that I don't
know how to qualify.
1.1 Also, the dependence on subjective assessment seems to be a problem
for some of these.
1.2 In addition, in practical situations, it seems to me the problem is
not about fixing the standard quickly but getting implementations that may
exhibit the problem to come up with important fixes by some sort of
pre-standard agreement that can be rolled into the standard as needed.
Putting together a coalition around a remedy, for something with
criticality, seems far more likely and relevant than cranking on the
standard.
2. (3) is easy. (1) is pretty easy too, since there is likely to be a
pretty good objective demonstration of the defect. Correcting or clarifying
the specification will matter for (1), but agreeing on the problem and its
repair for documents and implementations "in the wild" will have more
urgency.
3. (0) is difficult.
3.1 I am aware at least two security exposures around the use of
encryption and digest algorithms, but I would not put them in (0). They
demonstrate the absence of a worked-through threat model more than
representing an immediate public-safety matter.
3.2 In some cases, lack of accessibility provisions comes under civil
rights protections and also statutory requirements in certain domains of
use. I still bet these are in the (2-3) level, in some sense, depending on
any claims of scope, and to the extent that it is essential that provisions
be made in the format itself.
3.3 Actually, the definition, for packages, of the *required*
manifest:checksum element is a security disaster, since it basically allows
the file to be decrypted without knowing the passphrase from which the
digest is computed. (See 5.5, below. Even when the key generation
algorithm is chosen to use a different digest method, presence of the SHA1
digest considerably simplifies plaintext attack on the passphrase in order
to crack the document.) It intrigues me even more that this schema-required
attribute does not appear in the sample manifest and, I trust, not in any
actually-encrypted files. That the provision has still not been removed
says something, but I am unsure what.
3.4 [STOP THE PRESSES: I was so curious about manifest:checksum that I
used the OO.o save-with-password option on the 1.2 Package draft itself.
Surprise, surprise, not only are manifest:checksum attributes present, their
values are different for each encrypted item, even though I only entered one
pass phrase and the same digest algorithm is identified each time. This is
clearly not reproducible from any information provided in the specification
and anything understood about the "intent."]
4. For (4)-(5) there is not much to quarrel with, although I think where
there is an issue around ambiguity and understandability (especially in the
face of international translations), so we need to be careful about "trivial
for whom?"
4.1 I also think we should not collapse skilled-in-the-art and
skilled-in-language and also skilled-in-understanding-specifications.
4.2 It's my experience that those who are skilled-in-the-art of
specification with regard to a particular subject matter have a heightened
sensitivity to ambiguity and under-specification as well as sharpened
recognition of careless use of their specialty nomenclature and concepts.
If we are not those experts, we should not be saying "oh, the ones skilled
in the art will understand this precisely."
4.3 Furthermore, a specification for one audience that depends on skills
of an allied art needs to make that dependency very clear so that (1) those
not so specialized are led to the required resources (2) those not so
specialized are led to recognize that they require specialized knowledge,
and (3) those who are so specialized recognize that the dependency is
precisely-expressed.
5. (2) is the most problematic for me. The difficulty I see is over how one
ascertains intention on the parts of the standard writers and whether tacit
understanding is a reliable quality.
5.1 I suggest that any time it is necessary to inspect implementations,
and the standard does not say implementation-determined, that should be an
automatic (2).
5.2 Also, when a comment claims that the intention is not apparent, I
think we should accept that statement on face value, at least provisionally,
until there is enough deeper analysis to understand what the disconnect is.
There is probably some remedy required, even if it is not the one the
commenter suggests.
5.3 For (2), the lack of a measurable quality is particularly
troublesome. I don't think "likelihood of misapplication" is any help here.
What does it mean to "misapply" a standard? Is that the appropriate
criterion?
5.4 Here's an example. There are places where the specification provides
that digest algorithms to be applied in the handling of pass phrases that
are used for various document-protection purposes. The referenced
specifications for those digest algorithms (to the extent references are
provided) simply describe the input as a string of bits in storage.
Clearly, for the algorithm to work in a given application, there needs to be
an agreement on how that string of bits is coded before the digest algorithm
is applied, lest the result not be reproducible. Nowhere in the ODF
specifications is this missing piece of agreement specified. (I suspect the
same is true for many other applications that appeal to the digest algorithm
specifications.) In an international setting, this is a particularly
troubling situation, since there is a very big difference even when assuming
single-character octets (e.g., 7-bit ASCII versus ISO 8859-1) or
multi-byte/double-byte characters (coded in SHIFT-JIS versus UTF-8 or UTF-16
or UTF-32). There are, for complex languages, normalization rules that must
be applied as well to ensure that the "same" composed/combined characters
lead to the same encoding before the digest algorithm is applied. Finally,
there are white-space rules and other rules to be considered in order to
have the digest be reproducible among different products working with the
same document, with different default language settings, platform defaults,
etc., etc. I'd love to see how the intent is to be understood here.
5.5 Here's another on the same pet topic. The ODF-specific encryption
technique for package items applies a key derivation and encryption process
to each encrypted item in the package, and the manifest entry for each such
item contains the necessary parameters by which the key derivation can be
repeated and decryption accomplished. Nowhere is it required that all of
these encryptions start with the same pass phrase. In fact, it is
conceivable that a different pass phrase is used for each of the
encryptions. It is highly unlikely that is the case in any current
implementations, since it makes no sense to suppose that an user who
requests encryption and supplies a pass phrase (of the kind wondered about
in 5.4, above) has any idea which parts of the ODF package will be encrypted
as a result, and an user who knows or has been conveyed that pass phrase
certainly doesn't know which parts of the package have been encrypted. I
would claim, in this case, after having invested considerable study to this
part of the specification and the sample manifest (the only place to learn
certain things), but without even bothering to try it with OO.o, that there
is a single pass phrase and it (appropriately-digested) is used as part of
the key-generation procedure for each encrypted item in the package. You
could convince me that this single pass-phrase, symmetric key-derivation
procedure is "the way the standard is intended." I'm not sure what the
value of leaving this underspecified is other than to make developers work
harder to figure out what only makes sense, after verifying that with an
implementation or two. [Addendum: I have checked this with OO.o and have
found a baffling aspect to it, noted in 3.4, above.]
- Dennis
Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com]
Sent: Thursday, March 12, 2009 10:01
To: office@lists.oasis-open.org
Subject: [office] Defect severity
It is probably worth getting to a common understanding of defects and how
much we're going to commit to resolving for ODF 1.2. OASIS doesn't
mandate any particular taxonomy for defects, and ISO/IEC has only a
technical/editorial two-bucket classification system which is a bit too
course for our needs.
I'll toss out this classification scheme for defects, a scale of 6
severity levels:
0. Defects which could cause the standard to be used in ways which are
unsafe to persons or the environment, or which violate civil or human
rights. For example, defects related to privacy, safety tolerance,
encryption, etc.
1. Defects whose existence would likely cause direct business or financial
loss to users of the standard. For example, spreadsheet financial
functions which are defined incorrectly,
2. Defects which prevent the standard from being used in the way which it
was intended. This severity level requires a likelihood of misapplication
of the standard, not merely a remote potential for misapplication.
3. Defects which violate drafting requirements from OASIS or ISO/IEC. For
example, lack of a scope statement or misuse of control vocabulary.
4. De minimis defects , i.e., trivial defects, hardly worth fixing.
Obviously, even the smallest defect related to health and safety must be
given considerable regard. However, a typographical error where the
meaning is otherwise clear from the context may be considered trivial.
Similarly, a grammatical error which does not change the meaning of a
clause or a terminology question where the meaning is clear and
unambiguous to a person having ordinary skill in the art to which the
clause most closely pertains, i.e., 2D vector graphics.
5. Matters of personal style. For example, a request to use "do not"
rather than the contraction "don't". These are opinions, but not defects.
Obviously the above are not rigid mathematical definitions. Most are
judgement calls. We are fortunate to have so many ODF implementors on the
TC to help us accurately evaluate defects and set appropriate severity
levels.
If something like the above meets with the TC's approval, then we could
elaborate on the definitions and agree to apply them in our decision
making.
For example, we could say that defects reported on published ODF standards
would be processed as follows:
Severity 0-1 would trigger the TC to immediately prepare an errata
document.
Severity 2 would be resolved in the next-scheduled errata document.
Severity 3-4 will be resolved in the next technical revision of the ODF
standard, i.e., pushed into the next version.
We could also agree to treat this severity levels differently depending on
where we are in the drafting process for ODF 1.2. For example, once we
send out for public review, we might commit to fix all defects of severity
0-3, but not 4 & 5.
Let me know if this is is a useful model for thinking of defects.
-Rob
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php