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

[Ed Gerck <egerck@xxxxxxx>]

Stephen Kent wrote:

> Ed,
>
> >Mathematics does not provide security. The technical difference between
> >evidences of past actions (what you call NR)  based on strong crypto and,
> >for example, audit logs is none to me if Khadaffi provides both.
> >
> >Calling "evidences of past actions" by the name "non-repudiation" and
> >pretending they are more credible if based on certificates is simply arguing the
> >process when theattribution is at fault.
>
> Math does provide a basis for security; it the foundation for the public
> key crypto that underlies the focus of this WG.

Math is not self-secure -- anything you can do in math the attacker can also.  The
question is thus not whether math is the foundation for public-key algorithms.  But,
for example, who has the private-key or who/what do you trust.  By promoting
reliance on math, one promotes reliance on no differential between user and
attacker.  What you say is the same as those that simply want  "more bits" in
their keys but have their systems wide open to ActiveX controls -- they also
think that math does provide a basis for security.

But, it does not -- math is simply a tool to security.

> I'm sorry that you dislike the term "non repudiation" but we are NOT changing
> this "term of art" in this standards context.

I do not dislike the term "non-repudiation" at all.  In fact, I think that the concept
of non-repudiation can be very useful and even essential.  But when correctly used,
not as a misnomer to indicate a "NR bit" that has a PKIX description which everyone
(including you) agrees is neither necessary nor sufficient to indicate
non-repudiation.  And in math, when A is neither necessary nor sufficient to B
then this means that B exists independently of A.  In other words, non-repudiation
does not depend on the state of  the NR-bit as it is described in 2459/PKIX -- and
this is both a mathematical and a technical affirmation one should not ignore.

And, as I commented before, if the broken semantics of the NR bit  is not corrected
(and there are three options to do this -- either delete it, or define it truly as
non-repudiation, or rename and redefine it), then the market will be free to
understand the NR bit in many different and conflicting ways -- if this list exchange
in the past month can provide but a sample of them.  Which will be very much
equivalent to deleting it from the spec because "hands off that NR bit" will be
safer, also to the CAs.

So, doing what you propose is certainly one of the three options above. And,
not a bad one comparing how it was one month ago.

Cheers,

Ed Gerck