RE: Meaning of Non-repudiation

[Peter Williams <peterw@xxxxxxxxxxxx>]

When NIST?NSA folk evaluate a US network product/system, formally, 
they must, traditionally, use the following conceptions of NR. 
(Steve's notions of subject intent, and presumptions of signature
binding, are not relevant to a formal evaluation of a product/system
claiming to provide NR.)

It would be useful for some of our friends from NCSC/NIST
to perhaps find an actual evaluation/certification report
that certified an actual network product/system as meeting the
evaluation criteria for NR. This would provide us
with an example protocol under the Red Book
that was deemed "correct", as required by the criteria. 

Nothing in this NCSC criteria require (X.509) certs be used, or
particular bits be present in said certs.

Modern form of the criteria (CC 2.1) do not differ
in the criteria definition, though they remove the
material about digital signatures in favor of
requirements on evidence. They make no statements
about certificates. 
http://csrc.nist.gov/cc/ccv20/ccv2list.htm#ISO

Neither NCSC nor CC criteria deviate from NR being
(a) a network-based service that is semantically
tied to assertions of sending/receving messages,
and (b) an assurance of identity during an exchange
process, versus intent upon using a key. 

"4 Class FCO: Communication


137 This class provides two families specifically concerned with assuring
the identity
of a party participating in a data exchange. These families are related to
assuring the
identity of the originator of transmitted information (proof of origin) and
assuring
the identity of the recipient of transmitted information (proof of receipt).
These
families ensure that an originator cannot deny having sent the message, nor
can the
recipient deny having received it."


Peter.


---------------


http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-005.pdf

9.1.3. Non-repudiation
_ _ _ ___ ___________

+ Functionality
_____________

Non-repudiation service provides unforgeable proof of
shipment and/or receipt of data.

This service prevents the sender from disavowing a leg-itimate
message or the recipient from denying receipt. The
network may provide either or both of the following two
forms:

1. The recipient of data is provided with proof of
origin of data that will protect against any
attempt by the sender to falsely deny sending the
data or its contents.

2. The sender is provided with proof of delivery of
data such that the recipient cannot later deny
receiving the data or its contents.

Basis for Rating: Presence or absence of each of the
two forms.

Evaluation Range: None or present.

Discussion: Digital signatures are available techniques
that may be applied to non-repudiation mechanisms. Digital
signature mechanisms define two procedures:

1. Signing a data unit
2. Verifying a signed data unit

The signing process typically employs either an enci-pherment
of the data unit or the production of a crypto-graphic
checkfunction of the data unit, using the signer's private information 
as a private key.

The verification process involves using the public pro-cedure
and information to determine whether the signature
was produced with the signer's private key.

It is essential that the signature mechanism be
unforgeable and adjudicable. This means that the signature
can only be produced using the signer's private information,
and in case the signer should disavow signing the message,
it must be possible for a judge or arbitrator to resolve a
dispute arising between the signer and the recipient of the
message.

Digital signature schemes are usually classified into
one of two categories: true signatures or arbitrated signa-tures.

In a true signature scheme, signed messages produced
by the sender are transmitted directly to the receiver who
verifies their validity and authenticity. In an arbitrated
signature scheme, all signed messages are transmitted from
the sender to the receiver via an arbitrator who serves as a
notary public. In the latter case, a notarization mechanism
is needed.

Both public-key and conventional private-key cryptosys-tems
can be utilized to generate digital signatures. When a
message M is to be signed by a private-key cryptosystem, the
signature is a computed quantity catenated to M and sent
along with it. In a public-key implementation, when a mes-sage
M is to be signed, a transformation using the secret
key is applied to M before transmitting it. Thus, the signa-ture
is presented by the resulting transformed message.

+ Strength of Mechanism
________ __ _________

Basis for Rating: The strength and trustworthiness
given to non-repudiation service is bounded by the trust in
the underlying cryptography implementing digital signature
mechanism, the correctness of the protocol logic, and the
adequacy of protocol implementation. Additional information
may be found in the separate sections addressing these sub-jects.

Evaluation Range: None to good.

+ Assurance
_________

Basis for Rating: Assurance is concerned with guaran-teeing
or providing confidence that features to provide
non-repudiation service have been implemented correctly and
that the control objectives of each feature have been actu-
ally and accurately achieved.

This assurance is addressed by analysis of the logic of
the protocols and the implementation of the digital signa-ture
mechanisms to show correctness and effectiveness by
formal methods where possible (i.e., where tools exist) and
informal ones otherwise.

The information in the General Assurance, Encryption
Mechanisms, and Protocols sections also applies.

Evaluation Range: None to good.

-----Original Message-----
From: Tom Gindin [mailto:tgindin@xxxxxxxxxx]
Sent: Wednesday, April 11, 2001 3:51 PM
To: Stephen Kent
Cc: David P. Kemp; ietf-pkix@xxxxxxx
Subject: Re: Meaning of Non-repudiation



     IMHO, if X.509 had not been calling the bit in KeyUsage
"non-repudiation" for some years, I would prefer to put "Persistent Data
Authentication" into KeyUsage and define several different flavors of
non-repudiation in ExtendedKeyUsage, profiling non-repudiation services in
parallel with those ExtendedKeyUsage values.  This would also allow us to
define different levels of NR and put them into certificates in a natural
way.  However, they have been calling the bit "non-repudiation", and I'm
not sure we can change its meaning on the installed base of certificates
and on the X.509 group without an unusual level of unanimity and
near-certainty that it won't break anything.

          Tom Gindin