Subject: Re: Possible solution?

From: "David P. Kemp" <[email-masked]>
Date: Wed, 11 Aug 1999 10:22:35 -0400 (EDT)

> From: Alfred Arsenault <[email-masked]>
> 
> AWA:  Here's the situation:  a company builds an extranet for
> communication with its subscribers/customers/contractors, using the
> Internet as the transport mechanism and thus fulling under the PKIX
> purview, if there is such a thing.  The company decides as a matter of
> policy that all certs issued for the extranet will have the NR bit set,
> because the company wishes to provide the service of non-repudiation in
> its dealings.  On the paper forms, which users fill out to request
> initialization into the system, users are told all about this.  Thus,
> when the user later sends in the CMP or CMC request message for a
> certificate, there is no indication about the setting of the NR bit. 
> Such an indication is not needed.  I think that this is the case to
> which Steve Kent was referring, and I think that the company's position
> would have a chance of passing a court case.  Yes, in the case of public
> TTP, the CA should not arbitrarily set bits without the user's being
> aware of that, but remember that the public TTP is only one of the
> situations we need to support.

Al,

  My personal opinion is that saying "the company sets the NR bit
because it wishes to provide the service of non-repudiation in its
dealings" is something that PKIX should not touch with a ten foot
pole.  IMO, Key Usage bits should be *EXCLUSIVELY* for meanings that
can be interpreted by machines without making any reference to the
intent of users, CAs, CPSs or CPs.  If we want to make distinctions
about what the company wishes to provide, we should use the CP or other
extensions to communicate it, not the keyUsage extension.

In other words, the X.509 definition: "for verifying digital signatures
used in providing a nonrepudiation service" should be interpreted to
mean "providing a nonrepudiation *security service*", where the universe
of possible security services is the usual list: confidentiality, integrity,
authentication, nonrepudiation, ...

Because CMS signedData provides "the security service of nonrepudiation" or
"technical nonrepudiation", CMS applications which support the keyUsage
extension should require the NR bit to be set in order to create or
verify signedData.  CAs which set the NR bit are saying only that the
certs are usable for CMS signedData and other applications which use
digital signatures persistently applied to user data.  Users who
request certs with the NR bit set are simply requesting a cert which
can be used with S/MIME and the like.  They are *NOT* requesting a cert
which would enable "company non-repudiation" for some S/MIME messages,
as opposed to a different cert which would disclaim "company
non-repudiation" for other S/MIME messages.

If we in the IETF can get our act together enough to say that:

* "CMS signedData provides technical nonrepudiation and requires certs
  with the NR bit set", and

* "TLS does not provide technical nonrepudiation of user-level data,
   and when it uses digital signature certs those certs must have the
   DS bit set"

then we will have done the lawyers and legislators a profound service
by keeping our noses out of their business.

As my grandmother used to say of me in the kitchen, "you're a precious
little help".  She meant it purely in the complimentary sense, but I
can't escape the feeling that this discussion is of precious little help
to anyone in a policymaking position.

---

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 11 Aug 1999 14:26:37 -0400

Dave,

> ----------
> From: 	David P. Kemp[SMTP:[email-masked]]
> Reply To: 	David P. Kemp
> Sent: 	Wednesday, August 11, 1999 10:22 AM
> To: 	[email-masked]
> Subject: 	Re: Possible solution?
> 
[snip]

> IMO, Key Usage bits should be *EXCLUSIVELY* for meanings that
BF:  If machine interpretations should be *exclusively* devoid of
user/CA/CPS/CP intent, then should we not eliminate the keyUsage extension
from PKIX as a pre-emptive strike?  What other extensions do you feel should
have meanings solely interpreted by machines?  On the other hand, what
current extensions do you feel should be used to communicate user/CA/CPS/CP
intent?  What new extensions do you feel may be required to communicate
user/CA/CPS/CP intent? 

[snip]

> by keeping our noses out of their business.
BF:  What is "technical nonrepudiation"?

Thanks,

Bill

---

From: "Bill Brice (listserv)" <[email-masked]>
Date: Wed, 11 Aug 1999 14:08:32 -0500

If one wishes to programmatically determine the meaning
of an NR bit in a cert, it should consult both the 
key usage extension (for presence of NR), and the
certificate policies extension for the presence of a
cert policy OID that is understands. 

This requires, of course, that the software process
understand the implementation of NR under that CP
referenced by the OID.

-Bill Brice, CEO
alphatrust.com

> -----Original Message-----
> From: Flanigan, Bill [mailto:[email-masked]]
> Sent: Wednesday, August 11, 1999 1:27 PM
> To: 'David P. Kemp'
> Cc: [email-masked]
> Subject: RE: Possible solution?
> 
> 
> Dave,
> 
> > ----------

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 11 Aug 1999 12:07:54 -0700

>BF:  What is "technical nonrepudiation"?

Someone correct me if I'm wrong :)

"Technical Nonrepudiation" means that, modulo the current strength and
state of mathematics and (say) factoring:

   Data "D", public key "Y" and (mathematically) verified DigSig "S"
   constitute "proof positive" that the corresponding private key "X"
   collided with data D somewhere.

"Repudiation" of this conclusion would constitute repudiation of the
algorithm's quality of mathematical strength.

"Intent-to-sign" and "ownership-of-key" are not considerations.

But of course, this is nothing more than what is meant by "authentication"
in digital signatures.  So, unless someone can explain how "technical
non-repudiation" is more than this, it is a misleading redundancy (IMHO).

Someone distinguish "technical NR" from "technical authentication" for me,
and I'll will stand corrected.

___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: "David P. Kemp" <[email-masked]>
Date: Thu, 12 Aug 1999 13:40:41 -0400 (EDT)

> From: "Peter Williams" <[email-masked]>
> 
> (Note an "electronic signature" is not restricted to
> a digital signature security procedure; an S/MIME envelopedData
> message protected by persistent KEA certificates and the
> KEA key agreement security procedure does just as well,
> as does a MAC exchanged using a notarized symmetric key
> issued according to X9.17. Both of these latter procedures
> may also satisfy NR requirements, additionally.)

As Tony said,

> I agree that this is "technical NR".  The point is, it would seem to
> be uninvolved with issues of private key ownership and protection.

By design, KEA private keys are not held exclusively by the owner.
Because envelopedData may need to be unenveloped at sometime in
the future, and unenveloping requires private keys, the private
keys will be backed up.  This is in contrast to signedData where
no private keys are required to verify the signature.

So if the term "electronic signature"* applies to applications which
require disclosure of the private key in order to verify the signature,
I would say that keypairs for "electronic signature" mechanisms which
are not digital signatures should not have the NR bit asserted.

Symmetric-key-based "arbitrated digital signature schemes" (H.A.C.
11.107), which require an unconditionally trusted third party to
participate in signature generation and verification, are not within
the scope of PKIX or any other PKI.

---
* Since I am not familiar with a rigorous definition of electronic
signature, I can't say if KEA is, in fact, one.  I'll take your word
that it is.