ietf-smime
[Top] [All Lists]

RE: Change request for CMS

2005-03-09 09:57:37

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









<Prev in Thread] Current Thread [Next in Thread>
  • RE: Change request for CMS, Jim Schaad <=