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

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

> From: Tony Bartoletti <[email-masked]>
> 
> All,
> 
> Would it not be more "up front" to refer to the "signing entity"
> in the NR definition as the "certificate subject"?
> 
> Granted, in these circles it may seem to be another one of those
> "understood" things, but to common folk it might appear a bit
> disengenuous.

It would be disengenuous to refer to certificate subject.  "Signing
entity" or "keyholder" is the proper term, because an engineering
specification should not make claims it cannot enforce.

The production of ephemeral/non-ephemeral evidence is essentially all
the meaning you can cram into a single bit.  All of the rest of the
things that go into a technical/social system to support NR, including
how strongly the certified identity is bound to an entity and how
strongly the private key is bound to the same entity (not to mention
the entity's "intentions" when creating a non-ephemeral signed object,
and whether the legal system will allow the entity to reverse the
charges on a check he can prove he did not sign) are beyond the scope
of a keyUsage bit as it can be acted upon by software.

The NR bit, when 1, should enable an application to sign a non-ephemeral
object, using whatever private key corresponds to the certificate.
The NR bit, when 0, should inhibit an application from signing non-ephemeral
data (except as allowed by the cert and CRL bits).

What additional claims could be placed into a protocol standard in a
manner such that applications could be tested for conformance with the
standard?

Paul claims that this seven month discussion is not converging.  As one
step towards convergence, I pose the question:

  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?

My opinion is "yes".

---

From: Ed Gerck <[email-masked]>
Date: Tue, 23 Nov 1999 08:35:17 -0800

> specification should not make claims it cannot enforce.

Dave:

In engineering terms, the actor is the keyholder -- whoever that may be,
even more than one.  However, "signing entity" is not defined.  Further,
the keyholder is called the "certificate subject" in X.509.  So, the text
should not IMO go into a side track *in a definition*, and *there
alone in the entire spec*, introduce the "signing entity" out of X.509's
protoplasma ;-)

So, retaining "signing entity" is to retain a dangling reference.  To use
"keyholder" only makes sense in X.509 if it means the "certificate subject".
So, why not call the thing by its name?  "Certificate subject" is all we can
point our finger at -- and, if the certificate subject is NOT the only keyholder
then it is up to the certificate subject himself to deal with it, certainly not
the CA and certainly not X.509.

Any other presumption is thus IMO outside the scope of X.509 and might
belong in a CPS, but not in the engineering spec where we need to deal
with objectively qualified terms.

> the meaning you can cram into a single bit.

If the bit would be there to represent CRL lifetime.  This is not the case for the
NR bit (whatever that pesky bit may be) -- in an analogy, in order to fire a
bomb it makes sense to require an ephemeral authorization (the bomb is to
be fired now, not tomorrow)  that has a potentially ephemeral CRL listing,
but it also makes sense to require a non-repudiable authorization, one that
cannot be denied in the future (after the bomb exploded and after the
authorization expired).

Repudiation is not the same as expiration -- since repudiation of an act
negates the very existence of the act, whereas expiration only pertains
to the time window during which the act can be potentially applied.

So, the NR bit (as it is called, anyway) is there to prevent REPUDIATION
(as defined in X.509 -- the denial of some action), which has nothing to do
with LIFETIME (the time during which an authorization exists and can
be verified in a CRL).

>   NR bit enable the checking of software applications for conformance

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.

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.

even if the NR-bit would mean "non-ephemeral bit".

Cheers,

Ed Gerck

---

From: Irene Gassko <[email-masked]>
Date: Tue, 23 Nov 1999 12:11:11 -0500

>the CA and certainly not X.509.

Here is the problem with this as I see it. Suppose that an enterprise generates
(private,public) key pairs for its employees and distributes certificates
to them.
As a result of a software bug the same key was put into certs of two different
persons. One of them signed a document and now claims that the other one
is the real signer. Unless we have a provision that NR==1 requires saving
a hash of a certificate used for authentication, how do we know who it was?
In this case, a "key holder" is the only word that covers both of them. But it 
seems that unless we add the hash requirement, none of the wordings will
be helpful in a such a situation. 

Irene

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240