Blake "Broken Formatting" Ramsdell replies...
On Tuesday, March 24, 1998 3:32 PM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
I believe that my comment is appropriate. I believe that X.509 and
PKIX
clearly state the requirements to check the keyUsage encipherOnly and
decipherOnly bits when the keyUsage keyAgreement bit is set to 1 and
the
public key is to be used to either decrypt or encrypt data directly.
I
believe that people will wonder how that rule applies when using the
public
key to form a pairwise key to be used to encrypt or decrypt data.
That
is
where my proposed text would clarify the requirements.
First off, I have no qualm whatsoever with your statements. I believe
that they are completely consistent with the PKIX part 1 draft and my
beef isn't with you at all. It is with my (mis-) understanding of
Diffie-Hellman, its use in S/MIME, and its description in PKIX.
My proposed text is not unique to D-H. It is applicable in any
scenario
in
which the keyUsage keyAgreement bit is set to 1 and the public key is
to
be
used to form a pairwise key (this includes KEA in addition to the
variants
of D-H). The S/MIME software doesn't need to make a special check of
the
subjectPublicKeyInfo algorithmIdentifier just so that it knows to make
my
proposed keyUsage check. The S/MIME software will already know that a
pairwise key is required based on the subjectPublicKeyInfo
algorithmIdentifier. It will already be executing the code required
to
generate a pairwise key. In that code, the check could be made, so
there is
not an added, special check of the algorithmIdentifier just to
indicate
that
the keyUsage encipherOnly and decipherOnly bits must be checked.
In the event that an application is providing user interface for the
purpose of creating the association of certificates to email addresses,
it is necessary to know which one is the default encrypting certificate.
In order to make that association, the suitability of the certificate
must be determined before the association can occur. This is a very
basic tenet that comes in after all of the theoretical work is done. In
order to make this decision, both the algorithm field in the
SubjectPublicKeyInfo and the keyUsage v3 extension must be used together
to determine this. That is the only point that I am making.
Used with Triple-DES as a symmetric algorithm, a certificate is suitable
for encrypting a message iff:
1. The SubjectPublicKeyInfo AlgorithmIdentifier is rsaEncryption and the
keyUsage bit "keyEncipherment" is set (or keyUsage is not present).
2. The SubjectPublicKeyInfo AlgorithmIdentifier is dhpublicnumber and
the keyUsage bit "keyAgreement" is 1 and "decipherOnly" is 0 (or
keyUsage is not present, God Help you).
I understand that some of this is an artifact of the shoehorning of
Diffie-Hellman into an RSA model. Or maybe I don't. All I know is that
the same bit that determines the suitability for an rsaEncryption
certificate for encrypting the session key cannot be checked to
determine the suitability for a dhpublicnumber certificate.
Does the encipherOnly bit need to be checked at all? Isn't our use of
Diffie-Hellman limited to "forming a pairwise key to encrypt data"?
Blake (Diffie-Hellman impaired)
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060