Subject: Technical Corrigenda 3 to the 4th edition of X.509

From: Hoyt L Kesterson II <[email-masked]>
Date: Thu, 12 May 2005 01:51:24 -0700

Some you worked with the X.509 standards committee over the last
few years revising the text on key usage.

The Technical Corrigenda containing that revised text was
approved and is currently being incorporated into the 5th edition
currently being prepared.

You can find the text of that Technical Corrigenda at:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf

Note that this
document is written as a set of editing instructions to integrate the
text into the 4th edition. If you prefer to wait, the 5th edition will
be published before the end of the year

hoyt

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 12 May 2005 14:40:48 +0200

Hoyt L Kesterson II wrote:

> Some you worked with the X.509 standards committee over the last few 
> years revising the text on key usage.
>

You should avoid using characters in the filename that are not 
compatible with the Microsoft OS, it makes it harder to download that file.

 From the text :
"Bits in the KeyUsage type are as follows:
[...]
c) keyEncipherment: for enciphering keys or other security information, 
e.g. for key transport;
d) dataEncipherment: for enciphering user data, but not keys or other 
security information as in c) above;
e) keyAgreement: for use as a public key agreement key;"

It's not yet very precise. The contentCommitment bit text got very 
clear, so it shows how much we can improve on those bits.

The text by Peter is quite good, how about :

c) keyEncipherment: for enciphering keys or other security information, 
e.g. for key transport, and also data encryption that uses an 
intermediate symmetric cipher;
d) dataEncipherment: for directly enciphering raw user data, without the 
use of an intermediate symmetric cipher
e) keyAgreement: for use as a public key agreement key, for example a 
Diffie-Hellman protocol key;

Shouldn't we best find a way to say that an SSL client requires at a 
minimum only digitalSignature, but the SSL server must have 
keyEncipherment ?

Maybe we should precise :
In practice when someone wishes to send enciphered key or security 
information, he must check that the recipient has the keyEncipherment 
bit set before using his public key to encipher. For example in an SSL 
handshake, the client must check that the server has the keyEncipherment 
bit set before sending him an enciphered secret, but never needs to have 
that bit set in his own certificate, because the server will use his 
certificate only for authentification, not to send enciphered data.

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Thu, 12 May 2005 10:27:27 -0700

i apologize for the name problem

This is approved text with no posibility of change except by subsequent defect report or amendment.

Denis Pinkas was very active in the several ballots held on this document over the last few years as well as several other PKIX participants. Your comments would have been appreciated and considered during that period but cannot now be applied to the document that has had approval within ISO and ITU.

    hoyt

At 14:40 +0200 5/12/05, Jean-Marc Desperrier wrote:
>>Some you worked with the X.509 standards committee over the last few years revising the text on key usage.
>>
>You should avoid using characters in the filename that are not compatible with the Microsoft OS, it makes it harder to download that file.
>
>From the text :
>c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport;
>d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above;
>It's not yet very precise. The contentCommitment bit text got very clear, so it shows how much we can improve on those bits.
>
>c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport, and also data encryption that uses an intermediate symmetric cipher;
>d) dataEncipherment: for directly enciphering raw user data, without the use of an intermediate symmetric cipher
>e) keyAgreement: for use as a public key agreement key, for example a Diffie-Hellman protocol key;
>
>Shouldn't we best find a way to say that an SSL client requires at a minimum only digitalSignature, but the SSL server must have keyEncipherment ?
>
>In practice when someone wishes to send enciphered key or security information, he must check that the recipient has the keyEncipherment bit set before using his public key to encipher. For example in an SSL handshake, the client must check that the server has the keyEncipherment bit set before sending him an enciphered secret, but never needs to have that bit set in his own certificate, because the server will use his certificate only for authentification, not to send enciphered data.