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

[Stephen Kent <kent@xxxxxxx>]

Ed,
>
>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.

A response to your short remark: I've designed and developed Internet
security systems for over 20 years, before most people knew what the
Internet was.  I served on the IAB for over a decade, approving Internet
standards.  Don't presume to lecture me on what the Internet is or how to
secure communication in this environment.

As for the question of what the system MUST or MUST NOT do relative to the
NR bit, that is a local matter, in standards parlance.  What 2459 specifies
is the circumstances under which the bit should be asserted, but it imposes
no requirements on what the software operating on behalf of an RP MUST or
MUST NOT do.  That will be determined by locally-determined policies, maybe
with realtime human inputs, depending on the context. The extent to which
this can be automated will be a funciton not only of the features that we
establish in technical standards, but also the way in which CAs, users, and
RPs choose to take advantage of those features, including local laws and
personal risk tolerance.  We can't standardize much of this, certainly not
in the PKIX and IETF contexts.

<snip>

>> 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.

Yes, one could offer NR irrespective of the use of the NR bit. One could
also do so independent of the use of certs and public key crypto.  So, ...

>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.

Ed, at this point, I don't pay much attention to the lengthy messages you
are sending to the list.  Your arguments often employ terminology in a
fashion that is inconsistent with the generally accepted use in the PKI
arena, and in our standards in particular.  The arguments sometimes are
hard to follow (to understand their relevance to the technical focus of
this WG), often discuss legal issues that are outside the scope of this WG,
etc.  It's just not worth the time and effort.  Private communication with
several other folks who are normally substantative contributors to the list
confirms that they have adopted a similar response to your contributions,
i.e., they decline to devote any more time to responding to your postings.
So, don't interpret the lack of rebuttal to your extensive submissions as
acquiescence.

Steve