Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor PKIX. (Was: RE:ASN.1vs XML (usedto be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))

From: "Aram Perez" <[email-masked]>
Date: Wed, 11 Aug 1999 14:48:35 -0700

Alfred Arsenault wrote:

> Holy criminoley!  I'm now officially dazed and confused - not to mention
> hopelessly lost.  I'm trying to figure out how Sean and I are gonna
> write this one up in the PKIX Roadmap, and folks, I ain't got a clue.
> What the heck is this argument about, and what is it we want to
> accomplish, anyway?

Having "work" to do, and not wanting to contribute anymore to your confusion
(or anybody's else), these will be my last comments on the issue (but I
retain the right to repudiate this statement ;):

[snip]
>
> So, the question that seems to have arisen is:
>
>  Does the presence of the non-repudiation bit in the key usage
>  bits field do more harm than good?  That is, given that a
>  certificate with the non-repudiation bit turned on can be easily
>  used in a transaction for which the service of non-repudiation
>  is clearly not provided, is the bit so misleading as to be
>  harmful in a well-designed, well run system based on a PKI using
>  these certificates?
>
> If that's the question under discussion, then I've got at least a
> tenuous grasp on it.

This is the question/issue in my opinion (besides using the term
'non-repudiation'). And in my opinion, the bit does more harm than good. No
matter whether the bit is set or not set, no matter if the bit exists or
not, I can always repudiate a transaction/communication/etc that is signed
with a digital signatures (with the definition pointed out by Steve Kent).
What the digital signature provides is strong evidence for the rebuttal of a
repudiation.

>  If there's more, than somebody needs to enlighten me.

If and when you are enlighten, send some of that enlighten my way ;-)

>
> Now, we have to bear in mind that this question needs to apply across
> all models of PKI that might be put onto the Internet (for which we're
> supposed to be developing "standards").

But this is the PKIX WG which only concerns itself with the model of PKI
based X.509 and not with "all models of PKI" which would include the PGP
model.

>  That is, it should apply in the
> model where we're using a trusted third party such as Verisign,
> GTE-Cybertrust, or Thawte to provide services.  It should also apply in
> situations where a PKI is being run entirely internal to an
> organization, using software and/or hardware from folks like Entrust or
> Microsoft.  It should also apply in situations that combine elements of
> these two.  What is appropriate in one situation may not be appropriate
> in others.
>
> IF it's the case (and I emphasize the IF, there) that we're still trying
> to answer the question above for all of the situations above, and write
> a PKIX profile/successor to RFC 2459 that best supports those
> situations, then I'll stick with my previous position:  the NR bit is
> useful, and should be left in the PKIX profile. It's usefulness includes
> at a minimum the ability for a CA to signal to a relying party that a
> given certificate should NOT be used in a transaction requiring the
> service of non-repudiation.

I disagree because your statement seems to imply that the service of
non-repudiation can only be provided if the NR bit is set. I (or whoever)
should be able to use a "complete system" where I contractually agree that I
would not repudiate any transaction/communication/etc signed with my digital
signature (independent of whether certificate has the NR bit set or reset).

[snip]
>
> AWA:  I'm darned if I understand why having an NR bit turned on allows
> an issuer to "impose NR to all messages purportedly from a subscriber --
> in bulk and for all risks."  Yes, I guess that you could design a system
> such that, if the NR bit was turned on in the subject's certificate, the
> RP would automatically assume that the service of non-repudiation was
> being provided.  Such a system would be horribly wrong, IMNSHO (and to
> use Steve's "technical term").  There are far too many other
> considerations, which are far beyond the scope of PKIX.  You have to do
> the system engineering, or you ain't secure.

I'm confused. If the NR bit is set, how do you distinguish between the
"service of non-repudiation" is being provided and when it's not?

>
>> > >In other words, the NR bit should be used to denote a service, never to
>> > >provide it in any form (however weak).
>> >
>> > We agree that a bit cannot provide the service, just denote the suitability
>> > of the certificate as a component of the service.
>>
>> If we really agree, then we must agree that the NR bit cannot stand for
>> any semantics in regard to NR -- it must be merely a pointer to indicate
>> that a suitable NR service can be queried, which service can be denied
>> or granted prior to the reliance act. Not always granted as nowadays.
>>
>
> AWA:  I wish someone would point out the words in the PKIX documents
> that say, "if the NR bit is on, then NR is automatically provided."  I
> haven't found 'em, and I'd support their being changed.

See my confusion just above. You seem to be saying "If the NR bit is no,
then NR is *NOT* automatically provided". How does the relying party know
when NR is being provided?

[snip]
>
> AWA:  Again, if there are words in the PKIX documents that say or
> strongly imply that any transaction signed by a cert with the NR bit on
> automatically comes with the service of NR, then those words should be
> changed.  But I haven't found them.  Hey, I've been wrong before, I'm
> willing to be shown what I've overlooked.  But, honestly, I can't see
> this.

Ditto my previous comment.

[snip]
>
>  A certificate subject and a relying party (who relied on that
> certificate in carrying out some transaction) go to court over that
> transaction.  The relying party asserts that, based on the certificate
> in question, other evidence it possesses, and the basic qualities of the
> technology, the subject is the one who did something, and thus is
> liable.  The certificate subject asserts that, due to some circumstance
> and based on its own evidence (possibly even including its private key,
> posted on a web site as the solution to an RSA-1024 factoring
> challenge), it is not liable - perhaps this is all fraudulent activity
> on the part of the relying party itself.  The question is:  whom does
> the court believe, and how does it arrive at that belief?
> That's going to be a hard question to resolve, especially the first
> couple of times.  If the RP's evidence consists solely of the subject's
> cert with the NR bit set, the RP is most likely going to lose.

I agree 100% with you here.

>  If, on
> the other hand, the subject shows that its cert had the NR bit off, and
> the subject's CA asserts that that meant that this cert was never to
> have been used in transactions that require the service of
> non-repudiation, then I suspect that that's a strong point for the
> subject.  It may be overcome by other evidence, but it's a starting
> point.

I mostly disagree. The issue will not be decided on solely whether the NR
bit is set or reset. It will be decided on the body of evidence (and who has
the best lawyers).

>
> -- my own opinions.  As if anybody - especially my employer - would
> agree with them!!!

I agreed at least with one point!

Regards,
Aram Perez

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 13 Aug 1999 11:36:35 -0600

Steve, 

There was a fairly extensive discussion which I think I initiated, but
it may have taken place on the cert-talk list -- I just don't recall.

Bob

>>> Stephen Kent <[email-masked]> 08/12/99 03:55PM >>>
Larry,

I do not recall agreement on this list consistent with your suggestion that
the NR flag would tigger an application to invoke  some form of user alert
re signing.

Steve