Subject: Re: Non-Repudiation

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 13 Aug 1999 12:01:10 -0600

Dale,

I hope that the smart card manufacturers will in fact provide some kind of
additional protection for special purpose keys, in particular NR keys.
And since some people seem to equate a NR certificate to a "death
penalty" certificate (greatly exaggerated for effect), it might be appropriate
to paint those smart cards bright red as well.

My concern, however, is that even the German law is not adequately
distinguishing between a legitimate application of a digital signature for
authentication, either for SSL or for a casual, attribution-only, non-binding intent,
FYI type of message, vs. a contract that is intended to be legally binding.

Some of the more vocal detractors of PKI initiatives, notably Ben Wright of 
PenOp, have made a big deal about the ceremonial, due-caution issues 
that ought to be involved in a legally binding signature. Of course he is pushing 
PenOp's signature dynamics product, but what he says make some sense.

As another example of the differences that have to be made clear,
S/MIME version 3 supports the generation and transmission of 
a digitally signed message receipt, and s far as I know the intent is that 
this receipt be generated automatically.

This is an excellent example of a case where two certificates and 
two separate keys should really be provided, to differentiate between 
the case where something was generated automatically, although
on the user's behalf, vs. a willful, conscious intent type of signature.

Of course, as Ed and others have pointed out, both cases may have legal 
consequences, and may be binding in some circumstances and to some 
degree -- that's true even of an automatic, unsigned, "out of the office" reply.

Bob

>>> "Dale Gustafson" <[email-masked]> 08/13/99 10:57AM >>>
Hi Bob,

A comment or two, inline.

Best Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337 USA
612.808.2360 voice
612.890.2726 fax

Bob Jueneman wrote:

> (Warning -- longer than even Ed Gerck's missives, but worth every megabyte.)
>
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [email-masked] 
> 1-801-861-7387

[snip]

> The question, then is whether it is legitimate to INFER user intent from a particular
> key usage type, and to what extent, if any, the subscriber can be bound to such a
> an alleged "death penalty" type of certificate on the basis of some shrink-wrapped or
> "click-wrapped" contract of adhesion, based on the user's cursory acceptance of
> a CA's CPS or subscriber agreement.

[snip]

> But I disagree that CMS signedData provides nonrepudiation, except in the sense that
> Tony Bartoletti argued, i.e., authentication, UNLESS signedData REQUIRES AN
> EXPLICIT CONFIRMATION OF USER INTENT TO BE BOUND.  signedData therefore
> should NOT require a certificate with the NR bit set, since there are lots of times when
> it may be useful to provide authentication (integrity with origin) when there is absolutely
> no intent to be legally bound.  Instead, I would like to see an additional bit defined
> in CMS, perhaps called "bindingIntent."
>
> To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of
> public key cryptography into three relatively disjoint sets:
>
> 1.  Encryption.  Encryption (key agreement or key exchange, really) keys are generally
> subject to key recovery, either on behalf of the user, so he can recover stored
> encrypted data some number of years later, or on behalf of his organization, for
> reasons ranging from business continuity to investigating fraud.
>
> 2.  Authentication, using what is conventionally called a digital signature, and in
> particular using the DS key usage.  Since authentication is typically (but not always)
> used to access organizational resources and is not legally binding, authentication keys
> are typically not very sensitive to whether key recovery is permitted or not. But
> authentication may apply to a logon for a stream type of session, such as TLS, or it
> may apply to a signed message that is not intended to be legally binding. (The fact t
> hat it wasn't so intended doesn't necessarily mean that it couldn't be construed to be
> binding, however, just as an unsigned e-mail message might also be legally binding
> under the rather relaxed rules for what constitutes a signature.)
>
> 3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be
> legally bound, whether or not someone (such as the RP) bothers to go to the trouble of
> actually collecting all of the timestamps, CRLs, etc., that might make proving the validity
> of the signature considerably easier.  Since in this case it is vitally important to both the
> user and the RP that only the bona fide subscriber be able to sign such a document, business
> key recovery (and/or centralized key generation) is absolutely unacceptable, and even the
> ability to do personal key recovery may be unwise, because of the presumably greater risk
> of compromise.
>
> The reason why a mixed or unspecified use of encryption plus digital signature (much less NR)
> is such a bad idea is due to the business key recovery requirements, and in addition to the (US)
> export laws that tend to constrain the key length for encryption, but do not constrain digital
> signature key lengths, for those system that enforce such distinctions.

Smart card vendors will provide software libraries and card operating systems that include support
for a "signing only" key pair.  The distinguishing characteristic of this special type of
public/private key pair is that access to the private key component is protected by a special
"Signing Key PIN" (distinct from the User PIN that controls general user access to the card).  The
Signing Key PIN must be entered each and every time that private key is used to create a digital
signature (preferably through a protected authentication path reader device -- the PIN characters go
directly from the keyboard or PINpad to the card and do not traverse the user's desktop or laptop
machine.)

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.

> Hope this helps to clarify some of these issues.
>
> Regards,
>
> Bob

---

From: Ed Gerck <[email-masked]>
Date: Fri, 13 Aug 1999 14:48:30 -0700

> 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