Subject: Re: NR -- what the real issues are, and a proposal

From: [email-masked]
Date: Thu, 19 Aug 1999 10:58:00 -0600

>>> "Rich Ankney" <[email-masked]> 08/17/99 05:07PM >>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you might
be able to.

Of course, ANSI X9.45 defines a useful (CMS signed) attribute
to indicate the purpose of a signature.  Could we overload this (or
define something new but similar) to indicate intent?  The
syntax was an OID, so doing this is pretty simple.  I'd be
glad to force this thru X9 if the IETF crowd is not interested.

Best regards,
Rich

PS: I sent this to you personally rather than to the list in case
you'd like to discuss the details.  If not, of course, feel free
to post your response to the list.

Hi, Rich,

I'll take you upon your offer to post your note to the list, and
I'll also comment in passing on some other contributions from
Ed, Tony, and Steve, recognizing that some other suggestions have 
partially overtaken some of these ideas while I was preparing
this note and attending meetings. :-)

I agree with you regarding the case when the NR bit is off -- you
can't use the certificate for any nonrepudiation purpose in that case.
Perhaps I wasn't sufficiently clear in the proposal summary, 
although I think I was in the more detailed text, where I said that the NR
bit has to be used to ENABLE the NR bit in the message itself.

If NR bit is off, any message signed with the key in that certificate 
CANNOT intentionally or unintentionally be used for any legally 
binding purpose -- you are denying, in advance, that that was 
your intent, and signaling a prospective relying party that relying 
on your signature and certificate would be repudiated in court, if 
necessary, and hence such reliance would be quite unwise,
to say the least.
 
Why should you try to deny in advance something that might be 
legally binding (to answer someone else's question)?  Because 
you might be concerned about the possibility that your key might 
be stolen, and that it might not be YOU that is signing in that fashion!

Obviously you know (or at least ought to know) the strengths and 
weakness of your own key management system, and you might
very well decide that a given key/certificate was not sufficiently 
well protected to be used for any legally binding purposes -- it would 
just be too risky. Maybe your ordinary digital-signature-key-used-for-
network-logon-authentication-via-SSL is kept on your hard 
drive with relatively weak password encryption, and your 
nonrepudiation key/certificate is kept on a removable smart card.  
(I think this is Ed's point -- that if I don't have the power to deny 
a given capability in advance, it really isn't nonrepudiation -- it's 
just an option that I can't control and hence can't be binding, since 
it isn't voluntary.)

As I read Steve's note, I think he is in agreement with at least this point.

However, Steve, Tony, and even Ed then go down a path that I think is 
highly questionable, and that is the CA-centric view of enabling 
or disabling nonrepudiation within the CPS. Granted, if there is even 
the faintest suggestion that the CA might be liable for the user's 
actions with respect to his key and how they are used, then the 
CA ought to be able to deny the user the ability to set the NR bit. 
But it should do, obviously, by simply refusing to issue a certificate 
containing that bit.  But whether the CA can impose other conditions 
on the subscriber, or on the RP, in this particular area seems highly 
doubtful, as I will explain. (And as I expect that you, Rich, 
already know because of your banking involvement.)

There are three reasons why something like a NR bit should be in the 
certificate, and not just rely on a certificate policy OID (or worse yet, 
just a statement in the CPS itself.)

The first is a practical one -- very little RP software to date (none that I know of) 
implements the policy OID constraint, and without that constraint there is no 
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's certificate 
at all.  I'm not quite certain whether a policyOID constraint can be placed on 
the end-user's certificate -- can it? -- but even if it is it is far from obvious that
such a constraint is binding upon the application. What mechanisms are 
postulated to tell the RP what particular policy OID the user feels like accepting 
today?

So the relying party, or the relying party's IS department, may specify such a policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.  

Finally, as I believe I explained in a previous message, to the best of my
knowledge there is no legal way that I know of whereby the relying party
can be required to even read the CA's CPS prior to accepting a digital signature,
or more importantly why a CPS that reflects an agreement between the CA 
and the subscriber would be binding upon the RP.  

This is a contractual privity issue, and there simply isn't any way around it that 
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the defined 
semantics of the attribute itself.  If the NR bit is now so hopeless confused that
someone could wriggle out of this definition, then we ought to define a new one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long as we 
recognize that it is the turning off of the bit that is really the most important thing.

With respect to the suggestion to define a new signedAttribute to be applied 
to the message, Russ Housely indicates that would be outside of the current
SMIME WG's charter, but that the charter could be amended if there was 
sufficient interest.

If we can get some reasonable consensus on the overall approach, I would 
be happy to work with you, Rich, to perhaps define a joint IETF-SMIME and
 X9 contribution in this area.

Bob

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal

>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut t
>o the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>Now for the history lesson.
[snip]

---

From: Ed Gerck <[email-masked]>
Date: Thu, 19 Aug 1999 12:30:22 -0700

Bob:

I hope we both won't be blamed for the World Wide Wait ;-)

BTW, the lifetime of a cerficate tends to be inversely proportional

to the number of its attributes (old thread) but, fortunately, an

email can escape this rule by being also valid by parts -- not

just invalid as a whole when one part is wrong.  I especially

liked some parts of your email even though others invite

some counter-examples.

[email-masked] wrote:

I
agree with you regarding the case when the NR bit is

off -- you can't use the certificate for any nonrepudiation

purpose in that case.

The NR bit off case has three logic levels as
I commented. So,

which one is meant? This question cannot
be answered by a

boolean bit.  Appart from this, what
is it that each level means,

exactly? This questions seems to have 4 meanings
(three of

which were recently summarized by Tony).

Perhaps
I wasn't sufficiently clear in the proposal summary,although I think I
was in the more detailed text, where I said that the NRbit has to be used
to ENABLE the NR bit in the message itself.

I agree with this

Why should
you try to deny in advance something that might belegally binding (to answer
someone else's question)?

The problem here is that you may deny as much as
you wish and yet it

may be used in court and so accepted -- and not
only in the case of

a tort (when it is trivially accepted and even
rated as a further evidence

of intent to deceive).

(I think
this is Ed's point -- that if I don't have the power to denya given capability
in advance, it really isn't nonrepudiation -- it'sjust an option that I
can't control and hence can't be binding, sinceit isn't voluntary.)

This is correctly as I said.

However,
Steve, Tony, and even Ed then go down a path that I think ishighly questionable,
and that is the CA-centric view of enablingor disabling nonrepudiation
within the CPS.

Thanks for the "even Ed" ;-) -- but I guess we may
be talking across each other.

I see two different points here:

1. I posit that CA-centric and verifier-centric
are both valid PKI modes,

and I also include other two modes (different
thread).  Thus, it is IMO

valid to use a CA-centric mode when that mode
is justified.

2. We do have a distinct view on the r-p/ca/subscriber
legal

relationships due to extra-contractual issues.
I will address them

inline after your comments below.

There are
three reasons why something like a NR bit should be in thecertificate,
and not just rely on a certificate policy OID (or worse yet,just a statement
in the CPS itself.) The
first is a practical one -- very little RP software to date (none that
I know of)implements the policy OID constraint, and without that constraint
there is noenforcement.

Enforcement can never exist -- the r-p is free to
use any software and is free

to set any of its features.  The only thing
a CA can control is its own actions

-- a truism which crypto cannot change.

In fact,
I would bet that a lot of software would ignore theconstraint even if it
were marked critical -- they certainly ignore a lot of other critical attributes.

I agree, and this first reason is thus IMO not relevant
because not enforceable in principle.

The second
reason is more important.  Although I can, if I am the relyingparty,
choose a superior CA whose certificate specifies a policy OID constraint,I
am not required to do so. In fact, I can import and "trust" (accept as
valid)a user's certificate directly, without relying on any intervening
CA's certificateat all.  I'm not quite certain whether a policyOID
constraint can be placed onthe end-user's certificate -- can it? -- but
even if it is it is far from obvious thatsuch a constraint is binding upon
the application. What mechanisms arepostulated to tell the RP what particular
policy OID the user feels like acceptingtoday? So
the relying party, or the relying party's IS department, may specify such
a policyconstraint, BUT THEY ARE NOT REQUIRED TO DO SO.

This is the same case as the first, but in regard
to the subscriber. The subscriber is

free to do as it pleases -- and this is good
for security and free market reasons.

Thus, this second reason is also IMO not relevant
because not enforceable in principle.

Finally,
as I believe I explained in a previous message, to the best of myknowledge
there is no legal way that I know of whereby the relying partycan be required
to even read the CA's CPS prior to accepting a digital signature,or more
importantly why a CPS that reflects an agreement between the CAand the
subscriber would be binding upon the RP. This
is a contractual privity issue, and there simply isn't any way around it
thatI know of -- a contract between A and B is not binding on C, even if
there werealso a contract between B and C.

This is IMO the real issue.  The r-p is not
even required to read the PKIX, spec,

or not even read what his browser says. Again,
the r-p is free to do what it pleases.

But, there are some very strong and well-know
points that allow a CA to

impose conditions upon a r-p and, even, allow
a subscriber to impose

conditions upon a r-p, as well as allowing either
the CA or the subscriber

to grant legal rights to a r-p -- and all, without
contract privity with the r-p.

In fact, this is what makes a CPS dearly vital
to CAs -- as I am sure you

don't ignore because you must have faced this
issue with Novell's CPS.

To give some examples:

i. if the subscriber or the CA issue a blank warranty
such as was done by

the classical case of the Carbolic Ball Co. (I
cited this before and you may

recall it), then any r-p can claim rights to
that warranty even if there is no

contract privity between the r-p and either of
them (CA or subscriber).

ii. If the CA makes it publicly known (website,
legal register, ISBN-numbered

publications such as books, etc.) that any use
of a certificate issued by that CA

must be governed by the CA's CPS before any entity
may rely on the certificate,

then this is binding  upon any r-p as a
condition to use that certificate, even if

there is no specific contract between them.

iii. ditto for the subscriber -- for example,
in a form which the user must "accept"

in his browser before actually relying on that
subscriber's certificate for anything

iv. If the law of a specific jurisdiction consider
that a certificate is mostly

a "good" and not so much a "service" (for example,
because a cert is surely

something that is moveable at the time of identification
to the contract for sale

and in the sense that certs need to be moved
from the CA to the subscriber

or r-p), then the r-p can make the CA and the
subscriber liable much in the

same way that a consumer that buys a car from
a dealer (akin to subscriber)

can make the car manufacturer (akin to CA) directly
responsible for defects.

The legal doctrine of "caveat emptor"  (buyer,
beware) no longer applies to

such  relationships and this was overturned
in the US already in the 50's.

v. UCC Section 2-302 specifies that an agreement
will not be enforced when it is deemed unconscionable.  Thus, a too-strong
worded CPS that would deny all liability from

CAs to r-ps may be nullified. Unconscionability
can be found where the agreement is excessively one-sided, such as where
the terms are unreasonably favorable to one party and the other party had
little bargaining power and therefore an absence of meaningful choice.
A CA's disclaiming of implied warranties, exclusion of consequential damages,
exclusion of suitability of purpose and

a zero limit on its monetary liability, often
hiddent  in long, technical, complicated, legalese-intensive documents,
may thus backfire and open the CA to a consumer-law based claim from

the r-p -- where the burden of proof is reversed
to the CA.   Please see http://www.ilpf.org/work/ca/app3.htm
for a reference on this and related issues.

vi. The traditional rule in service relationships
has been that one party is not liable to any party not in contractual "privity"
(i.e., has entered into a contract with the party causing harm). However,
this general rule has been relaxed by several jurisdictions. In the case
of merchants, this means that in some

situations merchants may be able to benefit from
the warranties (if any) granted by the CA to the consumer.  There
is a continuum across jurisdictions in their adherence to the privity rule.
Among the theories deployed by jurisdictions: * Liability extends only
to those in privity. * Liability extends where the third party was known.
* Liability extends where the third party was known but only if there was
actual communication between the information provider and the third party.
* Liability extends to all foreseeable third parties. * Liability extends
based upon a balancing of various factors.  * Liability extends only
when the parties not in privity are physically injured.  Please see
http://www.ilpf.org/work/ca/app3.htm for a reference on this and in other
ways that even in the absence of a contract in place between a merchant
and a CA, there exist alternative arguments under common law for a merchant
to have recourse against a CA for losses suffered.

vii. The certificate is a copyrighted work, by
definition of copyright, even if it

does not mention it.  Thus, its use can
be controlled by a copyright declaration

and the r-p cannot claim ignorance of its terms.
Thus, the CPS can be viewed

as a copyright declaration that controls the
right to use that protected work -- the

certificate -- and thus deny or grant rights
to the user of that work.  The right

to make a copy being just one of them.

So the only
way that I know of to specify something of this type is in the defined
semantics of the attribute itself.

As above, no.  And note that even if your argument
would be correct it would

say too much -- in fact, even the"defined
semantics of the attribute itself" would also

not be in contractual privity and thus would
also be unenforceable under the

"caveat emptor" doctrine.  In other words,
not only the CPS is NOT in

contractual privity but also  the PKIX spec
itself is NOT in contractual

privity.

If
the NR bit is now so hopeless confused thatsomeone could wriggle out of
this definition, then we ought to define a new one,perhaps intentToBeLegallyBound,
and deprecate the old one.

ToBeLegallyBound is a name like any other but IMO
it still says too much -- its

denotational value is still confusing.
Here, I have suggested "proofOfAuthentication"

-- which essentially IMO says the same that you
want to express but does not mandate

a legal context (which may not exist, as in a
company).

However, I must say I am today more inclined to
use a term that you have explained here

and this may make it more acceptable in general
because your comment was IMO

very clear --- I would be more inclined to use
the name rebuttablePresumption for

that bit, because IMO this is what is meant by
the NR bit service.

In this case, the subscriber would be legally
bound unless he could prove otherwise.

This seems fair and this seems what has been
expressed here. Of course, this

implies a first step (often neglected), which
falls squarely on the shoulders

of the r-p -- to collect enough evidences in
order to convince the court that

the signer has to be called upon to present a
convinving denial (or, must

accept the deal).

BTW,  I first intended calling this bit "proofOfAuthentication"
exactly because

it enables the first step that the r-p must undertake:

The proofOfAuthentication bit is asserted
in a certificate as an authorization

to the effect that any message signed with
the certificate can be used as

evidence operating to determine the finding
of an authentication proof, but not

otherwise.

and because I try to avoid specific legal terms
--  however, "rebuttable

presumption" was also described and used in these
discussions by Bob

Blakley and others, so I guess it is OK. And,
more meaningful in order

to span that gulf between lawyers and non-lawyers.
I will comment in

a separate posting that the difference between
a "rebuttable presumption"

(ie, the old NR bit cert) and a "non-rebuttable
presumption" certificate

(ie, a possibly new non-repudiation bit cert)
may be made slight in practice,

though they are different in theory.

Cheers,

Ed Gerck

PS: I also agree to avoid HTML mail ;-)