Subject: Re: Possible solution?, was Re: Non-Repudiation

From: [email-masked]
Date: Wed, 11 Aug 1999 20:55:58 -0400

I hope it's not too presumptuous if I answer some of them myself :-)  I
have one question of my own.  Is David Kemp's suggestion that nonRepudiation
refers to a distinct class of object formats that might be signed consistent
with the recollection of members of this list, or is this quasi-legal discussion
the way to clarify the original intent?  If David's suggestion is the right one,
the set of formats for nonRepudiation would begin with PKCS-7 and CMS
SignedData, but might later grow to include XML signatures, for example.

          Tom Gindin

Ed Gerck <[email-masked]> on 08/11/99 07:42:36 PM

To:   Alfred Arsenault <[email-masked]>
cc:   Stephen Kent <[email-masked]>, Stephen Kent <[email-masked]>,
      "[email-masked]'" <[email-masked]>
Subject:  Re: Possible solution?, was Re: Non-Repudiation, was Re: Common
      misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML
      (usedto be RE: I-D      ACTION      :draft-ietf-pkix-scvp-00.txt))

Alfred:

I will reply with some questions ;-)

Alfred Arsenault wrote:

> Now, I think that most people agree that the purpose of the
> non-repudiation bit in the key usage bits field was to signal to relying
> parties that the CA intended to permit or prohibit a particular
> certificate from being used in a transaction for which the service of
> non-repudiation was provided.

1. Who is authoritative for the nonRepudiation bit state, the
CA or the subscriber?  What you say above ("the CA
intended to permit or prohibit") would still be valid if
the CA would not be authoritative for the NR bit?

2. Can a CA use PKIX in order to permit or prohibit a
particular subscriber certificate from being used in a
transaction?

[Tom Gindin]   A CA can set, and an EE can request, fields in a subscriber
certificate which restrict which transactions that certificate may be used in.
The simplest examples are values of a critical extendedKeyUsage extension.  For
that matter, a critical keyUsage containing neither digitalSignature nor
nonRepudiation cannot be used as authentication for most transactions.

3. Take a certificate with the nonRepudiation bit on
-- what can the relying-party depend upon: (i) in regard
to the certificate;  (ii) in regard to a transaction signed
with the certificate; (iii) in regard to the transaction being
repudiated?

[Tom Gindin]   (i) The relying party can assume that the certificate was
intended by the issuer to be used in some nonRepudiation transactions.  (ii) and
(iii) are the harder ones.

4   Take a certificate with the nonRepudiation bit off --
is this a negation, or a declaration of non-existence, or a
declaration of an ignored feature?  To clarify, if the NR
bit is off, does it mean that the NR is denied, or that
NR does not exist, or that NR can still be provided if so
declared elsewhere?

[Tom Gindin]   It might mean "proceed at your own risk", as well.  That would
deny NR, but not necessarily the transaction.

> How exactly the CA makes that decision is beyond the scope
> of PKIX; it's presumed that there's a CPS or some
> similar document that describes it for any given CA.

Yes, and the three questions above can also be declared beyond
the scope of PKIX -- which is my fourth question:

4. Are questions (1-3) beyond the scope of PKIX?

[Tom Gindin]   What happened to the other question 4? :-)

If you answer "Yes", please just delete this email and the following section
from 2459:

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

and I have no further comments on this matter.

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 11 Aug 1999 18:35:23 -0700

At 08:55 PM 8/11/99 -0400, [email-masked] wrote:

Apologies for the need to qualify every statement, but...

[Ed Gerck asked]
>nonRepudiation cannot be used as authentication for most transactions.

This assumes, implicitly, that the subsequent transaction was processed
through "PKIX-compliant" software.

I can certainly write non-compliant processes that would allow the
given transaction to proceed, regardless of what the CA intends.  This
may make it a bit harder for me to argue my case in court, but I doubt
by very much, given all other variables.

>(iii) are the harder ones.

I agree.  "Intended by the issuer" is all one can get, given that the
issuer has control over whether to sign a certificate or not.

>deny NR, but not necessarily the transaction.

Once again (now in reverse) if you intentionally sign a contract,
in the presence of suitable witnesses (for example), using a
key whose cert has the NR bit OFF, with the hope of being able
to later repudiate the signature, I may still be able to take you
to court and "prove" non-repudiability, if I have collected some
other suitable evidences that you were in sole possession of the
key, and expressed intent, etc., regarding the act.

So NR is NOT denied.  At most, the cert says "the CA denies".

As a general rule, assuming we trust a CA to any degree, it would be
well to remember that a certificate can never say anything more than
"the CA says X", since it is nothing more than a document signed
with their issuing key.

Regards,

___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: Ed Gerck <[email-masked]>
Date: Wed, 11 Aug 1999 19:05:39 -0700

Tom Gindin a.k.a. "<" wrote:

[snip]

> From Ed Gerck <[email-masked]> on 08/11/99 07:42:36 PM
> ....
>
> Alfred:
>

Tom:

Regarding question (1), that is why I motivated it -- in order to defer this matter
to be handled in the CPS, since either way (CA can set or EE can request) is
allowed in principle.

Regarding question  (2), IMO only the CPS can handle it in a consistent
way by policy or legal restrictions since all the CA can do is take good
care of what the CA signs, not what the subscriber signs.  The certificate
itself can be seen as a tamperproof communication channel from CA to
r-p but no assurance can be provided on how the corresponding
subscriber's private-key  is used in a transaction at the subscriber's platform.

> intended by the issuer to be used in some nonRepudiation transactions.

;-) or, intended by the subscriber? Or, by both? Or, by none of them (say,
by an intervening insurance agent)? Or, simply, the nonRepudiation bit on
means that the subscriber could not change it during Certificate Request
(as no subscriber can, BTW) -- so that the subscriber is not liable (perhaps,
just mildly negligent).

> (ii) and (iii) are the harder ones.
>

"proceed at your own risk" is the second option I offered, denying
NR.  In all *three* options for "bit off" (negation, non-existence,
ignore) I did not include any qualifier for the transaction itself -- which
remains authenticated (after all, it *was* signed).  So, denying NR has
nothing to with denying the transaction -- and, in fact, may be much safer
to the signer even if the signer intends to never repudiate the transaction.

> 4. Are questions (1-3) beyond the scope of PKIX?

Please correct my message to:

5. Are questions (1-4) beyond the scope of PKIX?

Cheers,

Ed Gerck