Subject: Re: Meaning of Non-repudiation

From: "David P. Kemp" <[email-masked]>
Date: Wed, 08 May 2002 10:49:41 -0400

Bill,

I have no problem with X.509 and PKIX following Trevor's approach.
Deprecate (using the strongest possible terms) the existing KeyUsage
OID, and define a new KeyUsage OID identical to the old one except
that bits 0 and 1 are replaced by nonceSign and dataSign.

Dave

Bill Burr wrote:
> 
> Santosh, Trevor and Sharon
> 
> My observation in the Federal PKI TWG meeting last week about
> nonRepudiation meaning only that the CA never knew the private key is
> the counsel of despair.  I think that the only thing most folks would
> agree to about nonRepudiation is that you shouldn't set it if the CA
> ever knew the private key.  That interpretation does have the advantage
> that the CA is attesting to something truly under it's control, while
> the word nonRepudiation carries so much other baggage that no CA could
> hope to control it.
> 
> I broke down and went back and read most of the messages in this thread,
> as well as the words that are now in son of  2459 and the latest draft
> of X.509 that I have.  Neither son of nor X.509 seem to me to stand up
> to a close reading on this subject.
> 
> It does seem to me that the place to indicate that a particular
> signature is meant as a nonrepudiable, binding legal signature is in the
> signature itself, or the document that is signed, and not in the
> certificate.
> 
> I think that Santosh's construction of the digitalSignature and
> nonRepudiation bits and four resulting cases is probably useful and
> workable, and generally in line with my understanding of the more
> "enlightened" interpretations of these bits.  I wish we could rename
> them signChallenges and signData.
> 
> I don't understand what Trevor's precise interpretation of these bits
> is, nor where it conflicts with Santosh's.  I suppose that Trevor must
> have some software that uses these bits in a way that conflicts with
> Santosh's.  It would help me to understand what is at steak here if
> Trevor could explain:
> -       what his interpretation of the exact meaning of these bits is
> (perhaps Trevor has, and I just haven't gone far enough back to find it
> - if so I apologize);
> -       how specifically these bits are then used in his products in
> ways that conflict with Santosh's rules;
> -       why Trevor's interpretation of the meaning of the words in the
> standards is more consistent with them than Santosh's clarification.
> 
> It does seem to me that where we have an ambiguity it's wrong to clarify
> it in a way that clearly contradicts whatever meaning can be clearly
> drawn from the existing text.  I think that Trevor is claiming that
> Santosh's proposal does that.  But where we have an ambiguity that is
> then clarified, we must accept that the clarification may break existing
> products.  We shouldn't do that lightly however, and should generally
> seek a clarification that breaks as little as possible.
> 
> To assign to nonRepudiation the meaning that the CA never knew the
> private key probably doesn't break any products (I hope).  I'm sure it's
> not the most informative or useful interpretation we could put on that
> bit, but it might be the only one that breaks no products.
> 
> Regards,
> 
> Bill Burr

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 May 2002 11:35:23 -0400

I support Dave's viewpoint also.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of David P. Kemp
Sent: Wednesday, May 08, 2002 10:50 AM
To: [email-masked]
Cc: '500 list (E-mail)'
Subject: Re: Meaning of Non-repudiation

Bill,

I have no problem with X.509 and PKIX following Trevor's approach.
Deprecate (using the strongest possible terms) the existing KeyUsage
OID, and define a new KeyUsage OID identical to the old one except that
bits 0 and 1 are replaced by nonceSign and dataSign.

Dave

Bill Burr wrote:
> ever knew the private key.  That interpretation does have the 
> advantage that the CA is attesting to something truly under it's 
> control, while the word nonRepudiation carries so much other baggage 
> that no CA could hope to control it.
> 
> I broke down and went back and read most of the messages in this 
> thread, as well as the words that are now in son of  2459 and the 
> latest draft of X.509 that I have.  Neither son of nor X.509 seem to 
> me to stand up to a close reading on this subject.
> 
> signature is meant as a nonrepudiable, binding legal signature is in 
> the signature itself, or the document that is signed, and not in the 
> certificate.
> 

> It does seem to me that where we have an ambiguity it's wrong to 
> clarify it in a way that clearly contradicts whatever meaning can be 
> clearly drawn from the existing text.  I think that Trevor is claiming

> that Santosh's proposal does that.  But where we have an ambiguity 
> that is then clarified, we must accept that the clarification may 
> break existing products.  We shouldn't do that lightly however, and 
> should generally seek a clarification that breaks as little as 
> possible.
> 
> private key probably doesn't break any products (I hope).  I'm sure 
> it's not the most informative or useful interpretation we could put on

> that bit, but it might be the only one that breaks no products.
> 
> Regards,
> 
> Bill Burr

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 May 2002 11:32:12 -0400

I agree with Bill's summary.

-----Original Message-----
From: Bill Burr [mailto:[email-masked]] 
Sent: Wednesday, May 08, 2002 9:58 AM
To: Santosh Chokhani; 'Sharon Boeyen'; [email-masked]; '500 list
(E-mail)'; [email-masked]
Subject: RE: Meaning of Non-repudiation

I broke down and went back and read most of the messages in this thread,
as well as the words that are now in son of 2459 and the latest draft of
X.509 that I have. Neither son of nor X.509 seem to me to stand up to a
close reading on this subject.

I think that Santosh's construction of the digitalSignature and
nonRepudiation bits and four resulting cases is probably useful and
workable, and generally in line with my understanding of the more
"enlightened" interpretations of these bits. I wish we could rename them
signChallenges and signData.

I don't understand what Trevor's precise interpretation of these bits
is, nor where it conflicts with Santosh's. I suppose that Trevor must
have some software that uses these bits in a way that conflicts with
Santosh's. It would help me to understand what is at steak here if
Trevor could explain:
- what his interpretation of the exact meaning of these bits is (perhaps
Trevor has, and I just haven't gone far enough back to find it - if so I
apologize); 
- how specifically these bits are then used in his products in ways that
conflict with Santosh's rules;
- why Trevor's interpretation of the meaning of the words in the
standards is more consistent with them than Santosh's clarification.

Regards,

Bill Burr

At 07:31 AM 5/8/02 -0400, Santosh Chokhani wrote: 

All:

Personally, I do not have a problem with this, but two of the major
objections to my proposal make this even worse.

Folks say that we do not want to change the semantics of this extension.
Well, all the other bits in the keyUsage say what cryptographic
operation clients can use the bit for. This bit does not do that. Also,
the them key usage means what operations the key can be used for. Please
read the introduction to X.509 definition of the extension.

I really believe the two bit distinction is only useful using what I
have recommended. I am not saying this because I finally got the
religion or anything. I think the proposal is in line with how all the
other bits are used for: what type of crypto operation on what type of
data.

But, since some key players are in violent disagreement, the best course
seems to be the language son of 2459 has.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: Tuesday, May 07, 2002 9:28 AM
To: [email-masked]; 500 list (E-mail)
Cc: Bill Burr (E-mail)
Subject: Meaning of Non-repudiation

I'd like to introduce another perspective on this topic, one that I
really think helps add some fundamental clarity to the topic. During the
US FPKI TWG meeting last week, this topic was raised and a short
discussion was held. Bill Burr commented that he understood the meaning
of the non-repudiation bit being set to be a statement by the
certificate issuer (CA) that they at no point had any access to the
private key corresponding to the public key being certified. I really
like this because it states what role this bit plays in a
non-repudiation context. It is simply that and nothing more. The
remaining mechanisms for supporting a non-repudiation service are
outside the scope of the definition of this bit. Legal and policy
schemes can determine the behaviour of relying parties and users when
this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then
that assertion should be something that accompanies a specific
signature. This bit cannot be expected to act as that assertion. 

I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it
is left to profiling groups, as it shoud be, what combinations of bits
they want set in their own environments. 

Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the
standard, as well as to fix bugs etc). Part of the problem is that there
isn't agreement on what the original text meant, hence the
clarification. Once there is some sort of agreement on what the "right
thing to do" is, then we'll determine what the process is to achieve the
intended result. That's part of the reason why we are having the
discussion before writing up a DR or an enhancement request.

Sharon 

Sharon Boeyen 
Principal, Advanced Security 
Tel: 613 270 3181 
www.entrust.com 

Entrust, Inc. 
Securing the Internet 

<<<<