[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: non-repudiation, was Re: proposed key usage text
> -----Original Message-----
> From: Ed Gerck [mailto:egerck@nma.com]
> Sent: Thursday, November 18, 1999 2:12 PM
> To: David P. Kemp
> Cc: ietf-pkix@imc.org
> Subject: Re: non-repudiation, was Re: proposed key usage text
>
Now that you are getting close to consensus, here is some
additional material to be potentially harmonized, or
considered (patents, particularly):
1. http://thesource.dwpub.com/frames/1997/09/18.html
2. Authentication & Non-Repudiation - Verifying the received document is
really from the advertised sender. Additionally, the non-repudiation process
involves processing and sending a message back to the sender so there can be
no repudiating the validity and authenticity of the sent and received
document.
(se.commerce.net)
3.
http://www.techweb.com/encyclopedia/defineterm?term=NON-REPUDIATION&exact=1
Unable to deny the validity of a document.
http://www.rnbo.com/PROD/rmadillo/b/b4doc1.htm#data
NSA's (old) view...
http://members.tripod.com/jayp_7/professional/Samples/EDI/EDI-4.htm
BT's 1992 View of bisynch's NR "undeniable confirmation that your trading
partner received your EDI transaction?"
http://csrc.ncsl.nist.gov/nistpubs/800-7/node239.html#SECTION083660000000000
00000
NIST admits that X.400 allows NR via non digital signature means...
http://www.itu.int/itudoc/itu-t/rec/f/f435.html extra NR services added
to X.400, in 1991
http://www.disa.mil/DISN/disns562.html
Encryption-based NR:
Making additional security protection available to DISN users commensurate
with policy-required provisions for authentication, non-repudiation of
traffic origination or delivery and protection of classified information.
This will be provided through the use of link encryption and end-to-end
encryption units, such as secure telephone units and secure video
teleconferencing systems.
http://www.arraydev.com/commerce/JIBC/9811-08.htm
Eric Blot-Lefevre's dematerialization view of NR
4. patents...
LMITCO Invention Disclosure, Digital Signature System with Non-Repudiation
for Relational Databases, B. J. Groeneveld, W. E. Austad, S. C. Walsh, C. A.
Herring, filed 27-July-1998.
http://id.inel.gov/4150/ppp/austad_wayne.html
Use of control vectors (like key usage extension...) to enable MOA NR:
http://www.patents.ibm.com/details?pn=US04918728__ (properly references
Davies.)
5 Fishing
http://www.fishnet.co.nz/gen/Dec3_97.html claims international standards for
NR already exist such that the NZ fishing industry does not need to
invent anything new.
>
>
> "David P. Kemp" wrote:
>
> > > Date: Thu, 18 Nov 1999 12:02:54 -0800
> > > From: Ed Gerck <egerck@nma.com>
> > >
> > > Stefan Santesson wrote:
> > >
> > > > 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.
> >
> > Some people believe that there is a difference between "provable
> > data origin authentication with integrity" and "entity
> authentication",
> > and that nonRepudiation as used in X.509 is an appropriate
> name for the
> > former.
>
> David:
>
> It is useful to list what X.509 actually says before further
> discussing about
> "nonRepudiation as used in X.509". These are all the
> occurrences that I
> find when I look for the key text "repudiation" in X.509:
>
> "It is a matter for the security policy and responsibility
> of the CA to keep old
> certificates for a period of time if a non repudiation of
> data service is provided."
>
> "If a non-repudiation of data service is dependent on keys
> provided by the CA,
> the service should ensure that all relevant keys of the CA
> (revoked or expired)
> and the timestamped revocation lists are archived and
> certified by a current
> authority."
>
> "nonRepudiation: for verifying digital signatures used in
> providing a
> nonrepudiation service which protects against the signing
> entity falsely
> denying some action (excluding certificate or CRL signing,
> as in f) or g)
> below);"
>
> "The date in this extension is not, by itself, sufficient
> for nonrepudiation
> purposes. For example, this date may be a date advised by
> the private key
> holder, and it is possible for such a person to fraudulently
> claim that a key
> was compromised some time in the past, in order to repudiate a
> validly-generated signature."
>
> "Repudiation -- The denial by a user of having participated
> in part or all
> of a communication."
>
> and, the one quoted by Stefan:
>
> "Non-repudiation -- This service provides proof of the
> integrity and origin
> of data -- both in an unforgeable relationship -- which can
> be verifed by any
> third party at any time."
>
> plus:
>
> "The data integrity mechanism supports the data integrity
> service. It also
> partially supports the non-repudiation service (that service
> also needs the
> digital signature mechanism for its requirements to be fully met)."
>
> "The digital signature mechanism supports the data integrity
> service and
> also supports the non-repudiation service."
>
> which shows that X.509 itself is in contradiction. To
> X.509, nonrepudiation
> does NOT provide proof of integrity, which needs the digital signature
> mechanism. This is made clear in Table B.1 "Threats and
> protection", where
> we can read that the non-repudiation service is depicted as
> protecting against
> the threats of replay and repudiation -- and that "data
> integrity" and "end
> authentication" are different services, different from
> non-repudiation.
>
> Thus, that is why I wrote the following in regard to the
> definition that Stefan
> quoted from X.509:
>
> 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.
>
> But, surprise! The above NR definition by Menezes can be also found in
> *another* part of X.509, if you read the X.509 definition for
> *repudiation*
> that I quoted above:
>
> "Repudiation -- The denial by a user of having participated
> in part or all
> of a communication."
>
> and you construct the logical complement of "non" as:
>
> Non-Repudiation -- Preventing the denial by a user of having
> participated in
> part or all of a communication.
>
> Further, authentication that is neither provable nor provides
> for integrity is
> not authentication in the sense of strong authentication as used in
> X.509 digital signatures (Section 10.1). Thus, when you say
> that "provable
> data origin authentication with integrity" is an appropriate name for
> non-repudiation in X.509, I must disagree and cite X.509
> itself. That X.509
> definition quoted by Stefan in incoherent with all other
> definitions of X.509.
> It was a bad pick.
>
> Actually, elsewhere as shown above, X.509 textually *agrees* with the
> definition by Menezes et. al. and with the usual sense people
> would attach
> to something that is the complement of repudiation, the
> complement of denial.
>
> On the other hand, "provable data origin authentication with
> integrity" is
> NOT an attribute of non-repudiation in X.509 but is provided by strong
> authentication as given in Section "10.1 Overview", where two-way
> authentication provides assurances for "the integrity and
> originality of the authentication token sent in the reply".
>
> So, should we accept that NR definition quoted by Stefan and deny
> all the other passages of X.509, including those for
> authentication, that
> contradict with it ... or should we mark that specific
> passage as wrong
> and accept the rest of X.509?
>
> Cheers,
>
> Ed Gerck
>