Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS

From: "John Ross" <[email-masked]>
Date: Thu, 11 Mar 1999 17:51:28 -0800

If you are going to allow the choice to be extended, I agree with Rick that
it should be controlled.  Just extending the choice with a new tag (and by
the way it also then needs a new version number), will give problems in the
future, as it is not a unique identifier.  What if a private extensions has
been defined already and used tag 3?  Also, if every extension to the choice
needs a new CMSversion number assigned, that may be a lot of CMSversion
around in the future. A while back I proposed to have an extensible "choice"
using octet string, it would be better using OID and any defined by as
follows:.

 The following is an example ASN.1:

 RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }

ExternalyDefinedKeyAgreement :: = SEQUENCE {
    keyTypeIdentifier ObjectIdentier,
    keyTypeInfo OCTECT STRING --any defined by OID}

This will at lease make sure that there is unique identifiers for all the
extensions to recipient info.

Regards

John Ross

-----Original Message-----
From: Rich Ankney <[email-masked]>
To: [email-masked] <[email-masked]>; Russ Housley
<[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Wednesday, March 10, 1999 10:39 AM
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS

>If we're going to add another recipient type, I'd like to see it be an
>open type (OID and ANY DEFINED BY), of which this would be
>the first case.  ANSI X9F3 would like to add another recipient type,
>as well (the Tecsec CKM stuff from X9.69).  So we would have:
>
>Key transport
>KEK
>Key agreement
>Other
> Password-based
> CKM
>
>Regards,
>Rich
>
>----------
>> From: Russ Housley <[email-masked]>
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
>> Date: Monday, March 08, 1999 4:43 AM
>>
>> Peter:
>>
>> I stayed silent to see if anyone would support your suggestion.  No one
>> spoke for it, but no one spke against it either.  I would like to heard
>> from the list members regarding this suggestion.  I do not consider
>silence
>> a reason to make an additional recipient type....
>>
>> Russ
>>
>> At 04:19 AM 2/21/99 +0000, Peter Gutmann wrote:
>> >I don't know what the final resolution on optional vs mandatory
>> KEKIdentifiers
>> >was, but I note that PKCS #15, which AFAIK is the first non-S/MIME use
>of CMS
>> >KEK encryption, already has to explicitly state that KEKIdentifiers are
>null
>> >strings wherever they occur because they're not useful for anything
>(actually
>> >there's a "not recommended" special-case use for them, see below).  I
>think
>> >this proves my earlier point that there's going to be very little use
>for a
>> >KEKIdentifier outside S/MIME, so that making it optional would be a good
>idea.
>> >
>> >Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a
>
>> >rather obvious recipient type missing from CMS: Password-based
>encryption.
>> >PKCS #15 has a hack for this which puts the key derivation information
>into
>> >the KEKIdentifier (this being the special-case use mentioned above), but
>I'm
>> >sure this isn't what it was intended for because it isn't a key
>identifier at
>> >all but contains the AlgorithmIdentifier for the password processing.
>What's
>> >really needed is a new recipient type, PasswordRecipientInfo.  Included
>below
>> >is a suggestion for this which could drop directly into the CMS draft.
>> >
>> >Peter.
>> >
>> >-- Snip --
>> >
>> >6.2.4  PasswordRecipientInfo Type
>> >
>> >   Recipient information using a user-supplied password is represented
>in the
>> >   type PasswordRecipientInfo.  Each instance of PasswordRecipientInfo
>will
>> >   transfer the content-encryption key to one or more recipients who
>have the
>> >   previously agreed-upon password.
>> >
>> >      PasswordRecipientInfo ::= SEQUENCE {
>> >        version CMSVersion,  -- always set to 0
>> >        keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>> >        keyEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
>> >        encryptedKey EncryptedKey }
>> >
>> >   The fields of type PasswordRecipientInfo have the following meanings:
>> >
>> >      version is the syntax version number.  It shall always be 0.
>> >
>> >      keyDerivationAlgorithm identifies the key-derivation algorithm,
>and any
>> >      associated parameters, used to derive the key-encryption key from
>the
>> >      user-supplied password.
>> >
>> >      keyEncryptionAlgorithm identifies the content-encryption
>algorithm, and
>> >      any associated parameters, used to encrypt the content-encryption
>key
>> >      with the password-derived key-encryption key.
>> >
>> >      encryptedKey is the result of encrypting the content-encryption
>key with
>> >      the password-derived key-encryption key.
>> >
>> >   The key derivation algorithms are:
>> >
>> >      KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>> >        { IDENTIFIED BY id-PBKDF2 },
>> >        ...
>> >        }
>> >
>> >    For key derivation, CMS implementations must include PBKDF2
>[PKCS5v2].
>> >
>> >    For content (= key) encryption, CMS implementations must include
>> >Triple-DES
>> >    in CBC mode, should include RC2 in CBC mode, and may include other
>> >    algorithms (CAST-128, RC5, IDEA, Skipjack) and modes as required.
>CMS
>> >    implementations should not include any KSG ciphers such as RC4.
>> >
>> >-- Snip --
>> >
>> >Comments:
>> >
>> >The ContentEncryptionAlgorithmIdentifier is something like:
>> >
>> >      ContentEncryptionAlgorithmIdentifier ::= {
>> >        { IDENTIFIED BY des-ede3-cbc },
>> >        { IDENTIFIED BY rc2CBC },
>> >        { IDENTIFIED BY cast5CBC },
>> >        { IDENTIFIED BY rc5CBC },
>> >        { IDENTIFIED BY ideaCBC },
>> >        { IDENTIFIED BY desCBC },
>> >        ... -- ... and anything else you can think of, eg Skipjack
>> >        }
>> >
>> >but enumerating every possible one is superfluous as they're specified
>> >elsewhere.
>> >
>> >The content is encrypted is as per the KEK algorithm, but using the IV
>given
>> >in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this
>is
>> >just standard CMS content encryption.  The advantage of using standard
>> OIDs is
>> >that it doesn't require defining a completely new set of OIDs which
>parallel
>> >all of the existing ones just to show that you're encrypting a key.
>Another
>> >way to handle this is as EncryptedContentInfo (which just adds an extra
>> >SEQUENCE around the existing ContentEncryptionAlgorithmIdentifier +
>> >EncryptedContent (=EncryptedKey)), but this is probably going overboard.
>> >
>> >(I'm prepared to accept a 'kekid [0] KEKIdentifier OPTIONAL' after the
>> version
>> > number if that's what's required to get people's grunt of approval for
>the
>> > thing).
>> >
>> >(Before people complain that you can't change the key wrap algorithm, if
>it
>> > ever does become necessary to change it (and I thought the point of the
>
>> > current key wrap design process was to build a solution once and for
>all),
>> > all you need to do is increment the RecipientInfo version number and
>add
>> > whatever you feel like).
>> >
>> >Peter.
>> >
>> >

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 11 Mar 1999 13:53:03 -0800

Folks:

Peter has posted an Internet Draft for an addition to CMS. I think it is 
very late for us to be adding things for which there is disagreement on how 
to put it in. We can discuss Peter's draft and decide if we want to pass it 
out of the working group. If we do, it can be a stand-alone RFC. If it gets 
two independent implementations, we might fold it into the CMS RFC (if we 
ever get there.....) when we move from Proposed Standard to Draft Standard.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Mar 1999 17:22:21 -0500

All:

I agree with Paul Hoffman.  We should proceed with CMS so that the S/MIME
v3 set of documents can become Proposed Standards.  Using the list, we can
discuss the best way to handle password-based key management.  We can do as
many Internet-Drafts as necessary to sort this out.  Once we reach
concensus, we can add the that technique to CMS when the document
progresses from Proposed Standard to Draft Standard.

Of the suggestions discussed so far, I am leaning toward the one made by
Magnus Nyström.  This seems to provide all of the capability needed for
PKCS#15.

On the other hand, the proposal made by Rich Ankney (and seconded by John
Ross) provides a open solution for new techniques are they are needed.  I
have concerns that this may not be the best solution for interoperability.
Rich can you post the ANSI X9F3 requirements for CKM?  Please start a new
thread for that topic.

Russ

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 16 Mar 1999 09:49:10 -0800

>progresses from Proposed Standard to Draft Standard.

I have a question about this.  Are you producing a document with a known
deficiency that you intend to correct later in the standards process?  It
appears to me that making the change that has been suggested using the
extension mechanism after it has been released as PS would likely cause CMS
to move backwards in the standards process, and not forwards.  Thus, the
whole process would be substantially delayed.  You're better off correcting
the problem now with the "..." or extension mechanism or whatever as part
of WG last call, and moving on rather than attempting to correct it later,
and then being shifted back in the standardization process...

Bruce
================================================
Bruce Greenblatt             
[email-masked]
http://www.directory-applications.com
================================================

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 16 Mar 1999 12:56:40 -0600

>deficiency that you intend to correct later in the standards process?

There is a difference between a deficiency and a security flaw. The desire 
for passwords was brought up very late in the process, an indication that 
there are not pressing market needs for it. It would be nice to have, but 
there are significant technical issues, and thus Peter is proposing an 
extension to CMS.

>  It
>to move backwards in the standards process, and not forwards.

I don't understand why. The separate proposal does not have to be bound to 
CMS. If we want to later bind it to CMS, we can postpone going from 
Proposed Standard to Draft Standard by enough months to let the extension 
catch up. Otherwise, they can independently move to Draft Standard. Both 
are quite common in the IETF.

>  Thus, the
>whole process would be substantially delayed.

Just the opposite: there is no delay at all.

>  You're better off correcting

I respectfully disagree.

--Paul Hoffman, Director

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 16 Mar 1999 21:24:54 -0800

At 12:07 AM 3/17/99 -0500, Russ Housley wrote:
>No.  The current document meets all of the original requirements.  We are
>considering an enhancement that is beyond the original charter.
>
>Russ
>

Thanks for the clarification.  As long as the enhancement to the protocol
doesn't "break" conformant implementations, I think that you and Paul are
right that the process won't be held up.  I thought that I read that an
extension mechanism was going to be put in between PS and DS that would
change the protocol in such a way that implementations that conformed to
the PS version of CMS might get confused by the DS version of the protocol.
 Obviously, this would be a bad thing.

Bruce

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Mar 1999 00:07:30 -0500

Russ