Re: Options, was Re: To Be, or NR To Be ...

[Ed Gerck <egerck@xxxxxxx>]

"David P. Kemp" wrote:

> Examining assumptions, clarifying language, and producing alternative
> interpretations is valuable up to a point.  But there is a point beyond
> which it is counterproductive.  I believe that when we have disagreement
> over the meaning of words like "false" and "deny" in the context of
> PKIX, we have crossed that point.

Dave:

Once I read a very interesting paper (forgot the URL) that began with the
eye-catching (approximate) phrase "My career in crime started four years
ago".  And went on to recount that Dean's tribulation with understanding
the crime of plagiarism and intellectual theft in university circles in his
"career (in understanding that) crime" before he could write rules to curb
that crime.  Likewise, my career in crime started 13 years ago and I guess
that some participants of this WG may count even twice or more time with
careers in crime.

Thus, I guess most of us can understand what was said next in that essay,
past these opening remarks.  The Dean explained what happened after
he understood the problems and wrote the rules. They were actually
applied to a high-visibility case that went to a court of law.  But, to his
surprise, the words that he had used rather at random when trying to
describe the various cases and definitions were taken to the letter by
lawyers and technical experts from both sides, who verified and derived
all types of conclusions and lack of conclusions in negative pregnants
from words he had simply jotted down on paper and had typed.

The lesson to our own careers in crime is that, yes, digital signature standards
will be picked apart -- and not only by implementers (resulting in potential
lack of interoperation as we just look at the various interpretations of the
NR bit we see here) but also by technical experts in various areas (forensic,
auditing, etc.) and by lawyers.

In this regard, even though I have no problems with the meaning of the
words "false and "denial" (and, thus, have not crossed that point which
you hold valuable), I do have serious objections to use both together in
"falsely denying" -- as in the present text.  It is either a prejudgement or a
misplaced statement of intent.

> It appears that only you believe that the keyUsage field must be
> interpreted as an interdependent unit instead of a collection of
> independent usages,

No, not even me!  I believe they should be fully independent.  I just
remarked (in reasoning by absurdum) that following your suggestion
that none of the eight bit definitions were "necessary and sufficient"
to define them (i.e., not just the NR bit had this problem) would lead to
interpret them together as octet-codes -- which would be very
confusing since for example the semantics would be elsewhere for those
240 or so undefined octet-codes.  Thus, I was denying the usefulness
of that suggestion -- IMO, all the eight bits must be defined with
necessary and sufficient clauses.

> and that the PKIX definition is incorrect and must be rewritten.

Rewritten in IMO in the following aspects, recalling that Dean's lesson
in his career in crime:

1.  rewritten to clarify the NR bit, also with a name change if the NR bit
continues to consider "non-repudiation" as "rebuttable presumption".

2. rewritten to lint those wordings which make the key usage bits dependent
from one another, though this was not intended in the mind of those that
wrote the spec.

3. rewritten with a revision of all possible logical cases that can arise from
key usage in the spec, verifying if they are coherent with one another *and*
if they are intended.

> The straightforward interpretation is that the
> bits are independent and can be set in any combination, subject to
> domain-dependent decisions concerning security assurance, usability,
> cost, etc.

This would be desirable, IMO.  And I see your table below as a step in the
direction of item (3) above.

> If we accept your interpretation that there are 4 flavors {A,B,C,D} of
> things that can be done with a digital signature algorithm that
> "support a nonrepudiation service", and assume that there are 7 other
> things {E,F,G,H,I,J,K} that can be done with a digital signature algorithm,
> two of which are signing key certs {F} and signing CRLs {G}, then the
> straightforward interpretation says that the keyUsage bits enable the
> digital signature "things" in an independent manner:
>
> keyUsage Bit         Things that can be done with digital signatures/keys
> DS NR KS CS          A B C D E F G H I J K    (.=No, Y=Yes)
> -----------          ---------------------
> 0  0  0  0           . . . . . . . . . . .
> 0  0  0  1           . . . . . . Y . . . .
> 0  0  1  0           . . . . . Y . . . . .
> 0  0  1  1           . . . . . Y Y . . . .
> 0  1  0  0           Y Y Y Y . . . . . . .
> 0  1  0  1           Y Y Y Y . . Y . . . .
> 1  0  0  0           . . . . Y . . Y Y Y Y
> 1  1  0  0           Y Y Y Y Y . . Y Y Y Y
> 1  1  1  1           Y Y Y Y Y Y Y Y Y Y Y
>

This is fine and may need just some tweaking. For example,  for a Y that is
critical versus a Y that is not critical -- so that a "don't care" condition ("X")
would be introduced. Further,  one must also define what happens when
you have "N" above.  This may seem trivial ("a cert with N is  required")
but anyone familiar with the null theory in relational databases will recognize
why I mentioned before that there are exactly three "flavors" of "off" (i.e., of N)
besides the trivial non-existence of Y (with a total of 4 different Ns) -- and
why they all need to be taken into account or we won't be able to represent
real-world cases just by considering N to be the absence of Y (one case of N).
Again, the Dean's lesson.

> If a consensus is later reached that there is a fifth digital signature
> thing {E} which supports non-repudiation, then thing E would be
> indicated by the NR bit instead of by the DS bit.  But that does not
> mean that the settings of the DS and NR bits have somehow become
> dependent; they can still be set in any combination, and they still
> legitimately signify sets of "things" as long as the things themselves
> are not mutually exclusive. (You can't, for example, define thing "C"
> as "not-K").

Yes, and I guess you mean "as long as the things themselves are
independent" -- since "mutually exclusive" is not the only dependency
that would break the encoding system depicted in your table. Then,
you can't really define thing "C" as "not-K" because C and K  are
unrelated.

I guess the issues are becoming clearer, though (as they say) there are
three things one should not watch as they are being made: sausages,
laws and standards ;-)  They will mostly taste fine afterwards, though.

Cheers,

Ed Gerck