Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor PKIX. (Was: RE:ASN.1vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))

From: "Aram Perez" <[email-masked]>
Date: Wed, 04 Aug 1999 10:12:14 -0700

Ed Gerck wrote:

> Stephen Kent wrote:
[snip]
> 
>> This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
>> Signatures. The technical definition of NR that we use comes from ISO
>> 7498-2.  Paraphrasing (since I don't have the spec in front of me on this
>> plane flight), NR is defined as a security service employed to prevent a
>> party in a communication from later denying having participated in the
>> communication.   Time is not mentioned explicitly, but because the
>> communication took place at some time, it is an implied component of NR.
>
> Steve, so many things are "implied" -- that one needs to be careful not
> to have "implied security" as well.  What I mean is that we need clear
> and well-defined concepts, if we want clear results. If NR is "to prevent
> a party in a communication from later denying having participated in the
> communication" as you say above then we must immediatley agree that NR
> does not exist and never will.

I totally agree with Ed. I can always deny (a.k.a. repudiate) participating
in a communication. And, at least in the US where I am presumed innocent
until proven guilty, it would be up to the other party to prove that I did
participate. However, this does not preclude me from agreeing to a
non-repudiation clause in a contract where I agree that my digital signature
signifies my participation in a communication.

[snip]
>
> Thus, all I am saying is that the definition of NR being used in this WG
> is wrong and I don't care who defined it and where you based it -- while
> I also point out that ISO is a private organization, which definitions can
> be used or not and that none of them is some sort of "international treaty"
> or even "standard" or "fact".

Again Ed is correct, the definition of NR is wrong. Quoting for the PKIX
Roadmap:

     "Security depends
      on all parts of the  certificate-using SYSTEM, including but not
      limited to: physical security of the place the computer resides;
      personnel security (i.e., the trustworthiness of the people who
      actually develop, install, run, and maintain the system); the
      security provided by the operating system on which the private key
      is used; and the security provided the CA.  A failure in any one
      of these areas can cause the entire system security to fail."

How can setting the NR bit ensure that there isn't a "failure in any one of
those areas"?

[snip]

Regards,
Aram Perez

---

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

>signifies my participation in a communication.

[tony-snip]

>How can setting the NR bit ensure that there isn't a "failure in any one of

Radically paraphrasing (I believe it was Steven Kent,) all that the
"non-repudiation bit" signifies is that, as far as the CA is concerned,
they assent to the use of a so-certified-key's signature in support of
a potential non-repudiation claim.

How far does that get anyone?  Not far. It is a bit like you want to
climb Mt. Everest, and to "support you" in this endeavor, I announce
that I will not stand in your way.

___tony___

P.S.  Has this thread been re-subjected enough times?  Reading it,
I feel a bit like an archaeologist.

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, 04 Aug 1999 12:52:15 -0700

Tony Bartoletti wrote:

> ... all that the

It is not "assent" because if the CA would assume this role or even
merely imply it, then that power to assent or co-assent to a key
usage by the subscriber would make the CA liable or co-liable for
that key's usage.

> that I will not stand in your way.

But... "I will charge for not standing in your way".  What this means is that
CAs now have two  "products": one with NR and another without NR--
and both are "standards-compliant".  The product without NR costs X and
warrants Z. The product with NR costs Y but also warrants Z, where
Y > X.  In other words, a "value-add" without the value ;-)

The subscriber not only pays more (ie, needs at least two certs) but has
now a larger liability.  Mere usage of that private-key NR cert (say, by a
hacker that snatched the private-key NR cert and broke the password)
at any time will imply NR.  Which is a good thing since such liability
argument can easily be defeated in law -- since the subscriber had no
power to deny it and was at the mercy of uncontrollable events (hackers
are, knowingly, uncontrollable and can penetrate even high-security
government networks).

But, some believe that the "non-repudiation bit" feature can still be justified,
even if not by reason nor by cost, by the "death penalty syndrome".  By
raising the stakes (ie, "be extra careful with that NR cert now, because any
misuse will haunt you")  the logic is that the "probability of occurrence" will
decrease.  In other words, the notion that there is somewhere a "law of
equal risks" that  says that the product of "value at stake" times "probability
of occurence" is constant -- so that increasing the "value at stake" decreases
the occurrence.  The logical flaw behind this is that such "law" does not exist
-- especially here, because the "value at stake" is not borne by the hacker.

BTW, I recall one friend that described a patrolman's rendering of the
"death penaly syndrome" in a true story -- which may further illustrate
the point.  Bill got a speeding ticket, and had to attend one of those
"driving school" classes, put on by a former highway patrolman, who
bemoaned the fact that "everyone" seems to speed, 5 or 10 MPH
above the posted limit.  Indeed, the instructor thought that even the
posted limits are too high and asked, "what if the penalty for
speeding, even 1 MPH above the limit, were punishable by death?"

He expected the answer "No one would dare speed."

But Bill's answer was that within a month or so, the Highway Patrol would be
disbanded, or at least precluded from issuing any tickets for speeding.
The same will perhaps happen with those CAs that issue "death penalty
certs".

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 1999 12:13:32 -0400

Ed & Aram,

>signifies my participation in a communication.

Sorry that you both disagree with the standard (technical) definition of
NR, but that's what were sticking with in this WG.

>How can setting the NR bit ensure that there isn't a "failure in any one of

Setting the NR bit does not ensure anything, and I don';t think anyone said
it did. It is a declaration of intent with respect to key usage, by a CA.
It is a component of the overall set of evidence that a RP would collect to
help counter an attempt at repudiation by the subject of the certificate.
That's all.

steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 1999 12:19:48 -0400

Ed,

<snip>

>are, knowingly, uncontrollable and can penetrate even high-security

Your analysis seems to assume that all CAs are TTPs, selling a service.
Another model is that organizations act as their own CAs, issuing certs to
employees, customers, etc., in which case the preceeding analysis is
inapplicable.

<snip>

steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 06 Aug 1999 09:07:56 +0200

Steve,

I would like to point out that the definition you are refering to is
only applicable to the OSI model (it is in part 2 of the OSI model).
Since then ISO has been considering NR on a broader scale and has
produced the NR framework (ISO 10181-4) where the scope of NR has
been enlarged.

In the introduction the text says:

"The goal of the NR service is to collect, maintain, make available
and validate irrefutable evidence concerning a claimed event or
action in order to resolve disputes about the occurence of the event
or action".

The event or action can be a communication, but does not need to be.

I believe that we are implicitely using that concept in the WG.

Denis

---

From: Ed Gerck <[email-masked]>
Date: Fri, 06 Aug 1999 06:21:57 -0700

> I believe that we are implicitely using that concept in the WG.

Dennis and WG friends:

I believe you are correct and that is why the approach is wrong -- because
this WG has been implictly using a concept which cannot stand even outside
a court of law.  I also believe that, eventually, the ISO authors will come
to realize that there is no such a thing as "irrefutable evidence" and
thus such a thing cannot be 'made available' or 'validated' either.  But, again,
since ISO is a private company, they may never do so.  However, I see
no need for this WG to be bound by anything that ISO declares, or even try
to change what ISO declares -- since ISO is simply a private company that
is free to follow its own way.

The reported ISO NR framework is IMO amiss also in a most fundamental
aspect: that NR is *neither* a stronger authentication *nor* added data in
support of an authentication act -- but a different act altogether.

And that is why NR can exist (as I can show if needed) even in pure protocol
terms in systems that rely only on symmetrically shared secrets (contrary to
Dave's expectation that NR would not exist in such systems).  And, as Aram
exemplified and as I agree, NR can also be provided by non-protocol means.

There were also some questions raised by Steve, which I will reply in
separate but there is one which links to this msg and which I will deal with here:

 "Setting the NR bit does not ensure anything, and I don';t think anyone said
 it did. It is a declaration of intent with respect to key usage, by a CA.
 It is a component of the overall set of evidence that a RP would collect to
 help counter an attempt at repudiation by the subject of the certificate.
 That's all."

This text says that Alice (the r-p) will trust to a certain extent a NR declaration
by a CA in regard to *all* messages to be signed by a key purportedly
held by Bob.  But, who is solely responsible for the private-key's security?
Who signs each message? Who verifies each message before being sent
to Alice? Who backs and indemnifies such trust? The CA? No, it is Bob in
all counts.  So, NR is not a "bulk" property that can follow a "push" model
but one that depends on *each* message and must (as I previously
exemplified in several metrics) involve some mechanism of challenge-response.
Which again shows what is wrong with ISO's "irrefutable evidence"  NR
model -- NR cannot be produced by an "irrefutable oracle" approach.

In fact, examples have been produced here showing that the "NR bit"
in PKIX:

- is neither necessary nor sufficient for NR;

- can be very confusing to users (since it declares what it does not provide),
even to sophisticated users such as a US State government contractor;

- mislead CAs with a "standards-compliant" procedure to issue ineffectual
certificates (since NR depends on actions by the subscriber, not by the CA);

- wrongly shift the user's focus from the subscriber to the CA so that the
liability is fully reflected to the user itself (even if the CA is a company
issuing NR certs to employees as Steve asked for);

- presents a serious security risk for "death penalty certificates" as if higher
security could be achieved by increasing the value at stake (ie, with NR
certs that carry a higher risk burden if stolen by a hacker -- and, so
the notion goes, would thus be "better guarded by the subscriber");

- should be restricted to self-signed certs in PKIX;

- should be deprecated for any other use.

Cheers,

Ed Gerck

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 06 Aug 1999 15:55:56 +0200

Ed,

(text deleted)

> is free to follow its own way.

A small detail:

ISO is not a private company, but an international organization.
ANSI is a member of ISO.

Regards,

Denis

---

From: Ed Gerck <[email-masked]>
Date: Fri, 06 Aug 1999 07:45:51 -0700

> ISO is not a private company, but an international organization.

This is a common misconception, and I say this with no argumentative
intent -- ISO is neither "international" (status reserved for bodies such
as WIPO) nor "public".  As a matter of law, ISO has no special stature
whatsoever, nor do their standards.

Let me quote a comment by Tony Rutkowski, elsewhere:

------------begin quote---------
Sorry to disagree - but the International Organization for Standardization
(which is its correct name) is a PRIVATE organization.  I don't mean to
be argumentative, but this is one of my specialities, and as an official
was responsible for ISO relations.  PUBLIC organizations are those established
by treaty instruments among governmental members.  PRIVATE organizations
are those created by incorporation in some jurisdiction.  The ISO is
such a creature.  I have a copy of its "constitution" on my bookshelf
and it exists as a Swiss non-profit corporation.  The fact that national
standards bodies are its members does not make it a public corporation.
In a number of cases, those national bodies are just non-profit organizations
themselves.  The US member is ANSI - a private, non-profit corporation.

The term "international agreement" has no significance whatsoever.
It simply infers that two or more parties from different places in
the works effected some agreement.  Similarly, the "used by government"
criteria is not particularly significant, as governments use all kinds
of standards - even tcp/ip. :-)

Again, I'm not denigrating ISO.  It's just that as a matter of law,
they have no special stature whatsoever, nor do their standards.
------------end quote-----------

Further info in [http://www.iso.ch/infoe/intro.htm#What is ISO]
(note: this is one of those pesky URLs that include spaces).

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Aug 1999 11:06:12 -0400

Ed,
>support of an authentication act -- but a different act altogether.

I appreciate Denis pointing out the more recent ISO definition for NR, but
I don't think it substantially detracts from my point about the differences
between technical definitions of the sort we will use in this WG vs. ones
developed by the legal community as it attempts to understand the technical
capabilities being developed.

I do agree with your observation that NR not only embodies authentication
(and integrity) but also exhibits properties that distinguish it from these
other base security services.  Still, this WG needs to discuss these
services in a technical context, not a legal one.

>exemplified and as I agree, NR can also be provided by non-protocol means.

One can, by fiat, declare any mechanism/procedure to offer NR.  In a sense,
that is what the banking community did for many years with the use of X9.9.
However, we are a technical WG and our goal, in this case, is to device
infrastructure in suppport of NR in a technical sense.

>model -- NR cannot be produced by an "irrefutable oracle" approach.

The NR bit may not be a declaration by a CA, but a passthrough of a
declaration by the subject on the intended use of the private key
corresponding to the public key in the certificate.  In some cases, CA
policy may simply says that it passes on whatever KU bits the subject
selects, or it may refuse to set some bits requested by the subject.

>- should be deprecated for any other use.

At least the latter 4 of the above statements are not true, or merely
represent your view, vs. an objective statement.  The list extensively
discussed the question of whether this bit might be confusing, and although
there was some sentiment that it might be, the concensus was to keep it. it
is neither necessary nor suff icient, but it is useful in that NOT turining
on the bit is an explciit declaration that the cert in question ought not
be used in an NR context.   Competent CAs can figure out how they wish to
use the bit as part of their policy.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 06 Aug 1999 08:57:30 -0700

Stephen Kent wrote:

> ...  it is neither necessary nor suff icient, but it is useful in that NOT turining
> be used in an NR context.

Compare with this:

 "Certificates that ascertain the non-repudiation bit MUST be issued by
 the subject."

This is what I suggested. It also implictly deprecates use of the NR bit
in those cases where it can be abused -- ie, when subject just passively
receives a NR cert from an issuer (eg, a commercial CA, a company-wide
CA, etc.), when the subject has a NR cert signed by a CA but the CA
neither backs nor indemnifies the ensuing liability; etc.

I believe this solution is a minimum change that would both improve the
protocol (by being VERY clear) and reduce confusion/fraud.

>   Competent CAs can figure out how they wish to

This is useful and is also captured by my suggestion -- CAs can
self-sign their NR CA certs and can use them as they seem fit. Also,
any issuer could do the same.

Comments?

Cheers,

Ed Gerck

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 06 Aug 1999 09:15:10 -0700

>  "Certificates that ascertain the non-repudiation bit MUST be issued by

A certificate is an inanimate object. It cannot "ascertain" anything. It 
can't "know" anything. (Yes, I've been guilty of writing about software 
that ascertains and knows, but that's a process, not a format for bits.)

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Aug 1999 13:22:37 -0400

Ed,

> "Certificates that ascertain the non-repudiation bit MUST be issued by

PKIX does not encourage issuance of certs by end-entities, so this is a
non-starter (to use a buzzword).  One might imagine text such as "A CA
SHOULD NOT issue a certificates asserting the NR key usgae bit unless it
was requested by the Subject."  However, this would preclude certain CA
policies and we don't want to do that.  So, I don't envision any change to
the text.

>any issuer could do the same.

I've generally assumed this bit would appear only in certs issued to EEs,
not to CAs.  It might be applicable for some forms of CA certs,  but I
think the semantics for certs and CRLs and OCSP messages, plus a CA's CSP,
already provide the necessary (and more definitive) info about the NR
aspects of data signed with the corresponding private keys.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 06 Aug 1999 12:36:41 -0700

Stephen Kent wrote:

> policies and we don't want to do that.

Can you pls exemplify what CA policies would be both precluded and yet useful
for NR, by following either usage above: (i) MUST; and (ii) SHOULD NOT?

> So, I don't envision any change to the text.

Is this a matter of consensus? Or, sensus?

> aspects of data signed with the corresponding private keys.

In a world where anyone can be an issuer (ie, a CA), it makes sense to
make some CAs just informative, not only affirmative.  Even in CA-centric
PKIs it may also be useful for CAs to use the NR bit but on the other way
around (since in PKIX all CAs are just as affirmative as their CPS) --
where the certSign bit could then carry more weight than today's no-warranty
and no-suitability-of-purpose disclaimers, but when combined with the
nonRepudiation bit.  In fact, one could have four combinations of reliance
modes.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Aug 1999 17:38:22 -0400

Ed,

>for NR, by following either usage above: (i) MUST; and (ii) SHOULD NOT?

A CA might offer a policy under which all users were issued signature certs
with the NR bit on, but the users don't explicitly request it in such
cases.  In general, PKIX tries to be policy neutral.

>Is this a matter of consensus? Or, sensus?

My dictionary does not contain an entry for "sensus," so I'll have to pass
on that one.

>nonRepudiation bit.  In fact, one could have four combinations of reliance

Yes, a CA can specify, in its policies, what legal assurances it associates
with use of these bits, beyond the straightforward, technical definitions
contained in 2459.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Sat, 07 Aug 1999 20:13:43 -0700

Stephen Kent wrote:

> cases.

You may recognize that such act has null validity in general -- since the subscribers
(ie, "users" as you call) would become liable for what they did not explictly request.

The main difference point may be summarized by saying that a NR certificate:

- should merely define that a NR service is available in a suitable query,

- should not attempt to provide NR, neither by declaring that the message signed
with that NR cert is non-repudiable by itself nor by declaring that the message
was signed with an intent of NR.

In other words, the NR bit should be used to denote a service, never to
provide it in any form (however weak).

This could be expressed for example as:

 1. A certificate that sets the nonRepudiation bit also implictly defines where
     the non-repudiation service is provided, which MUST be:
    1.a. by the issuer if the certificate is self-signed, or otherwise,
    1.b. as regulated in the CPS.

Which would solve IMO the power/liability problem because the subscriber
would always have the power to deny NR upon query (even if done indirectly through
a CA) -- and  the r-p would also know where to query, who is responsible for what
NR aspect (there may be many, with one entity answering for each aspect, for example
in time NR, policy NR, etc.) and in what terms, *before* deciding to rely on the liability
implied by the NR service.

Note that the text above says that the subscriber could deny NR upon query but this
only applies *before* the reliance act, not afterwards (ie, if NR is granted by the
subscriber for that act). Also note that the above mechanism eliminates the bulk NR
aspect  of the present text (which binds NR to the cert, hence to all messages signed
by that cert at all times) and allows NR to be managed per user and per message.

> In general, PKIX tries to be policy neutral.

And that is what it is not, by setting a policy for *key usage*. Which, BTW,
allows an issuer to unilaterally impose a liability upon a subscriber in regard to
all relying-parties at all times -- even if the subscriber does not request  or
know about it.

> My dictionary does not contain an entry for "sensus," so I'll have to pass

Maybe the lawyers in this list can answer that to you for a change ;-) but
"sensus" is Latin for feeling or perception -- ie, "personal sense" in English.
Not to be confused with census, neither as voting nor as censorship.

My phrase simply asked whether your position is a matter of consensus
(collective agreement) or  sensus (personal feeling).

In regard to NR you may however note that even if PKIX does not change
its text, the beans are already out.   The archived exchanges in this list and
your own bit by bit agreement that setting the nonRepudiation bit is neither
necessary nor sufficient for NR already provides IMO enough grounds for
legal and technical repudiation of the whole concept as currently stated in
the PKIX text.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Aug 1999 13:20:32 -0400

Ed,

>(ie, "users" as you call) would become liable for what they did not

Note that I said the users did not "explicitly" request that NR be turned
on.  That does not mean that the user is unaware that the bit has been
turned on, e.g., it may be described in the CPS and thus considred an
intrinsic part of having subscribed to the CA's service.

>- should merely define that a NR service is available in a suitable query,

NR is a service that requires certain actions on the part of an RP, perhaps
requiring one or more queries to various servers, but not always.

>was signed with an intent of NR.

The second piint is precisley why the bit is included, so I doubt that we
would reverse the semantics based on your suggestion.

>provide it in any form (however weak).

We agree that a bit cannot provide the service, just denote the suitability
of the certificate as a component of the service.

>    1.b. as regulated in the CPS.

Becuase multiple servers may be required to provide NR (e.g., a TSA, a
directory, etc.) I don't think "1.a" is quite right.

>implied by the NR service.

You seem to be fixated on this notion of a query involving the subscriber
or CA, neither of which is intrinsic to NR.

>all relying-parties at all times -- even if the subscriber does not

There is a difference between the spec being policy neutral and between the
spec providing a means for a cert issuer to express policy.  I think you
are confusing the two here.

>legal and technical repudiation of the whole concept as currently stated in

Thanks for sharing your opinion on this topic.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 09 Aug 1999 22:06:51 -0700

Stephen Kent wrote:

> >You may recognize that such act has null validity in general -- since the
> >subscribers (ie, "users" as you call) would become liable for what they
> >did not explictly request.
>

I noted that.  But, legislatures often disfavor provisions imposed on
consumers in standard form contracts if they believe that they will
result in unfairness. In California, for example, an agreement to conduct
a transaction electronically may not be contained in a standard form
contract that is not an electronic record, and an agreement in such a
standard form contract may not be conditioned upon an agreement
to conduct transactions electronically.  In most countries, consumer
laws also allow a period of at least seven days for a consumer to
repudiate any transaction for which the consumer was not physically
present (eg, phone orders, Internet orders).

So, if the subscriber did not explictly request that NR be turned on then
I believe that consumer law will protect consumers from this about face
overreaching by a business sector in a standard form contract that would
have no alternative and no clear voluntary adhesion, all in detriment to the
subscriber that was not physically present to even discuss the contract.

> requiring one or more queries to various servers, but not always.

I posit that challenge-response (again, not necessarily cryptographic) is
a sine qua non condition for any form of NR.  This statement can be reviewed
in my previous postings and is based on a quite general formal modeling.

> >- should not attempt to provide NR, neither by declaring that the message
> >signed with that NR cert is non-repudiable by itself nor by declaring that the
> >messagewas signed with an intent of NR.
>

Not reverse, but correct the present reversion of cause and effect. The cause
must be the subscriber right to choose to offer or deny NR in a message by
message analysis conducted by the subscriber himself as a function of risk
and cost, not the issuer's power to impose NR to all messages purportedly
from a subscriber -- in bulk and for all risks.

> of the certificate as a component of the service.

If we really agree, then we must agree that the NR bit cannot stand for
any semantics in regard to NR -- it must be merely a pointer to indicate
that a suitable NR service can be queried, which service can be denied
or granted prior to the reliance act. Not always granted as nowadays.

> > 1. A certificate that sets the nonRepudiation bit also implictly defines
> >where  the non-repudiation service is provided, which MUST be:

If the certificate is self-signed, the logic is that the issuer can define
by itself if and where such multiple servers may be required -- since
the issuer is identical to the subject and there is no division of powers
or liability between issuer and subject.  This may also preclude the need
for an extensive CPS.  In this case, the NR argument goes inductively
from the issuer to the subject because it was the subject that initially caused
the certificate to be authoritatively self-signed at one past point in time.

> >would always have the power to deny NR upon query (even if done indirectly
> >through a CA) -- and  the r-p would also know where to query, who is
> >responsible for what NR aspect (there may be many, with one entity answering
> >for each aspect, for example in time NR, policy NR, etc.) and in what terms,
> >*before* deciding to rely on the liability implied by the NR service.
>

What you tend to call NR is IMO actually an act of information control from the
CA over the subscriber -- and that is why IMO you see no need for a query
over a matter already decided.  But, if you really agree that "a [NR] bit cannot
provide the service, just denote the suitability of the certificate as a component
of the service" as you wrote above then you must also agree that the NR service
must be provided elsewhere -- ie, when a client queries a server or a list of
servers (TSAs, etc.).

The tension between these two visions is perhaps the disconnect here.  Indeed, I am
fixated (ie, focused) on the notion that NR is a liability to the subscriber and one
which the subscriber must not be powerless to deny in a message by message case.
And, more, I posit that if the subscriber is put in such a situation (ie, being powerless
to deny for each case) then it will backfire and be nullified.

> >Note that the text above says that the subscriber could deny NR upon query
> >but this only applies *before* the reliance act, not afterwards (ie, if NR is
> >granted by thesubscriber for that act). Also note that the above mechanism
> >eliminates the bulk NR aspect  of the present text (which binds NR to the cert,
> >hence to all messages signed by that cert at all times) and allows NR to be
> >managed per user and per message.
> >
> >allows an issuer to unilaterally impose a liability upon a subscriber in
> >regard to all relying-parties at all times -- even if the subscriber does not
> >request  or know about it.
>

I am saying that the present text is not policy neutral because it imposes a
NR policy.  Further, I am saying that this NR policy is not neutral because it
imposes a liability which the subscriber is powerless to control.  For example,
it is irrelevant whether the NR cert is used to sign a $50.00 or a $500.00
contract, or whether the contract includes cascading risks -- the subscriber
cannot vary its NR liability according to risk or even total its NR liability under
a certain cap warranted by insurance. Thus, the PKIX spec became the NR
policy and an unfair one. However, the "other side" can define the NR policy
it wants for the transaction -- so that the seller may end up not liable at all
for NR on the seller's obligations but the buyer may have to carry the
burden of PKIX NR. At least, until the buyer consults a lawyer ;-)

> Thanks for sharing your opinion on this topic.

I suggest that a study of Verisign's NetSure plan (for example) will
reveal further weight to the notion that a party must not offer bulk NR
or be forced into it as predicated in the PKIX spec for the nonRepudiation
bit.  There are specific needs (including virus, cascading risks, etc.) that need
to be taken into account by anyone offering to cover a risk. Which is what
NR is all about -- eg, the risk that the cert subscriber may need to repudiate
a transaction (for example, because the terms were not well understood at
03:00 AM or because a virus precluded him to read the full contract).  And,
pushing for unfair NR in the PKIX spec itself will perhaps only serve to
make CAs liable for it -- since adoption of PKIX is, after all, voluntary by
each CA.

Cheers,

Ed Gerck

---

From: Alfred Arsenault <[email-masked]>
Date: Tue, 10 Aug 1999 22:28:37 -0400

Holy criminoley!  I'm now officially dazed and confused - not to mention
hopelessly lost.  I'm trying to figure out how Sean and I are gonna
write this one up in the PKIX Roadmap, and folks, I ain't got a clue. 
What the heck is this argument about, and what is it we want to
accomplish, anyway?  

As I understand it, the situation is this:

	- some organizations wish to provide a certificate-based system that
provides the service of non-repudiation for some or all transactions.

	- other organizations wish to provide a certificate-based system  that
provides the authentication and/or confidentiality services, but does
not provide the service of non-repudiation.

These are the things that are within the scope of PKIX.  There are
obviously others who want to provide authentication, confidentiality,
and/or non-repudiation WITHOUT the use of certificates, but they're by
definition outside the scope of PKIX.

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

I think that everybody is in violent agreement that actually providing
the service of non-repudiation for any given transaction involves a lot
more than a bit in a certificate being turned on.  It requires an entire
system being well-defined and working properly, including the human
beings who have to interact with it.  However, much of this is beyond
the scope of PKIX, once again.  There's also general agreement that,
since there's little to no case law, nobody's sure what it takes to
really provide the service of non-repudiation in a certificate-based
system.  But, it's beyond the charter of this group to describe how you
do the whole thing, and to levy requirements upon anybody to actually do
it.

So, the question that seems to have arisen is:

	Does the presence of the non-repudiation bit in the key usage
	bits field do more harm than good?  That is, given that a 
	certificate with the non-repudiation bit turned on can be easily
	used in a transaction for which the service of non-repudiation
	is clearly not provided, is the bit so misleading as to be 
	harmful in a well-designed, well run system based on a PKI using
	these certificates?

If that's the question under discussion, then I've got at least a
tenuous grasp on it.  If there's more, than somebody needs to enlighten
me.

Now, we have to bear in mind that this question needs to apply across
all models of PKI that might be put onto the Internet (for which we're
supposed to be developing "standards").  That is, it should apply in the
model where we're using a trusted third party such as Verisign,
GTE-Cybertrust, or Thawte to provide services.  It should also apply in
situations where a PKI is being run entirely internal to an
organization, using software and/or hardware from folks like Entrust or
Microsoft.  It should also apply in situations that combine elements of
these two.  What is appropriate in one situation may not be appropriate
in others.

IF it's the case (and I emphasize the IF, there) that we're still trying
to answer the question above for all of the situations above, and write
a PKIX profile/successor to RFC 2459 that best supports those
situations, then I'll stick with my previous position:  the NR bit is
useful, and should be left in the PKIX profile. It's usefulness includes
at a minimum the ability for a CA to signal to a relying party that a
given certificate should NOT be used in a transaction requiring the
service of non-repudiation. 

If, however, there's something more under discussion, then I'm at a
loss, and I wish that somebody would explain it to me.

Lemme address a couple of the specific things that are causing me
confusion (large snips present below; my comments are prefaced by my
initials):

On the setting of the NR-bit without the explicit requesting of such by

> subscriber that was not physically present to even discuss the contract.

AWA:  Here's the situation:  a company builds an extranet for
communication with its subscribers/customers/contractors, using the
Internet as the transport mechanism and thus fulling under the PKIX
purview, if there is such a thing.  The company decides as a matter of
policy that all certs issued for the extranet will have the NR bit set,
because the company wishes to provide the service of non-repudiation in
its dealings.  On the paper forms, which users fill out to request
initialization into the system, users are told all about this.  Thus,
when the user later sends in the CMP or CMC request message for a
certificate, there is no indication about the setting of the NR bit. 
Such an indication is not needed.  I think that this is the case to
which Steve Kent was referring, and I think that the company's position
would have a chance of passing a court case.  Yes, in the case of public
TTP, the CA should not arbitrarily set bits without the user's being
aware of that, but remember that the public TTP is only one of the
situations we need to support.

> from a subscriber -- in bulk and for all risks.

AWA:  I'm darned if I understand why having an NR bit turned on allows
an issuer to "impose NR to all messages purportedly from a subscriber --
in bulk and for all risks."  Yes, I guess that you could design a system
such that, if the NR bit was turned on in the subject's certificate, the
RP would automatically assume that the service of non-repudiation was
being provided.  Such a system would be horribly wrong, IMNSHO (and to
use Steve's "technical term").  There are far too many other
considerations, which are far beyond the scope of PKIX.  You have to do
the system engineering, or you ain't secure.

> or granted prior to the reliance act. Not always granted as nowadays.

AWA:  I wish someone would point out the words in the PKIX documents
that say, "if the NR bit is on, then NR is automatically provided."  I
haven't found 'em, and I'd support their being changed.

> > >managed per user and per message.

AWA:  Again, if there are words in the PKIX documents that say or
strongly imply that any transaction signed by a cert with the NR bit on
automatically comes with the service of NR, then those words should be
changed.  But I haven't found them.  Hey, I've been wrong before, I'm
willing to be shown what I've overlooked.  But, honestly, I can't see
this.

> burden of PKIX NR. At least, until the buyer consults a lawyer ;-)

AWA:  I'm dazed, confused, lost, and beating my head against the wall. 
I can't find any of this in the PKIX specs. All I can find is stuff
about asserting policies (which, btw, would cover the 50 vs. 500 above,
if you wanted it to), etc., which would seem to me to imply more control
over liability, not less. 

> make CAs liable for it -- since adoption of PKIX is, after all, voluntary by

AWA:  Okay, this doesn't help.  I've read everything on Verisign's web
site I could find about NetSure(sm).  (It's really cool.  I especially
like section 2.4, which says that if anybody comes up with a factoring
attack, and can thus deduce your private key given your public one in a
feasible amount of time, it means that you didn't adequately protect
your private key from compromise and they don't have to pay.  Neat - no
matter what happens, it's your fault.)  However, I didn't see anything
in those documents that relates to this discussion.  Verisign is simply
limiting its risk by stating the obvious: IF the subject hasn't cheated,
and IF the subject doesn't cheat in the future, and IF nobody figures
out a fast way to factor large numbers, and IF a bunch of other stuff
happens, then the system should work, and if they screw up, they'll pay
(maybe).  Of course they're not accepting liability as a CA for
everything that happens in the Internet - they'd be out of business by
next month if they did.

As I understand it from talking to lawyers (and I've done far too much
of that in the last 18 months, again IMNSHO), the situation that will
someday come up will be something like this: (I'm not a lawyer; if I get
this wrong, mea culpa, mea culpa, mea maxima culpa.)

	A certificate subject and a relying party (who relied on that
certificate in carrying out some transaction) go to court over that
transaction.  The relying party asserts that, based on the certificate
in question, other evidence it possesses, and the basic qualities of the
technology, the subject is the one who did something, and thus is
liable.  The certificate subject asserts that, due to some circumstance
and based on its own evidence (possibly even including its private key,
posted on a web site as the solution to an RSA-1024 factoring
challenge), it is not liable - perhaps this is all fraudulent activity
on the part of the relying party itself.  The question is:  whom does
the court believe, and how does it arrive at that belief?
That's going to be a hard question to resolve, especially the first
couple of times.  If the RP's evidence consists solely of the subject's
cert with the NR bit set, the RP is most likely going to lose.  If, on
the other hand, the subject shows that its cert had the NR bit off, and
the subject's CA asserts that that meant that this cert was never to
have been used in transactions that require the service of
non-repudiation, then I suspect that that's a strong point for the
subject.  It may be overcome by other evidence, but it's a starting
point.  

	That's my thoughts.  Any help here would be appreciated.

			Al Arsenault

-- my own opinions.  As if anybody - especially my employer - would
agree with them!!!

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Aug 1999 13:10:11 -0400

Ed,

<snip>

>in my previous postings and is based on a quite general formal modeling.

There has been no substanbtitive support for that assertion by others on
this list, so ...

>from a subscriber -- in bulk and for all risks.

Subscriber's are not, generally, required to sign up for service with a
given CA, so implicit agreement to enabling the NR bit, as part of a
subscriber agreeemnt, might well be considered equivalent to explicit
request for the bit to be turned on in  a request.  This is especially true
in the current environment, where many cert request implementations do not
permit a user to explicitly request specific cert features in this detail.

>or granted prior to the reliance act. Not always granted as nowadays.

No. NR is not a service provided by a single bit, a single cert, a single
CRL or OCSP response, or a singloe time stamp from a TSA.  NR reuqires a
collection of subsidiary mechanisms to support it.  Just because the NR bit
is neither sufficient nor necessary for NR in all cases, that does not mean
that it is not of value, that it does not have a role to play.

>the certificate to be authoritatively self-signed at one past point in time.

Self-signed certs are generally just a syntactic convenience with minimal
security properties, as 2459 points out.   They should not be construed as
anything more.  A cert used in an NR context ought to be issued by a CA
with a published CPS.  If I were an RP, I would not accept a cert in
support of NR from a CA unless I could access and evaluate the
corresponding CPS.

>must be provided elsewhere -- ie, when a client queries a server or a list of

The specific requirements for NR are context specific.  Cert revocatioin
info might be acquired by a query to a directory or an OSCP server, or it
might be multicast to a subscriber set.  A transaction and supporting NR
data might be sent to a TSA to be time stamped, or a TTP might act as a
intermediary in the transaction and thus provide the necessary archival
protection w/o recourse to a query. This is how the e-mail equivalent of
registered mail could work, e.g., sending the message via a suitable relay
could provide the necessary NR data.

>to deny for each case) then it will backfire and be nullified.

We don't disagree that NR is ultimately a subscriber and RP issue; the role
of a CA in NR is to provide accurate certs and to act as the source of cert
revocation status info (perhaps distributed via others).  Others may have a
role as well, e.g., TSAs.

>burden of PKIX NR. At least, until the buyer consults a lawyer ;-)

As noted above, a subscriber chooses a CA and associated CPS which
constitutes a critical part of the context for NR.  It is unlikely that a
public, commercial CA would unilaterally impose an NR policy on
subscribers, since that would likely cause subscrubers to look elsewhere.
If an employer acts as a CA and mandates issuance of certs in support of NR
for its employees, for use in their jobs, that is not radically different
from the various other constraints imposed by emoployers (e.g.,
intellectual property agreeements) as conditions of employment. For
example, to travel on business for my employer, I MUST use a Corporate Amex
card issued in my name, and for which I am personally liable for charges.
I didn't get to choose the credit card, and the associated agreement terms,
because my employer has a database link to Amex to collect data om air
carrier, hotel, and car rental use as a means of negotiating better rates
in the future. This is analogous (though not perfectly so) to imposition of
NR policy on users of a CA, in a non-cooperative fashion, and it is a very
real example.

>make CAs liable for it -- since adoption of PKIX is, after all, voluntary by

Now that IS an example of a specific NR policy.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 11 Aug 1999 16:42:36 -0700

Alfred:

I will reply with some questions ;-)

Alfred Arsenault wrote:

> 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?

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?

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?

> How exactly the CA makes that decision is beyond the scope
> of PKIX; it's presumed that there's a CPS or some

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?

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