Subject: Re: Non-Repudiation

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 13 Aug 1999 17:00:45 -0600

Ed,

I doubt it, too.  I just didn't beat up on Dale, the author of that paragraph, too much.

As to whether this is true of PKIX, PKIX is a specification of a protocol, not of
an application, and so you are right.

However, I tend to disagree with your characterization of all of this as a CA issue,
for other than perhaps counter-signing or witnessing the subscriber's desire to 
enable a particular key/certificate for a higher level of presumptive validity, 
I don't think the CA plays a role at all with respect to nonrepudiation.  And 
in particular, although this is just my personal opinion, I don't think that the CPS
is going to be particularly relevant in this area, since contracts are not transitive.

Even if the subscriber agrees to a contract with the CA, and even if the RP also 
contracts with the CA, that does not mean that can rely on the CAs contract with 
the subscriber. At best, the RP can hope that the CA will take on some liability
for the subscriber's actions, but fat chance.  (Insurance, however, is a different 
issue.)

I'm not sure what your returning underwear has to do with nonrepudiation, but
I have said repeatedly that "technical nonrepudiation" is NOT required in order for
a signature to be legally binding.  It may, however, make it easier to prove,
it may help to decide who has the burden of proof, and it may also shed a significant 
amount of light on whether the RP's reliance on a signature could be considered 
commercially reasonable, which has a very great deal to do with who should 
bear the risk of loss.

The question of whether or not an application actually enforces some user action,
e.g., asking a due-caution, ceremonial intent question prior to using a NR certificate
and/or setting a bit appropriately in CMS is not something that "PKIX tribunal" should 
decide, obviously.  It can be decided very quickly by expert witness testimony.

If users request such functionality, the vendors (at least this vendor) would be happy to 
oblige them, and we wouldn't dare NOT enforce such  criteria for fear of the lawsuits 
that might follow, not withstanding shrink wrapped contracts.

I'll grant that this issue (application behavior) is somewhat outside of the scope of this
WG, but we don't hesitate to say what "PKIX-compliant" products must do in other areas, 
such as the enforcement of the Critical bit, or various constraints.

I'm not trying to eliminate the concept of nonrepudiation, I'm merely trying to clarify
what it means.  And obviously, I'm not trying to make it mandatory somehow --
if someone doesn't want to use it, don't turn it on.  And if a relying party wants to be 
more consumer friendly by not requiring the amount of detail you would find in a 
mortgage contract in order to buy underwear over the Internet, then that's fine 
with me.

Just don't eliminate the ability to sell goods of vastly higher value by eliminating or failing to 
clarify an important concept.

Bob

>>> Ed Gerck <[email-masked]> 08/13/99 03:48PM >>>

Bob Jueneman wrote:

> I believe card vendor initial requirements were defined and driven by the new German Digital
> Signature laws.  Perhaps their concept of requiring the user to enter this signing key PIN (or
> perform some other concious action) for each and every digital signature, which appears to be
> motivated by a very similar set of issues, may be useful to this discussion as well.

Bob:

Sorry to harp on your text again in less than a day (since I do agree with some
of the things you put forth in this discussion), but I doubt it. A smart-card is
physically made by a company that uses a series of physical and logical
tamperproof techniques in order to precisely control *usage* of the smart-card
-- for example, by enforcing the need to enter a PIN every time before
authentication, by internally fusing a relay that makes the card dead if more
than 10 successive attempts are made with a wrong PIN, by limiting the number of
authentications possible with the card, etc.  Further, a smart-card needs to be
physically handled by a user -- you can't just pipe commands into it.

None of this is true for PKIX. So, the analogy is not illuminating and requiring
the user to do anything in PKIX is an empty promise.  All the CA can do is take
good care of what the CA signs, not what the subscriber signs.   The only place
where user actions, rights, duties, powers and liabilities can be handled is in the
CPS but the CPS is outside the scope of this WG -- in fact, outside the scope
of PKIX.

Further, contrary to a smart-card, the objects in PKIX are exchanged exclusively
among applications (not between an application and a user) -- so, how can one
even consider "user intent" or "requiring users" if:  (i) the user is not necessarily
engaged, (ii) there is no way to know if the user is engaged.

I also find that one should seriously consider the large value of repudiable
transactions in commerce, which are nonetheless legally binding.  The myth
that a contract must be non-repudiable in order to be "useful", "strong",
"valuable"  or "legally binding" is simply wrong.  Just walk into a store,
buy a product and return it back within 30 days -- "no questions asked".
AFAIK, this procedure seems to fail only for the sales of underwear -- but,
then, only if the package is open and the buying act was physically done at
the store.

So, if commerce thrives and actually favors wide reaching return policies
(i.e., favors not harassing the consumer with a non-repudiation bit of prose),
why should this WG favor the opposite and introduce PKIX as a tribunal
over its users, with language such as (2459):

 " ...to provide a non-repudiation service which protects against the signing
  entity falsely denying some action"

I think it is time to stop beating around the bush and calling examples that do
not fit at all in the case at hand or speak in lawyerly terms, and just make the
changes needed to make precise the semantics of the nonRepudiation bit.  This
responsibility falls IMO on the spec authors, but I believe this list has provided
ample examples and counterexamples.

Thus, where IMO the present PKIX spec fails is that by saying too much
the baby is going with the baby water. The NR text in 2549 (which I
quoted before) should be simply deleted IMO, as a first correcting action.

Cheers,

Ed Gerck