Subject: Re: Question about the edition of RFC 3280

From: Denis Pinkas <[email-masked]>
Date: Mon, 05 May 2003 17:10:50 +0200

Peter,

> hi Denis,

> Do you have some result? 

Thank you for inquiring.

> regards
> Peter

The following people have participated to a meeting held on Monday April, 14 
during the RSA Security Conference :

  - Tim Polk, editor of RFC 3280 and PKIX co-chair;
  - Russ Housley, editor of RFC 3280 and recently designated as
    Security Area Director;
  - Denis Pinkas, PKIX participant;
  - Hoyt Kesterson, chair of the ISO/ITU SC 6 X.509 WG (partly);

History

The change was made during the 48 hours window period for editorial changes. 
The requestor for the change was Stefan Santesson. Neither Russ, Tim or 
Stefan have any record of the e-mail from Stefan that lead to that change.

Russ and Tim said, that in the opinion of the editors, the change that 
happened between draft 12 and RFC 3280 was purely editorial, to make it 
consistent with the sentence that has been added after a long debate 
("Further distinctions between the digitalSignature and nonRepudiation bits 
may be provided in specific certificate policies"). An observation was made 
that a simple way to resolve the consistency would have been to remove the 
additional sentence (which had been accepted on the basis that no other 
change was being made to the remaining text).

However, the RFC editor was wondering whether that change was really 
editorial, but both Steve Kent (co-chair of the PKIX WG) and Jeff Schiller 
(Security Area Director) confirmed that the change was editorial. The PKIX 
list has not been informed of the change.

The Monday discussion

 From the discussion that took place on the Monday, it appears that the 
rational for the use of bits 0 and 1 as defined in both X.509 and RFC 2459 
was not fully understood by Tim Polk.

The rational has to do with the use of private keys in untrusted 
environments: in an untrusted environment, a private key holder cannot make 
sure of the data that is being signed.

In a trusted environment, a private key holder is able to control the data 
that is being signed. For example, if the private key is used to sign 
contracts, the client software may display the contract on which a hash will 
be computed, or if the key is used for authentication purposes, the client 
software may combine the random value sent by a server with a random number 
chosen by the client software.

An example has been used to illustrate the problem:

A signature private key is being used for authentication purposes to open a 
door lock placed in an *untrusted* environment. The door lock sends a 
challenge and the challenge is signed. The signer has no control on the 
value of the challenge. If that challenge happened not to be to be a random 
number, but the hash of a contract, the signer would have signed the 
contract without knowing it ! Without an indication for the key usage it 
would be impossible for the signer to say that he only intended to sign a 
challenge but not a contract.

This is exactly why two bits are being used.

If the key is usable for authentication purposes, then the key usage bit 0 
shall be set.

If the key is usable for non-repudiation purposes, then the key usage bit 1 
shall be set.

In order to make the difference, the signer should use two certificates:

- one for non-repudiation purposes, that is only usable
   in trusted environments;

- one for authentication purposes, usable in any kind
   of environment (i.e.untrusted or trusted).

When using the door lock if a contract has been signed, the signer can say: 
a key corresponding for an authentication certificate has been used, so the 
contract is non valid since a certificate with the bit 1 set (the non 
repudiation bit) should have been used. Now, if the signer willingly 
recognizes that the signature is good, that fine, but it is similar as 
making a transaction with a credit card over the Internet: the card holder 
may repudiate the transaction at any time without the need to prove anything 
and independently of any context.

A certificate policy may further restrict the use of the certificate but may 
not override the meaning of the bits.

Now, if both bits are set in a certificate, what are the implications ?

The private key corresponding to that certificate can only be used safely, 
if always used in trusted environments. For example, a smart card protecting 
the private key is always used with client software trusted by the signer.

It may be observed that all key usage bits (except bit 0) are defined as 
security service bits, while bit 0 is defined as a security mechanism bit 
with the exception of a few security services (notably the non-repudiation 
service).

It would be better to define bit 0 as a service bit saying explicitly which 
are the security services for which the private key can be used for, namely 
an authentication service and/or an integrity service.

A way forward

The topic is being discussed within ISO SC 6 since a Defect Report has been 
raised. A "clarification" is indeed needed, but opinions differ whether it 
is really a "defect" or not. It is desirable to maintain alignment between 
the IETF RFCs and ISO X.509.

At this time it is too early to know which text will be proposed and adopted 
by ISO, but it is clear that the current text from RFC 3280 will *not* be 
used. As a matter of fact, RFC 3280 is no more backwards compatible with RFC 
2459 nor X.509, since the meaning of the DS bit has been changed. In X.509 
and RFC 2459 this bit is set when a digital signature mechanism is being 
used, but not when the digital signature mechanism is used to provide a non 
repudiation service. In RFC 3280, the later restriction has disappeared. The 
signer is thus loosing its argument to repudiate its signature.

When the new proposal from ISO will circulate, the PKIX WG should consider it.

A draft 3280bis document should be started now and include for the time 
being an indication which shall be placed in section 4.2.1.3 (Key Usage) to 
warn the reader that the text is not backward compatible with RFC 2459 and 
that section is subject to changes. People wishing to comply with the text 
from section 4.2.1.3 (Key Usage) from RFC 2459 will be unable to reference 
RFC 3280 until a new RFC is produced. However, X.509 (2000) can be 
referenced instead.

It is expected that ISO could agree on a final text in the September time-frame.

Denis

PS.Extracts from the Introduction of ISO 10181-4 (Non-repudiation 
Framework). "The goal of the Non-repudiation service is to collect, 
maintain, make available and validate irrefutable evidence concerning a 
claimed event or action in order to resolve disputes about the occurence or 
non-occurrence of the event or action".

"Non-repudiation involves the generation of evidence that can be used to 
prove some kind of event or action has taken place, so that this event or 
action cannot be repudiated later".

>>Date: Thu, 10 Apr 2003 10:54:54 +0200
>>From: Denis Pinkas <[email-masked]>
>>
>>Stefan,
>>
>>Thank you for the response.
>>
>>I realize that very unfortunately both the sender of the message and the 
>>receivers of the message lost the message. :-|
>>
>>Now, looking forward, I would like to make the following proposal:
>>
>>Next week there is the RSA 2003 Security Conference. I will attend the 
>>Conference and I guess may other people from the PKIX WG will do so as well.
>>
>>Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
>>the Wednesday, I propose to have an informal meeting about key usage bits 0 
>>and 1 on the Monday evening for anyone interrested.
>>
>>I thus propose to meet in the North Lobby, in front of the registration 
>>desks at 5:30 p.m. on the Monday evening.
>>
>>I would like to discuss the meaning of a certificate that has:
>>
>>  1° only the key usage bit 1 set,
>>  2° only the key usage bit 0 set,
>>  3° both the key usage bits 0 and 1 set.
>>
>>   ... when looking at the writing of RFC 2459 and
>>       when looking at the writing of RFC 3280.
>>
>>Denis
>>
> 
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 May 2003 01:16:08 -0400

Denis:

I find your report stilted.  In particular it omits any discussion of the 
last paragraph of the key usage section (that is, the last paragraph of 
section 4.2.1.3 of RFC 3280).  I repeat it here:

    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 [PKIXALGS].

I completely disagree with your claim that Tim Polk did not fully 
understand this issue.  This is simply incorrect.

I am not going to participate in another email debate about the semantics 
of these two key usage bits.  The authors and chairs and area directors did 
the best that we could to capture the lack of consensus on this 
point.  Denis feels that we missed the mark.  Others have posted comments 
to the contrary.

I am going to wait for the ISO / ITU-T proposed text before I make any 
further comments on this subject.  I hope everyone else will do the same.

Russ