Subject: Re: NR bit absence, was Re: Deprecate the NR bit?

From: "David P. Kemp" <[email-masked]>
Date: Fri, 3 Sep 1999 15:44:17 -0400 (EDT)

> Date: Fri, 03 Sep 1999 11:17:36 -0700
> From: Ed Gerck <[email-masked]>
> 
> * Applications that do signature require that the key
>    signature bit be set, and ignore the rest.
> 
> which would imply that such applications would sign a message as
> NR ... just because the cert NR bit was set ... and ignored.  So, the
> application would do what was NOT requested by defaulting to an
> ACK when the NR bit is detected, instead of defaulting to an
> NACK  -- a common mistake in protocols.

This presupposes that there are "applications which sign a message as
NR" as well as "applications which sign a message as non-NR"; we are
attempting to clarify the (non-)validity of that presumption.

One possible outcome of Tom's draft is a definition of "applications
which can support NR" and "applications which use a digital signature
in a manner which does not support NR".  Under such a definition, any
application which signs a "message" falls into the first category and
would require the NR bit to be set, and an application which signs
something else would only require the DS bit.   Under this definition,
it doesn't matter if a human user saw what was signed, or intended to
sign what was signed, or performed some special ceremony to enable the
signing.  Under this definition, an automatically-generated email
receipt can support NR if signed with an NR key, because the receipt is
a signed object that is intended to be verified after the connection
over which it was sent is closed.

A digital signature used to authenticate the connection (TLS, IPSEC,
SSH, ...) over which a message was sent would not generate a signature
that was intended to be verified after the termination of the
connection (notwithstanding Peter W's position on trespassing), and
thus would require the DS bit to be set.

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 03 Sep 1999 14:09:44 -0700

>attempting to clarify the (non-)validity of that presumption.

By "signs a message as NR", I am sure Ed simply means "signs a message
with the key in question", which can subsequently be shown to have been
certified with "NR=1".  Thus the relying party, or who-knows-who, may
attempt to assert NR even though the application may not have cared.

Is this point in dispute?

According to your earlier post, a PKIX-conforming application could apply
"signature" if the signature bit is set, and ignore any possible NR-bit
setting.  This is at least a clear position.  You also write that a PKIX-
conforming CA would not issue certain combinations of key usage bits.

This is a bit vague.  Does (CA) PKIX-conformance preclude "SIG+NR" set?
And would signing applications know that a CA is PKIX-conformant by
virtue of the certificate?

Without a definitive "Yes" to both of the last questions, we could have 
"conformance all around" and still end up with the situation Ed mentions.

Of course, a signing application could simply refuse certs with both
SIG+NR set, but it would not be required of conformance.

___tony___

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, 03 Sep 1999 14:34:16 -0700

> attempting to clarify the (non-)validity of that presumption.

No, let me try to make it clearer. My argument pressuposes (as you also
do) that there are:

a. certs with the DS bit set --> they sign
b. certs with NR bit set --> they sign with NR services

and now, if we recall that the DS and NR bits are independent, to be
compliant with  RFC 2459, Section 4.2.1.3:

 "This profile does not restrict the combinations of bits that may
 be set in an instantiation of the keyUsage extension."

then two (bad) things would happen if NR absence is NOT detected
before signing:

1. a cert with NR bit set could be used by mistake for signing with NR,
since the application for (example) would not be required to pop-up a dialogue
box saying "Are you sure you want to assert non-repudiation as PKIX
has defined it?"  Of course, one may also have an automatic option (for
example, "Check this box in order to always grant NR confirmation") for
NR, but this should be for the user to decide.  So, the application MUST
provide the capability for a user to verify absence of the NR bit, or
to turn it always on if so desired, or grant it case by case with a dialogue.
To do otherwise is to allow NR services to be asserted when they are
not desired.

2. certs with the DS and the NR bit set are possible -- which means that
an application that needs to detect the DS bit but is not required to check
for absence  of the NR bit would automatically sign a message with
NR... when that  was not originally intended at all.

Thus, instead of  deleting the bit-independence rule of RFC 2459,
Section 4.2.1.3 (which rule you also agree with) in order to prevent
(2) above and then invent all sorts of allowed and forbidden
octect-codes, the solution should be to recognize, as I wrote before:

 As a general principle, compliant PKIX applications MUST require
 the absence of a particular key usage bit in certain situations, for
 example, by requiring absence of the NR bit in the key cert when the
 message to be signed by the corresponding key does not use NR
 services.

Note that this would not preclude automatic NR signing (ie, without
human intervention, as you want) since someone/something can
previously check a control option that confirms *all* messages as
NR.  Which, BTW, is much safer than having all applications blindly
and out of the box assume NR for all and every message, no? Here,
at least, someone/something had to *previously* confirm the desire
to use automatic NR.

A useful comparison can be seen in the Unix command rm.  Of course,
you can use rm if you want and then immediately delete any file with
full non-repudiation -- even if you type "rm *". But, that is why it is
possible, useful and very common to instruct the shell to use "rm -i"
whenever you type rm -- so that you have a chance to repudiate your
"death penalty" command.

BTW, the Unix command rm provides an example of technical
non-repudiation. And why one needs to be very careful with
asserting non-repudiation.  Especially, automatic non-repudiation
that runs amok out of the box without any chance for controlled
testing before -- but, the NR bug is a deadly bug ;-).. not a simple
"Error: reboot your system".

I hope to have provided above yet more reasons why the NR bit
needs to be tested for absence (or, for lack of presence -- which is
the same), besides the two that I gave before.   But, there are many
more examples of this logic, also if you go to higher orders, for
example when a NR service (whatever that might be) is triggered
by receiving a NR message from another service (in order to be
on the same level of response) -- then, you may get a NR message
from a service due to a NR fault from another one that ignored the
double presence of the DS and the NR bit and assumed it was NR.

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 03 Sep 1999 14:40:35 -0700

At 02:09 PM 9/3/99 -0700, Tony Bartoletti wrote:

Addendum:  See below.

>SIG+NR set, but it would not be required of conformance.

(Addendum):

Of course, many signing applications, I presume, require only the
private key, and care nothing of how the corresponding public key
was certified.  Hence, in the absense of a 1-to-1 relationship
between keys and certificates, and signing applications that care,
this discussion seems academic in the extreme. 

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Ed Gerck <[email-masked]>
Date: Fri, 03 Sep 1999 15:41:40 -0700

> this discussion seems academic in the extreme.

Good point. But, no, it highlights the fact that there are now TWO
signing procedures for ONE key, so that the former implict 1:1
relationship between ONE signing policy (DS) for ONE key is
no longer valid.

The 1:1 thus breaks down, and it does so quite perversely, towards
the default ACK for NR instead of a default NACK for NR -- as I
commented and exemplified in several cases.

This just highlights the fact that there is no real-world usage model
for NR in PKIX.  It is not just the NR bit definition that needs to be,
hmmm... defined.  It is the framework and the threat model that are also
missing and would need to be defined for NR to be useful.  That is
why so many PKIX NR examples are rebuked here. And, this is what
Bob Jueneman was trying to say IMO when he called for the NR bit
to be deprecated but, as I commented, this would be the worse option
and this WG  needs to start from somewhere in the NR issue.

In this regard, again, I think that Tom's RFC is the most one can have at
this moment and should be supported as a starting point.  And, one
should not close the door on detecting NR bit absence -- not even in
the name of simplicity.  Because it won't work that way and all the effort
to improve the definition of NR in PKIX would be mostly moot if NR is
to be confused at the application level.

Thus, let the applications that want to use the NR bit worry about
how that linking will be made -- perhaps, quite simply, by checking
the corresponding public-key cert that the keyholder must have a copy
of, for presence/absence of the DS and NR bits. And, later on, by
cheking the private-key cert if and when asserting DS and NR bits
is well-defined and relied upon in private-key certs.

Cheers,

Ed Gerck