Subject: Re: rat hole, was Re: Non-Repudiation

From: "David P. Kemp" <[email-masked]>
Date: Mon, 16 Aug 1999 16:38:29 -0400 (EDT)

> From: Ed Gerck <[email-masked]>
> 
> A secondary but overshadowing mistake is, as I have also commented, that
> this IETF WG may be connected with an extension of IETF protocols over
> the domain of applications and, even, what "user intent" is. Language in the
> current text says :
> 
>  " ...to provide a non-repudiation service which protects against the signing
>   entity falsely denying some action"
> 
> and now we have user intent ("falsely denying") as a parameter in an IETF
> spec, besides the empty word "protects".

Ed,

If this discussion is a rat hole, you must take some partial
responsibility for injecting irrelevancies into it.  "User intent" has
no connection with "denying" - I can deny driving above the speed
limit, or I can deny intending to drive above the speed limit while
admitting that in fact I did.  Radar evidence says absolutely nothing
about my intent, yet provides generally-accepted protection against the
first denial.  The word "protects" itself is no more empty than any
other word in a dictionary.  A signature obviously does not protect
data -- software and people and procedures and mathematical algorithms
protect data -- yet in common parlance it is always said that keys
protect data and no one is confused about what is meant.

RFC 2459 does not have "user intent" as a parameter.  The X.509
certificate format contains nothing with respect to user intent.  A CA
claims nothing about user intent WRT a specific transaction when
signing a cert with the NR bit (or any other bit) asserted; the CA
claims only that the key may be used for a particular purpose.

If you have a piece of data covered by a digital signature, you have a
piece of evidence that a particular private key was used to generate
the signature.  The type of data is relevant to PKIX: it could be a random
number used in a challenge-response entity authentication protocol, or
it could be something with intrinsic meaning (a message).

The NR bit is set if the *purpose* of the signature is to create an object
that can later be shown to have been signed by the private key.

The DS bit is set (and NR unset) if the *purpose* of the signature is
something else (such as an authenticated session), notwithstanding the
fact that protocol byproducts might be used later in forensic analysis.

User intent and many many other factors are critically important when
using PKIs and digital signatures to support business processes.  But
it is not the purpose of the Internet X.509 PKI Certificate and CRL
Profile to describe business processes.  Perhaps we need a "pki-talk"
mail list.

---

From: Ed Gerck <[email-masked]>
Date: Mon, 16 Aug 1999 14:44:33 -0700

"David P. Kemp" wrote:

> If this discussion is a rat hole,

Unfortunately, you misread and I did not say or imply that this
discussion is a rat hole, neither did I coin the term.  Pls read
my original text, after I commented that the present NR bit
setting and definition could "create lateral damage, besides
their own technical and legal damage":

} Already in another thread here, we can read [Russ Housley]:
}
} "The setting of the nonrepudiation bit is a rat hole, as you can see on
} other threads on ietf-pkix.  It does not impact cert path validation, so I
} would like to avoid that rat hole...."

Thus, clearly, the term 'rat hole' in regard to NR was coined by Russ
and it is clear that he did not mean the NR discussions either, but the
current definitions used in setting the NR bit in the PKIX spec.

> you must take some partial responsibility for injecting irrelevancies into it.

Also, I fail to see any irrelevancies in any of my emails posted in this
context here -- including this one. The first relevant purpose of this
email is simply to show again that Steve Kent has brought it upon
himself to have the setting of the NR bit described by other persons
as a "rat hole" -- for example, by using Tina Turner to exemplify
what he believes is the NR trust model or by his other misleading
comments referred to in the 'rat hole' message.  So, no, Steve did
not have my help in order to inject irrelevancies into his debate.

Indeed, I have waited to see if the situtation would improve and
then, when it did  not,  decided to answer to the point (not bullying)
when I saw that the obvious was being negated once again.

In regard to legal issues, yes, they must not be involved in IETF protocols
but they must not be ignored either. Otherwise, those protocols will be
either "illegal" or useless.  Since I have no interest whatsoever in IETF
politics, I guess I am also rather free and unbiased when saying it.

And, IMO, the lawyers will get their "revenge" and field day when they realize
how insecure, misrepresented and misleading those products are out there
and then go after the companies that produced them or that were involved
in their production, and that effected misprision by setting 'standards' that they
said were 'true', 'fine' and 'safe' but they themselves knew they were not as
proved by list archives, emails, etc -- if the tobacco lawsuits can teach
us anything.

I tried to show otherwise by stressing the positive qualities -- not by
being uncorteous, irrelevant, bullying in debate, or less than deliberative,
which could be taken as an excuse by a person to cut off debate, but that
was BTW already cut off IMO.

Thoughtful, group-aware and courteous messages are IMO the only way
to try to put things in a useful track.  If you read anything else in my
messages, pls read again.  Sometimes we must share differences, which
are sometimes (unfortunately) distorted by email flatness that then they
get reconstructed with too much emotion.

Again, I am not questioning anyone's authority or the Chair's authority or
using my email as a personal argument vector (not even this one) but I
am pointing out that the Chair of this WG has overstepped that limit
defined when bullying a debate -- that  limit over which people may just
politely bow and let the way clear to the cliff.

I indeed believe this limit has been reached in this WG in regard to Steve's
comments and I have shown it by quoting several instances where I have
rather let the mistake pass uncommented than going for a dog fight with
Tina Turner.  Further, recognizing that this limit was overstepped is the
first action needed in order to solve it -- which must be done by those
that brought it upon themselves, of course.  And, that is how I ended
my message:

} So, in all fairness,  I think this WG has reached a reasonable intersubjective
} understanding of the NR issue and it is now up to the spec scribes to make
} the next move and correct the old spec version. That is what this WG is for,
} no?

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Mon, 16 Aug 1999 15:52:42 -0700

> > spec, besides the empty word "protects".

[snip, already commented]

> "User intent" has no connection with "denying" - I can deny driving
> above the speed limit, or I can deny intending to drive above the
> speed limit while admitting that in fact I did.

But the language used is "falsely denying", not denying.  And, in both
versions (Dave: I am bundling here my reply to your other msg on X509
vs. 2459 NR text):

1. X.509, "12.2.2.3 Key Usage field":

    "b) 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);"

2. RFC 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."

So, either section goes into the mistakes of stating intention (viz, "falsely
denying some action")  and providing a blank service ("protects against")
and IMO this adds nothing that will be missed elsewhere in the specs.

But, will the solution be a simple deletion of the word "falsely"?  No, because
such "protection" is not possible at all *within* PKIX.  This is not like an
umbrella that "protects" against rain or cryptography that "protects" against
eavesdropping. This is a nonrepudiation service which is NOT provided in
PKIX by that pesky bit and hence setting it neither "protects" nor fails to
"protect" anything that PKIX can reach, provide, enforce or even negate.
In particular, as said here several times, the "nonrepudiation bit" is neither
necessary nor sufficient for nonrepudiation --so, not seting it can also allow
NR to be applied.

As Paul Koning commented today:

"It doesn't seem like a good idea to have  a bit [NR] whose name suggests
a specific application, but it doesn't actually support those applications, and
if it supports other things, those things aren't what the name implies."

Further, the nonrepudiation bit is NOT "used in providing" any
nonrepudiation service described elsewhere in the spec or even elsewhere
else (pls, no pointers to the abstract, wrong and useless ISO definition of
NR).

This is also what is called, in technical writing terms, a "dangling clause":

dangling clause:  to occur in a sentence without having a normally expected
syntactic relation to the rest of the sentence <the word climbing in
"Climbing the mountain the cabin came into view" is dangling>.

Good for poetry, when ambiguity and obscurity are useful and allows each
reader to use their own imagination, but it is a capital sin in technical and
legal writing.

> RFC 2459 does not have "user intent" as a parameter.

As above, "falsely denying" is an user intention -- Webster:

false:  intentionally untrue <false testimony> b : adjusted or made so
as to deceive <false scales> <a trunk with a false bottom>
c : intended or tending to mislead <a false promise>

>  The X.509 certificate format contains nothing with respect to user
> intent.

Ditto, the same mistake as above in "12.2.2.3.b" -- and, it is not the
only place where X.509 makes this mistake but this is not relevant to
NR so I will skip it here.

> A CA claims nothing about user intent WRT a specific transaction when

Perhaps, not even this.  As we all know, this is where PKIX sends the
reader to the each CA's CPS -- so what a CA 'claims' is off-topic to
the PKIX NR discussion, IMO.

> that can later be shown to have been signed by the private key.

This is not what the spec says, as above. But, even if it did, one would
have some other questions and three cases for bit-on and three cases
for bit-off which would need to be well-defined in the specs:

1. Who is authoritative for the nonRepudiation bit state, the
CA or the subscriber?

2. Can a CA use PKIX in order to permit or prohibit a
particular subscriber certificate from being used in a
transaction?

3. Take a certificate with the nonRepudiation bit on
-- what can the relying-party depend upon: (i) in regard
to the certificate;  (ii) in regard to a transaction signed
with the certificate; (iii) in regard to the transaction being
repudiated?

4   Take a certificate with the nonRepudiation bit off --
is this a negation, or a declaration of non-existence, or a
declaration of an ignored feature?  To clarify, if the NR
bit is off, does it mean that the NR is denied, or that
NR does not exist, or that NR can still be provided if so
declared elsewhere?

5. Are questions (1-4) beyond the scope of PKIX?

These are the main technical  questions that need to be and can
be addressed here, IMO. Dangling clauses will not help -- this
is not pkix-poetry ;-)

Cheers,

Ed Gerck