Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

From: "Pawling, John" <[email-masked]>
Date: Mon, 2 Jul 2001 10:38:31 -0400

All,

I change my proposal for the Section 6.1, EnvelopedData version setting
algorithm to:

    IF ((originatorInfo is present) AND 
	 (any version 2 attribute certificates are present)) OR
	 (any RecipientInfo structures are pwri CHOICE) OR
 	 (any RecipientInfo structures are ori CHOICE)
    THEN version is 3
    ELSE
	 IF (originatorInfo is present) OR
	    (unprotectedAttrs is present) OR
	    (any RecipientInfo structures are a version other than 0)
       THEN version is 2
       ELSE version is 0

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Pawling, John [mailto:[email-masked]]
Sent: Friday, June 29, 2001 2:45 PM
To: SMIME WG (E-mail)
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

Russ,

Thank you for your thoughtful responses to my comments.  I agree with all of
your responses and counter-proposals except for the following:
  
I stated: "7) Section 6.2.4, recommend changing PasswordRecipientInfo
version value to 1.  This would cause the EnvelopedData version number to be
set to 2 if the PasswordRecipientInfo was present.  This would assist with
debugging and error reporting."

You responded; "Please raise this on a separate thread.  This is a comment
on draft-ietf-smime-password, not CMS.  Right now, draft-ietf-smime-password
says to use version 0.

We can change the version setting algorithm...."

A few months ago, I proposed that the PasswordRecipientInfo version value
should be changed in draft-ietf-smime-password.  My proposal met with
resistance.  I propose that the Section 6.1, EnvelopedData version setting
algorithm should be changed as follows:

   [*** NEW ***] version is the syntax version number.  The
   appropriate value depends on originatorInfo, RecipientInfo, and
   unprotectedAttrs.  The version MUST be assigned as follows:

   IF (originatorInfo is present) OR (unprotectedAttrs is present)
     THEN
        IF (any version 2 attribute certificates are present)
        THEN version is 3
        ELSE version is 2
     ELSE
        IF (any RecipientInfo structures are a version other than 0) OR
           (any RecipientInfo structures are pwri CHOICE) 
        THEN version is 2
        ELSE version is 0

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 10 Jul 2001 17:21:07 (NZST)

"Jim Schaad" <[email-masked]> writes:

>I do not think that the EnvelopedData version number field was ever addressed
>in the Peter's document.  I agree that the algorithm needs to be updated.

That was deliberate, I don't see that a new RecipientInfo definition (or
anything similar) should be placing contraints on RFC 2630.  If there's a need
to change EnvelopedData then it should be done where it's defined, not in an
external document.

(While I'm commenting on this, I also feel that the best way to resolve this is
to issue a draft which leaves the issue unspecified, then in the next draft
write down what it is that implementations are doing, which will ensure that
(a) it's consensus behaviour and (b) the RFC reflects the real world.  Trying
to second-guess the behaviour of implementations seems risky at best).

Peter.

---

From: "Pawling, John" <[email-masked]>
Date: Tue, 10 Jul 2001 09:51:31 -0400

Peter,

I agree that the Password-based Encryption spec should not include
requirements for setting the EnvelopedData version field.  I agree that the
rfc2630bis spec is the correct document in which to specify the
EnvelopedData version-setting algorithm.  I proposed that the rfc2630bis
spec, Section 6.1, EnvelopedData version-setting algorithm should be changed
as follows: (same as proposed in my 7/2 reply to Russ and 7/5 reply to Jim):

        ELSE version is 0]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 1:21 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

That was deliberate, I don't see that a new RecipientInfo definition (or
anything similar) should be placing contraints on RFC 2630.  If there's a
need
to change EnvelopedData then it should be done where it's defined, not in an
external document.

(While I'm commenting on this, I also feel that the best way to resolve this
is
to issue a draft which leaves the issue unspecified, then in the next draft
write down what it is that implementations are doing, which will ensure that
(a) it's consensus behaviour and (b) the RFC reflects the real world.
Trying
to second-guess the behaviour of implementations seems risky at best).

Peter.

---

From: "Pawling, John" <[email-masked]>
Date: Wed, 11 Jul 2001 11:06:24 -0400

Peter,

My comments are in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 10:38 AM
To: [email-masked]; [email-masked]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

<snip>

Didn't we already go through all of this in April? My comment back then was:

  If the EnvelopedData version was incremented whenever a new RecipientInfo
was
  added then it's bad, 

[John: That is not what I am proposing.  I am proposing that the
EnvelopedData version number-setting algorithm should be changed because the
overall structure of the EnvelopedData syntax is being changed due to the
addition of the pwri and ori alternatives to RecipientInfo; and due to the
addition of the 2000 X.509 Attribute Certificate syntax to OriginatorInfo.
The ori syntax provides a mechanism for adding support for additional key
management techniques to RecipientInfo without changing the overall
structure of the EnvelopedData syntax.  The EnvelopedData version number
will not need to be changed if new key management techniques are added using
ori.] 

  because adding a single vers.n+1 RI to a bunch of vers.n
  RIs will change the EnvelopedData version even though there are vers.n RIs
  there which could be processed (that is, the code could still process the
  EnvelopedData except that the presence of the vers.n+1 value for the
  EnvelopedData would stop it). 

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.  When we
had this discussion in April, nobody (except for you) stated that their
implementations rejected an EnvelopedData based solely on the version value.
The S/MIME Freeware Library will not reject an object based solely on the
version value.  Typically, the version value is used as part of the process
of trying to determine why an implementation could not successfully process
an EnvelopedData object.] 

 OTOH if the EnvelopedData version is only
  incremented when the overall structure of the EnvelopedData is changed
then
  it's fine, because it won't try and decode something in a completely
  different format.

[John: The overall structure of the EnvelopedData is being changed.]

Consider what will happen if the scheme you propose is used.  If I produce
something with RSA and <foo, where foo = some exotic new method> key
transport
and set the syntax version number to anything other than 0, existing clients
will break.  

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.] 

If I set it to 0 there's at least some chance that existing
clients will handle it if they see the RSA RI first (that is, setting it to
0
may or may not work, but setting it to n will definitely break an existing
client...I think I modified my code at one point to specifically emit the
original RI's first so that existing apps would see them before they saw any
of
the new types).  In addition if an implementation sees a syntax version
number
of n then that doesn't mean that there isn't version 0 (or whatever)
information in there which it can still use.  As a result the only behaviour
for an implementation which makes much sense is:

  - When consuming data, ignore the version number.  Just because it's
labelled
    version 3 doesn't mean there isn't version 0 information in there
    somewhere, which makes the syntax version value meaningless.

[John: I disagree.  The version value is used as part of the process of
trying to determine why an implementation could not successfully process an
EnvelopedData object.]

  - When producing data, call it version 0.  This may or may not work with
    existing implementations, but it's better than calling it version 3
which 
    definitely won't work with existing applications.

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.] 

As I mentioned in my previous post, once implementation developers consider
the
implications of the syntax version numbers it won't matter what the spec
says,
what will be implemented is what causes the least interop problems.  I'll
repeat again my previous suggestion that in this area the spec codify what
implementations are doing rather than forcing arbitrary restrictions on
them.

[John: I believe that most implementations will not reject an EnvelopedData
based solely on the version number value, so I believe that my proposal does
not force arbitrary restrictions on them.]

Peter.

---

From: "Pawling, John" <[email-masked]>
Date: Wed, 11 Jul 2001 12:06:20 -0400

Russ,

I agree with your counter-proposals.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 11:31 AM
To: Pawling, John
Cc: [email-masked]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

John:

>Regarding Jim's comment 7: In previous messages, I proposed changes to the
>Section 6.1, EnvelopedData version-setting algorithm that address your
>comments.  I repeated the proposal today in my reply to Peter Gutmann's
>message sent to the S/MIME mail list.
>
>Regarding Jim's comment 11: In a previous reply to Jim (which he concurred
>with), I proposed the following:
>
>[John: I agree that a non-match is a critical security error.  Propose that
>the following sentence be added to Section 5.6 Message Signature
>Verification Process as the last paragraph:  "If the signedData signerInfo
>includes signedAttributes and the content-type attribute value is different
>from the signedData encapContentInfo eContentType value, then the CMS
>implementation MUST report an error."

How about an additional paragraph that says:  "If the SignedData signerInfo 
includes signedAttributes, then the content-type attribute value MUST match 
the SignedData encapContentInfo eContentType value."

>Propose that the following sentence be added to Section 9.3 MAC
Verification
>as the last paragraph:  "If the authenticatedData includes
>authenticatedAttributes and the content-type attribute value is different
>from the authenticatedData encapContentInfo eContentType value, then the
CMS
>implementation MUST report an error."]

To be parrallel, I propose a new paragraph in section 9.3 that says: "If 
the AuthenticatedData includes authenticatedAttributes, then the 
content-type attribute value MUST match the AuthenticatedData 
encapContentInfo eContentType value."

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 12 Jul 2001 03:29:46 (NZST)

"Pawling, John" <[email-masked]> writes:

>When we had this discussion in April, nobody (except for you) stated that
>their implementations rejected an EnvelopedData based solely on the version
>value.

Actually there were only two bits of code surveyed, the SFL and my code, which
have completely different interpretations of how to handle the version number
issue.  It could be that both of our views are wrong, and that everyone else
does something different again.  I'd like to see some comments from other
implementors on what their code will do when it finds an unexpected version
number in the EnvelopedData.

NB: Quietly changing your code, then reporting what the updated code does, is
    cheating :-).

Peter.

---

From: "Pawling, John" <[email-masked]>
Date: Wed, 18 Jul 2001 14:16:43 -0400

Russ,

I believe that the EnvelopedData version number-setting algorithm should be
changed when the
overall structure of the EnvelopedData syntax is changed (such as adding a
new alternative directly to the RecipientInfo CHOICE).  The ori syntax
provides a mechanism for adding support for additional key management
techniques to RecipientInfo without changing the overall structure of the
EnvelopedData syntax.  The EnvelopedData version number will not need to be
changed if new key management techniques are added using ori.  I still
believe that the EnvelopedData version number-setting text that I proposed
in earlier messages is the best solution.

In reference to your example, if the key management information required by
John is included in the ori alternative of the RecipientInfo CHOICE, then I
agree that Jim's receiving S/MIME implementation need not decode the
oriValue if it first finds a ktri alternative of the RecipientInfo CHOICE
for Jim.  However, if the key management information required by John is
included in a new alternative added directly to the RecipientInfo CHOICE,
then I disagree with the notion that all S/MIME implementations can ignore
an unrecognized alternative in a CHOICE. 

You stated: "If the overall EnvelopedData version must be updated to handle
the RecipientInfo for John, then Jim will reject the message,"  I disagree
with the theory that the EnvelopedData version value alone will cause
implementations to reject an EnvelopedData object.  Nobody (except for
Peter) has stated that their implementations rejected an EnvelopedData based
solely on the version value.  The S/MIME Freeware Library will not reject an
object based solely on the
version value.  Typically, the version value is used as part of the process
of trying to determine why an implementation could not successfully process
an EnvelopedData object.

In summary, adding new alternatives directly to the RecipientInfo CHOICE
does not maintain backwards compatibility with previous EnvelopedData
syntaxes.  Using the ori syntax to add support for an additional key
management technique does promote backwards compatibility because it does
not change the overall structure of the EnvelopedData syntax.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 7:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

Peter raises an interesting point here.

Does a change to a subordinate RecipientInfo structure necessarily require 
a change to the EnvelopedData version.  Consider the following.

Peter wants to encrypt a message for two recipients, Jim and John.  Jim has 
S/MIME v2!  To accomodate Jim, Peter uses RSA PKCS#1 v1.5 key transport for 
the 3-DES key.  John has a new widget, so Peter uses it to send the same 
3-DES CEK, but the new widget requires an updated RecipientInfo 
structure.  If the overall EnvelopedData version must be updated to handle 
the RecipientInfo for John, then Jim will reject the message, even though 
he would be able to parse the portion of the message intended for him.  Jim 
has no reason to decode the RecipientInfo intended for John.

What is the best way to handle backward compatibility?

Russ

---

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 19 Jul 2001 11:54:38 -0700

We blow out if the EnvelopedData version != 0.  I understand that this
prevents us from processing a message with mixed RecipientInfo structures.
In retrospect, we can probably get away with skipping any RecipientInfo for
which we don't recognize the version.

Blake

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 5:32 PM
To: [email-masked]; [email-masked]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

"Pawling, John" <[email-masked]> writes:

>Nobody (except for Peter) has stated that their implementations rejected an
>EnvelopedData based solely on the version value.

OTOH nobody (except for you) has stated that their implementations won't
reject
an EnvelopedData based solely on the version value.  I'd really like to see
some comments from other implementors - Baltimore, MS, Entrust, OpenSSL,
Netscape, what do all of these implementations do?  If the vendors won't
respond, perhaps someone who has all this stuff installed for interop
testing
or whatever could feed them some EnvelopedData with a weird version number
(eg
42) to see what they do.

Peter.

---

From: Andrew Shellshear <[email-masked]>
Date: Fri, 20 Jul 2001 10:39:28 +1000

Baltimore has two implementations.  The old implementation,
SMT, ignores the version number and will fail if it gets
anything that falls outside the PKCS#7 spec.  

The newer implementation, KeyTools S/MIME, pays attention
to the version number and won't process the message unless 
it understands it.  It's debatable - and I suppose that's 
what this is about - whether this is a better approach.

Taking a stab at it (and I haven't been reading this 
thread thoroughly, so apologies if this is treading old
ground) ideally, I'd ignore all the tagged ASN.1 that we 
don't know about, keep going until there's some parsing 
error we can't deal with, and *then* check the version 
number for error-reporting.  This would have gotten us
through the differences between PKCS#7 and RFC2630 
fairly handily.

By the way, while I'm here - the CMS in PKCS#7 is v1.5.
What's the version of CMS in RFC2630?  How should we
refer to it?

Andrew Shellshear.

"Guttman, Peter" <[email-masked]> writes:
> OTOH nobody (except for you) has stated that their 
> implementations won't reject
> respond, perhaps someone who has all this stuff installed for 
> interop testing
> or whatever could feed them some EnvelopedData with a weird 
> version number (eg
> 42) to see what they do.
> 
> Peter.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Jul 2001 12:36:22 -0400

>What's the version of CMS in RFC2630?  How should we

Is the RFC number sufficient?  If not, I can coordinate with the PKCS 
editor to sort this out.

Russ