RE: Deprecate the NR bit?

[Ron Ramsay <Ron.Ramsay@xxxxxxxxxxxxxxxxxxxx>]

Except that the NR bit cannot be added to the certificate by the
application!

I think PKIX has to say something about the NR bit even if the
interpretation is finally left to the application.

> -----Original Message-----
> From:	Paul Koning [SMTP:pkoning@xedia.com]
> Sent:	Saturday, August 28, 1999 3:43 AM
> To:	dwfilli@missi.ncsc.mil
> Cc:	stefan@accurata.se; jlinn@securitydynamics.com;
> ietf-pkix@imc.org
> Subject:	RE: Deprecate the NR bit?
> 
> 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.