Subject: Meaning of Non-repudiation

From: Sharon Boeyen <[email-masked]>
Date: Tue, 7 May 2002 09:28:23 -0400

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 7 May 2002 17:55:55 +0200

Meaning of Non-repudiationSharon,

  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.
An interesting definition indeed.  Being deeply involved in server-based PKI, where a portal "CA" and portal "clients" may live in full symbiosis including access to private keys, I note that it would mean that it would be an error to set the NR-bit in such systems.  Therefore I feel some "bad vibes" to this definition of what an NR-bit really is.  But OTOH the "granularity" in the e-commerce world is not that great, so it probably just a no-issue. :-)

cheers,
Anders

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 May 2002 07:31:02 -0400

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 

Entrust, Inc. 
Securing the Internet