Re: Question about the edition of RFC 3280
Denis Pinkas <Denis.Pinkas <at> bull.net>
2003-05-05 15:10:50 GMT
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 <Denis.Pinkas <at> bull.net>
>>
>>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
>>
>
>
RSS Feed