Subject: Re: NR Signing-Entity vs Certificate-Subject

From: "David P. Kemp" <[email-masked]>
Date: Tue, 23 Nov 1999 13:21:48 -0500 (EST)

> From: Ed Gerck <[email-masked]>

> 
> >   Should we require that whatever definition we come up with for the
> >   NR bit enable the checking of software applications for conformance
> >   with the definition?
> 
> Yes, trivially -- even if the definition cannot enable the checking of
> software applications for conformance with the definition, as the CPS
> definition does not allow, because not checking would be part of the
> definition.

If consensus were reached on this interpretation, then I would agree
with those who suggest that the bit be deprecated, because the bit has
no useful meaning if applications cannot be usefully checked for
conformance.  Requiring that applications ignore the state of the bit,
or act on the bit only in the context of some external and non-parsable
information, is not a useful conformance specification.

> May this highlight the difficulty we have, because any definition
> for the NR bit MUST rely on factors outside the scope if X.509
> if we are willing to continue to accept the only conclusion that we
> so far unanimously agreed upon:
> 
>  The NR bit is neither necessary nor sufficient to provide
>  non-repudiation services.

Public key cryptography is neither necessary nor sufficient to provide
non-repudiation services.

PKIX is neither necessary nor sufficient to provide non-repudiation
services.

V3 certs with a critical keyUsage extension are neither necessary nor
sufficient to provide non-repudiation services.

So the conclusion is unanimously agreed to because it is trivially
true.  However, it has no meaning that can be used as a basis for
further reasoning.

The question to be answered is: "are there any application actions
which depend on the state of a single bit, can be specified in a
testable manner without reference to a CPS or other non-protocol
documentation, and which are useful in support of a system which
provides non-repudiation services?"

This is a weaker criterion than requiring that a keyUsage bit be
necessary (you can't provide non-repudiation services without that bit)
and sufficient (the bit guarantees the success of non-repudiation
services).

"Weaker", however, does not equate to "worthless" or "should be
deprecated".

---

From: Ed Gerck <[email-masked]>
Date: Tue, 23 Nov 1999 11:39:03 -0800

> provides non-repudiation services?"

Dave:

This is the conclusion I tried to motivate -- unless we restrict the scope
of your previous question, any answer is OK.  This is the same malady
plaguing the NR bit, where so many things are implied in today's definition
that nothing can be asserted -- who asserts what, the CA or the subscriber,
is just the first indeterminate issue.

So, now that we agree on more than one topic ;-) is there an answer
in a more restricted scope?

Yes, most definitely IMO.  The present state-of-the-art answer is
supplied by Tom Gidin's RFC.  And, to allow such answer to be
further developed there are only a few changes needed when
transposing X.509 to PKIX. The changes are:

1. to lint a faulty NR definition (that can be deleted and replaced
with the main one) and,

2. to avoid the lame reference "falsely" in the NR definition,
which can however be introduced in a coherent way by the
NR service itself if one desires to first qualify and then verify.

3. (Tony's) change "signing entity" to "subject in a certificate"
in the NR definition.

4. To include Tom Gidin's RFC as a suggested implementation
(experimental might be a better word) -- let's work with it
and improve it.

Thus, the NR definitions (plural) in X.509 would be unified
to read:

 nonRepudiation:  for verifying digital signatures used in providing a
 service which protects against the subject in a certificate denying
 some action.

and Tom's RFC would provide a starting basis. Note that while Tom's
RFC on non-repudiation service is compliant with this definition,
authentication service alone is not.  Which IMO shows its usefulness.

Cheers,

Ed Gerck