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