Re: Deprecate the NR bit?

[Ed Gerck <egerck@xxxxxxx>]

Ron Ramsay wrote:

> I disagree.

Ron:

It seems that  you tend to see things down under ;-) This is my conclusion,
the one that you disagree with:

>Ed Gerck wrote:
>>
>>Thus, I welcomed Tom's initiative and I ask you Bob to take a good hard look
>> at it and perhaps you will also agree that if this RFC is the most one can
>> have at the  moment ... then let's have it.

as one can see at the end of the message (that I have kept for reference).  But,
perhaps, it is just yet another simple confusion -- you simply confused my
argument with my conclusion. To make it clearer to distinguish them for future
reading,  you could note that the conclusion is almost always preceded by
"thus".

Cheers,

Ed Gerck


> What this group needs is a strictly technical definition of NR. This CAN
> be defined. Full NR is what has caused the fraught debate on this list.
> It CANNOT be defined.
>
> We can only provide (technical) procedures with specific outcomes that
> may support real world procedures. If we continue to debate 'full' NR I
> think we will sink without trace.
>
> I congratulate Tom for his brave first step.
>
> Ron.
>
> > -----Original Message-----
> > From: Ed Gerck [SMTP:egerck@nma.com]
> > Sent: Friday, September 03, 1999 4:23 AM
> > To:   Bob Jueneman
> > Cc:   kent@po1.bbn.com; ietf-pkix@imc.org; Tom Gindin
> > Subject:      Re: Deprecate the NR bit?
> >
> >
> >
> > Bob Jueneman wrote:
> >
> > > But even if he [Tom Gindin] comes up with a satisfactory, suitably
> > limited definition of
> > > "technical NR" or something like that, I think we have clearly
> > identified a need for additional
> > > functionality that needs to be endorsed by the CA in order to
> > constitute adequate
> > > notice. so I think additional bits will be necessary.  Whether we
> > put them in the keyUsage
> > > or the extendedKeyUsage fields, I don't care.
> >
> > In my analysis, four cases are needed at least -- and, for heaven's
> > sake, yes, four different
> > names. Instead of calling all as "NR".  We now have "technical NR",
> > "full NR", and maybe,
> > following this track we will have "waning NR",  "quasi-empty NR", etc.
> > ;-)
> >
> > Of course (paraphrasing a very well-known text), no objection can be
> > raised
> > against the self-definition of NR itself in PKIX, at most one might
> > take exception
> > to the name "non-repudiation" given to this quantity on the ground
> > that the term is
> > reserved for another, "known" concept.  But, as far as the exposition
> > of PKIX
> > clarified by Tom's proposed RFC is concerned, the term was not "known"
> > -- as it has
> > appeared for the "first time" in PKIX and then was defined in a
> > precise form in Tom's
> > proposed RFC.
> >
> > It is true however that human beings, business and law do have a
> > concept of
> > non-repudiation which differs from PKIX usage, and I think it is
> > unfortunate that
> > these ends cannot meet when I would think it would be very easy to do
> > so.  But,
> > it just adds another level of indirection.
> >
> > However, I feel that today this issue is NOT the most relevant one.
> > The most
> > relevant issue today IMO is to massage Tom's RFC to an at least
> > passing grade.
> >
> > As I see it any full treatment will have to be formally defined, not
> > just protocol
> > defined -- since protocol is not the only way of implementing it and
> > protocol
> > cannot do it alone. I already circulated a draft on the formalism to
> > two people in
> > the WG but it seems that interest is not high enough at this time.  It
> > is like talking
> > about the need to have air traffic control in 1920, it seems ;-) ..
> > just too soon.  Thus,
> > I welcomed Tom's initiative and I ask you Bob to take a good hard look
> > at it
> > and perhaps you will also agree that if this RFC is the most one can
> > have at the
> > moment ... then let's have it.
> >
> > Cheers,
> >
> > Ed Gerck

--
Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                    egerck@nma.com
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---