Subject: Redefining the Key Usage bits 0 and 1

From: "Trevor Freeman" <[email-masked]>
Date: Sun, 5 May 2002 22:21:42 -0700

Santosh,
Stop the spin doctoring semantic examples. We are not talking about NR here. You are proposing redefining the scope of the key usage bits 0 and 1. That is changing semantics. If you truly want to express this kind of policy in certificates, that is fine and a reasonable request, and you have several courses of action open to you.
1) Define the new semantics for use in an extension of identical structure to the existing key usage extension but use a different OID to identify the extension.
2) Define new OIDs for use with the EKU extension.
3) Define an entirely new extension.
4) Define a new policy qualifier (Russ will love that option)

I really don't care which course you choose to achieve your objective, but you cannot redefine the semantics of the existing key usage extension and retain the same identifier. That course of action as they say is a dead parrot. It is deceased. It is no alive. It is kaput. It will not fly. It is pushing up daises.
Get the picture.

Trevor 

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Saturday, May 04, 2002 6:16 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Trevor:

I am not trying to define new mechanisms.  I am simply suggesting how to
differentiate between the two bits that has some technical meaning.  If
you know of any technical meaning between the two bits, let me know.

Compliant implementations that set both bits so that the same key is
used for signing data and signing challenges can continue to do so.

Thus, in order to validate if I am changing the semantics of the
implementation and/or if my proposal will fly in the face of backward
compatibility, we need to determine how the current implementations use
the two bits.

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 8:21 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Santosh,
Your suggestion is not backwards compatible with the exiting standard.
If you want to introduce new ways to further restrict what can be signed
with a digital signature key then I suggest you look to the existing key
usage extension mechanisms and if you still want to define a new
mechanism justify why since those extension mechanisms are inadequate
since they were designed for such a purpose. Changing the existing
semantics of existing extensions is out of scope no matter how
inadequate those semantics may seem. Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [email-masked]; 'Omer Hasret'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [email-masked]; Omer Hasret
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [email-masked]; 'Omer Hasret'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [email-masked]
Subject: RE: Meaning of Non-repudiation

"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[email-masked]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[email-masked]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[email-masked]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|

Olaf,

See below,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: vendredi 3 mai 2002 12:43
> To: [email-masked]
> Cc: 'Santosh Chokhani'; [email-masked];
> [email-masked]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a 
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, 
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)

> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[email-masked]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[email-masked]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[email-masked]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[email-masked]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he 
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only for 
> authentication and let others who want to implement their own NR 
> systems do it by other means. (Some ways to do this have been posted 
> on the list a day or two days ago.) And I really do not think this as 
> a "dictation" because you don't have to use that bit just because its 
> name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating 
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [email-masked]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not 
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a 
> > random challenge.
> >
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [email-masked]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as 
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR 
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over 
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [email-masked]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an 
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will 
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing 
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove 
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be 
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit 
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in 
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that 
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a 
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 6 May 2002 19:53:48 -0400

Trevor:

This is likely to be my last e-mail on the topic.  I do not mean to
belabor the point.  But, which of the four scenarios are out of line
with current implementations?

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Monday, May 06, 2002 1:22 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Redefining the Key Usage bits 0 and 1

Santosh,
Stop the spin doctoring semantic examples. We are not talking about NR
here. You are proposing redefining the scope of the key usage bits 0 and
1. That is changing semantics. If you truly want to express this kind of
policy in certificates, that is fine and a reasonable request, and you
have several courses of action open to you.
1) Define the new semantics for use in an extension of identical
structure to the existing key usage extension but use a different OID to
identify the extension.
2) Define new OIDs for use with the EKU extension.
3) Define an entirely new extension.
4) Define a new policy qualifier (Russ will love that option)

I really don't care which course you choose to achieve your objective,
but you cannot redefine the semantics of the existing key usage
extension and retain the same identifier. That course of action as they
say is a dead parrot. It is deceased. It is no alive. It is kaput. It
will not fly. It is pushing up daises. Get the picture.

Trevor 

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Saturday, May 04, 2002 6:16 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Trevor:

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 8:21 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Santosh,

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [email-masked]; 'Omer Hasret'
Cc: [email-masked]
Subject: RE: Meaning of Non-repudiation

Trevor:

-----Original Message-----

Santosh,

-----Original Message-----

Olaf,

See below,

-------------|
-------------|