Subject: Re: NR -- what the real issues are, and a proposal

From: "Bob Blakley" <[email-masked]>
Date: Wed, 18 Aug 1999 16:14:53 -0500

Bob

>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.

I think this is a good choice of semantics for the key usage bit, but I have
some questions about how it's implemented.  Specifically, I want to know
by whom the bit is going to be set, and on the basis of what assurances.
You clearly don't want a CA to be creating certs. with this bit set and
handing
them out to people without prior authorization, because if such a cert and
its corresponding private key got sent to the wrong person for any reason,
it would be an instrument which could legally bind someone else.  I think
people
are going to want to have a record that they authorized the creation of such
a liability-bearing instrument -- they might even want to set the bit
themselves,
in some sense.  Perhaps we'd have to look at a two-stage process, whereby
a non-binding cert would be generated and distributed, and then a request
for a binding cert would be generated and signed using the non-binding cert...

>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.

This is the real crux of the matter and is another good suggestion, in my
view.
How we assure that the CHI has taken place is of course a theological
discussion...

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: Daniel Finkelstein <[email-masked]>
Date: Wed, 18 Aug 1999 17:31:42 -0400

> How we assure that the CHI has taken place is of course a theological

Let the lawyers worry about the law. I think we're spinning our wheels here.
Frankly, we could argue "proof" and "truth" until we're blue in the face, but
with each argument we step further away from technical/business requirements and
closer to legalspeak.

We must settle on something that is sufficient for our use (and if lucky,
extensible enough to outgrow it). While the search for perfection is noble, it is
also futile. We'll let perfection be the realm of PhD theses, and functionality
be driven by our businesses.

--
Daniel Alex Finkelstein
New Technologies
phone   212-383-2951
pager   917-427-1630
fax     212-383-3289
Securities Industry Automation Corporation

---

From: [email-masked] (Bodo Moeller)
Date: Tue, 31 Aug 1999 23:53:51 +0200 (CEST)

Bob Blakley <[email-masked]>:

>> [...]

> I think this is a good choice of semantics for the key usage bit,
> but I have some questions about how it's implemented.  [...]
> You clearly don't want a CA to be creating certs. with this bit set
> and handing them out to people without prior authorization, [...]
> I think people are going to want to have a record that they
> authorized the creation of such a liability-bearing instrument [...]

If you want to be able to convince entities other than the CA itself
that some signature made with a certified key is non-reputable (in
whatever sense) for the certificate subject, then you *must* require
the CA's keeping records of certificate applications.  If the CA
cannot provide record that indeed Bob requested a certificate for what
ostensibly is Bob's signing key, then -- assuming that we can take for
granted that neither the CA nor Bob fell victim to some attack --
others (the relying party; the judge who may have to resolve a
dispute) cannot tell if it's Bob or the CA who is trying to cheat.
In other words, then everything boils down to whether the CA is
considered trustworthy.

Of course this applies to NR bits just as well as to subject DNs --

> Perhaps we'd have to look at a two-stage process, whereby a
> non-binding cert would be generated and distributed, and then a
> request for a binding cert would be generated and signed using the
> non-binding cert...

If your are worried about a CA setting the NR bit in your certificate
against your will, then exactly the same fears should be evoked by the
scenario where the CA first creates a non-NR cert that merely has your
name in it while the key is held by someone else, and then in stage
two creates a NR cert according to the second request.  The two-stage
procedure is just overhead.

Bodo M"oller
<[email-masked]>