Subject: RE: Deprecate the NR bit?

From: "Fillingham, David W." <[email-masked]>
Date: Fri, 27 Aug 1999 12:50:42 -0400

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

Dave Fillingham

> ----------
> From: 	Linn, John[SMTP:[email-masked]]
> Sent: 	Friday, August 27, 1999 12:38 PM
> To: 	'Stefan Santesson'
> Cc: 	[email-masked]'
> 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.  In advance of that
> process (which could be slow to converge), I think that PKIX should retain
> RFC-2459's current treatment of the bit.  I believe the binary switch is
> useful and appropriate to distinguish between classes of intended usages;
> this seems a valuable first-level indicator which may be appropriately
> complemented in future by additional, finer-grained attributes. 
> 
> --jl
> 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Friday, August 27, 1999 10:05 AM
> > To: William Flanigan; Bob Jueneman
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Deprecate the NR bit?
> > 
> > 
> > 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.
> > 
> > So I would rather deprecate this discussion within PKIX then 
> > deprecate the bit.
> > 
> > /Stefan
> > 
> > At 09:39 AM 8/27/99 -0400, William Flanigan wrote:
> > >Now, this makes sense!  What do others feel?
> > >
> > >Bob Jueneman wrote:
> > >
> > >[snip]
> > >> 
> > >> My sense is that tempers are fraying, everyone's patience 
> > is wearing
> > >> decidedly thin, and that the group is getting quite 
> > frustrated by the
> > >> fact that we haven't been able to identify any single, reasonably
> > >> simple definition for what we mean by NR.
> > >> 
> > >> If that is the case, I believe we should deprecate the NR 
> > bit within
> > >> PKIX, and then charter another WG to explore the 
> > interaction between
> > >> the certificate contents, application (as opposed to 
> > protocol) behavior,
> > >> and the business and legal issues involved with signed documents.
> > >> 
> > >> Bob
> > 
> > -------------------------------------------------------------------
> > Stefan Santesson                <[email-masked]>
> > Accurata AB                     http://www.accurata.se
> > Slagthuset                      Tel. +46-40 108588              
> > 211 20  Malmö                   Fax. +46-40 150790              
> > Sweden                        Mobile +46-70 5247799
> > 
> > PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> > -------------------------------------------------------------------
> > 
>

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 27 Aug 1999 10:27:26 -0700

RE: Deprecate the NR bit?I agree we should not deprecate the bit; there are
coherent
application contexts, including NATO X.400 secure inter-personal
and organizational messaging service,  and Authenticode. Neither
of these contexts deviate from the ISO NR definitions and intent.

We should remove any "mandatory requirement" for
use of the NR-bit in IETF std protocols/profiles, however.

Use of the NR bit should always be an operational
choice; it is helpful if operational context(s)
is/are signaled in the enhancedKeyUsage field.

Any PKIX language which implies a dependency between
use of the NR bit and any other key usage bit, should be
ignored for the purpose of compliance testing.
  -----Original Message-----
  From: Fillingham, David W. [mailto:[email-masked]]
  Sent: Friday, August 27, 1999 9:51 AM
  To: 'Stefan Santesson'; 'Linn, John'
  Cc: [email-masked]'
  Subject: RE: Deprecate the NR bit?

  Dave Fillingham

    ----------

    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.  In advance of that
    process (which could be slow to converge), I think that PKIX should
retain
    RFC-2459's current treatment of the bit.  I believe the binary switch is
    useful and appropriate to distinguish between classes of intended
usages;
    this seems a valuable first-level indicator which may be appropriately
    complemented in future by additional, finer-grained attributes.

    --jl

---

From: Paul Koning <[email-masked]>
Date: Fri, 27 Aug 1999 13:43:19 -0400

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 <[email-masked]> 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:[email-masked]] Sent:
 >> Friday, August 27, 1999 12:38 PM To: 'Stefan Santesson' Cc:
 >> [email-masked]' 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.
 >> 
 >> characteristics which PKI-supported NR services might possess, or
 >> in organizing those characteristics into an ordering.

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 27 Aug 1999 10:57:05 -0700

Peter,

I think you've struck the best compromise that can be reached

on this issue.

___tony___

At 10:27 AM 8/27/99 -0700, Peter Williams wrote: 

<excerpt>

<fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>I
agree we should not deprecate the bit; there are coherent

</color></fontfamily><bigger>  

</bigger><fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>We
should remove any "mandatory requirement" for

</color></fontfamily><bigger>  

</bigger><fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>Use
of the NR bit should always be an operational 

</color></fontfamily><bigger>  

</bigger><fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>Any
PKIX language which implies a dependency between

</color></fontfamily></excerpt>

Tony Bartoletti                                             LL

IOWA Center                                              LL LL

Lawrence Livermore National Laboratory                LL LL LL

PO Box 808, L - 089                                   LL LL LL

Livermore, CA 94551-9900                              LL LL LLLLLLLL

phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL

email: [email-masked]                                   LLLLLLLL

---

From: Ed Gerck <[email-masked]>
Date: Fri, 27 Aug 1999 11:51:43 -0700

Peter Williams wrote:
 I agree we should not deprecate the bit; there are coherentapplication contexts, including NATO X.400 secure inter-personaland organizational messaging service, and Authenticode. Neitherof these contexts deviate from the ISO NR definitions and intent.

Yes, IMO deprecating the NR bit would mean more uncertainty than
the intersubjective understanding already achieved.
 We should remove any "mandatory requirement" foruse of the NR-bit in IETF std protocols/profiles, however.

Yes, as well as (in a minimalistic edit) change "falsely denying"
to "deny" in 2459. Use of the NR bit should always be an operationalchoice; it is helpful if operational context(s)is/are signaled in the enhancedKeyUsage field.

Yes, agreed also.
 Any PKIX language which implies a dependency betweenuse of the NR bit and any other key usage bit, should beignored for the purpose of compliance testing.

Yes, and I suggest the same should be applied to all other bits
in the keyUsage field.

Cheers,

Ed Gerck

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Aug 1999 10:23:43 +0200

Paul,

X.509 (and thus also RFC 2459) does define semantics for the NR bit, up to
a certain point.

X.509 Annex B, section B1 defines the service non-repudiation as:
"Non-repudiation:  This service provides proof of the integrity and origin
of data  both in an unforgeable relationship  which can be verifed by any
third party at any time."

As RFC 2459 is a profile of X.509, this definition applies to RFC 2459 as well.

Now, this level of definition is not sufficient for all higher level
contexts but that doesn't make it useless. It just means that the full
semantics of this bit (service) must be combined with some policy
definitions (implicit or explicit). It still work fine as a switch saying
that 1)the basic definition above and 2)these higher level policy
definitions, apply to this cert.

And actually this is also the case with other key-usage bits as well as
other parts of X.509 certificates.

So what I mean is that PKIX should not go into more detail than what X.509
already does. In fact, doing so would be incompatible with X.509, and that
would be to go against the PKIX charter.

/Stefan