Subject: RE: Meaning of Non-repudiation

From: Philip Hallam-Baker <[email-masked]>
Date: Fri, 6 Apr 2001 10:29:14 -0700

> From: Carlin Covey [mailto:[email-masked]]

> Philip Hallam-Baker wrote
>       "... We had a six hour discussion of the 
> non-repudiation bit ....
>       At the end of the meeting Tim received a signed and 
> sealed statement
>       from Michael [Baum] himself stating that we did not 
> need to discuss
>       the topic ever again.  ..."
> 
> Was the non-repudiation bit set in the certificate used to sign that
> statement?

Damn! You are right!

If the lawyers want to discuss the issue again they are going to have to
share the foix gras and caviar this time and not keep it to themselves!

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

---

From: Peter Williams <[email-masked]>
Date: Fri, 06 Apr 2001 12:09:04 -0700

Phillip,

This is intended as a pleasant message, before the PKI movement's
annual festival during which we can analyse the previous
year's concrete accomplishments and look forward
to enhancing privacy in email:

A valid implication of your expert group's statement is: that the IESG was 
wrong to have passed RFC 1421/1422, which seemed to claim to standardize a
mechanism for providing a proof of origin with non-repudiation service. IESG
was 
wrong as there was no NR bit in the certificate of the day, and, therefore,
the 1421/1422 mechanism for providing the claimed service was not adequate.

As this implication seems very far fetched indeed (as IESG
are infallible) it makes me doubt the validity of the expert group's very 
proper assertion. Lets try to find  evidence for the contrary 
position - which would support IESG decisions:

"Certificates are used in PEM to provide the originator of a
   message with the (authenticated) public component of each recipient
   and to provide each recipient with the (authenticated) public
   component of the originator.  " [RFC 1422]

"Authentication, integrity, and (when
   asymmetric key management is employed) non-repudiation of origin
   services are applied to all PEM messages; confidentiality services
   are optionally selectable." [ RFC 1421]

By focusing on authenticated public component, 1421/1422 removes from the
notion
of verification of digital signatures any requirement to consider
certificates. 
The phrase "Asymmetric key management" is declared to be the (only)
condition 
for provision of the non-repudiation with origin service. Indeed, 1422 never

mentions the term "repudiation": the architecture provides only for the 
distribution of authenticated public components.  Indeed, 1422 makes no
claim 
to support the non-repudiation of origin service declared in 1421. It goes
out 
of its way to limit its support to data origin authentication.
In summary, the "Certificate-based key distribution" specification of 1422 
does not claim to be "Asymmetric key management". By inference, 1422 support

for 1421 does not provide for non-repudiation of origin. Also by inference, 
certificates alone are not sufficient for non-repudiation - assuming 1422's 
avoidance of listing support for 1421's non-repudiation of origin service
was 
deliberate.

RFC 1422 apparently contrasts with RFC 3039, which introduces a
format-profile 
of certs that specifically claims to support an identification service,
suitable 
for a public non-repudiation service. But again, we note, 3039 does not
claim 
that certificates are necessary for non-repudiation - only, that conforming 
certificate schemes provide for the necessary assurance for the
"identification 
facility" used in providing a non-repudiation service. In this, 3038 is
compatible 
with 1422, in that certificate-assured identification is a common element
for both
the data origin authentication facility that 1422 does list as supporting,
and  
the "public" non-repudiation service that 3038 supports.

Other PKIX documents introduce bizzare, non-normative notions that we should
probably ignore: "Users of public key-based systems must be confident that, 
any time they rely on a public key, the subject that they are communicating
with owns the associated private key [...]" in case anyone claims that
PKIX is self-contradictory. This quote from a PKIX theory I-D introduces
the strange idea of "relying on" public keys, and introduces a (legal) 
contingency concerning  "ownership". Though strange, it is interesting to 
note the compatibility of the PKIX theory with 1422, in its focus on public
keys 
rather than certificates.

In conclusion, I can view the RFC/ID evidence as supporting either position
- for 
or against the experts statement that certificates and a given signal are
necessary 
for non-repudiation. PKIX and historical IETF PKI standards-track works are
apparently
very carefully worded to offer NO support for a formal claim of providing 
non-repudiation on the basis that (a) certificates are used and/or (b) that 
particular certificate processing is used. Bringing the issue uptodate for
the 
NR-relevant protocols that Internet subscribers use, we note that S/MIME v2 
has a largely PEM compatible model: non-repudiation of origin is a result of
"using 
digital signatures." To test the experts groups assertion seems to depend
upon 
the definition of a digital signature.   And on that there 
seems to be NO consensus in the statutory (legal) world we live in on 
the matter of any *necessary* relationship to certificates - as another
essay on
the definitions used in a statute to which IESG refers might show.

Peter.

 -----Original Message-----
From: Philip Hallam-Baker [mailto:[email-masked]]
Sent: Friday, April 06, 2001 9:09 AM
To: [email-masked]
Subject: RE: Meaning of Non-repudiation

I am confused here. Last washington IETF myself, Russ, Denis and Tim were
taken in a black limosine off to a meeting of the joint ABA-New world order
PKI working group being chaired by Michael Baum. We had a six hour dicussion
of the non repudiation bit puctuated only by the stream of liveried servants
dishing out foie gras, oysters and caviar to the lawyers. At the end of the
meeting Tim recieved a signed and sealed statement from Michael himself
stating that we did not need to discuss the topic ever again. I hope that
Tim has not lost the statement.

At the meeting the strongest statement that could be agreed upon concerning
the non repudiation bit was:

1) The setting of the non repudiation bit in the certificate was a necessary
but not sufficient condition for a relying party to consider a signature to
have the non-repudiation property.

Beyond that there was considerable dispute as to the legal and technical
issues. I believe that the utility of the bit is limited to identifying keys
which are considered (for whatever reason) repudiable. Beyond that
non-repudiation is not a binary quality, there will always be degrees of
repudiation contol and the degree of control provided in a specific
circumstance is ultimately determined by the CP and CPS. Trying to condense
that down to a single bit is futile.

There is a utility in leaving the non-repudiation bit clear in a certificate
for a cable modem, 802.11b card, SSL server or the like.

Unfortunately the people who are most concerned about the bit tend to want
it for an affirmation that non-repudiation services be provided.

One solution would be to call it the 'repudiation bit' and state that when
clear repudiability was asserted.

        Phill
Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

---

From: "Bob Jueneman" <[email-masked]>
Date: Sat, 07 Apr 2001 10:55:44 -0600

Although I enjoyed Tony's tongue-in-cheek usage scenario, I'm not sure that I agree with his assumption that it is the issuing CA that is driving this -- I don't view this as being a CA-centric issue.  Yes, I agree that the CA COULD define the meaning of the bit in it's CPS and CP, but WILL they -- that is the question.  and if they do, is it enforceable against the CA, or only against the subscriber -- that is the issue.

In particular, I do NOT think that the NR bit says something very noteworthy about what the CA is going to do or not do. Instead, I believe the NR bit is exclusively saying something about the signing party's behavior.  It seems pretty unlikely that the CA (or some independent auditing group) is going to actually go out to the subscriber's premises and investigate their practices, not to mention intrusive.  And I don't think that the NR bit should be construed as implying something about how the CA is going to keep CRL records until infinity, etc.

So at best the NR bit is a representation made by the subscriber to the world via the CA.  In this case the CA is essentially acting as the trusted publisher of a Legal Notice in the paper.  The CA/publisher is not necessarily itself guaranteeing the correctness or truthfulness of the notice, only that it is printed verbatim as received from the subscriber.  Of course if the CA wants to get into the insurance business, or the notary business, or some other business that involves guaranteeing either the user's behavior or the particular transaction, that is a completely different matter, and one that I don't believe could or should be inferred from the NR bit.

So if the NR bit is a representation made by the subscriber, essentially in the form of a Legal Notice, then what specifically is being represented?

Well, in an ideal world, the subscriber would have a Subscriber Usage Statement that would be similar to the Certification Practice Statement of a CA.  In one of the first implementations I did of PKI, back when I was with CSC, I included exactly that -- a set of representations as to what the subscriber would or would not agree to, digitally signed and made available as an Affidavit of Legal Mark.  Basically the Affidavit said "I am going to honor the herein described electronic process as though it were in every respect my legal mark or signature, subject to the following caveats and conditions."  If necessary, that affidavit could be printed and signed with a wet signature.

Of course if we could come to some reasonable agreement as to what a reasonable set of caveats and conditions might be -- not their values, just the semantic definitions -- then it would be possible codify those values in the certificate, as a representation made to the CA-as-publisher.  I've tried to do some of that in the Certificate Quality portion of Novell Security Attributes, but it just describes the technical conditions associated with the certificate -- key quality, class of user, etc. -- and not the conditions under which the subscriber would agree to be bound.  So there would be a lot more work required to implement such a concept in a way that wouldn't require reading a huge document along with every subscriber's signature.

From this perspective, the thought of trying to condense all of that kind of information into a one-size-fits-all single bit, called nonRepudiation, would be truly laughable, if it weren't so naive and arrogant at the same time.

But to get back to the real world, I recently saw an very interesting device being made by Sony, the FIU-710 Fingerprint Identification Unit.  This isn't a plug for Sony -- other people may well make something similar, and their's might be better, cheaper, or just different -- I don't know.  I'm merely describing it for people who may not have seem something similar.

But the Sony unit is getting a lot closer to something that I think we need, and might be deserving of being represented with the NR bit.  According to the spec, the stand-alone unit is 54x85 mm and 9.5 mm thick. It plugs into a computer via a USB port or serial cable.  It has a fingerprint scanner capable of 1 second registration time and less than one second verification time, with the fingerprint recognition circuitry embedded in the device. The false acceptance rate is .008% or less, with a false rejection rate of 4% or less.

In addition the unit contains 512KB of user memory and is PKCS#11 compliant, able to generate and store up to 1024-bit RSA keys. It can also encrypt files with DES and triple-DES, and can store passwords lists, user profiles, and other data, and can support up to eight applications in one session.

According to a vendor (Saflink Corp.) that is marketing the device and their software as an authentication method for our NMAS authentication framework, the tamper-proof unit is supposed to be certified as FIPS 140-1 level three or better, some time in the next year, although I haven't seen that in writing anywhere.

The most important point, however, is that here is a tamper-proof device that is the equivalent of a smart card or a PCMCIA card in terms of its cryptographic capabilities, and in addition it has a biometric device built-in that is capable of locking the private keys so that they cannot be accessed without fingerprint identification.  Assuming all this is true and that the device has the necessary configuration flexibility to support this, this would go a very long way towards satisfying several elements that might reasonably be required for nonrepudiation, including biometric identification of the user for every NR signature operation.  Because I don't have a trusted display device, I still don't know that what was signed was really what I intended, but at least I can be certain that I only signed one thing, and that goes a long way.

I wouldn't go so far as what Tony suggests in terms of using it at a kiosk -- the unit may be tamper-proof, but that doesn't prevent the entire unit from being physically substituted, as in the "fake ATM" ploy.  But that unit, in combination with an operating system that was accredited at the C2 level of trust (and properly installed, which is harder), would go a long, long way in the desired direction.

To get back to Dave's question, though, at least we reach this nirvana state, I would suggest that he be very wary of generating or accepting a certificate that has his name on it in combination with the NR bit, because some judge somewhere might somehow come to the conclusion that the NR bit actually means something.  On the other hand, if I were a relying party I certainly wouldn't put much if any credence in a transaction that was verified against a certificate containing the NR bit, because some other judge might decide that the NR bit meant nothing at all.

And given that scenario, I continue to believe that the currently ill-defined bit should be officially deprecated, and some other attributes defined as necessary with a great deal more precision.  If ISO X.509 and/or the PKIX group refuses to deprecate the bit, then certainly the user community should.  IMHO, of course.

Regards,

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> Tony Bartoletti <[email-masked]> 04/06/01 06:24PM >>>
At 03:52 PM 4/6/01 -0600, Bob Jueneman wrote:
>Alas, poor Dave, you have fallen into the black hole of PKI, from which 
>there is no escape.

Also Known As, the point of No Return (NR).

(I feel as a moth drawn to a flame.)

I think Bob has laid out the issues very nicely regarding the (lack of) 
necessity, sufficiency, and (arguable) usefulness of the "NR" bit.

My feeling is that if the NR bit says anything at all, it is the issuing CA 
that is speaking.  I cannot go to a (reputable) CA, and ask for a key to be 
certified with any attributes of my choosing.  There is some understanding 
(modulo CP/CPS) that the CA "stands behind" the attributes contained in the 
certificates they issue, at least in terms of their having followed their 
(self-defined) process.  (Beats me just what this is worth...).

The most I can hope is that, at some future point, the PKI Protocol Players 
come to agree upon some common standard of certificate issuance processing 
"guaranteed" by inclusion of the set NR bit.  Even then, it will be little 
more than one more piece of evidence that may be provided in case of a dispute.

I have thought about how far one could really go, in making the NR-bit 
stand for what folks naively expect it to be.  My "program" addresses both 
issuance and usage.  (It may seem "humorous", but I wonder how far off this 
will really be.)

Issuance of NR-bit Certificates:
--------------------------------

The NR-bit Certificate shall contain or reference:

1.  The CA-signed audio file of the certificate subject, reading aloud the 
CA's CP/CPS verbatim, and correctly responding to several randomly selected 
questions about this material.

2.  The CA-signed photograph of the certificate subject shaking hands with 
the CA president under a banner that reads "Another Satisfied NR Customer".

Usage of NR-bit Signature Keys:
-------------------------------

These keys will be contained in biometrically-sensitive key-cards that self 
destruct under reasonable signs of tampering.

The keys/key-cards can be used in any of the "Signature Kiosks" that we 
expect will replace the common "auto-teller" machines.  These kiosks will 
be operated by the major banks, and serve as "secured web portals".  Users 
will be able to insert their NR key-card to conduct transactions that would 
otherwise require the presence of two witnesses and a roomful of lawyers.

Prior to reaching the "signature preparation phase" of a transaction, the 
terms of agreement may be perused at the user's leisure.  To enter the 
"signature preparation phase", the user must place their thumb, palm, or 
otherwise previously-registered part of their warm body in full contact 
with the key-card's "bio-read" surface, so that authentication and 
biometric stress data can be recorded.  The user is then presented with 5 
randomly selected multiple-choice questions about the terms of the 
transaction.  The user must answer all questions correctly in order to 
proceed to the actual signature phase.

Note:  The card will refuse to unlock the contained NR-key if:

a.  Bio-authentication fails (fingerprint, DNA-read, etc).
b.  Excessive alcohol or other mind-altering elements are detected.
c.  Skin-galvanic properties detect undue psychological stress.

Once all of these simple measures are in place, you will be able to walk 
down any city street, stop at a signature kiosk, withdraw some cash, 
purchase some postage stamps, and close escrow on that house you've been 
eyeing...

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 09 Apr 2001 11:46:34 -0700

At 10:55 AM 4/7/01 -0600, Bob Jueneman wrote:
>Although I enjoyed Tony's tongue-in-cheek usage scenario, I'm not sure 
>that I agree with his assumption that it is the issuing CA that is driving 
>this -- I don't view this as being a CA-centric issue.  Yes, I agree that 
>the CA COULD define the meaning of the bit in it's CPS and CP, but WILL 
>they -- that is the question.  and if they do, is it enforceable against 
>the CA, or only against the subscriber -- that is the issue.
>
>In particular, I do NOT think that the NR bit says something very 
>noteworthy about what the CA is going to do or not do. Instead, I believe 
>the NR bit is exclusively saying something about the signing party's 
>behavior.  It seems pretty unlikely that the CA (or some independent 
>auditing group) is going to actually go out to the subscriber's premises 
>and investigate their practices, not to mention intrusive.  And I don't 
>think that the NR bit should be construed as implying something about how 
>the CA is going to keep CRL records until infinity, etc.
>
>So at best the NR bit is a representation made by the subscriber to the 
>world via the CA.  In this case the CA is essentially acting as the 
>trusted publisher of a Legal Notice in the paper.  The CA/publisher is not 
>necessarily itself guaranteeing the correctness or truthfulness of the 
>notice, only that it is printed verbatim as received from the 
>subscriber.  Of course if the CA wants to get into the insurance business, 
>or the notary business, or some other business that involves guaranteeing 
>either the user's behavior or the particular transaction, that is a 
>completely different matter, and one that I don't believe could or should 
>be inferred from the NR bit.

Bob,

In essence, I agree with you.  The most that any CA can (currently) say 
about a certificate issued with NR=1 is "The subscriber asked that this bit 
be set."  (One would hope that the subscriber is NOT issued a NR=1 
certificate when this was NOT asked for.)

I was certainly not imagining that the CA would perform any 
"follow-through" on the key usage, but a CA that required the "subscriber 
affidavit of NR responsibility" is a possibility, and would mean something 
more than "they asked to set this bit, whatever it means."

A reputable CA should not issue to me a certificate as Bob Jueneman 
<[email-masked]> simply because I ask for it.  Why should things be 
any different for a request that NR=1?
I would prefer they go further still, and accommodate the "Technical 
Non-Repudiation"
assurances described in Tom Ginden's draft.

By issuing a certificate, a CA should be providing something more than the 
assurance that "string X has been cryptographically bound to string Y, 
under our CA-key".

Reading Aram's comment, though, (multiple certification of a single key,) 
things get muddier still.

___tony___

---

From: [email-masked]
Date: Wed, 11 Apr 2001 21:01:42 +0000

Actually by adding a simple OID structure to the NR bit
this whole problem goes away. The OID represents the type
of NR the bit signifies the state

--
Regards,
Todd
> [email-masked] wrote:
> > 
> > David,
> > 
> > >...Here is the litmus test: do you agree that in
> > >order to validate a signature on an S/MIME message (any message, for
> > >any purpose, signed by any entity), the NR bit must be set?
> > 
> > I certainly don't, because of the ambiguity caused by the uncertain
> > legalisms. I note that the certificates issued by DoD and contained on
> > the
> > Common Access Card, even those issued to federal contractors, DO
> > contain the NR bit, and for that reason I would be quite reluctant
> > personally to use such a certificate.
> 
> 
> That's why, if Steve doesn't want to change the name of the bit,
> definitions are essential.  Are we talking:
> 
> 1) non-binding (ephemeral) authentication vs. binding (persistent)
>    signatures, or
> 
> 2) non-legally-binding persistent signatures vs. legally-binding
>    persistent signatures.
> 
> We haven't had any success in two years of attempting to come to grips
> with 2.  I agree with Ed Gerck that problem 2 is important, but it
> cannot be solved with one bit in a certificate.  I agree with you
> that a bit that claims to address 2 should be deprecated.
> 
> Problem 1 is easily solved with one bit, as long as the definitions
> are unambiguous.  It would be preferable to rename the bit because
> the word NR is an obstacle to common understanding and agreement.
> But if agreement and understanding can occur without changing the
> name, that's fine with me.

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 11 Apr 2001 15:44:46 -0600

Oh, indeed it does.  The OID refers to the Dewey decimal system 
number of a book on the shelf in the public library of Grand Forks,
ND, which happens to be under water right now due to a flood, 
but if you go there and read the book, it will answer all of your 
questions.

"42"

Bob

>>> <[email-masked]> 04/11/01 03:01PM >>>

--
Regards,
Todd

---

From: "Tom Gindin" <[email-masked]>
Date: Wed, 11 Apr 2001 18:50:57 -0400

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

---

From: Peter Williams <[email-masked]>
Date: Fri, 20 Apr 2001 12:05:30 -0700

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:[email-masked]]
Sent: Wednesday, April 11, 2001 3:51 PM
To: Stephen Kent
Cc: David P. Kemp; [email-masked]
Subject: Re: Meaning of Non-repudiation

          Tom Gindin

---

From: Peter Williams <[email-masked]>
Date: Fri, 20 Apr 2001 18:35:51 -0700

<http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf>
http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf
 <http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf>
http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf

Further to my memo earlier today, I inspected the
security target for Entrust/RA and Entrust/Authority for which the UK
Certification
Body recently issued certification report P.153.

The target claims

9.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>
Q.QRIGIN
FCO_NRO.2
This requirement ensures that the TOE generates

 
evidence of origin fortransmitted public key

The TOE must generate evidence of
 
certificates:

origin for transmitted public key

certificates.
 
FCO_NRO.2 ensures that evidence of origin is

 
generated for certificates, CRLs, and ARLs so the

 
identity of the originator can be related to the

 
information.

10.
Q.RECEIPT
FCO_NRR.2
This requirement ensures that the TOE generates

 
evidence of receipt for transmitted public key

The TOE must generate evidence of
 
certificates:

receipt fortransmitted public key

certificates.
 
FCO_NRR.2 ensures that evidence of receipt is

 
generated automatically for public key certificates

 
received via SEP or PKIX-CMP.
 
The certification report indicates that Entrust/RA provides both SFRs:
FCO_NRO(2) and
SFR_NRR(2) (Section O).
 
This implies, given the criteria, that 'the sub-protocol in PKIX-CMP for
returning the
necessary evidence of receipt of a public-key certificate' is "correct". 
 
This implies that, should any "user data" be attached to the message that
delivers the certificate via PKIX-CMP, and the automatic receipt is
generated, then there is now, a citable method for NR for arbitrary data.
Any protocol using receipt-evidentary methods compatible with PKIX-CMP can 
now realistically get certified as doing "proof of receipt with
non-repudiation."

It would be fascinating to know if the PKIX-CMP certificates involved have
the
NR bit set, in practice. Perhaps the Entrust ITSEC engineers will tell us.

Set or not set, there are interesting implications of the certification
report due to the design of PKIX-CMP "receipt-oriented" security services.
 
The CC do say, in informational annexes that: 
 
"The PP/ST author must specify the conditions that must be met to be able to
verify
the validity of the evidence. An example of a condition which could be
specified is
where the verification of evidence must occur within 24 hours. These
conditions,
therefore, allow the tailoring of the non-repudiation to legal requirements,
such as
being able to provide evidence for several years."
 
I have not found the words in the Entrust ST which satisfy this requirement,
yet. When we do, we can see some of the legal implications.
 
We seem to be making some concrete progress on NR, both technical
and legal, thanks to the world of public disclosure of STs.
 
Peter.

-----Original Message-----
From: Peter Williams [  <mailto:[email-masked]>
mailto:[email-masked]]
Sent: Friday, April 20, 2001 12:06 PM
To: 'Tom Gindin'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation