Subject: To Be, or NR To Be ...

From: Tony Bartoletti <[email-masked]>
Date: Mon, 16 Aug 1999 18:41:25 -0700

The more I think about this NR-bit discussion, the more I begin
to question some of the founding motivations.

Often, there is posited a supposedly sharp distinction between 
these three key usages (leaving aside crypto for confidentiality):

1.  Data Authentication (or Integrity).
    The purpose, to tamperproof data during transport.  The data
    as received is the data as sent.

2.  Endpoint Authentication.
    The purpose, to thwart "origin spoofing".  That data really
    did come from X, and was really received by Y.

3.  "Digital Signature".
    The purpose, to enforce "I meant to do that."  I intend to
    be bound by terms contained in the data.

 (Unfortunately, the root mechanism expected to enable these
 assurances is often the same in each case, a digital signature.
 And all hinge on some assumption about who/what wields the key.)

On the surface, it seems reasonable to make these distinctions.
In particular, to (hope to) apply NR only to usage (3).  And yet
it seems that in a contract or transaction of such value that
NR becomes a goal, its benefits could be applied to any and all
of these usages.

If I employed a PK solution to authenticate "remote logins",
why should I settle for a mere "repudiable" login?

And to loosely paraphrase Ed Gerck:  If you think you are talking
with the US President, but in reality it is Saddam Hussein, then
what does having a "tamperproof, data-protected" channel buy you?

These use-cases have overlapping effects and implications, in
particular due to the characteristics of the PK mechanism.

In PK, most all bets hinge upon "who holds the private key".
The only value a certificate NR-bit can hold is one that conveys
some reliable assurance about uniquely identifying the keyholder.

It must have some value beyond "I better be REAL careful with
THIS key, since its (cert's) NR-bit is set." (death penalty cert.)

As Ed has asked, Who is authoritative regarding the NR-bit setting?
And I ask, what are the "lower and upper bounds" to what it being
attested to in each case?

___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: Stephen Kent <[email-masked]>
Date: Tue, 17 Aug 1999 15:12:15 -0400

Tony,

>why should I settle for a mere "repudiable" login?

You mioght have to settle for a repudiable login to the extent that none of
the current schemes for protected sessions (e.g., IPsec, SSL, Telnet
authentication, ...) provide NR for the session.  Yes, one could engineer
and exchange that provided evidence that a user logged in, but current
protocols do not provide good technical evidence of what the user did after
login.

>what does having a "tamperproof, data-protected" channel buy you?

If I have good NR mechanisms, then it may help in my defense that I had
valid reason to believe that I was talking to the president, and thus my
actions were justified.

>some reliable assurance about uniquely identifying the keyholder.

No.  The NR bit is an assertion that the private key is being used in a
fashion that the key holder and CA acknowledge is consistent with
generation of evidence in support of the NR service.  In many respects, it
is the absence of the NR bit that is especially helpful, i.e., to prevent
the use of signed data from authentication or key exchanges from later
being submitted as NR evidence, contrary to the declaration provided in the
cert.

>attested to in each case?

The question of bounds is outside the scope of that single bit, e.g., it is
represented in the CPS or CA policy.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 17 Aug 1999 14:44:28 -0700

>protocols do not provide good technical evidence of what the user did after

Should it not be up to the relying party to consider whether their system
can maintain the NR-trail for actions that occur during after login?

>being submitted as NR evidence, contrary to the declaration provided in the

But this begs the question "Why is this helpful?"  That is, why should
signed data from authentication or key-exchanges NOT be submittable as
NR-evidence?  Why allow repudiation of the authenticity of the data or
its origin?  Indeed, the mathematics supports its own role in the NR
(via key-pair uniqueness) and so the issue still falls to assumptions
about the identity of the "key-wielder" (be it the legal owner or not).

On the other hand, if NR is expected to be a reliable announcement
of INTENT to conform-to-the-terms of the data so-signed, then that
is a different matter.  But the description of the NR-bit as simply
a joint (CA/Subscriber) agreement that "use will be consistent with
providing evidences for NR, modulo CPS" is rather wide open.

Hence my suggestion to add another few key-usage bits, say Red, Blue,
and Green, indicating a joint agreement that key use will be consistent
with evidences for R,G, or B, (see CPS or CA Policy for details.)
 
Really, I am not trying to be difficult here.  Perhaps a clarification
can be afforded by example:

Suppose I have two documents, each says "Will pay Tony $X on day Y".
Document "A" closes with "Signer agrees to the above terms", while
the other (document "B") does not.

I send either document to my debtor, who (I assume) signs and returns
the document (electronically), using a key certified either with or
without the NR-bit set.

This leads to 4 possible pairs (docA or docB)x(NR or not-NR)

Day Y passes with no payment.  I approach my debtor, who says (perhaps)
"I don't know what you are referring to.  I made no such agreement.)

In court, would the pair (docB,NR) be any stronger than (docA,not-NR)
given equal assurances that the signing key was uniquely in the hands
of the debtor?

How can the CA's certification of the key, in one state or another,
serve to better sway the court regarding an activity between the
subscriber and the relying party?  I cannot help but feel that by
precluding an NR-key from use in "mindless authentication", one
either expects that it will thus not be as loosely held, or that
the given CPS can somehow lend force to the idea that the subscriber
knew what they were getting into by requesting an NR key.

It just seems to me that many other bits could be added that would
be just as useful (meaning defined according to CPS and CA Policy).

Regards,

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Aug 1999 18:28:57 -0400

Tony,

>about the identity of the "key-wielder" (be it the legal owner or not).

Two things:
	- One wants the provide the user with the ability to make a choice
bnetweenuse of a key which is declared explicity as being supportive of NR
vs. not.  I think this is an important feature to retain.

	- Many authentication protocols do not provide NR; only some that
make use of signature are suitable as a start.  if one wants to explicitly
design protocols that provide NR and are used for bind-time user
authentication. then it seems OK to do so and to then use an NR-labelled
cert as part of them.  Again, making this explicit is appropriate.  But,
because some auth protocols that involve signatures could be used to create
sigs for hashs of things that a user never saw, it would be a mistake to
talk in terms of auth protocols being used for NRTT in general.  One has to
be quite careful here.

>providing evidences for NR, modulo CPS" is rather wide open.

It's not as concrete as some might like, but I think it is at a suitable
level of abstraction for 2459, gievn our desire to relegate NR policy
details to CA policies.

>with evidences for R,G, or B, (see CPS or CA Policy for details.)

Why do this vs. using a policy OID?

<snip>

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Aug 1999 18:32:30 -0400

Tony,

>can maintain the NR-trail for actions that occur during after login?

Now you are moving into an area where we no longer have crypto support for
NR.  The protocols I cited permit either end to generate an audit trail for
data that was not sent by the other party, and thus they do not provide a
strong basis for NR (using "strong" in the technical sense, e.g., "strong
authentication.")

<snip>

Steve

P.S.  I forgot to respond to teh first paragraph in my previous message.

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 17 Aug 1999 16:58:35 -0700

At 06:28 PM 8/17/99 -0400, Stephen Kent wrote:
[I wrote]
>Why do this vs. using a policy OID?

Prescience!  I REALLY WAS going to ask that same question.

Why is NR being treated differently?  Its just another key usage bit.

My feeling is, it is because the "market" is clamoring for NR, whatever
they may intend by that, and that we humor them by providing an NR bit,
reserved exclusively for that mysterious "NR" thingy.

However, by doing so, we take the first step down that slippery slope,
and invite the protocol-vs-policy debate we see today.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 17 Aug 1999 17:57:00 -0700

At 06:32 PM 8/17/99 -0400, Stephen Kent wrote:
[I wrote]
>strong basis for NR (using "strong" in the technical sense, e.g., "strong

I don't claim to be expert on all the existing protocols.  But certainly
there could arise protocols that provide for crypto-strength throughout.
In such a case, it would seem that an "NR-authentication" might be required
at the outset of the session, else the chain has no anchors.

But the entire discussion is still confused, I believe, by the often
unspoken distinction between "repudiating that you took some action"
versus "repudiating that you did so intentionally, understood your
exposure to liability, etc."

If I can be assured, by whatever means, that you are the sole-wielder
of a private key, then the existence of its signature on any object
(login-token or mortgage contract) assures me that it was you that
interacted with said object so to affix signature.  And no NR-bit
is required to make "the fact" of this signature "non-repudiable"
(modulo current mathematical strengths).

It is only when NR hopes to manage "intent" or "knowing liability"
that it has any additional force.  But here, I have yet to understand
how its setting, protocol-wise, helps to effect this end.  It may
help in precluding key use in "lightweight or automatic" operations,
authentications, it is true.  But of what value?  If these lightweight
operations are less interested in NR, why employ keys that are
"identity-certified" at all?

If I want to be sure that its "really really" you, then why should I
not want the ability to establish later, in court if necessary, that
it was "really really" you, (independent of your intent or actions)? 

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Aug 1999 10:25:19 -0400

Tony,

>at the outset of the session, else the chain has no anchors.

Usually, we provide NR only in the context of a specific application,
because the semantics of the application are an important part of NR.
Since one does all sorts of things during a "login session" it may be less
appropriate to suppoort NR at the Telnet level.  However, I don't dispute
your suggestion that it might be possible to fashion NR at this granularity.

>exposure to liability, etc."

Agreed.

>(modulo current mathematical strengths).

No, the NR bit is not intrinsically required for this from a purely
crypto-technical perspective.

>"identity-certified" at all?

I do think that precluding key use in these non-NR contexts is valuable,
for the reasons I cited earflier, e.g., such apps might permit acquisition
of signatures on hashes for data the user has never had access to.

>it was "really really" you, (independent of your intent or actions)?

It's a two-way street.  If all communicationm we engage in was
non-repudiable, some of that communication would never take place; the
political characterization is "plausible deniability."  So, sometimes I
NEED to authenticate myself to gain access to a resourec, but that does not
mean that I want to make use of NR-capable protocols for the interaction.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 18 Aug 1999 12:58:06 -0700

A number of conclusions are emerging. I present
some facts to substantiate them. I suggest
a change to PKIX-QC.

(a) strong authentication during entity authentication (login)
is very useful. It may prove that one trespasses on an information
resource, regardless of what one damages during
the act of trespass. The availability
of NR on that security service is as useful to
information owners as proof of origin of interpersonal
messages is to msg recipients.  IPSEC Client, and SSL
client Auth, when applied to network applications such
as VPNs and https, both support login. Should the packets be
stored (as all American ISPs are now required to
do for 180 days by the US authorities to allow for
surveillance and prosecution of Americans), non-repudiation
services in these contexts should be recognized by PKIX to
potentially prevent denial of the act of network/resource
login/trespass.

Therefore, the NR bit should be allowed
in IPSEC client, and SSL Client auth certs, where the
extended keyusage extension is suitably set
for those application contexts. 2459 does not support this
legitimate NR application, and it clearly should. When PKIX-QC
name-constrained certs are used, furthermore in this
context, such signature devices may meet CEC
directive requirements, additionally.

(b) Today, a Korean name was affixed to a pkix mailing
list memo.  My browser popped up a dialogue, enabling
me to download software to display that name in the
character set of native speaker. Removal of enforced
US-English cultural imperialism is a nice internet-centric
direction, IMO! The software was  protected via the
Authenticode application, featuring
a PKCS7 digital signature msg & 2459-conforming certificates.
The signature has been timestamped, records kept, and the CA
highly audited to rigorous standards following PKIX-IV.  PKIX
2459 does not allow that signature maker (software publisher)
to enable users to use a NR service for that act. Why
not? Clearly PKIX is insufficient, and not consistent
with its technical NR model, and application focus now
admitted.

My conclusion is, that to embrace the technical NR
model being advanced in Steve's mail, we could
should mandate in PKIX-QC a model in which two existing
extensions must be used in collaboration when dealing
with NR: the keyusage NR bit can signal what Steve
asserts, and the extended key usage  bit can label
the necessary application context. (IPSEC
Client, for example). Authenticode can fit into this
scheme, simply by defining itself an extended key
usage OID. (One notes that other Publisher security
services have already adopted this scheme, and the
Internet's PKIX-like public CA PKIs works just fine;
working code (deployed worldwide) can be shown, if
needed.)

To cut through to the changes necessary to address this
discussion thread, PKIX-QC might incorporate the
rule discussed above; it is limited to technical
matters, and does not address policy matters, or
regulatory environments. It does link NR to applications.

As most US state laws specifically do not provide recognition
for the highest grade of personal signature (those on wills for
example) where NR value is most recognized by consumers,
bringing PKIX into line with a world in which NR bit is made
inherently  application sensitive would move use forward both
architecturally, and to properly address such as the
Authenticode PKI security  services actually used by tens
of thousands of people  each and every day. For free, the FBI
can also use those same Internet packets to prosecute people for spreading
viruses, or trespassing - with less chance they can repudiate the technical
evidence.

Peter.

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 7:25 AM
> To: Tony Bartoletti
> Cc: [email-masked]
> Subject: Re: To Be, or NR To Be ...
>
>
> Tony,
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Aug 1999 11:35:29 -0400

Peter,

I am leary of your suggestion wrt NR for logins. Which specific values in
IKE and SSL protocol exchanges provide evidence of the time at which the
exchange took place, i.e., distinguishing in a user verifiable fashion,
which login instance the evidence pertains to?  Absent an ability to
establish which login session the evidence pertains to, the evidence
merely supports the contention that the user in question executed a login
at some point prior to the time at which the evidence was timestamped,
right?  For both IPsec and SSL (with client certs), a user who is
successfully authenticated and granted access to a system must have been an
authorized user at some time. So, what good is evidence that the user did
log in at some time, if we can't establish what time the login took place?
I worry about the transition from crypto-strong evidence that a login took
place, to evidence (based on procedural security and minimal technical
safeguards) that the login in question is tied to a session during which
something unlawful happened.  I don't like to give technical credibility to
the overall process when we know that there is a big disconnect between the
potentially non-repudiable login vs. the audit trail that follows. This
sort of analysis underlies my contention that security protocols designed
for login do not necessarily contain the features we would want for NR.

I agree with the notion that use of extended key usage bits can provide
better specification of the context in which a cert is intended to be used.
That's precisely the reason for having this extension. I'm not sure that we
have enough evidence yet to mandate such use, and it may be preferable to
leave this decision to the relevant application WGs.

In the specific case of the Authenticode example, I agree that it might be
reasonable to amend 2459 to allow the NR bit to be set as well as the DS
bit.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 20 Aug 1999 11:37:20 -0700

> Sent: Friday, August 20, 1999 8:35 AM
> To: Peter Williams
> Cc: [email-masked]
> Subject: RE: To Be, or NR To Be ...
>
>
> Peter,
>
> which login instance the evidence pertains to?

We learned, from the differences in older and more modern ISO
definitions of (technical) NR, that there are communication-oriented
and event-oriented modes of NR. We are concerned here with the case of mere
login, or SSL or IKE connection-establishment more correctly.
We note that like of these are subject to pen-trap surveillance
laws in the  US, allowing for warrantless-surveillance of
traffic patterns and storage of the data.

The crypto handshake elements, and definition of connection, and the
point at which an SSL-connection is established in SSL/TLS
is clear; I assume IKE is as competent.

Absent an ability to
> right?

As we know, effective NR services requires that there be
timestamped records; the records collect together all the technical
data that would be used to (re-)validate the underlying
proof-grade security service.

We know from US law, that CALEA-enforced ISP collection
of packets represents effective timestamped records; and these
include the cleartext initial handshake messages of the
SSL connection establishment procedure. Nothing in ISO
NR definitions requires timestamping be a cryptographic
process; only that the binding of records/packets to time is
assured. Pen-trap evidence has long relied upon the assurances
of telephone company records, and (now) ISP records of packet
flow/content, to bind time to peoples location and intent
to communicate with another. Warrants may be required
for the session content, but the cleartext connection data
records are available without so much as a hassle.

On this basis, the initial packet of the SSL handshake
procedure is effectively timestamped, TODAY; the 180 day records
backup-capability obligation faced by American ISPs also provides
infrastructure for effective data archival, for long-term NR
records. The cryptographic security of the SSL handshake ensures
that all SSL messages in the handshake protocol are
irrefutably bound to a unique instance of the procedure, and
the first record in that sequence is timestamped by
the ISP, to all intents and purposes. The crypto process built
into the handshake’s challenge-response of course provides assurance
that the resulting agreement to SSL-conect is proof of a
SSL-connection event. The potential NR services and
required assurances derive from the trustworthy
records environment, as described, as one would expect
of any NR service option.

 For both IPsec and SSL (with client certs), a user who is
> authorized user at some time.

This is a systems/communication usage of security, possibly
requiring NR benefits. But this is not our concern, in this
bind/login thread.  We are concerned merely with the undeniable
“event” of binding ; the “I was undeniably here”, doctrine.
This event is the foundation of trespass on networks, information
or other property. By definition, if you trespass, you
are not authorized; you may still be identified, however. And it is
this implied lack of authorization, WITH strong
identification, that one  seeks in the form of irrefutable
evidence, to pursue a network property trespass case.

So, what good is evidence that the user did
> log in at some time, if we can't establish what time the login took place?

As we know, effective NR requires records, binding time
to the messages. We know the means by which this
is performed is outside the definition of
proof-grade security services, and is not limited to
PKI techniques. We know this time assurance is available
to day for US Internet packets from ISP records. Other
comemrcial techniques may also come along, from TTP ISPs - wherein
user IP data flows pass within virtual IP tunnels
whose own IPSEC AH headers convey authoriative current time
asserted by the tunnel-provider’s TTP routers. The outer
tunnel, and its stored packets, constitue the electronic
records for the tunneled data.

> for login do not necessarily contain the features we would want for NR.

We must disgaree on this fun topic, and its at the model
level. You evidently continue to concentrate on the resulting
session, not the connection event. Trespass is concerned with
the initial connection “event” (which is apparently not subject
to 4th Amendment protections in the US.) This initial event
may be the illegal or tortuous act, and accountability thereto
requires no system-oriented audit trail or other
session-data handling. What damage was done
in the session is irrelevant, nor is the evidence (or lack
thereof) relevant to a application layer-entity strong
binding procedure (otherwise known as
user/network login). You were there, and you
were not supposed to be! What you did there,
with or without authorization, is irrelevant
for trespass.

> leave this decision to the relevant application WGs.

I am happy with this delegation of authority to other WGs,
and private IP-application makers, by normal extension. I would
ask that PKIX, in the  next 2459 revision, if any, remove any
prohibition or advice against use of of the NR bit in application
WGs, including those leveraging IKE or SSL/TLS. Should IPSEC+APP WG define a
VPN network application relying upon the IKE handshake in the course
of a layer-7 (ACSE-like) connection procedure, and define
use of the NR bit, the PKIX standards should not stand in
the way, or assert an authoritative position.

> reasonable to amend 2459 to allow the NR bit to be set as well as the DS

This was discussed before, and the list agreed with
my assertion then, as you evidently do now. Unaccountable
offline msgs got the bit removed, presumably.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Aug 1999 16:12:21 -0400

Peter,

Your long discussion of other asepcts of NR evidence for user sessions is
consistent with my observation, and my rationale for NOT wanting to assert
NR for such applications.

If law enforcement is willing to rely on logs created by ISPs, system
operators, etc. as evidence of someone's activity, then they will continue
to do so irrespective of our technical recommendations re use of the NR
bit.  We know that the evidentiary mechanisms described in your message are
very much tamperable; they rely extensively, if not exclusively, on
physical, procedural, and personnel security of many individuals.  The
legal system can easily make use of the signed data from an SSL or IKE
exchange as part of this evidence, irrespective of whether the NR bit is
set.

I think it would be a mistake to grant the imprimatur of crypto-based NR to
this larger process by endorsing the use of the NR bit in these application
contexts.  We know better, in a technical context, and I think we ought to
take a stand here, distinguishing crypto-based NR in its most secure forms,
from other forms of NR evidence that can, by fiat, be used.

As an analogy, I cite the long held position of some in the banking
community that the service provided by a DES-MAC is NR. We all know that
either party to a transaction can create a MAC value that will pass as
genuine for traffic purportedly transmitted by the other party. Yes, the
use of two-party key control and audit logs at each end lend increased
credence to the claim that a logged MAC was really created by the other
party, but we have seen evidence of bank fraud on a larbe scale (remember
BCCI) and we know that multi-party authorization is not foolproof,
especially when tamperable computers are involved.

I beleive it is appropriate for this WG to stake a claim for the technical
high ground in dealing with these issues, which translates into not
endorsing use of the NR bit in these circumstances, and not modifying our
technical, crypto-based definitions for NR.

Steve

---

From: "tog" <[email-masked]>
Date: Fri, 20 Aug 1999 13:57:09 -0700

----- Original Message -----
From: Stephen Kent <[email-masked]>
To: Tony Bartoletti <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 18, 1999 7:25 AM
Subject: Re: To Be, or NR To Be ...

> >exposure to liability, etc."

Actually the agrument seems to be based in whether the NR bit is a protocol
flag to the application or for use within the protocol itself as part of the
protocol process.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Aug 1999 17:17:25 -0400

Peter,

>records are available without so much as a hassle.

There are a number of technical detail errors in the above paragraph.
First, CALEA in not in force yet.  Second, the terminology is
"pen-register" and "trap and trace."  Third, a warrant is required for this
sort of monitoring, but it is an easier warrant to get than the title III
warrant required for monitoring content.  Also, a title 3 warrant is very
hard to get and may be issued only for felonies enumerated in a list that
is very small.  For example, just breaking into a gov computer won't get a
judge to sign a title 3 warrant.  Then, of course, there are FISA warrants,
...

>of any NR service option.

We are an American ISP and we DO NOT maintain a 180-day record of anything
more than some very minimal dial up access data items, NOT content. (I
verified my suspicion on this by checking with the folks who are
responsible for our operational security.)  Also, we do this only in our
role as a merchant, selling dialup access, in case of credit card
dispuites.  I'm not sure who you were thinking of here.  Maybe AOL, a
content provider, not an ISP?

>evidence, to pursue a network property trespass case.

A user employing a cert for ID will be rejected as a prospective accessor
or a system or network unless the authentication exchange is valid AND the
user is authorized by the system/network.  Attackers don't usually try to
gain access using their real IDs.  So, the case of interest seems to be an
authorized user who later denies having used the resource in question in an
unauthorized fashion.

>records for the tunneled data.

Oh, give me a break!  Again, as an ISP, I can assue you that we do not
envision wasting precious router resources doing anything of this sort.

>with or without authorization, is irrelevant

See my note above, i.e., tresspassers don't use their own names when
trespassing!

>the way, or assert an authoritative position.

We'll see.

>offline msgs got the bit removed, presumably.

I don't recall that "the list agreed" on this topic, but then the length of
many of your messages precludes reading them to the end :-).  If the 2459
authors agree, then we're OK.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 20 Aug 1999 14:24:20 -0700

>NR for such applications.

[snip]

>technical, crypto-based definitions for NR.

from 2459:

     "The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing."

Steve,

What part of the above definition for the nonRepudiation bit implies
a technical, crypto-based definition for NR?  And what exactly is a/the
crypto-based definition for NR, aside from DigSig-Strength-Authentication?

I think the sub-phrase:

  "protects against the signing entity falsely denying some action"

is poor.  First, I would drop "falsely", since that is merely added
as a gratuitous "for instance, falsely".  Second, there needs to be a
clarification for what is meant by "some action".  In particular, it
should mean either "the act of having knowingly signed" or it should
mean "the intent to be bound to the terms contained under signature".
It should not be "take your pick".

If one or the other were settled upon, I think developers would have
a much better time forging software that enforces usage consistently,
(because sponsors could be more clear about the intended usage in the
software requirements.)

Otherwise, another bit is needed.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 20 Aug 1999 14:46:22 -0700

At 01:57 PM 8/20/99 -0700, tog wrote:

[snip]
>flag to the application or for use within the protocol itself as part of the

Agree also.  But since the cert is just another signed object, the
application layer is free to read it as well, or to listen to a provided
protocol flag.  At either level, it would be better to have a more
specific intent for the bit.  And unless its intent is better specified,
there will always wage debate over which layer is the intended endpoint.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Aug 1999 18:28:25 -0400

Tony,

>crypto-based definition for NR, aside from DigSig-Strength-Authentication?

This WG establishes standards for public key crypto technology.  Thus, 2459
and associated PKIX documents should always be interpreted in that context.
As I mentioned in a recent response to Peter, other forms of NR evidence
may be acceptable in a court, but that does not mean that we ought to
endorse their use when we understand the technical differences between NR
evidence based on strong crypto and, for example, audit logs.

>It should not be "take your pick".

I tend to think of the action as knowlingly applied the signature, which is
the technical aspect of the process analogous to a wet signature.  The
second things cited above seems one step removed and is probably not best
represented by a bit in a cert.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 20 Aug 1999 16:47:14 -0700

>evidence based on strong crypto and, for example, audit logs.

I agree that a distinction can be made between "PK-crypto-evidence" and
"other forms of NR evidence."  But I can only assume that the meaning of
the nonRepudiation bit is that it toggles "the protocol is obliged to
cooperate (cryptographically) with services that intend to provide for
(ostensibly cryptographic) non repudiation capabilities".

Unfortunately, saying that the NR-bit (cryptographically) toggles the
enablement of cryptographic NR services somewhere" isn't very helpful.
(Or, put another way, its *too* helpful, open to wide interpretation.)

>represented by a bit in a cert.

Then, as a first cut, I would replace the paragraph with:

   "The nonRepudiation bit is asserted when the subject public key is
    used to verify digital signatures within a cryptographic service
    which protects against the signing entity denying a cognizant role
    in the signature generation, excluding certificate or CRL signing."

Or, in a more positive form:

   "The nonRepudiation bit is asserted when the subject public key is
    used to verify digital signatures within a cryptographic service
    which intends to secure the cognizant role of the signing entity
    in the signature generation, excluding certificate or CRL signing."

Of course, some may argue that "cognizant" should be replaced by one of
"active", "culpatory", etc.

Thoughts?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Ed Gerck <[email-masked]>
Date: Fri, 20 Aug 1999 18:40:33 -0700

> evidence based on strong crypto and, for example, audit logs.

Mathematics does not provide security. The technical difference between evidences
of past actions (what you call NR)  based on strong crypto and, for example, audit
logs is none to me if Khadaffi provides both.

Calling "evidences of past actions" by the name "non-repudiation" and pretending
they are more credible if based on certificates is simply arguing the process when the
attribution is at fault.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Aug 1999 10:33:34 -0400

Ed,

>they are more credible if based on certificates is simply arguing the

Math does provide a basis for security; it the foundation for the public
key crypto that underlies the focus of this WG.  I'm sorry that you dislike
the term "non repudiation" but we are NOT changing this "term of art" in
this standards context.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 24 Aug 1999 10:27:17 -0700

Stephen Kent wrote:

> Ed,
>
> >Mathematics does not provide security. The technical difference between
> >evidences of past actions (what you call NR)  based on strong crypto and,
> >for example, audit logs is none to me if Khadaffi provides both.
> >
> >Calling "evidences of past actions" by the name "non-repudiation" and
> >pretending they are more credible if based on certificates is simply arguing the
> >process when theattribution is at fault.
>
> key crypto that underlies the focus of this WG.

Math is not self-secure -- anything you can do in math the attacker can also.  The
question is thus not whether math is the foundation for public-key algorithms.  But,
for example, who has the private-key or who/what do you trust.  By promoting
reliance on math, one promotes reliance on no differential between user and
attacker.  What you say is the same as those that simply want  "more bits" in
their keys but have their systems wide open to ActiveX controls -- they also
think that math does provide a basis for security.

But, it does not -- math is simply a tool to security.

> I'm sorry that you dislike the term "non repudiation" but we are NOT changing
> this "term of art" in this standards context.

I do not dislike the term "non-repudiation" at all.  In fact, I think that the concept
of non-repudiation can be very useful and even essential.  But when correctly used,
not as a misnomer to indicate a "NR bit" that has a PKIX description which everyone
(including you) agrees is neither necessary nor sufficient to indicate
non-repudiation.  And in math, when A is neither necessary nor sufficient to B
then this means that B exists independently of A.  In other words, non-repudiation
does not depend on the state of  the NR-bit as it is described in 2459/PKIX -- and
this is both a mathematical and a technical affirmation one should not ignore.

And, as I commented before, if the broken semantics of the NR bit  is not corrected
(and there are three options to do this -- either delete it, or define it truly as
non-repudiation, or rename and redefine it), then the market will be free to
understand the NR bit in many different and conflicting ways -- if this list exchange
in the past month can provide but a sample of them.  Which will be very much
equivalent to deleting it from the spec because "hands off that NR bit" will be
safer, also to the CAs.

So, doing what you propose is certainly one of the three options above. And,
not a bad one comparing how it was one month ago.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Aug 1999 11:10:13 -0400

Ed,

>
>Math is not self-secure -- anything you can do in math the attacker can also.

But the math underlying cryptography, and public key cryptography in
particular, introduces an asymmetry into what the users must do vs. what an
attacker must do.  So, your statement above is true, but not relevant to
the question of the security of digital signatures, the foundation of PKI
crypto-security.

>The question is thus not whether math is the foundation for public-key
>algorithms.  But,

I agree that the math foundation is but part of the system, and it is
usually not the part that In would attack.  However, from a technical
security perspective, we focus on standards that don't address all of the
other security assurance issues.  We have promulgated such standards in the
past (e.g., the TCSEC, ITSEC, and now the Common Criteria) and even the
IETF has published informational documents such as the site security
handbook.  However, the focus of this WG is protocols (not that part 4 of
PKIX is informational, not standards track).

>But, it does not -- math is simply a tool to security.

Agreed, modulo the choice of preposition.

>equivalent to deleting it from the spec because "hands off that NR bit"

Although I agreed that use of the NR bit is neither necessary nor
sufficient, in isolation, I have also given many examples of where the bit
of of significant benefit in an overall NR scheme.  I'll avoid continuing
the debate of whether the PKIX notion of NR is corect or not, relative to
your notion.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 25 Aug 1999 09:34:41 -0700

Stephen Kent wrote:

> Ed Gerck wrote:
> >algorithms.  But, for example, who has the private-key or who/what do
> >you trust.  By promoting reliance on math, one promotes reliance on no
> >differential between user and attacker.  What you say is the same as those
> >that simply want  "more bits" in their keys but have their systems wide
> >open to ActiveX controls -- they also think that math does provide a
> >basis for security.
>
> other security assurance issues.

Steve:

A short remark. In classical systems (e.g., as existing in single networks), security
is localized and your approach might work with some success.  In internets, we
deal with networks of networks -- where there is no common reporting point
and no deterministic communication path, and where no one controls both
ends of a communication channel.  That is why reliance on math (even
asymmetric crypto) falls short for internet security -- so that protocols need to
provide the "glue" for math to work.  This glue is simply missing if you don't
address at least some of the other *relevant* security assurance issues -- such
as what MUST the system really do or MUST NOT really do when that NR bit
is on/off, and what do these actions mean in a language that does not have to say
that the bit name is not what the bit enables.

> Agreed, modulo the choice of preposition.

Math is simply a tool to [achieve] security.  This simply stresses the notion
that use of math alone does not provide for security but may help to achieve
it. So, calling it "mathematical" does not equate to "secure", even if the
crypto is asymmetric.  Who is at the other side? Is that key really from the
sender? Is the key still valid? Questions soon appear and it becomes clear that
public-key cryptography has indeed solved the problem of public-key security
but not the problems of public-key acquisition, recognition, revocation,
distribution, re-distribution, validation and, most importantly, key-binding to
an identifier and/or key-attribution to a real-world entity. Communications can
yet not be verified, neither for origin authentication nor for data-integrity --
communications can be private but not yet secure. Of course, a private
communication with a thief is not secure just because it is private.
[http://www.mcg.org.br/whycert.htm]

> of of significant benefit in an overall NR scheme.

I do not recall any use of the "NR bit" in isolation and I don't think it
would be usable either.  The statement that the NR bit is neither necessary nor
sufficient to provide NR services had no indeed no opposition in this WG --
and this statement simply proves that NR services are independent of such
NR bit, q.e.d.

In regard to your examples where the current description (and name) of the NR
bit is of  "significant benefit" in an overall NR scheme, I recall that you have not
replied when those examples were rebutted and parallel schemes could be shown
where the NR bit was significantly ambiguous and even obscure in its usage.

> I'll avoid continuing the debate of whether the PKIX notion of NR is corect or not,
> relative to your notion.

I would not say this is "my" notion or "your" notion, Steve.  This seems not to be
a case for stressing sensus, but for stressing consensus.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Aug 1999 13:20:50 -0400

Ed,
>that the bit name is not what the bit enables.

A response to your short remark: I've designed and developed Internet
security systems for over 20 years, before most people knew what the
Internet was.  I served on the IAB for over a decade, approving Internet
standards.  Don't presume to lecture me on what the Internet is or how to
secure communication in this environment.

As for the question of what the system MUST or MUST NOT do relative to the
NR bit, that is a local matter, in standards parlance.  What 2459 specifies
is the circumstances under which the bit should be asserted, but it imposes
no requirements on what the software operating on behalf of an RP MUST or
MUST NOT do.  That will be determined by locally-determined policies, maybe
with realtime human inputs, depending on the context. The extent to which
this can be automated will be a funciton not only of the features that we
establish in technical standards, but also the way in which CAs, users, and
RPs choose to take advantage of those features, including local laws and
personal risk tolerance.  We can't standardize much of this, certainly not
in the PKIX and IETF contexts.

<snip>

>and this statement simply proves that NR services are independent of such

Yes, one could offer NR irrespective of the use of the NR bit. One could
also do so independent of the use of certs and public key crypto.  So, ...

>where the NR bit was significantly ambiguous and even obscure in its usage.

Ed, at this point, I don't pay much attention to the lengthy messages you
are sending to the list.  Your arguments often employ terminology in a
fashion that is inconsistent with the generally accepted use in the PKI
arena, and in our standards in particular.  The arguments sometimes are
hard to follow (to understand their relevance to the technical focus of
this WG), often discuss legal issues that are outside the scope of this WG,
etc.  It's just not worth the time and effort.  Private communication with
several other folks who are normally substantative contributors to the list
confirms that they have adopted a similar response to your contributions,
i.e., they decline to devote any more time to responding to your postings.
So, don't interpret the lack of rebuttal to your extensive submissions as
acquiescence.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 25 Aug 1999 10:37:39 -0700

>the debate of whether the PKIX notion of NR is corect or not, relative to

In some ways, the NR-bit is like marketing bottles of wood alcohol that
are simply labeled "alcohol".  The designation is "not necessary" to those
that have performed investigation and use the liquid for cleaning purposes.
The designation is "not sufficient" for those who assume that the liquid
is grain alcohol and can be taken internally.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL