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

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> Date: Fri, 03 Sep 1999 11:17:36 -0700
> From: Ed Gerck <egerck@nma.com>
> 
> * 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.