Subject: Re: proposed key usage text

From: [email-masked] (Peter Gutmann)
Date: Thu, 18 Nov 1999 16:26:38 (NZDT)

Tony Bartoletti <[email-masked]> writes:

>I sometimes doubt that a CA-asserted "NR bit" can represent anything useful.  
>But if I am proven wrong, it would be a shame to waste this bit on the fuzzy 
>"Simon Says it OK to use this cert for X" when there is no clear sense of 
>what X represents.
>
>I just wish I had a better notion of what a CA expects to be held to, if 
>anything at all, for signing with NR=0/NR=1 at my request.
>
>Free Hints Accepted :)

Why not use NR vs digitalSignature to distinguish long-term signature vs 
short-term authentication signing?  Several standards already use it for this,
this usage at least is practical and meaningful.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Nov 1999 09:45:22 +0100

In fact we know rather well, up to a certain level, what NR means.

NR is defined in X.509 as:

Non-repudiation:  This service provides proof of the integrity and origin of
data  both in an unforgeable relationship  which can be verified by any third
party at any time.

And that's all we know about it....

It does not say anything about:
- The quality of the proof
- The legal implications of the proof
- The ability to use the proof in the future (long term/short term)

All these additional interesting things must be provided by the certificate
policy, if provided at all. 

In this sense the NR bit is actually very similar to a policy-qualifier, so
that some parts in a policy may become active if the NR-bit is set.

But even without the additional things that the policy may add to this, the bit
have its basic defined meaning. To some applications that meaning is useless
but to some it may be very useful. But it is up to the relying party to decide
if this has any relevant meaning at all.

Finally, one of the problem with the proposed text is that it talks about
"falsely denying some action". Well this makes it very hard to distinguish NR
from authentication, because also pure authentication (challenge response) may
have this property.

X.509 (and the European ES-directive) on the other hand talks about "integrity
and origin of DATA", which is very different. In this sense the scope is
clearly limited to electronic signatures in order to proof origin and
authentication of a message. Not just any proof that I opened a door or logged
into a system.

So to make this easy, I would adopt the X.509 definition into RFC2459 with some
added notes about the dependency on a certificate policy for full understanding
of the implications of the bit.

Some systems will in fact use this information to technically separate keys
used for the challenge/response type of signing (DS bit) and the electronic
signature on a message type of signing (NR-bit). So this IS a very useful and
relevant distinction, even in absence of a policy.

/Stefan

>this usage at least is practical and meaningful.

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Ed Gerck <[email-masked]>
Date: Thu, 18 Nov 1999 08:59:44 -0800

> data  both in an unforgeable relationship  which can be verified by any third

This definition is wrong, as well as the consequences derived from it. Compare
with the technical definition of Menezes in  Handbook of Applied
Cryptography (cf.):

 Non-repudiation: a service that prevents the denial of a previous act.

and we may agree that the definition in X.509 is just a round-about way
of defining *strong authentication* -- where authentication affirms the
truth of an act (which can be verified by any third party at any time).
Quite different logic, as non-repudiation denies the falsity of an act --
and, thus, prevents the denial of the act.  Both are equal if and only if
the proposition is boolean, which it almost never the case is in security
(where propositions are not atomic, and are multivalued).

So, confusing non-repudiation with "authentication", or
"strong authentication", or "non-ephemeral authentication"
and thus actually vacating the concept of non-repudiation
will not go very far.  It leaves non-repudiation undefined
though still needed.

In other words, to rename or to forget a problem is not a
solution to the problem ... at least, technically ;-)

Cheers,

Ed Gerck

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Nov 1999 20:37:09 +0100

How can you say that the X.509 definition is wrong???

Since we are discussing the meaning of a X.509 defined bit for NR. Then of
course we have to align with the X.509 definition of the term. 

That's common sense to me.

/Stefan

---

From: Ed Gerck <[email-masked]>
Date: Thu, 18 Nov 1999 12:02:54 -0800

> How can you say that the X.509 definition is wrong???

Because it is redundant (the same as authentication as I commented)
and thus superfluous. Because there is an accepted definition in the
technical cryptographic literature which is different, is simpler,
corresponds to the real-world usage of the term "non-repudiation"
as that which cannot be negated, is not redundant and thus cannot
be ignored --  namely, that definition by Menezes et. al.  in the HAC:

> That's common sense to me.

To align PKIX with the X.509 meaning is also fine to me, but in this
case there is NO meaning.  The "definition" of NR in X.509 is simply
a restatement of authentication properties -- there is no new meaning,
and no meaning that migh resemble non-repudiation practices in
business, banking, dictionaries.

Of course, I agree with Mark T. that common sense is that which
everyone always seems to have a lots of -- but in this case the sense
defined in X.509 does not seem to be common at all.

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 18 Nov 1999 12:12:28 -0800

>this usage at least is practical and meaningful.

At the extremes, this is practical and meaningful (distinguishing minor
authentication assurance from, say, binding contract signatures.)

The problem, if any, comes when I decide I must maintain a long-term,
unforgeable log of every authenticated access to a system.  Suppose I
allow authenticated login with NR=0, but submit the signed "logins",
along with certs, CRLs, etc to "NR, Inc" for permanent archive.

Will "NR, Inc" reject the submission since the certs have NR=0?

Should I require the users to obtain NR=1 certs for login purposes?
And would they want to use the same keys for signing contracts?

Perhaps this is grasping at straws.  Long-term vs Short-term (without
any additional implications of purpose) does, in fact, coincide almost
precisely with Tom Gindin's version.  It then becomes a matter for
applications to decide when a particular transaction requires formal
NR treatment, which would consequently require the "Long-Term Bit".

Still, my fundamental concern is a confusion about "who is in the
driver's seat" with respect to the setting, signing, vouching for
NR=1 certificates.  This would seem to be the CA, as they form and
"make authentic" the certificate itself.  And yet they are really
outside of the dialog itself.

Let me try to make this clearer (to myself at least:)

As a RP/application, I decide that certain transactions require
that the elements be given an NR treatment.  I must convey this
to the user community, even if only to let them know that their
"actions" will be (as it were) non-repudiable.  The users can
either agree or not.  Say they agree.  How can I know that they
have agreed?  By requiring them to obtain NR=1 certificates for
the keys they will use.

But I will not accept just any CA's certs that say NR=1.  Why?
If a given CA hands out NR=1 certs exactly as it would NR=0,
then when a dispute arises, the signer can still argue that
(1) they never read my "page" that said "this transaction is NR"
and (2) they didn't know they were using an NR-key.  Hence it
must be a CA that I trust (at least) to make the buyer (subscriber)
well aware of the implications in the use of NR=1 certified keys.

After all, so long as I have some "proof" that the signer "knew"
they were entering into a NR-transaction, I could care less if the
cert said NR=0 or NR=1, and neither should anyone else.  Its only
REAL purpose, it seems, is to engage the CA as yet-another-piece-
of-evidence that the subscriber understands the implications of
doing "the NR thing".

As a flag to my application, its only reasonable semantic would then
be "I can now act as if the signer knowns this is a NR transaction".

Of course, I would like to know more from the CA.  Especially,
did they take additional precautions that the subscriber was
really who they presented themselves to be?  But that would
really put them (the CA) on the hook, placing them directly
into the line-of-liability should things go wrong.

OK.  It didn't work.  I think I'm still confused, but I'm not sure.

___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: Russ Housley <[email-masked]>
Date: Fri, 19 Nov 1999 09:32:55 -0500

Ed:

To my way of thinking, you are omitting an important 
distinction.  Authentication involves only two parties.  In those two 
parties are satisfied, then sthe service is provided.  Non-repudiation 
involves three parties.  In a conflict, the two parties can takes theire 
evidence to a third party (a judge or adjudicator) who can independently 
verify the transactions without either party having to disclose any secret 
or private values.

Russ

---

From: Ed Gerck <[email-masked]>
Date: Fri, 19 Nov 1999 07:49:16 -0800

Russ Housley wrote:

> involves three parties.

Russ:

The distinction is omitted because it is not correct, though often
mentioned. The same argument you make for non-repudiation can
of course be  made for authentication -- or, where would one consider
the CA?  The CA is a third-party; authentication per X.509 involves
three parties. Conversely, authentication even in X.509/PKIX (but, not
for end-users) can be provided with only two parties in the case of
self-signed certificates, which also opens the possibility for
non-repudiation based on two parties only -- with the
same problems/features as when self-signed certificates are used.

> In a conflict, the two parties can takes theire

In a three-party model, but in the same way as authentication -- where in the
case of absence of a known public-key for each, the two parties can
take their query to a third-party (the CA) who can independently
provide the respective keys without either party having to disclose
any secret or private values.

This could also be a four-party model for authentication and
for non-repudiation, where each party would *additionally* rely
on a common insurance agent. Or, a five-party model where
the insurance agent would be different for each party and could
then dispute between themselves.  Or, a six-party model, or,
seven-party and so on as you include an arbitration court,
jury, etc.

So, the number of parties involved  is not what distingushes
authentication from non-repudiation [1].

Further, in PKIX/X.509 both authentication and non-repudiation
must be based on three-parties for end-users [2].

Cheers,

Ed Gerck

[1]  Both dialogue parties (though NOT in PKIX/X.509) could also
rely only on themselves for each case.  To do this in a reliable
fashion one would need however to consider the dynamics of trust
building between both parties, which is  outside the scope of
X.509/PKIX  *both* for authentication as well as for non-repudiation
cases.

[2]  BUT not for the CA signing certificate which is self-signed
for authentication and self-validated for non-repudiation.  If I
receive a CA certificate signed by Verisign, I have no algorithmic
way of relying on it and I need to trust Verisign to affirm signing it
by itself (in self-authentication) or to deny its validity by itself (in
self-repudiation), as well known.  Note that simple absence of that
CA certificate in a CRL is not enough to support its validity in
non-repudiation because it might be a rogue certificate.  And, even
if the CA certificate came embedded in my newest browser, because
that CA certificate is a new trust point that I need to acquire and I
have no assurances from the browser provider that any embedded
certificate is correct.