Subject: Re: proposed key usage text

From: [email-masked]
Date: Wed, 17 Nov 1999 16:20:25 -0500

Your proposed description of the NR bit goes: "The nonRepudiation bit
is asserted when the subject public key is used to verify digital
signatures used to provide a non-repudiation service which protects against
the signing entity falsely denying some action, excluding certificate or
CRL signing.  In the case of later conflict, a reliable third party may
determine the authenticity of the signed data."

     Mine replaces the clause starting with "which protects" by : "which
provides evidence that a given object was signed by the private key
corresponding to a given certificate which was valid at the time of
signature. "

     The issue comes down to which assertions are necessary to constitute a
non-repudiation service.  In particular, is a service still a
non-repudiation service if the principal evidence that the signer is also
the subject of the signing certificate is derived from the CA?  Also, is a
service still a non-repudiation service if there is not conclusive proof
that the signer was adequately informed of the content of the document
being signed?

          Tom Gindin

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 17 Nov 1999 15:49:55 -0800

[Tim Polk provides, from 4.2.1.3 Key Usage]:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-
   repudiation service which protects against the signing entity
   falsely denying some action, excluding certificate or CRL  signing.
   In the case of later conflict, a reliable third party may deter-
   mine the authenticity of the signed data.

Apologies to Tim Polk and Russ Housley, but this NR paragraph is easily
as wishy-washy as the original, if not more so.  Are we to suppose that
the NR bit could NOT be used to protect against a presumed signer "honestly"
denying some action?  Are we to suppose that if NR=0, then a reliable third
party is somehow precluded from determining the authenticity? 

Importantly, is the term "signing entity" intended to signify the
"ActiveSigner", the "SubscriberInFact" or the "SubscriberOfRecord"?
(See definitions below.)

It doth seem to me that the NR-bit asserts nothing of any substance.

One might as well add a "crimeFree" (CF) bit with usage specified as

  "The crimeFree bit is asserted when subject public key is used to verify
  digital signatures for transactions that are not a perpetration of fraud
  or other illegal activities.  In cases of dispute, get a good lawyer."

Of what value is this to anyone?  Would criminals seek to obtain certs
with CF=0 to avoid liability?  Would CF=1 lead you to increased trust
in the signature? For what possible reason?

[Tom writes]
>that the signer was adequately informed of the content of the document

Tom,

I agree that we need to ask about the utility of the assertion made wrt NR.
Your version seems to boil down to "a cert for this key was valid at time
of signature", which seems like an odd assertion for a CA to make before
any such signatures have been generated.
 
Since it is the CA which signs, and hence asserts the key usage binding,
one has to ask what assertion the CA can make that will make the given
certificate more "useful" to some (possibly independent) NR service.

This is a question in two parts:

  a.  What CA-asserted key usage restrictions are reasonably enforceable
      by the CA (hence worth more than simply "the CA wishes...").

  b.  What subset of (a) above are of value to any independent NR service.

In particular, is the NR service provider interested in binding a given
signature act to the: (my definitions)

1   SubscriberInFact:
        The person who presented themselves as "X" to the CA in order to
        receive a certificate that says "key owned by X"

2   SubscriberOfRecord:
        The person named as subscriber in the certificate.  That is, the
        "X" in "key owned by X"

3   ActiveSigner:
        The person actually effecting a signature to occur, in particular,
        independent of whether or not they are the "owner".

Consider that if person Y presents herself as X to a CA and obtains a
fraudulent certificate, but then has the key stolen and used by Z,
all three of the above may be different people.  In a certificate fraud,
we might expect (1) and (3) to be functionally the same, and yet it
seems that much of NR is focused upon binding the act to (2)!

Should NR=1 be the CA's vouching for a (functional) equivalence between
some two of the above?  But what CA is of use that does not intend to
assert that the "SubscriberInFact" is exactly the "SubscriberOfRecord"?

My suggested version was originally:

   "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."

But in retrospect, it suffers the same unspoken assumption that the
term "signing entity" is understood.

Additionally, the term "cognizant" may be too strong, inappropriate,
or unneeded.  Perhaps "active" or "liable" would better state the
case.

Which of these nine versions of assurance with regard to signature
generation really represent NR? 

1.   "to secure the ACTIVE role of the ActiveSigner" (that's redundant!)
2.   "to secure the ACTIVE role of the SubscriberOfRecord"
3.   "to secure the ACTIVE role of the SubscriberInFact"
4.   "to secure the LIABILITY of the ActiveSigner"
5.   "to secure the LIABILITY of the SubscriberOfRecord"
6.   "to secure the LIABILITY of the SubscriberInFact"
7.   "to secure the COGNIZANT role of the ActiveSigner"
8.   "to secure the COGNIZANT role of the SubscriberOfRecord"
9.   "to secure the COGNIZANT role of the SubscriberInFact"

I imagine that a plaintiff is only interested in liability.  Who cares
if you were cognizant, or even took an active role, if you end up liable
anyway?  The plaintiff just wants to get paid.  The question is then
"Who is the 'YOU' that the plaintiff will go after?  Is it the YOU that
pushed the signature-button?  Or the YOU that is named in the certificate?
Or the YOU that obtained a fraudulent certificate in someone elses name?

Perhaps in the end, the NR service should "secure the liability of
someone who can pay for the damages."

The more I think about it, the less it seems that a CA should be
centrally involved in NR assertions.

___tony___

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: Al Arsenault <[email-masked]>
Date: Thu, 18 Nov 1999 22:11:56 -0500

> party is somehow precluded from determining the authenticity?

AWA:  As I noted in my response to Ed Gerck, yes, I believe that in the
general case the NR bit is irrelevant if a presumed signer is "honestly"
(and has the evidence to back it up) denying some action.  Also, if NR
=0, the attorneys will do what they want, and that may include holding
the signer liable for his/her actions.  All that NR=0 means is that the
CA did not want this certificate to be used in situations where a
non-repudiation service is offered, and possibly the CA will not/cannot
support any "investigation".

> "ActiveSigner", the "SubscriberInFact" or the "SubscriberOfRecord"?

AWA:  In your terms, the "SubscriberOfRecord".  That is the "purported
signer" of the message, unless demonstrated otherwise.
 
> It doth seem to me that the NR-bit asserts nothing of any substance.

AWA:  It asserts the CA's intent.
 
<CF stuff snipped.>

>       by the CA (hence worth more than simply "the CA wishes...").

AWA:  None are "enforceable" by the CA; they're all enforced by the
applications/rest of the system.  The only thing a CA can do after
issuing the certificate is, in accordance with its CP/CPS, maintain
records (or not), and cooperate or not with later investigations.
 
> seems that much of NR is focused upon binding the act to (2)!

AWA:  As already pointed out:  If 1 <> 2, then a fraud or effor has
occurred.  The system depends on the CA preventing this; if it happens,
then all of the security of the PKI has vanished.

Assuming that 1 = 2, if 1 <> 3, then a "key compromise" (in effect) has
occurred. (Whether somebody stole the private key, or broke into the
facility and gained access to the computer on which the key was stored,
or factored a large composite number into its primes, or... is not
important.  We consider whatever happened to be a "key compromise".)
Again, in this case the security of the PKI (for at least this part of
it) is gone.  No NR or any other system in the world will protect
against this.

> assert that the "SubscriberInFact" is exactly the "SubscriberOfRecord"?

AWA:  No, NR=1 is not specifically the CA vouching for anything related
to 1-3 above.  In every certificate, the CA asserts that 1 = 2; it is up
to the rest of the system to assert that 1=3 and 2= 3 (the CA can't do
anything about that).  NR=1 is simply the CA's assertion about its
desires for the use of the certificate, and possibly an indication of
the support it will or won't provide later on.

<snip>
> centrally involved in NR assertions.

AWA:  The CA is involved in NR assertions only to the point of stating
its desires, and implicitly what it will or won't support with respect
to later investigations.  Everything else comes from outside the CA.

				Al Arsenault

-- this message represents the opinions of its author, and may or may
not represent the policies of his employer or of any other organization
with which he has a relationship

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 19 Nov 1999 11:41:08 -0800

>to later investigations.  Everything else comes from outside the CA.

Al,

This is my conclusion, as well.

I suppose one must consider the NR bit to be a potential signal to
(1) the CA upon certification, (2) the RP upon transaction acceptance,
and (3) the signer upon transaction initiation.  And one must ask how
much benefit, assurance or liability each can extract from this bit.
The bit speaks to all three, and so its definition must reveal its
significance to all three.

That is, I imagine myself an RP who wants certain transactions to
be non-repudiable (as far as possible).  So I ensure my application
only accepts NR=1 certified signatures, and I can sleep peacefully;)
Seriously, what kind of assurance does this get me?  On the CA side,
it would seem entirely dependent upon the CP statement, so in this
respect we would need to think of it as the "CA's NR policies bit".

If there were some way to ensure that the signer can only initiate
the transactions of interest through a NR-sensitive interface that
flashes colors and warning buzzers when the user signs with NR=1,
(and this could be somehow demonstrable at a later time) then of
course the RP may sleep easier.  And so, I imagine, would the signer.

Which brings me around to the signer's interest in NR=1 certificates.

As a signer, why would I want one?  (Or, is NR-phobia a good thing?)
Likely, I want one because some transaction required it.  How would
I know this?  I suppose that my "signing application" will tell me.
(NOTE:  I call it MY signing application, but would it not likely
be the RP's applet?)  I suppose when I click the button that says:

    "Try our free trial home delivery?"  <OK>

it (the applet) may search my disk for an NR cert, and complain if
one is not found.  But will it say anything at all if one IS found?
As a prudent NR-cert holder, should I want low-level auditing
running on my system at all times, just in case, and notarized on
an hourly basis?

Backing up a few steps, what is the possibility that I may request
a certificate, and not even know that it is an NR-cert?

It would seem that this NR-bit needs to speak loud and clear to all
parties, and of course this means to all implementers of code.
After all, the "Key-Usage Definitions" are first and foremost a
signal to the folks who will write the code that reads the bits.

Does the definition say enough to them?  Perhaps it does?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Al Arsenault <[email-masked]>
Date: Fri, 19 Nov 1999 17:28:50 -0500

Tony,

	Comments in line.

> respect we would need to think of it as the "CA's NR policies bit".

AWA:  I agree with this.

> course the RP may sleep easier.  And so, I imagine, would the signer.

AWA:  Again, I agree - it would make for a stronger NR system if this
could be shown to be the case.

> running on my system at all times, just in case, and notarized on

AWA:  The only reason I can think of for a signer wanting an NR cert is
because the application (s)he wants to use requires it.

I would hope that an NR system would say something about "this is the
key/certificate that I'm going to use; is this okay?"  If it did not,
but instead blindly selected keys, that might provide a ground for later
repudiation.
 
> a certificate, and not even know that it is an NR-cert?

AWA:  One would hope that your application lets you look at the contents
of the certificate you get in some nice, human-friendly format.  I
recognize that not all products do, though; it's an issue that has to be
worked with developers.  It's also, in my opinion, beyond the scope of
what PKIX can do (we don't address the way systems present information
to humans.)
 
> Does the definition say enough to them?  Perhaps it does?

AWA:  To me, it says as much as it can.  Perhaps when Tom Gindin's draft
is more complete, that will help as well.  And, potentially, the ABA
might produce some useful guidelines.  But, I don't think that we should
hold up son-of-RFC-2459 because of it. 

			Al Arsenault