Subject: proposed key usage text

From: Tim Polk <[email-masked]>
Date: Wed, 17 Nov 1999 11:50:51 -0500

<bigger>

Folks,

In hopes of settling the key usage debate (insert laughter here) Russ
Housley and I are proposing some minor additions in the key usage text. 
We recognize that complete consensus regarding the nonRepudiation bit
does not (and may never) exist.  However, this text represents a 
compromise position that should make everyopne equally unhapppy.

Please review this text and decide if you can *live with it*.

Thanks,

Tim Polk and Russ Housley 

----Proposed text for 4.2.1.3 Key Usage

4.2.1.3  Key Usage

   The key usage extension defines the purpose (e.g., encipherment, 
sig-

   nature, certificate signing) of the key contained in the 
certificate.

   The usage restriction might be employed when a key that could be 
used

   for more than one operation is to be restricted.  For example, when

   an RSA key should be used only for signing, the digitalSignature

   and/or nonRepudiation bits would be asserted. Likewise, when an RSA

   key should be used only for key management, the keyEncipherment bit

   would be asserted. When used, this extension SHOULD be marked criti-

   cal.

      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

      KeyUsage ::= BIT STRING {

           digitalSignature        (0),

           nonRepudiation          (1),

           keyEncipherment         (2),

           dataEncipherment        (3),

           keyAgreement            (4),

           keyCertSign             (5),

           cRLSign                 (6),

           encipherOnly            (7),

           decipherOnly            (8) }

   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key

      is used with a digital signature mechanism to support security

      services other than non-repudiation (bit 1), certificate signing

      (bit 5), or revocation information signing (bit 6). Digital 
signa-

      ture mechanisms are often used for entity authentication and data

      origin authentication with integrity.

      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.

      In the case of later conflict, a reliable third party may deter-

      mine the authenticity of the signed data.

      Further distinctions between the digitalSignature and nonRepudia-

      tion bits may be provided in specific certificate policies.

      The keyEncipherment bit is asserted when the subject public key 
is

      used for key transport.  For example, when an RSA key is to be

      used for key management, then this bit shall asserted.

      The dataEncipherment bit is asserted when the subject public key

      is used for enciphering user data, other than cryptographic keys.

      The keyAgreement bit is asserted when the subject public key is

      used for key agreement.  For example, when a Diffie-Hellman key 
is

      to be used for key management, then this bit shall asserted.

      The keyCertSign bit is asserted when the subject public key is

      used for verifying a signature on certificates.  This bit may 
only

      be asserted in CA certificates.  If the keyCertSign bit is

      asserted, then the cA bit in the basic constraints extension (see

      4.2.1.10) MUST also be asserted. If the keyCertSign bit is not

      asserted, then the cA bit in the basic constraints extension MUST

      NOT be asserted.

      The cRLSign bit is asserted when the subject public key is used

      for verifying a signature on revocation information (e.g., a 
CRL).

      The meaning of the encipherOnly bit is undefined in the absence 
of

      the keyAgreement bit.  When the encipherOnly bit is asserted and

      the keyAgreement bit is also set, the subject public key may be

      used only for enciphering data while performing key agreement.

      The meaning of the decipherOnly bit is undefined in the absence 
of

      the keyAgreement bit.  When the decipherOnly bit is asserted and

      the keyAgreement bit is also set, the subject public key may be

      used only for deciphering data while performing key agreement.

   This profile does not restrict the combinations of bits that may be

   set in an instantiation of the keyUsage extension.  However,

   appropriate values for keyUsage extensions for particular algorithms

   are specified in section 7.3.

</bigger>

---

From: [email-masked]
Date: Wed, 17 Nov 1999 20:00:33 -0500

In the message below, my points assume that the NR bit is to be set
even for services which meet no more stringent requirements than those of
"technical non-repudiation".

          Tom Gindin

Tony Bartoletti <[email-masked]> on 11/17/99 06:49:55 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Tim Polk <[email-masked]>
cc:   [email-masked]
Subject:  Re: proposed key usage text

[Tim Polk provides, from 4.2.1.3 Key Usage]:

   falsely denying some action, excluding certificate or CRL  signing.

Apologies to Tim Polk and Russ Housley, but this NR paragraph is easily
as wishy-washy as the original, if not more so.  Are we to suppose that
the NR bit could NOT be used to protect against a presumed signer
"honestly"
denying some action?  Are we to suppose that if NR=0, then a reliable third
party is somehow precluded from determining the authenticity?

Importantly, is the term "signing entity" intended to signify the
"ActiveSigner", the "SubscriberInFact" or the "SubscriberOfRecord"?
(See definitions below.)

It doth seem to me that the NR-bit asserts nothing of any substance.

One might as well add a "crimeFree" (CF) bit with usage specified as

  "The crimeFree bit is asserted when subject public key is used to verify
  digital signatures for transactions that are not a perpetration of fraud
  or other illegal activities.  In cases of dispute, get a good lawyer."

Of what value is this to anyone?  Would criminals seek to obtain certs
with CF=0 to avoid liability?  Would CF=1 lead you to increased trust
in the signature? For what possible reason?

[Tom writes]
>     Mine replaces the clause starting with "which protects" by : "which
>provides evidence that a given object was signed by the private key
>corresponding to a given certificate which was valid at the time of
>signature. "
>
>     The issue comes down to which assertions are necessary to constitute
a
>non-repudiation service.  In particular, is a service still a
>non-repudiation service if the principal evidence that the signer is also
>the subject of the signing certificate is derived from the CA?  Also, is a
>service still a non-repudiation service if there is not conclusive proof
>that the signer was adequately informed of the content of the document
>being signed?
>
>          Tom Gindin

Tom,

I agree that we need to ask about the utility of the assertion made wrt NR.
Your version seems to boil down to "a cert for this key was valid at time
of signature", which seems like an odd assertion for a CA to make before
any such signatures have been generated.

Since it is the CA which signs, and hence asserts the key usage binding,
one has to ask what assertion the CA can make that will make the given
certificate more "useful" to some (possibly independent) NR service.

[Tom Gindin]   The assertions I listed were assertions made by the NR
service.  The CA is merely stating that the NR service may use this
certificate.

This is a question in two parts:

  a.  What CA-asserted key usage restrictions are reasonably enforceable
      by the CA (hence worth more than simply "the CA wishes...").

  b.  What subset of (a) above are of value to any independent NR service.

In particular, is the NR service provider interested in binding a given
signature act to the: (my definitions)

1   SubscriberInFact:
        The person who presented themselves as "X" to the CA in order to
        receive a certificate that says "key owned by X"

2   SubscriberOfRecord:
        The person named as subscriber in the certificate.  That is, the
        "X" in "key owned by X"

3   ActiveSigner:
        The person actually effecting a signature to occur, in particular,
        independent of whether or not they are the "owner".

Consider that if person Y presents herself as X to a CA and obtains a
fraudulent certificate, but then has the key stolen and used by Z,
all three of the above may be different people.  In a certificate fraud,
we might expect (1) and (3) to be functionally the same, and yet it
seems that much of NR is focused upon binding the act to (2)!

[Tom Gindin]   When parties 1 and 3 are different, key compromise has
occurred and a revocation is usually expected.  When parties 1 and 2 are
different, a fraud has been perpetrated on the CA.  Also, the CA can't
enforce the distinction between keyEncipherment and dataEncipherment either
- the applications must.

Should NR=1 be the CA's vouching for a (functional) equivalence between
some two of the above?  But what CA is of use that does not intend to
assert that the "SubscriberInFact" is exactly the "SubscriberOfRecord"?

[Tom Gindin]   Actually, I think there is at least one CA which is not
asserting that.  The effective use of such a CA is that if you see two
transactions from the same key you can assume that they came from the same
party, and that the party wished to be described as having a specific name.
However, I think we can assume that any CA who issues an NR cert is
asserting that the SubscriberInFact is the SubscriberOfRecord, at least to
a rather high confidence level.

My suggested version was originally:

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

But in retrospect, it suffers the same unspoken assumption that the
term "signing entity" is understood.

Additionally, the term "cognizant" may be too strong, inappropriate,
or unneeded.  Perhaps "active" or "liable" would better state the
case.

Which of these nine versions of assurance with regard to signature
generation really represent NR?

1.   "to secure the ACTIVE role of the ActiveSigner" (that's redundant!)
2.   "to secure the ACTIVE role of the SubscriberOfRecord"
3.   "to secure the ACTIVE role of the SubscriberInFact"
4.   "to secure the LIABILITY of the ActiveSigner"
5.   "to secure the LIABILITY of the SubscriberOfRecord"
6.   "to secure the LIABILITY of the SubscriberInFact"
7.   "to secure the COGNIZANT role of the ActiveSigner"
8.   "to secure the COGNIZANT role of the SubscriberOfRecord"
9.   "to secure the COGNIZANT role of the SubscriberInFact"

I imagine that a plaintiff is only interested in liability.  Who cares
if you were cognizant, or even took an active role, if you end up liable
anyway?  The plaintiff just wants to get paid.  The question is then
"Who is the 'YOU' that the plaintiff will go after?  Is it the YOU that
pushed the signature-button?  Or the YOU that is named in the certificate?
Or the YOU that obtained a fraudulent certificate in someone elses name?

[Tom Gindin]   Now I'll get legalistic.  No statute should ever create
liability for the SubscriberOfRecord if he or she is not the
SubscriberInFact - a much more likely rule would be to create liability for
the SubscriberInFact if he or she can be found, and if not the liability
rests on the CA or perhaps the RP.  In general, the only duty the
SubscriberOfRecord will have when he or she is not the SubscriberInFact is
to prove that.  Legislators or judges will set standards for the required
level of proof of that statement - PKIX won't.  Again, how much proof is
needed for a claim of key compromise and who bears responsibility if the
claim is late are legal matters.  Liability is not the only issue in NR,
because the purpose of some NR transactions is to produce clear evidence
that a given statement was made by the ActiveSigner at a known time - an
example would be a progress report submitted on a given date, which could
then be introduced by a contract supervisor in support of a claim that
progress had been misrepresented.  If there was a signed receipt, such a
report could be introduced by the person who wrote the report to prove that
he had advised the supervisor of the difficulties in a timely fashion.  As
for the distinction between ACTIVE and COGNIZANT roles, different
jurisdictions will require different standards for responsibility - all the
way from "no willful misrepresentation by RP" up to "multiple, clearly
worded and manually accepted dialog boxes".  We don't know which
jurisdiction will pick which standard, and for which agreements.

Perhaps in the end, the NR service should "secure the liability of
someone who can pay for the damages."

The more I think about it, the less it seems that a CA should be
centrally involved in NR assertions.

___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: Tony Bartoletti <[email-masked]>
Date: Wed, 17 Nov 1999 17:22:17 -0800

Tom,

>any such signatures have been generated.
 
I was really overstating the problem.  It is OK for the CA to assert that
the USAGE IS INTENDED IN SUPPORT OF SERVICES that would provide assurance
that "a cert for this key was valid at time of signature".

I guess what really bothers me is the implication that, for any other usage
bit settings, such a service is not-to-be supported.  That, in essence, one
could not otherwise secure such a service, or the CA does not agree to
cooperate with such an endeavor.

Are not ALL key-usage bits an assertion by the CA that "If the key is used
in a manner that violates the key usage, then the CA is (possibly) freed
from some terms stated in its CP/CPS?"  And that this may be of some legal
consequence to an RP or NR-service?

If so, then the NR-bit question becomes "What elements of CA responsibility
become voided when NR=1 but the "signing entity" turns out to be someone
other than expected (in particular, an "owner" obtaining a certificate
through fraudulent credentials.)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 17 Nov 1999 18:32:32 -0800

Tom,

I think I really agree with your version, as being something that tends
toward "substance", especially given the standing alternative.

I sometimes doubt that a CA-asserted "NR bit" can represent anything
useful.  But if I am proven wrong, it would be a shame to waste this
bit on the fuzzy "Simon Says it OK to use this cert for X" when there
is no clear sense of what X represents.

I just wish I had a better notion of what a CA expects to be held to,
if anything at all, for signing with NR=0/NR=1 at my request.

Free Hints Accepted :)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Nov 1999 09:15:13 -0500

Hi Aram.

 >>       (bit 5), or revocation information signing (bit 6). Digital  signa-
 > What is happens when both the digitalSignature and nonRepudiation bits are
 > set? Does one of them take precendence?

I guess that you missed our point altogether.  There is no precedence.  If 
both the digitalSignature and nonRepudiation bits are set, then the public 
key may be used with a digital signature mechanism to support 
authentication and integrity and it may also be used to verify digital 
signatures used to provide non-repudiation.  One public can might be used 
for both purposes.

Russ

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 19 Nov 1999 15:29:43 -0800

At 06:02 PM 11/19/1999 -0500, [email-masked] wrote:
[snip]
>     One other possibility would be for a rule to be applied to all new
>protocols other than those explicit barring NR certificates as follows: the
>suggested nonce MAY have the sequence (standard repudiation attribute)
>appended to it before signing.  It would be SEQUENCE { OID
>id-authentication-exchange, NULL }.

Tom,

Would the inclusion of (standard repudiation attribute) above be something
that can be toggled by the signer upon receipt (perhaps invisible receipt)
of the nonce?  Or would it be strictly controlled by the challenger?

My thought, as a sort of "Safety Feature", would be to set my signing
application to ALWAYS toggle to "repudiable", unless I forcefully override.

Do any extant protocols allow the "challengee" to append to a given
challange?  Seems only to require the challenger do a tiny bit of parsing
to ensure the original challenge was indeed contained.  Thus timeliness,
replay protection and POP are still satisfied.  And if the repudiation
attribute can "trump all others wrt NR", there is no longer the fear of
signing challenges, some portion of which may be "unseen".

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: "Aram Perez" <[email-masked]>
Date: Mon, 22 Nov 1999 09:14:24 -0800

Hi Lynn,

> 
> 
> we are doing something like that for AADS radius (i.e. being able to upgrade
> something like 99% of the current internet ISP authentication infrastructure
to
> digital signature authentication). The strategy is that the ISP sends a
> challenge string ... basically somehting like "please authenticate 'userid'"
> with a time-stamp/nonce (in lieu of the "please enter password" message), the
> user then adds their own nonce, signs it and returns it.

Having the party being authenticated add their own nonce is a step that many
authentication protocols forget and hence the situation I described.

[snip]

Regards,
Aram Perez

---

From: "Aram Perez" <[email-masked]>
Date: Mon, 22 Nov 1999 09:21:20 -0800

David Kemp wrote:

>> But how do you distinguish between what use was intended? If someone
>> captures a message that I signed for "authentication and integrity" and
>> another message that I signed for "non-repudiation", how does a third party
>> distinguish which use was intended?
>
>
> If you care about separating challenge signatures from signed messages,
> you will use different keys, with DS set for one and NR set for the other.
>
> There's no point in defining a "precedence" to handle the case where
> both bits are set, because no one who cares will set both.  Those
> who choose to use one key for two functions are accepting the risk
> that an authentication server will send them a contract and their
> client will blindly sign it.
>

This is one of my big security pet peeves: Why do we, who claim to be
security experts, allow non-security persons to take what we would consider
unacceptable risks?

Regards,
Aram Perez

---

From: "Aram Perez" <[email-masked]>
Date: Mon, 22 Nov 1999 09:35:42 -0800

Al Arsenault wrote:

> Aram Perez wrote:
>> Hi Russ,
signa-
signing.
>> I have seen many authentication protocols that require the party being
>> authenticated to sign a challenge (that is supposed to be a random number or
>> a nonce). Now suppose that I'm trying to get access to a system that instead
>> of sending me a random challenge, sends me the following message: "I agree
>> to sell 1000 shares of Apple at $10.00 per share." My software will blindly
>> sign the message and send my certificate which has the DS and NR bits set.
>> Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
>> third party that I was only trying to do authentication and not
>> non-repudiation?
>>
>> Regards,
>> Aram Perez
>
>
> AWA:  Aram, that's what the rest of the non-repudiation system is for.
> Your key has been shown to have been used to sign a message.  You do not
> want to take the action indicated in the signed message.  Among other
> things, the following questions have to be answered:
>
>  1 - was it really you that caused the signature to occur?  Was your key
> compromised, or your workstation used by one of your co-workers without
> your knowledge/permission?  What evidence exists that it really was or
> was not you?
>
>  2 - did you know what you were signing?  Should you have known?  What
> evidence is there that you took a conscious effort to understand and
> verify before signing?
>
>  3 - was the key used appropriate for the message signed?
>
> The value of the NR bit only enters into #3 here.  And I suspect you
> will find a lawyer willing to argue for you and against you regardless
> of the value of that bit.
>
> A non-repudiation system consists of a lot more than just one bit in a
> certificate.

I totally agree with your statements. I have previously stated that for
non-repudiation you need to look at the "system" and not just the bit. And
since this bit seems to cause more confusion and hence discussion than any
other bit, I personally believe it should be deprecated (as I have also
stated previously). If we who claim to be security experts can't agree on
the meaning and value of the bit, how are programmers trying to implement
the standard supposed to know what to do?

Regards,
Aram Perez

---

From: "Heimberg, Jim" <[email-masked]>
Date: Mon, 22 Nov 1999 12:37:18 -0500

I have been following this discussion for a while, but wanted to clarify
what I read here.  So, for the sake of clarity, do you mean that in an X.500
based system, authentication is based on directory information and
nonrepudiation is based on the user's information?  If that is so, it might
clarify the discussion.

Our understanding is that use of STRONG binding in the certificate will
result in authentication being based on the certificate, but use of SIMPLE
binding will result in authentication based on the directory information.
Hope that helps.
Jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, November 22, 1999 11:31 AM
To: Stefan Santesson
Cc: Aram Perez; [email-masked]
Subject: Re: proposed key usage text

At 10:47 AM 11/22/99 +0100, Stefan Santesson wrote:
>So to me there is no such thing as signing messages just for authentication
>purpose but NOT for non-repudiation. Not in real life.
>
>Can anyone show me a REAL implementation where a messages are signed, where
>this is strictly NOT non-repudiation.

Yes.  X.509 was originally written for X.500 Directory Strong 
Authentication.  This is a case where authentication, not non-repudiation, 
is implemented.

Russ