RE: Deprecate the NR bit?

[Paul Koning <pkoning@xxxxxxxxx>]

Let me see if I understand this.

Stefan says that PKIX can't, and shouldn't try to, provide a common
understanding of what NR is.  

Stefan and John both say that the semantics of the NR bit aren't
defined in PKIX, they are defined by what lives above and vary
depending on what lives above.

And David says that they have semantics for the bit but they are
different. 

So in summary, PKIX can define the bit but it can't define what it
means, and if you ask what it means you will get either no answer or a 
variable answer.

That does suggest to me the bit doesn't belong here.  Let it go into
the applications that have a defined semantic, with a name appropriate 
for its meaning, and a definition of its meaning.

	paul

>>>>> "Fillingham," == Fillingham, David W <dwfilli@missi.ncsc.mil> writes:

 Fillingham,> I agree with John and Stefan that the NR bit not be
 Fillingham,> deprecated, for the reasons they indicate, and because
 Fillingham,> the current draft DoD Certificate Policy has slightly
 Fillingham,> different requirements for certificate generation and
 Fillingham,> management for digital signature certificates that do or
 Fillingham,> do not assert the non-repudiation key usage bit.

 >> ---------- From: Linn, John[SMTP:jlinn@securitydynamics.com] Sent:
 >> Friday, August 27, 1999 12:38 PM To: 'Stefan Santesson' Cc:
 >> 'ietf-pkix@imc.org' Subject: RE: Deprecate the NR bit?
 >> 
 >> I agree with Stefan.  While an NR bit is appropriately sourced
 >> within a PKIX infrastructure (representing, in a protected manner,
 >> an assertion by an issuing CA), it's primarily consumed above the
 >> infrastructure.  Its consumption and semantics will depend on
 >> operational environments and their policies.
 >> 
 >> Consensus hasn't yet become apparent on identifying all of the
 >> characteristics which PKI-supported NR services might possess, or
 >> in organizing those characteristics into an ordering. 

> From: Stefan Santesson [mailto:stefan@accurata.se]
>
> I must admit that I have not followed everything said
> regarding the NR-bit
> on this list, but I'm not surprised that PKIX can't provide a common
> understanding on what NR is in detail.
>
> In fact I don't think PKIX should even try to do that, other
> than in the
> very general context that has already been done in RFC 2459.
>
> This does not mean that the bit is useless and should be
> deprecated. The NR
> bit belongs in a much wider context totally above the PKIX
> level. The fact
> is also that the NR-bit is used in many higher level context
> with success.
> If you would deprecate the bit you would force them to be
> non-compliant to
> PKIX.
>
> It is up to higher level of system design to provide the
> exact semantics of
> this bit, presumably in combination with some defined
> electronic signature
> policy. And then its up to the lawyers and judges to judge
> the outcome of
> this higher level context.