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

From: [email-masked] (Peter Gutmann)
Date: Wed, 10 Mar 1999 17:35:06 (NZDT)

>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....
 
The maxim of the law is that silence gives consent.  Obviously everyone agrees
with me :-).
 
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....
 
The maxim of the law is that silence gives consent.  Obviously everyone agrees
with me :-).
 
Peter.

---

From: [email-masked] (John Pawling)
Date: Wed, 10 Mar 1999 09:34:25 -0500

Peter, Russ and friends,

Initially, I was opposed to this proposal because it adds yet more
complexity to CMS.  However, I agree with Peter that it is better to have a
clearly defined, meaningful ASN.1 syntax rather than to kludge data into an
existing syntax.  I assume that PKCS #15 is going to be widely used, so it
is worthwhile to enhance the CMS RecipientInfo syntax to include Peter's
proposed PasswordRecipientInfo CHOICE.   

I have a few comments to Peter's proposed additions to CMS:

1) Peter's proposal uses the ALGORITHM-IDENTIFIER syntax which is not part
of the 1988 ASN.1 grammar.  Many moons ago the S/MIME WG decided that the
S/MIME v3 set of specs will only use the 1988 ASN.1 grammar, so I believe
that Peter's proposal should be re-worded to eliminate use of the
ALGORITHM-IDENTIFIER syntax.

2) Recommend that "KSG" be spelled.  

3) Also, please reword the following to use 1988 ASN.1 syntax:
>>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
>>        }

Assuming that CMS is changed to include PasswordRecipientInfo, I don't
believe that the KEKRecipientInfo kekid needs to be changed to be OPTIONAL
(as Peter also proposed) because PKCS #15 will no longer use the
KEKRecipientInfo syntax.

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
========================================================

---

From: "Rich Ankney" <[email-masked]>
Date: Wed, 10 Mar 1999 13:16:52 -0500

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:
> > 
> >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).

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Wed, 10 Mar 1999 10:20:40 -0800

John & Peter,

At this point in time I am not willing to support this. I have two reasons
for this

1.  I want to get CMS approved, and there are other options for how to
approach this (such as a new I-D) and we know a new version of CMS is coming
soon to deal with OEAP

2.  I don't think this is the correct set of items that are needed.  You
have not proposed an appropriate set of text for section 12.  I don't
understand why the Content Encrytion Alg should be encoded twice.  I don't
understand why the KEK Wrap algorithm is not specified.  I just don't think
this is complete yet.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 10, 1999 6:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS

Peter, Russ and friends,

---

From: Darren Harter <[email-masked]>
Date: Fri, 12 Mar 1999 09:16:54 -0000

John,

I agree in general with what you propose.  I understand the benefit of using an OCTET STRING to ensure easy decoding for recipients that do not understand the syntax of the data associated with keyTypeIdentifier.  However, I believe that a true ANY would be better than an OCTET STRING in this case.

Applications that support CMS already have to deal with a lot of ANY's, so one more is not going to add much complexity.  Also, using an ANY rather than an OCTET STRING allows for a single pass decode process, which an embedded OCTET STRING encoding does not.

The amended part of your syntax would be:

ExternalyDefinedKeyAgreement :: = SEQUENCE {
    keyTypeIdentifier OBJECT IDENTIFIER,
    keyTypeInfo ANY DEFINED BY keyTypeIdentifier }

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
+44 (0) 1452 371383
Email: mailto:[email-masked]

---

From: [email-masked] (John Pawling)
Date: Fri, 12 Mar 1999 09:50:11 -0500

Jim and Friends,

I agree with Jim's message.  When I expressed support for Peter's proposal
to enhance the CMS RecipientInfo syntax, I assumed that there was consensus
in the PKCS-15 community regarding the proposal.  Based on subsequent e-mail
traffic, that assumption has been proved to be false.  Therefore, I agree
with Jim that the CMS RecipientInfo syntax should remain unchanged.

- John Pawling

---

From: [email-masked] (John Pawling)
Date: Fri, 12 Mar 1999 10:03:48 -0500

All,

I believe that this proposal leads to non-interoperable S/MIME
implementations, so I oppose it.  If the originator chooses a kext syntax
that the recipient's software does not understand, then the recipient will
not be able to decrypt the EnvelopedData content.  I believe that the CMS
RecipientInfo syntax should not be changed until it is proven that it does
not meet a valid requirement ("valid" as defined by consensus of the S/MIME
WG).  If that occurs, then we should consider adding a well-defined syntax
as a ReceipientInfo CHOICE (not a wild card).

At 05:51 PM 3/11/99 -0800, John Ross wrote:
>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 }
>
>
>
>    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
>

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 13 Mar 1999 05:16:24 (NZDT)

Paul Hoffman / IMC <[email-masked]> writes:
 
>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.
 
The point of making it an independent RFC was that it wouldn't hold up the CMS 
RFC - that can proceed as usual, and the PWRI RFC could be developed at its 
own pace.
 
>As an alternative, if the current CMS draft would allow for the 'PBES2' 
>algorithm identifier defined in PKCS #5 v2 in the set of 
>KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in 
>CMS. Another advantage with this is that it would enable an easy way to send 
>encrypted email where the key is derived from a previously agreed-upon 
>password.
 
I don't think this is such a good idea, it's a significant change to the CMS 
RFC at a late stage (which I was trying to avoid by having an independent PWRI 
RFC), and it's rather a kludge.  I think it'd be better to leave KEKRI for 
what it was intended for and have a dedicated PWRI which specifically 
addresses the requirements of password-based encryption.
 
"John Ross" <[email-masked]> writes:
 
>Also, if every extension to the choice needs a new CMSversion number 
>assigned, that may be a lot of CMSversion around in the future.
 
You don't need to do this though, if you use '...' as I suggested in a 
previous message then implementations will know that there could be further 
types added there and skip any new ones they don't recognise.  Once this is 
done, there's no need to change the version number whenever a new choice is 
added.
 
Peter.

---

From: "ross@secstan" <[email-masked]>
Date: Fri, 12 Mar 1999 18:52:21 -0000

I am happy to use '...' in the choice syntax, but unfortunately that is not
available when using 1988 ASN.1.  So that option is not available.

If there is strong objection to having a "controlled" way of extending the
choice (i.e the OID route), but there is agreement to specifically allow the
equivalent of '...' in 88 syntax (i.e. extend the choice), then there is a
need to add a comment in the ASN.1.   Also it would be a advisable to say
under what condition the CMSversion needs to change (if any).  Rule are
needed so that there is no misunderstanding on how to  expansion the choice
in the future.

Personally I think a new  version number is advisable every time the choice
is extended, as that  would make the handing of any extended choice easier
to handle on reception. But I am happy to follow the general consensus on
that issue.

---

From: [email-masked] (John Pawling)
Date: Fri, 12 Mar 1999 14:12:12 -0500

All,

I disagree with adding "..." to the RecipientInfo CHOICE because I believe
that leads to non-interoperable S/MIME implementations.  I believe that the
CMS RecipientInfo syntax should not be changed until it is proven that it does
not meet a valid requirement ("valid" as defined by consensus of the S/MIME
WG).  If that occurs, then we should consider adding a well-defined syntax
as a ReceipientInfo CHOICE (not a wild card).

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 14 Mar 1999 05:00:49 (NZDT)

>that leads to non-interoperable S/MIME implementations.
 
>Personally I think a new version number is advisable every time the choice is
>extended, as that would make the handing of any extended choice easier to
>handle on reception. But I am happy to follow the general consensus on that
>issue.
 
<grumble>
Why are people trying to manufacture all this unnecessary complexity for 
something so simple?  X.500 has had this capability (the Name CHOICE) for over 
10 years and it's never lead to any problems because the only way to extend it 
is via changes to X.500 (that is, you need to extend the standard to extend 
the CHOICE).  Similarly, someone can't just drop in a new CHOICE option for 
CMS, it'd have to be done via the usual CMS standards process, so that 
resulting implementations would be just as interoperable as, say, ESS 
implementations.
 
Similarly, I don't see why it's necessary to change the version number every 
time the CHOICE is extended - if you don't recognise a CHOICE alternative, you 
skip it and continue.  Since CMS already requires changes from S/MIME v2/PKCS 
#7 (by adding the CHOICE) adding an extra line or two of code to 
implementations to skip unrecognised choices can't be that hard.
</grumble>
 
This is why I asked for '...' (or text to that effect for those still stuck
with ASN.1:1988) be added to CMS, it means it'll be possible to extend the
CHOICE in the future with further RFC's without requiring an update to CMS
itself (I believe this was the same rationale behind X.500's Name CHOICE).
There won't be an uncontrolled explosion of choices since the only way to
extend it would be as a full RFC, which would have to go through the usual
carefully-controlled standards process.
 
Peter.

---

From: "John Ross" <[email-masked]>
Date: Mon, 15 Mar 1999 09:17:38 -0800

I agree with Peter, CMS should allow the extension of the Choice syntax
 i.e. in text using  the old ASN.1 rules), which gives a good pointer to the
implementors that they should not object if the they receive an extended
choice.

I also agree with John Pawling, that any extension must be controlled and
should only be done when there is a requirement not met by the current
syntax. As per Peter's comment, control of the choice can be achieved by the
normal RFC process.  Also, if more control is required on S/MIME for
interoperability reasons, the S/MIME specification  (not the CMS spec) could
prohibit the expansion of the choice unless a new version number is agreed.

Regards
JR

---

From: [email-masked] (John Pawling)
Date: Mon, 15 Mar 1999 10:42:07 -0500

Peter,

I still oppose the addition of "..." to the CMS RecipientInfo syntax.  IMHO,
"..." does not add any value to the document.  Implementors realize that the
S/MIME v3 documents are subject to enhancements.  If people need to add a
CHOICE to the CMS RecipientInfo syntax, then they need to propose a specific
syntax and accompanying text for inclusion in CMS.  

You stated: "- if you don't recognise a CHOICE alternative, you skip it and
continue." 

If you were talking about v3 cert extensions or signedAttributes, I would
agree with your "skip it and continue" strategy for unrecognized syntaxes.
In the case of a CHOICE syntax, I disagree that it is straightforward to
"skip" an unrecognized CHOICE alternative.  Most S/MIME implementations use
an ASN.1 decoding strategy by which the entire object (i.e. envelopedData,
signedData, etc) is decoded via a single call to an ASN.1 library that
implements general purpose ASN.1 decoding rules.  In this case, there is no
easy way to "skip" an unrecognized CHOICE syntax.  That is an error
condition.  For example, if a RecipientInfo includes a CHOICE alternative
not defined in the CMS standard, then the decoding software returns an error
when attempting to decode the object.  I believe that you will find that the
vast majority of S/MIME implementations work in this fashion.  For example,
the S/MIME Freeware Library calls the freeware SNACC ASN.1 library to decode
objects.  The SNACC ASN.1 library is capable of using general purpose ASN.1
rules to decode the ASN.1 syntaxes included in the ASN.1 modules provided at
compile time (ex: CMS ASN.1 module).  If the SNACC library encounters an
unrecognized CHOICE alternative, it returns an error.  There is no easy way
to add code to handle a special case like "skip an unrecognized CHOICE
alternative in recipientInfo".  

>itself (I believe this was the same rationale behind X.500's Name CHOICE).

I don't like the idea of splitting a CHOICE syntax definition between
multiple documents.  IMHO, that is OK for defining attributes and
extensions, but not CHOICEs.

---

From: [email-masked] (John Pawling)
Date: Mon, 15 Mar 1999 10:55:37 -0500

John,

>implementors that they should not object if the they receive an extended

I agree that the CMS RecipientInfo CHOICE syntax could be modified in future
versions of CMS through the addition of well-defined ASN.1 syntaxes, but I
disagree that adding "..." in the current CMS RecipientInfo syntax adds any
value.  If your use of "extended choice" refers to a RecipientInfo including
a CHOICE alternative not specified in the CMS document, then I object to
your statement that implementors "should not object if the they receive an
extended choice."  Please see my previous message for the explanation of why
I object to the premise that it is straightforward for recipient software to
ignore undefined CHOICE alternatives. 

- John Pawling

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 16 Mar 1999 17:27:06 (NZDT)

"John Ross" <[email-masked]> writes:
 
>should only be done when there is a requirement not met by the current syntax.
>As per Peter's comment, control of the choice can be achieved by the normal
>RFC process.  Also, if more control is required on S/MIME for interoperability
>reasons, the S/MIME specification (not the CMS spec) could prohibit the
>expansion of the choice unless a new version number is agreed.
 
This sounds like a good way to handle it, that way MSG can profile the stuff
specifically required for S/MIME leaving CMS able to be extended to handle
things which aren't necessarily useful for S/MIME, but are useful for other
applications (things like protection of stored data, of which PKCS #15 is a
prime example).
 
Peter.

---

From: "ross@secstan" <[email-masked]>
Date: Tue, 16 Mar 1999 17:11:34 -0000

John,

If the choice includes an OID extension with an OCTET STRING, then the one
pass ASN.1 decoding strategy on the entire object works OK. Correct?

If the implementation can support an OID extension will  it need to dig
deeper into the OCTETSTRING.  Implementations that do not support any OID
extension to the choice will just ignore it,  there should be no syntax or
decoder failure.   The end result will be that envelopeData will decode
correctly.

So I favour adding the OID extension to the choice.

Regards

JR
.

---

From: "Rich Ankney" <[email-masked]>
Date: Tue, 16 Mar 1999 14:03:58 -0500

I agree with this approach.  Otherwise I'd like to reserve the version
number 73, for X9.73 with CKM key management :-)

/ Rich

----------
> From: ross@secstan <[email-masked]>
> To: [email-masked]; John Pawling <[email-masked]>
> Date: Tuesday, March 16, 1999 12:11 PM
> 
> John,
> 
> >> i.e. in text using  the old ASN.1 rules), which gives a good pointer
to
> >I object to the premise that it is straightforward for recipient
software
> to

---

From: [email-masked] (John Pawling)
Date: Tue, 16 Mar 1999 14:38:49 -0500

John,

Upon further investigation, your proposal (excerpted below) does not cause
the ASN.1 decoding problems that I thought that it would.  Contrary to what
I stated in yesterday's message, I agree that your proposal would allow
general purpose ASN.1 libraries (such as SNACC) to be able to successfully
decode the RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and
keyTypeInfo OCTET STRING on the first pass.  The receiving software could
then examine the keyTypeIdentifier OID to determine if it is able to decode
the data within the keyTypeInfo OCTET STRING.  If it does not recognize the
OID, then it could skip the processing of this instance of RecipientInfo and
attempt to find another instance that it recognizes.  If it does not find a
recognized RecipientInfo CHOICE syntax that includes the recipient's
protected CEK, then the software would return an error.  

Also, Darren Harter's comment to change keyTypeInfo to an ANY will allow
general purpose ASN.1 decode libraries to be able to successfully decode the
RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and keyTypeInfo
ANY on the first pass.  I agree with Darren's comment that the receiving
software could completely decode the keyTypeInfo ANY as part of the first
pass if it recognizes the keyTypeIdentifier OID. 

>    keyTypeInfo OCTECT STRING --any defined by OID}

In summary, I agree that your proposal is technically feasible, but I am
still not sure that adding kext is the right thing to do.  This strategy
leads us to yet another S/MIME v3 spec that would define
ExternallyDefinedKeyAgreement syntaxes.  It seems that another strategy
would be to develop a new version of the base CMS document when the syntax
needs to be enhanced.  

- John Pawling