Russ,
While I agree that it might be useful, the EncryptedData object rather
intentionally does not have any key eminence in it. It does not even really
have the location for the key derivation function which is probably more
problematic that the fact that there is not a name for a password.
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ
Housley
Sent: Saturday, February 19, 2005 7:23 PM
To: ietf(_at_)augustcellars(_dot_)com; jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Change request for CMS
Jim:
I have been thinking about this, and I do not think that this
is the only place where this situation comes into play. The
other place that I found is in EncryptedData. An identifier
of the key needed for decryption would be helpful.
So far, I have not heard from anyone except you about this
idea. I do not want to work on it unless there is a
constituency that agrees it ought to be done.
Russ
At 04:15 PM 1/27/2005, Jim Schaad wrote:
Russ,
Yes I am just trying to name the password, I suppose that all I need
for such an identifier is really a UTF8String. I was just trying to
re-use what was already there.
An update for this would be fine for me.
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ
Housley
Sent: Thursday, January 27, 2005 7:17 AM
To: jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Change request for CMS
Jim:
I can see how this helps enrollment.
Aren't you trying to name the password? Assuming the password is
one to one and onto with the KEK, the identifier actually names
both.
For a change of this size, I think that an update to the document
(as opposed to the whole document) is appropriate.
Russ
At 03:23 PM 1/26/2005, Jim Schaad wrote:
Russ,
Sometimes I wonder if this will ever end - the endless
updates to
documents as we find things that seem to be lacking. Oh
well.....
I find myself wanting to identify a key using the password
recipient info type in an enveloped data structure.
Specifcally I
am
sending a
enveloped data structure between a server and a client
system. They do
not yet have certificates setup so that there is no way to
use a public/private key pair.
They however do have an identifier/passphase setup
between them.
It would be convient if one could place the identifier in the
PasswordRecipientInfo structure so that all of the data
is together
rather than looking in many different places for the
infomration needed.
I would like to change the structure to
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion -- {v0, v1}
kekid [1] KEKIdentifier OPTIONAL, -- if present version = 1
keyDerivationAlgorithm [0]
KeyyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey
}
Jim