Re: Subdividing the NR bit.

[Tony Bartoletti <azb@xxxxxxxx>]

At 12:57 PM 8/23/99 -0400, tgindin@us.ibm.com 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: azb@llnl.gov                                   LLLLLLLL