NR, redux, again.

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

I agree with Ed that there have been a multiplicity of meanings 
proposed for the NR bit, and as yet no clear consensus. And that
despite the fact that the decedent horse has been well and
truly flogged.

Yet is it clear, I believe, that this matter simply MUST be resolved,
one way or the other (or the other, or the other).  Not everyone 
is going to be happy with the outcome, in all probability, but
if we can at least define the rules of the road, both subscribers
and relying parties will know whether to accept or reject a 
certificate that contains the NR bit.

The Washington meeting offers a fortuitous opportunity
to address this issue, in that the ABA Information Security committee
will have been meeting Monday - Wednesday, and an informal 
joint meeting has been proposed for Thursday.

I'm not certain what the agenda for that meeting is supposed to be --
I expect it will probably revolve around the work the ISC has been doing to 
define PKI evaluation guidelines -- but it would be a shame if we didn't
get the technologists and the attorneys together and try to hammer
out some consensus, even if it takes until midnight.

Then, once it becomes obvious that a single bit is not sufficient
to represent all of the different and useful notions that are at
least close to NR, we can them make progress in defining those
addition bits or states.

Bob

>>> Ed Gerck <egerck@nma.com> 10/31/99 01:59AM >>>


Alfred Arsenault wrote:

> Ed,
>
>         What was the "consensus" of this WG on the meaning of
> "non-repudiation"?

Wading through the messages in the archives it is possible to see that this
WG reached clear consensus on several NR items. For example, that NR is
not simply the setting of a bit -- in fact, this WG's  *unanimity* (!!) on NR was
that setting the NR-bit is neither necessary nor sufficient to define the
provision of NR services.

Based on this 100% consensual understanding,  this WG considered various
possibilities for defining the provision of NR services in a technical protocol,
and several clearly distinct modes of NR emerged -- I counted four main modes
(see archives).  Some of these NR modes were detailed in an effort by Tom Gindin
...that  is not even  *cited* in the roadmap .... with a proposed RFC... but which
was nonetheless extensively discussed in this WG and is archived at the IETF.
Can we NR that RFC? ;-))

Thus, reading the roadmap I felt a warp effect --  how could the roadmap ignore
these points of consensus and actions including a proposed RFC and, instead,
come up with an equivalence between NR and lifetime which was not discussed
at all? And, which is 100% redundant with the notion of lifetime itself -- after all,
if we want to signal a short lifetime there is a very well defined field for this in
PKIX that has nothing to do with NR.  Besides, the roadmap confused
"authenticated connection" (which authentication is ephemeral by definition and
lasts as long as the connection itself) with "signed object" (a certificate) which
can last much longer than even its signature lifetime (when providing support
for signature verification as in... NR ).

There are other problems with the new roadmap (see my previous msgs) and problems
which I did not address either --- and which IMO seriously undermine its usefulness
to reflect what this WG discussed and what the protocols are for.  Two of its key
purposes -- and that is why I suggested it should be recalled and redone.  It may be
that the new PKIX roadmap  "captured the WG's feelings from around mid '98
timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
around end '99 timeframe?

Cheers,

Ed Gerck