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

[Ed Gerck <egerck@xxxxxxx>]

Stephen Kent wrote:

> Ed Gerck wrote:
> >
> >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.
>
> I agree that the math foundation is but part of the system, and it is
> usually not the part that In would attack.  However, from a technical
> security perspective, we focus on standards that don't address all of the
> other security assurance issues.

Steve:

A short remark. In classical systems (e.g., as existing in single networks), security
is localized and your approach might work with some success.  In internets, we
deal with networks of networks -- where there is no common reporting point
and no deterministic communication path, and where no one controls both
ends of a communication channel.  That is why reliance on math (even
asymmetric crypto) falls short for internet security -- so that protocols need to
provide the "glue" for math to work.  This glue is simply missing if you don't
address at least some of the other *relevant* security assurance issues -- such
as what MUST the system really do or MUST NOT really do when that NR bit
is on/off, and what do these actions mean in a language that does not have to say
that the bit name is not what the bit enables.

> >But, it does not -- math is simply a tool to security.
>
> Agreed, modulo the choice of preposition.

Math is simply a tool to [achieve] security.  This simply stresses the notion
that use of math alone does not provide for security but may help to achieve
it. So, calling it "mathematical" does not equate to "secure", even if the
crypto is asymmetric.  Who is at the other side? Is that key really from the
sender? Is the key still valid? Questions soon appear and it becomes clear that
public-key cryptography has indeed solved the problem of public-key security
but not the problems of public-key acquisition, recognition, revocation,
distribution, re-distribution, validation and, most importantly, key-binding to
an identifier and/or key-attribution to a real-world entity. Communications can
yet not be verified, neither for origin authentication nor for data-integrity --
communications can be private but not yet secure. Of course, a private
communication with a thief is not secure just because it is private.
[http://www.mcg.org.br/whycert.htm]

> Although I agreed that use of the NR bit is neither necessary nor
> sufficient, in isolation, I have also given many examples of where the bit
> of of significant benefit in an overall NR scheme.

I do not recall any use of the "NR bit" in isolation and I don't think it
would be usable either.  The statement that the NR bit is neither necessary nor
sufficient to provide NR services had no indeed no opposition in this WG --
and this statement simply proves that NR services are independent of such
NR bit, q.e.d.

In regard to your examples where the current description (and name) of the NR
bit is of  "significant benefit" in an overall NR scheme, I recall that you have not
replied when those examples were rebutted and parallel schemes could be shown
where the NR bit was significantly ambiguous and even obscure in its usage.

> I'll avoid continuing the debate of whether the PKIX notion of NR is corect or not,
> relative to your notion.

I would not say this is "my" notion or "your" notion, Steve.  This seems not to be
a case for stressing sensus, but for stressing consensus.

Cheers,

Ed Gerck