Subject: Re: Subdividing the NR bit.

From: Tony Bartoletti <[email-masked]>
Date: Mon, 23 Aug 1999 18:14:32 -0700

At 12:57 PM 8/23/99 -0400, [email-masked] wrote:

[snip]

>     A particular difficulty with the current definition is the phrase "protect
>against a false denial", since one can only protect against the consequences of
>a false denial by disproving it.  While I think that requirements might be more
>productive in this particular debate than definitions, I would still replace the
>which clause in NR's definition in 2459 ("which protects against the signing
>entity falsely denying some action, excluding certificate or CRL signing") by
>something like "which permits an independent third party to determine whether
>the signing entity has or has not signed some object, excluding certificates or
>CRL's, when presented with the apparent signature at a time removed from its
>creation".  In addition to the emphasis on what amount to legal claims in the
>current definition, it's almost a triple negative (against, falsely, and
>denial).

Agreed.  Hence my suggestion was to replace the current definition with

   "The nonRepudiation bit is asserted when the subject public key is
    used to verify digital signatures within a cryptographic service
    which intends to secure the cognizant role of the signing entity
    in the signature generation, excluding certificate or CRL signing."

An improvement, but in the end still unsatisfactorily vague about
why the setting of this key should make any difference to anyone.

>     Here are my thoughts about the other repudiation techniques.
>
>     Repudiations #2 and #4 are active defenses, and require real evidence from
>the signer.  It is not our function here to ensure that a user of this service
>will win every lawsuit, just that they won't lose most of them because our
>definition was seriously inadequate.  As for repudiation #3, who set up the
>automated process?  If I set an agent to watch an auction on eBay and make bids,
>I am responsible for those bids - and if I'm remotely sane there will be a
>limit.  Repudiation #5 is another active defense, and may constitute a claim of
>fraud against the RP or of malpractice against a software provider.  Its
>threshold is probably lower than #2 and #4, though.  As for #6, it's a standard
>consumer protection claim today, and it won't disappear just because we go
>electronic.

I think the central point of all of this, is that the CA (where possible)
should not be signing an object whose terms it cannot control.  We all know
that if a certificate is fraudulently requested (say, I forge your driver's
license, know your VISA card number, whatever is required) then everything
else pretty much falls apart.  So the central role of the CA is to certify
the proper ownership of the keypair.  Beyond this, the CA could add bits
to indicate that it will archive in some manner, for whatever reason, and
may indicate many other things that are under its control.

It seems that the NR-bit is a sort of arm-waving approach to covering many
unspecified things, such as "took extra care to ascertain real ownership",
"used a cleaner-room to generate certificate", "promise to archive for a
long, long, time."  But none of this is actually promised or specified.
Instead, they abide to sign "NR=1" where its meaning is "some of all of
the above, to some degree, (see CA/CPS for details)" which does not
automate well.  Beyond this, the only mechanical use of the NR-bit is
"not to be set in conjunction with bits x, y, or z" (something they DO
have control over, if they actually read what they sign.)

As a relying party with a non-repudiation need, my interest in the
certificate qualities are going to be:

  (1) How sure can I be that the indicated key owner is accurate?
  (2) How far can I rely upon the future existence of evidences?

My need to rely upon the signer also being [willful, knowledgeable]
is acute, but can it be satisfied by a key-usage bit?  And is this
what many will expect when they see "NR"?

Until there is ubiquitous software that can tell the difference
between an Email and a Contract, reliably making the distinction
known to the operator, AND the CA has some way to ascertain at
the time of my signature that such software is in force, they
should not be providing a bit called "NR".  I prefer Ed's POA
(Proof of Authentication) bit as a more accurate description.

Better to certify the specifics under their control, and let others
decide if those specifics meet their conditions for use in their
particular sense of a non-repudiation service.

That's my two cents (and counting;)

___tony___

>Beyond this, I thought about a hierarchy of possible "repudiations"
>and wondered just what means would be needed (pre-sig and post-sig)
>to support (protect against) them:
>
>1.  Not My Key:  (argue a forged cert request)
>
>2.  Not My Usage:  (key compromised, etc.)
>
>3.  Not My Active Usage:  (Automated process made the signature)
>
>4.  Not My Willful Active Usage:  (gun to my head)
>
>5.  Not My Intent To Sign THAT:  (False Content Displayed for Signature)
>
>6.  Not My Intent To Be Bound:  (That was a Contract?)
>
>Now, in each case, imagine the NR-bit is set in the certificate, and
>the relying party duly gathers up all evidence for archive.  How much
>protection can this afford against each of these repudiations?
>
>For #1, I think that the RP should retrive and archive, from the CA,
>the photograph taken of the subscriber shaking hands with the CA President,
>a banner in the background stating "Another Fine Customer Purchases an
>NR Certificate, Public Key xxxxx, Date yyyyyy", such photograph digitally
>signed and cosigned by both the CA and subscriber keys, and perhaps
>digitally watermarked with these keys as well.  A voice-print of the
>subscriber reciting the CA/CPS verbatim would be another good piece
>of evidence to archive.

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: Stephen Kent <[email-masked]>
Date: Tue, 24 Aug 1999 10:30:55 -0400

Tony,

<snip>

>have control over, if they actually read what they sign.)

I think part of the problem here is a presumption that one can automate all
of the decision making process on the part of an RP.  I don't think this is
realistic.  A more tractable model assumes that the RP makes a value
judgement, perhaps based on reading the CPS for the CA in question, and
then decides to accept certs that contain an appropriate policy OID and
have the NR bit set to 1.  Use of the NR bit supports this use model, with
no further enchacements.  The NR is useful in this context because it
allows a user to have multiple certs under the same CA, perhaps under the
same policy OID, and to segregate these by intended use.

<snip>

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 24 Aug 1999 11:21:58 -0700

>same policy OID, and to segregate these by intended use.

Steve,

Perhaps my emphasis upon automation is misplaced (caveat, I believe the
future hold far more automation than we generally imagine.)

As long as the RP will be expected to review the CPS prior to accepting
a cert with a given subset of key-usage bits, then the NR-bit supports
this use model, as you say.

A burden, perhaps necessary, to place upon the RP.

(Aside - Does this model intentionally impede extended automation?)

And there is no particular gain in adding additional key-usage bits
(e.g., subdividing NR) if the bits do not distinguish an automatably
distinct key-usage catagory.

But does this provide sufficient guidance to the subscriber in wielding
the keys in question?  Does software need know?  Am I promising intent?
Am I declaring future denials apriori null and void?  Am I declaring
only simple cognizance of the signing act?
 
I also suppose that the main motivation behind a revision of the NR
(nomenclature or definition) comes from developers who must take their
cues from the folks that give them requirements, those folks possessing
varied/conflicting notions about the precise intent of the NR-bit setting.

The evidence of this list suggests at least some of these issues
remain a concern.

Regards,

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Aug 1999 10:01:07 -0400

Tony,

>A burden, perhaps necessary, to place upon the RP.

Note that this is not a burden that has to be endured every time one
accepts signed data in an NR context.  There is a notion of evaluating the
CPS and associated policies once, and then being able to put in place rules
that embody the value judgement made by the individual who read the
material.

>(Aside - Does this model intentionally impede extended automation?)

The model I cite does not support completely automated RP processing, but
it is consistent with the level of due diligence currently exercised on a
bilateral basis in establishing business relationships.  I've spoken to a
number of attorneys working in the PKI arena, and many of them believe that
this is a reasonable goal for PKIs, and it would offer significant
benefits, even though it does not go all the way toward automating RP
processing.

>distinct key-usage catagory.

Agreed.

>only simple cognizance of the signing act?

These distinctions can be declared through policies and specified via OIDs,
at the discretion of the CA.

>varied/conflicting notions about the precise intent of the NR-bit setting.

Hopefully we have clarified this in our discussions, and maybe we can add
some text to 2459 to codify that clarification.

Steve