RE: Comments: draft-ietf-smime-rfc2630bis-00

["Pawling, John" <[e-mail]>]

Russ,

I agree with all of your second round of responses to Jim's comments.  I
have a few minor comments:

25) Section 6.2.1, para "rid":  Please change "support one at least of these
alternatives." to  "support at least one of these alternatives."

29) Section 6.3, para 2:  You want to preserve the following sentence: "The
input to the content-encryption process is the "value" of the content being
enveloped."  In my opinion, this sentence is not needed and is confusing.
For example, when encrypting an ASN.1 encoded content, an implementer might
interpret this statement to mean that the tag and length octets of the ASN.1
encoded content should not be encrypted.  I still believe that the first
paragraph is fine (as is included in draft-ietf-smime-rfc2630bis-01) and
that the second paragraph should be deleted.    

36) countersignatures: Also, please change Section 5.4, para 2, as follows:

OLD: "The content type attribute is not required when used as part of a
countersignature unsigned attribute as defined in section 11.4."

NEW: "The content-type attribute MUST NOT be used as part of a
countersignature unsigned attribute as defined in section 11.4."

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================





Received: by above.proper.com (8.11.3/8.11.3) id f5TLHEm15969 for ietf-smime-bks; Fri, 29 Jun 2001 14:17:14 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5TLHDm15913 for <[e-mail]>; Fri, 29 Jun 2001 14:17:13 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98BQK>; Fri, 29 Jun 2001 17:17:30 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
Date: Fri, 29 Jun 2001 17:17:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I agree with all of your second round of responses to Jim's comments.  I
have a few minor comments:

25) Section 6.2.1, para "rid":  Please change "support one at least of these
alternatives." to  "support at least one of these alternatives."

29) Section 6.3, para 2:  You want to preserve the following sentence: "The
input to the content-encryption process is the "value" of the content being
enveloped."  In my opinion, this sentence is not needed and is confusing.
For example, when encrypting an ASN.1 encoded content, an implementer might
interpret this statement to mean that the tag and length octets of the ASN.1
encoded content should not be encrypted.  I still believe that the first
paragraph is fine (as is included in draft-ietf-smime-rfc2630bis-01) and
that the second paragraph should be deleted.    

36) countersignatures: Also, please change Section 5.4, para 2, as follows:

OLD: "The content type attribute is not required when used as part of a
countersignature unsigned attribute as defined in section 11.4."

NEW: "The content-type attribute MUST NOT be used as part of a
countersignature unsigned attribute as defined in section 11.4."

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================




Received: by above.proper.com (8.11.3/8.11.3) id f5TIiN018194 for ietf-smime-bks; Fri, 29 Jun 2001 11:44:23 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5TIiMm18190 for <[e-mail]>; Fri, 29 Jun 2001 11:44:22 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ97079>; Fri, 29 Jun 2001 14:44:38 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Fri, 29 Jun 2001 14:44:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SLi2s27367 for ietf-smime-bks; Thu, 28 Jun 2001 14:44:02 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SLi0m27362 for <[e-mail]>; Thu, 28 Jun 2001 14:44:00 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030eb7615320df48@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Thu, 28 Jun 2001 14:43:58 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Mandatory to Implement Algorithms in CMS
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:13 AM -0400 6/28/01, Housley, Russ wrote:
>As many of you know, I am arguing for a common set of cryptographic 
>algorithms throughout the IETF Security Area.  Having each CMS 
>referee specify their own set of algorithms does not support this 
>objective.
>
>What do others think?

Russ is right on a technical front: the IETF should use a common set. 
It is now looking better that this might happen, given that the TLS 
folks are going to use RSA with OEAP for AES ciphers.

On a political front, this is going to be a long battle. The IETF 
security area takes forever to act on things that they have agreed 
to; for instance, IPsec still mandates DES (not TripleDES) years 
after our self-congratulatory pronouncements about changing. There is 
very little cross-pollination in the security area, as shown by the 
TLS debate.

It is worth a shot, but don't expect success.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SKZDd25535 for ietf-smime-bks; Thu, 28 Jun 2001 13:35:13 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SKZBm25531 for <[e-mail]>; Thu, 28 Jun 2001 13:35:11 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.3/XCERT) with ESMTP id f5SKZ6i18129 for <[e-mail]>; Thu, 28 Jun 2001 13:35:06 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.3/XCERT) with ESMTP id f5SKZ6U10659 for <[e-mail]>; Thu, 28 Jun 2001 13:35:06 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <N4LJRPDN>; Thu, 28 Jun 2001 13:35:48 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TMPA7; Thu, 28 Jun 2001 16:33:26 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 28 Jun 2001 09:13:17 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Mandatory to Implement Algorithms in CMS
In-Reply-To: <003801c0eece$aaec7230$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

A few weeks ago, Jim Schaad submitted a simple comment on 
draft-ietf-smime-rfc2630bis-00.  Jim wrote:

>2.  I have a sever problem with the following text "However, implementations
>of the CMS MUST support the mandatory to implement algorithms specified in
>[CMSALG], or its successor."  It is my believe that this statement should be
>removed for the following reasons:
>
>a)  This violates the letter and spirit of the IETF process rules for
>pushing documents to standards.  In my opinion if this becomes a standard
>then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
>must this draft.  The words "MUST support" is extremely normative.
>
>b)  If I create a toolkit or other system and publish that I am STD [CMS]
>conformant.  It does not make sense that by updating the set of required
>algorithms I loose conformance to that standard.  I was compliant, I loose
>compliance through no action of mine.  This argues that a new standard
>number should be applied.
>
>c)  The reasoning behind not having a MUST for certificates is even more
>strongly appliciable here.  While certificates and heirarchies can move
>between different applications (thus making the arugment that application
>spaces should mandate algorithms a somewhat odd argument), that is not the
>case with CMS objects.  If S/MIME and CMS/SET were to specificy that
>different content encryption algorithms be required, there is no
>interactions between the spaces.  An S/MIME message would never be consumed
>(successfully) by a CMS/SET application nor would one expect it to be used.
>
> From this standpoint I think that not requiring a MUST on algorithms from
>CMS makes sense.

I have discussed this issue with both of the Security Area Directors.  Only 
one thing is clear: we cannot have a MUST statement that references 
"[CMSALG], or its successor."

If we were to achieve Full Standard status with the specification that we 
are working on, then changing the mandatory to implement algorithm would 
reset the status of the updated protocol to Proposed Standard.  I expect 
such a change at some point, probably to change the mandatory cipher from 
Triple-DES CBC to AES CBC.

There are other protocols besides S/MIME that are using CMS.  If CMS has 
mandatory to implement algorithms, then many of the interoperability issues 
are handled by a simple reference.  On the other hand, if CMS does not 
include any mandatory to implement algorithms, then each reference must 
specify them.

As many of you know, I am arguing for a common set of cryptographic 
algorithms throughout the IETF Security Area.  Having each CMS referee 
specify their own set of algorithms does not support this objective.

What do others think?

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f5SKXYs25496 for ietf-smime-bks; Thu, 28 Jun 2001 13:33:34 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5SKXUm25484 for <[e-mail]>; Thu, 28 Jun 2001 13:33:30 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Jun 2001 20:32:17 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA19445 for <[e-mail]>; Thu, 28 Jun 2001 16:33:32 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TMPBD>; Thu, 28 Jun 2001 16:33:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TMPA9; Thu, 28 Jun 2001 16:33:28 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 28 Jun 2001 11:09:13 -0400
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

This one comment was not addressed in my long reply to Jim Schaad's
note.  So, I am handling it separately.

>39) Section 11.3 Signing Time:  Jim stated and Russ agreed: "I think we
>should loosen up the locations allows for signing-time.  I would like to see
>it allowed as an autenticated attribute."
>I don't object to this change.  If the change is made, please make the
>following replacement:
>
>OLD: The SignedAttributes syntax is defined as a SET OF Attributes.  The
>      SignedAttributes in a signerInfo MUST not include multiple instances
>      of the signing-time attribute.
>
>NEW: The SignedAttributes and AuthAttributes syntaxes are each defined as
>      a SET OF Attributes.  The SignedAttributes in a signerInfo MUST NOT
>      include multiple instances of the signing-time attribute.  Similarly,
>      the AuthAttributes in an AuthenticatedData MUST NOT include multiple
>      instances of the signing-time attribute.

Good catch.  I did some minor edits on your proposed text:

    The SignedAttributes syntax and the AuthAttributes syntax are each
    defined as a SET OF Attributes.  The SignedAttributes in a signerInfo
    MUST NOT include multiple instances of the signing-time attribute.
    Similarly, the AuthAttributes in an AuthenticatedData MUST NOT
    include multiple instances of the signing-time attribute.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SKXYQ25498 for ietf-smime-bks; Thu, 28 Jun 2001 13:33:34 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5SKXUm25486 for <[e-mail]>; Thu, 28 Jun 2001 13:33:30 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Jun 2001 20:32:18 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA19450 for <[e-mail]>; Thu, 28 Jun 2001 16:33:32 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TMPB1>; Thu, 28 Jun 2001 16:33:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TMPA0; Thu, 28 Jun 2001 16:33:29 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 28 Jun 2001 16:15:02 -0400
Subject: Re: Comments to draft-ietf-smime-rfc2630bis-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

Thanks for you careful review.  I respond to each of your comments
below.  I think that all but one are resolved.

>1) Section 5.1, SignedData version description:  The existing text is
>confusing and could lead to multiple interpretations.  Recommend the
>following:
>
>    [*** NEW ***] version is the syntax version number.  The version
>    MUST be assigned as follows:
>
>      IF any v2 attribute certificates are present in certificates
>      THEN version MUST be 4
>      ELSE
>           IF any v1 attribute certificates are present in certificates
>            OR encapContentInfo eContentType is other than id-data
>            OR any version 3 SignerInfos are present
>           THEN version MUST be 3
>           ELSE version MUST be 1

I agree that a bit of pseudocode is useful here.  Yet, I want the
formatting of the pseudocode to be the same as was done for the
enveloped-data version.

How about:

       [*** NEW ***] version is the syntax version number.  The
       appropriate value depends on certificates, eContentType, and
       SignerInfo.  The version MUST be assigned as follows:

          IF (certificates is present) AND
             (any version 2 attribute certificates are present)
          THEN version MUST be 4
          ELSE
             IF ((certificates is present) AND
                 (any version 1 attribute certificates are present)) OR
                (encapContentInfo eContentType is other than id-data) OR
                (any SignerInfo structures are version 3)
             THEN version MUST be 3
             ELSE version MUST be 1


>2) Section 5.1, SignedData certificates description:  Please delete: "As
>discussed above, if attribute certificates are present, then the value of
>version MUST be 3."  I don't believe that we need to repeat the version
>setting algorithm in this text.

Good point.  The paragraph now reads:

       certificates is a collection of certificates.  It is intended that
       the set of certificates be sufficient to contain chains from a
       recognized "root" or "top-level certification authority" to all of
       the signers in the signerInfos field.  There may be more
       certificates than necessary, and there may be certificates
       sufficient to contain chains from two or more independent top-
       level certification authorities.  There may also be fewer
       certificates than necessary, if it is expected that recipients
       have an alternate means of obtaining necessary certificates (e.g.,
       from a previous set of certificates).  The signer's certificate
       MAY be included.  The use of version 1 attribute certificates is
       discouraged.

>3) Section 6.1, EnvelopedData version description:  The existing text is
>confusing and could lead to multiple interpretations.  I believe that Russ'
>recommended solution included in his reply to Jim Schaad's comments is
>correct 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)
>              THEN version is 2
>              ELSE version is 0"

I have already put this in the yet-to-be-published -02 draft that I am
working on.

>4) Section 6.2, RecipientInfo description:  Please delete "are" from the
>following sentence: "  [*** NEW ***] All implementations MUST support the
>mandatory to implement key management algorithms are specified in [CMSALG],
>or its successor."

Done.

>5) Section 6.2: I strongly agree that the pwri and ori CHOICES should be
>included in RecipientInfo.

I have put them into the yet-to-be-published -02 draft that I am working on.

>6) Section 6.2.4, 1rst paragraph: Replace "posses" with "possess".

Done.

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

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

>8) Section 6.2.5, 1rst sentence: Replace with "Recipient information for
>additional key management techniques are represented in the type
>OtherRecipientInfo."

Done.

>9) Section 6.4, last sentence: Please change to: "Any of the aforementioned
>key management techniques can be used for each recipient of the same
>encrypted content."

Done.

>10) Section 10.2.2. I strongly agree that the v1AttrCert and v2AttrCert
>CHOICES should be included in CertificateChoices.

Okay.  No change is needed.

>11) Section 11.1 Content Type:  Please add as last sentence of first
>paragraph: "The content-type attribute value MUST match the encapContentInfo
>eContentType value in the signed-data or authenticated-data."

Done.

>12) Section 11.2 Message Digest: Please replace the last paragraph with the
>following:
>
>    "The SignedAttributes and AuthAttributes syntaxes are each defined as
>    a SET OF Attributes.  The SignedAttributes in a signerInfo MUST NOT
>    include multiple instances of the message-digest attribute.  Similarly,
>    the AuthAttributes in an AuthenticatedData MUST NOT include multiple
>    instances of the message-digest attribute."

I agree, but I prefer a minor rewording to be parallel with the wording
that I proposed in the response to Jim Schaad's comments.  How about:

    The SignedAttributes syntax and AuthAttributes syntax are each
    defined as a SET OF Attributes.  The SignedAttributes in a signerInfo
    MUST NOT include multiple instances of the message-digest attribute.
    Similarly, the AuthAttributes in an AuthenticatedData MUST NOT
    include multiple instances of the message-digest attribute.

>13) Section 11.3 Signing Time: Please replace MAY with MUST in the following
>sentence: "[*** NEW ***] The signing-time attribute MAY be a signed
>attribute; it MUST NOT be an unsigned atribute, authenticated attribute,
>unauthenticated attribute, or unprotected attribute."

Done.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SKXYk25497 for ietf-smime-bks; Thu, 28 Jun 2001 13:33:34 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5SKXUm25485 for <[e-mail]>; Thu, 28 Jun 2001 13:33:30 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Jun 2001 20:32:17 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA19444 for <[e-mail]>; Thu, 28 Jun 2001 16:33:32 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TMPBF>; Thu, 28 Jun 2001 16:33:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TMPA8; Thu, 28 Jun 2001 16:33:26 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 28 Jun 2001 11:01:18 -0400
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
In-Reply-To: <003e01c0eed7$fe076250$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

Here are my responses.  I have not included the comments where my previous
reply resolved your concerns.

Where appropriate, I have addressed John Pawling's comments at the same
time.  I hope that this leads to quicker closure, not confusion is
subsequent replies to this message.

> > >1.  "The CMS ..." should be uniformly changed to "CMS ...".
> > I think that "The Cryptographic Message Syntax (CMS) ..." is correct.  Are
> > there places that I omitted "the"?
>
>Actually I have no problems with "The Crryptographic Message Syntax (CMS)".
>However as I look at the abstract for draft -00, the second paragraph starts
>"The CMS is derived from PKCS#7 ..."  In doing searches of the draft the
>phrase "the CMS" is quite common.  I count 5 that should be altered.

Okay.  I added "the" in the places that seems appropriate.

> > >2.  I have a sever problem with the following text "However,
> implementations
> > >of the CMS MUST support the mandatory to implement algorithms specified in
> > >[CMSALG], or its successor."  It is my believe that this statement
> should be
> > >removed for the following reasons:
> > >
> > >a)  This violates the letter and spirit of the IETF process rules for
> > >pushing documents to standards.  In my opinion if this becomes a standard
> > >then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
> > >must this draft.  The words "MUST support" is extremely normative.
> > >
> > >b)  If I create a toolkit or other system and publish that I am STD [CMS]
> > >conformant.  It does not make sense that by updating the set of required
> > >algorithms I loose conformance to that standard.  I was compliant, I loose
> > >compliance through no action of mine.  This argues that a new standard
> > >number should be applied.
> > >
> > >c)  The reasoning behind not having a MUST for certificates is even more
> > >strongly appliciable here.  While certificates and heirarchies can move
> > >between different applications (thus making the arugment that application
> > >spaces should mandate algorithms a somewhat odd argument), that is not the
> > >case with CMS objects.  If S/MIME and CMS/SET were to specificy that
> > >different content encryption algorithms be required, there is no
> > >interactions between the spaces.  An S/MIME message would never be
> consumed
> > >(successfully) by a CMS/SET application nor would one expect it to be
> used.
> > >
> > > From this standpoint I think that not requiring a MUST on algorithms from
> > >CMS makes sense.
> >
> > I have asked Jeff and Marcus for guidance.  So far, I have
> > not received input.

This is may be a thorny issue, so I started a separate thread for it.

> > >14) Section 5.3, para "signature":  I don't understand the
> > MUST in this
> > >paragraph.  The field is not optional how can it be omitted?
> >  The MUST is
> > >redundant.
> >
> > I agree that the ASN.1 definition and this must statement are
> > redundant.  They are not contradictory.  What do you not
> > understand?  What
> > change are you requesting?
>
>I am requesting the removal of the MUST as there is no option. (Just to be
>irritating, the field could be present but of zero length under the current
>text.)

John Pawling said: I agree with Jim.  Recommend the following replacement:

OLD: [*** NEW ***] This field MUST be present; however, the details of the
signature      depend on the signature algorithm employed.

NEW: [*** NEW ***] The details of the signature depend on the signature
algorithm employed.

Okay, you guys have convinced me.  I dropped the first portion of the
sentence.  The text now says:

       signature is the result of digital signature generation, using the
       message digest and the signer's private key.  [*** NEW ***] The
       details of the signature depend on the signature algorithm
       employed.

> > >16) Section 5.3, para "attrValues":  Append the following sentence.
> > >"attrType may impose additional restrictions on the number of items in the
> > >set."
> >
> > How about:
> >
> >     attrValues is a set of values that comprise the attribute.  The
> >     type of each value in the set can be determined uniquely by
> >     attrType.  The attrType MAY impose restrictions on the number of
> >     items in the set.
>
>I think this should be may not MAY as there is no protocol statement at this
>point.  If you want one then it should be "Signatures MUST fail verification
>if any restrictions on the number of items in the set, imposed by an
>attrType definition, are not met."

Agree, the "MAY" should be "can".

I go not agree with the MUST statement that you suggest.  To enforce this,
a recipient must know all possible OIDs and the restrictions associated
with them.

The text now reads (I provided a bit more surrounding text for context):

    The fields of type SignedAttribute and UnsignedAttribute have the
    following meanings:

       attrType indicates the type of attribute.  It is an object
       identifier.

       attrValues is a set of values that comprise the attribute.  The
       type of each value in the set can be determined uniquely by
       attrType.  The attrType can impose restrictions on the number of
       items in the set.

> > >21) Section 6.1, para "recipientInfos":  Should change the ASN to
> > >"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to reflect the
> MUST
> > >in the text?
> >
> > We use "SET OF" many places.  I do not think we want to add "SIZE (1..MAX)"
> > to them all.  Therefore, I am not sure that there is any real value in
> > adding it to this one.
>
>This is the only one that I see where we have a requirement that the set
>must not be empty and the element itself is not optional.  In most all of
>the other locations either the element itself can be omitted or the SET can
>consist of 0 items.

John Pawling said: I agree with Jim's recommendation.

Jim makes a good point.  I will add the "SIZE (1..MAX)" here.

> > >25) Section 6.2.1, para "rid": Two items
> > >a)  do we want to change to text to allow for SKI's to be
> non-certificate based.
>[Snip]
>
> > >c)  do we need to support both for specifying the certificate or just for
> > >locating a certificate? (i.e. encode vs decode)
> >
> > We need both (for send and receive).  I prefer the subject key identifier;
> > it is smaller.  However, S/MIME v2 requires issuer and serial number, which
> > is bigger than a subject key identifier.  If you do not think that the MUST
> > statement is complete, please propose an alternative.
>
>Alternative:  "Implementations MUST support both alternatives for specifying
>the recipient's certificate when decoding.  Implementations MUST support one
>of these alternatives for encoding."

John Pawling said: Recommend changing second sentence to: "Implementations
MUST support at least one of these alternatives for encoding.".

In an attempt to use the same terminology as the rest of the paragraph, I
prefer "recipient processing" to "decode" and "sender processing" to "encode."

How about:

       rid specifies the recipient's certificate or key that was used by
       the sender to protect the content-encryption key.  The
       RecipientIdentifier provides two alternatives for specifying the
       recipient's certificate, and thereby the recipient's public key.
       The recipient's certificate MUST contain a key transport public
       key.  The content-encryption key is encrypted with the recipient's
       public key.  The issuerAndSerialNumber alternative identifies the
       recipient's certificate by the issuer's distinguished name and the
       certificate serial number; the subjectKeyIdentifier identifies the
       recipient's certificate by the X.509 subjectKeyIdentifier
       extension value.  [*** NEW ***] For recipient processing,
       implementations MUST support both of these alternatives for
       specifying the recipient's certificate; and for sender processing,
       implementations MUST support one at least of these alternatives.

> > >27) Section 6.2.2, para "ukm":  I believe this is a MUST not a SHOULD
> > >statement.  I understand that we don't require it for the default
> algorithm
> > >(ESDH), but it is premitted to occur.  If UKM is not supported then
> all that
> > >could be done would be to ignore the recipient.  (Note: there is a
> MUST use
> > >UKM in rfc2631 for one case.)
> >
> > UKM is required for Static-Static Diffie-Hellman.  I basically agree with
> > your point, and it is not a big burden on an implementation. However, I
> > would like to hear from more implementors before I make a change here.
>
>John - please respond.

John Pawling said: Recommend the following replacement:

OLD:  [*** NEW ***] Implementations SHOULD support UKM
processing.  Implementations that do not process UKMs MUST gracefully
handle the presence of UKMs.

NEW:  [*** NEW ***] Implementations MUST support ASN.1 decoding a
KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. Implementations
that do not fully support the processing of UKMs MUST gracefully handle the
presence of UKMs.

Thanks John.  Again, in an attempt to use common terminology, I prefer
"recipient processing" to "decode."  How about:

       ukm is optional.  With some key agreement algorithms, the sender
       provides a User Keying Material (UKM) to ensure that a different
       key is generated each time the same two parties generate a
       pairwise key.  [*** NEW ***] Implementations MUST support
       recipient processing of a KeyAgreeRecipientInfo SEQUENCE that
       includes a ukm field.  Implementations that do not support key
       agreement algorithms that make use of UKMs MUST gracefully handle
       the presence of UKMs.

> > >28) Section 6.3.  Lets seperate the discussion on how to pad from the
> > >content encryption process.  I believe this should be moved to the
> algorithm
> > >section or a seperate section in this document.  The CEK algorithm is what
> > >determines the padding method not CMS.
> >
> > Not true.  CMS encryption always uses this padding.  CMS also supports
> > algorithms that do not require any padding (for example, a stream cipher),
> > but if padding is needed, this is the padding technique that MUST be used.
>
>I beg to differ with you on this issue.  I believe that I could define a new
>OID for RC5 with Ron's funky padding mode where the cipher text and plain
>text are the same lengths.  More importantly, with some of the new chaining
>modes for AES where there is interleaving between mutiple chains, I can see
>the padding to be done over a multiple of n blocks of data rather than one.
>I repeat, the padding alogorithm is a fucntion of the specified encryption
>algorithm and is not fixed.

You have not convinced me.  The way that I read the RFC 2630 text, we are
saying that if padding is needed, then this one padding technique must be
used.  If no padding is needed, as is the case if Triple-DES CFB8 is used,
then no padding is present.  If one of the proposed AES modes that provide
integrity and confidentiality were employed, the value of k might not match
the AES block size, but padding is still needed.

Right now, if padding is needed, we have one and only one way to do it.  I
want to preserve this feature.  In my view, support for other padding
approaches will only lead to more ways to fail interoperability.

If you still feel strongly about this one, please start a separate thread
for the discussion.

> > >29) Section 6.3, para 2:  I don't like the second sentence in this
> > >paragraph.  The content begin encrypted has little or nothing to do
> with the
> > >value of the encrypted data octet string.  This is the post encryption
> > >value.
> >
> > I understand your point.  These words have not changed in a very long
> > time.  Perhaps you would like to propose some better ones.
>
>Proposal:  "The input to the content-encryption process is the "value" of
>the content being enveloped.  The resulting value of the encryption process
>is then wrapped in an OCTET string for transporting."

John Pawling said: I believe that this paragraph should be deleted because
it is redundant to the first paragraph in section 6.3.

There was one point in the second paragraph that I thought should be
preserved.  I have merged the two paragraphs as follows:

    The content-encryption key for the desired content-encryption
    algorithm is randomly generated.  The input to the content-encryption
    process is the "value" of the content being enveloped.  This input
    data is padded as described below, then the padded data is encrypted
    using the content-encryption key.  The encryption operation maps an
    arbitrary string of octets (the data) to another string of octets
    (the ciphertext) under control of a content-encryption key.  The
    encrypted data is included in the envelopedData encryptedContentInfo
    encryptedContent OCTET STRING.

Note:  Nothing is marked as "[*** NEW ***]."  I consider this change to be
completely editorial.

> > >36) Section 11.1: Content-type MUST be omitted when building counter
> > >signatures.
> >
> > Elsewhere the document says: "The content-type attribute is not required
> > when used as part of a countersignature unsigned attribute as defined in
> > section 11.4."  This does not say MUST NOT to me.  It says MAY.  Eh?
>
>I agree that that is what it presently says.  In practice I don't believe
>that any has ever encoding in a content-type and I would like to codify that
>practice.

John Pawling said: I agree with Jim.  Recommend the following re-wording of
his proposal be added as the last sentence of the 1rst paragraph: "The
content-type attribute MUST be omitted when used as part of a
countersignature unsigned attribute as defined in section 11.4."

I changed the discussion of the content-type attribute in section 5.3 as
follows:

          A content-type attribute having as its value the content type
          of the EncapsulatedContentInfo value being signed.  Section
          11.1 defines the content-type attribute.  [*** NEW ***]
          However, the content-type attribute MUST NOT be used as part of
          a countersignature unsigned attribute as defined in section
          11.4.

I also changed section 11.4 to match:

    [*** NEW ***] Countersignature values have the same meaning as
    SignerInfo values for ordinary signatures, except that:


       1.  The signedAttributes field MUST NOT contain a content-type
       attribute; there is no content type for countersignatures.

       2.  The signedAttributes field MUST contain a message-digest
       attribute if it contains any other attributes.

       3.  The input to the message-digesting process is the contents
       octets of the DER encoding of the signatureValue field of the
       SignerInfo value with which the attribute is associated.

> > >37) Section 11.1: There MUST be exactly one instance of AttributeValue
> > >present.  -- MUST NOT is not testable.
> >
> > It says: "A content-type attribute MUST have a single attribute value, even
> > though the syntax is defined as a SET OF AttributeValue. There MUST NOT be
> > zero or multiple instances of AttributeValue present."
> >
> > So, you agree with the first sentence.  I think the second sentence is a
> > restatement of the first.  Does the second sentence help anyone understand?
>
>I don't believe that the second statement helps.  I did miss the fact that
>it is a restatement of the first.

Perhaps making it all one sentence will make it clear that there is only
one idea being expressed.  I consider this an editorial change, and I did
not insert "[*** NEW ***]."

How about:

    Even though the syntax is defined as a SET OF AttributeValue, a
    content-type attribute MUST have a single attribute value; zero or
    multiple instances of AttributeValue are not permitted.

> > >43) Section 11.5: Item 1 in the values.  Change to "... but MUST NOT
> contain
> > >a content-type attribute. (No content type has been defined for a
> > >counter-signature.)"
> >
> > I assume that this is a comment about section 11.4, there is
> > no section 11.5.
> >
> > See response to comment 36.  It seem to me that you are interpreting "need
> > not" as "MUST NOT."  What have other implementors done?
>
>see comment above on 36.

John Pawling said:  Recommend the following
replacement:

OLD:  1.  The signedAttributes field MUST contain a message-digest
       attribute if it contains any other attributes, but need not
       contain a content-type attribute, as there is no content type for
       countersignatures.

NEW:  1.  The signedAttributes field MUST contain a message-digest
       attribute if it contains any other attributes.

         2.  The signedAttributes field MUST NOT contain a content-type
         attribute, because there is no content type for countersignatures.

I composed the text in response to comment 36 before I read John's
proposal.  My text and John's text are almost identical (except for order),
so I assume that the text that I proposed above is acceptable.

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RJnPX26655 for ietf-smime-bks; Wed, 27 Jun 2001 12:49:25 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RJnOm26651 for <[e-mail]>; Wed, 27 Jun 2001 12:49:24 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ97SAB>; Wed, 27 Jun 2001 15:49:41 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
Date: Wed, 27 Jun 2001 15:49:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I agree with the majority of Jim's comments and Russ' responses.  I have a
few comments regarding their statements.  My comments are numbered
consistently with Jim's original message.   


14) Section 5.3, SignerInfo signature description:  Jim stated: "I don't
understand the MUST in this paragraph.  The field is not optional how can it
be omitted?  The MUST is redundant."  I agree with Jim.  Recommend the
following replacement:

OLD: [*** NEW ***] This field MUST be present; however, the details of the
signature
     depend on the signature algorithm employed.

NEW: [*** NEW ***] The details of the signature depend on the signature
algorithm employed.


21) Section 6.1, EnvelopedData:  I agree with Jim's recommendation as
follows: "Should change the ASN to "RecipientInfos ::= SET SIZE (1..MAX) OF
RecipientInfo" to reflect the MUST in the text?"


25) Section 6.2.1, KeyTransRecipientInfo rid description: Jim proposed:
"Alternative:  "Implementations MUST support both alternatives for
specifying the recipient's certificate when decoding.  Implementations MUST
support one of these alternatives for encoding."  Recommend changing second
sentence to: "Implementations MUST support at least one of these
alternatives for encoding.".


27) Section 6.2.2, KeyAgreeRecipientInfo ukm description: Jim stated: "I
believe this is a MUST not a SHOULD statement."  Recommend the following
replacement:

OLD:  [*** NEW ***] Implementations SHOULD support UKM
      processing.  Implementations that do not process UKMs MUST
      gracefully handle the presence of UKMs.

NEW:  [*** NEW ***] Implementations MUST support ASN.1 decoding a 
	KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
	Implementations that do not fully support the processing of
	UKMs MUST gracefully handle the presence of UKMs.  


29) Section 6.3 Content-encryption Process, paragraph 2:  Jim Proposed: "The
input to the content-encryption process is the "value" of the content being
enveloped.  The resulting value of the encryption process is then wrapped in
an OCTET string for transporting."  I believe that this paragraph should be
deleted because it is redundant to the first paragraph in section 6.3.  


36) Section 11.1 Content Type:  Jim proposed: "Content-type MUST be omitted
when building counter signatures."  I agree with Jim.  Recommend the
following re-wording of his proposal be added as the last sentence of the
1rst paragraph: "The content-type attribute MUST be omitted when used as
part of a countersignature unsigned attribute as defined in section 11.4."


39) Section 11.3 Signing Time:  Jim stated and Russ agreed: "I think we
should loosen up the locations allows for signing-time.  I would like to see
it allowed as an autenticated attribute."
I don't object to this change.  If the change is made, please make the
following replacement:

OLD: The SignedAttributes syntax is defined as a SET OF Attributes.  The
     SignedAttributes in a signerInfo MUST not include multiple instances
     of the signing-time attribute.

NEW: The SignedAttributes and AuthAttributes syntaxes are each defined as
     a SET OF Attributes.  The SignedAttributes in a signerInfo MUST NOT
     include multiple instances of the signing-time attribute.  Similarly,
     the AuthAttributes in an AuthenticatedData MUST NOT include multiple
     instances of the signing-time attribute.


43) Section 11.4 Countersignature:  Jim stated "Item 1 in the values.
Change to "... but MUST NOT contain a content-type attribute. (No content
type has been defined for a counter-signature.)"  Recommend the following
replacement:

OLD:  1.  The signedAttributes field MUST contain a message-digest
      attribute if it contains any other attributes, but need not
      contain a content-type attribute, as there is no content type for
      countersignatures.

NEW:  1.  The signedAttributes field MUST contain a message-digest
      attribute if it contains any other attributes.

	2.  The signedAttributes field MUST NOT contain a content-type
	attribute, because there is no content type for countersignatures.


===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RHbcH21869 for ietf-smime-bks; Wed, 27 Jun 2001 10:37:38 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5RHbbm21865 for <[e-mail]>; Wed, 27 Jun 2001 10:37:37 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 27 Jun 2001 10:37:34 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BR2H9>; Wed, 27 Jun 2001 10:37:33 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Simon Blanchet'" <[e-mail]>, [e-mail]
Subject: RE: Difference between application/x-pkcs7-mime and application/p kcs7-mime?
Date: Wed, 27 Jun 2001 10:37:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1724C65743046-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The x- got dropped when S/MIME became cool.  The good news is that some
clients don't recognize the non-x- version, and the even better news is that
some clients only generate the x- version.

This is one of those unfortunate things, where "being conservative in what
you send" means "send the x- version", and "being liberal in what you
accept" means parsing both.

Blake

-----Original Message-----
From: Simon Blanchet [mailto:[e-mail]]
Sent: Wednesday, June 27, 2001 7:00 AM
To: [e-mail]
Subject: Difference between application/x-pkcs7-mime and
application/pkcs7-mime?



HI,

Having read S/MIME RFCs and others ressources about S/MIME in general I've
seen
2 versions of Content-Type for CMS Entity.  I was just wandering the
difference
between the 2 Content-Type:

application/x-pkcs7-mime

and

application/pkcs7-mime

Is it the S/MIME version?  From an application stand point, when it's time
to
recognize S/MIME message do we have to handle both Content-Type?

Thanks

|=========================================
| Simon Blanchet, B.Sc.Comp.Sc.
| Software Designer
| Matrox Electronic Systems Ltd.
|
| Email: [e-mail]
| Web: http://www.matrox.com
| Phone: [phone] x7421
| Fax: [phone]
|=========================================




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RFii018381 for ietf-smime-bks; Wed, 27 Jun 2001 08:44:44 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RFiim18377 for <[e-mail]>; Wed, 27 Jun 2001 08:44:44 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ97P14>; Wed, 27 Jun 2001 11:45:00 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: Comments to draft-ietf-smime-rfc2630bis-01
Date: Wed, 27 Jun 2001 11:44:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

In my opinion, Russ did an outstanding job of updating this document.  I
agree with the vast majority of the proposed changes.  I have comments as
follows:

1) Section 5.1, SignedData version description:  The existing text is
confusing and could lead to multiple interpretations.  Recommend the
following: 

   [*** NEW ***] version is the syntax version number.  The version
   MUST be assigned as follows:

     IF any v2 attribute certificates are present in certificates
     THEN version MUST be 4
     ELSE 
	  IF any v1 attribute certificates are present in certificates
           OR encapContentInfo eContentType is other than id-data
           OR any version 3 SignerInfos are present
 	  THEN version MUST be 3
	  ELSE version MUST be 1


2) Section 5.1, SignedData certificates description:  Please delete: "As
discussed above, if attribute certificates are present, then the value of
version MUST be 3."  I don't believe that we need to repeat the version
setting algorithm in this text.  

3) Section 6.1, EnvelopedData version description:  The existing text is
confusing and could lead to multiple interpretations.  I believe that Russ'
recommended solution included in his reply to Jim Schaad's comments is
correct 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)
             THEN version is 2
             ELSE version is 0"


4) Section 6.2, RecipientInfo description:  Please delete "are" from the
following sentence: "  [*** NEW ***] All implementations MUST support the
mandatory to implement key management algorithms are specified in [CMSALG],
or its successor."

5) Section 6.2: I strongly agree that the pwri and ori CHOICES should be
included in RecipientInfo.

6) Section 6.2.4, 1rst paragraph: Replace "posses" with "possess".

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.

8) Section 6.2.5, 1rst sentence: Replace with "Recipient information for
additional key management techniques are represented in the type
OtherRecipientInfo."

9) Section 6.4, last sentence: Please change to: "Any of the aforementioned
key management techniques can be used for each recipient of the same
encrypted content."

10) Section 10.2.2. I strongly agree that the v1AttrCert and v2AttrCert
CHOICES should be included in CertificateChoices.

11) Section 11.1 Content Type:  Please add as last sentence of first
paragraph: "The content-type attribute value MUST match the encapContentInfo
eContentType value in the signed-data or authenticated-data."

12) Section 11.2 Message Digest: Please replace the last paragraph with the
following:

   "The SignedAttributes and AuthAttributes syntaxes are each defined as
   a SET OF Attributes.  The SignedAttributes in a signerInfo MUST NOT
   include multiple instances of the message-digest attribute.  Similarly,
   the AuthAttributes in an AuthenticatedData MUST NOT include multiple
   instances of the message-digest attribute."

13) Section 11.3 Signing Time: Please replace MAY with MUST in the following
sentence: "[*** NEW ***] The signing-time attribute MAY be a signed
attribute; it MUST NOT be an unsigned atribute, authenticated attribute,
unauthenticated attribute, or unprotected attribute."


===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================






                                                         






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RE1Jd10807 for ietf-smime-bks; Wed, 27 Jun 2001 07:01:19 -0700 (PDT)
Received: from morrison.matrox.com (morrison.matrox.com [138.11.254.205]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RE1Hm10800 for <[e-mail]>; Wed, 27 Jun 2001 07:01:17 -0700 (PDT)
Received: (from mtxmail@localhost) by morrison.matrox.com (8.8.8/8.8.8) id KAA03634 for <[e-mail]>; Wed, 27 Jun 2001 10:01:17 -0400 (EDT)
Received: from venus(192.168.1.30) by morrison via smap (V2.0) id xma003488; Wed, 27 Jun 01 10:00:24 -0400
Received: from pluton.matrox.com (pluton.matrox.com [192.168.51.7]) by venus.matrox.com (8.11.0/8.11.0) with ESMTP id f5RE0Ol01109 for <[e-mail]>; Wed, 27 Jun 2001 10:00:24 -0400 (EDT)
Received: from sblanche (dyn-18-110.matrox.com [192.168.18.110]) by pluton.matrox.com (8.8.8/8.8.8) with SMTP id JAA24553 for <[e-mail]>; Wed, 27 Jun 2001 09:59:34 -0400 (EDT)
From: "Simon Blanchet" <[e-mail]>
To: <[e-mail]>
Subject: Difference between application/x-pkcs7-mime and application/pkcs7-mime?
Date: Wed, 27 Jun 2001 10:00:23 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

HI,

Having read S/MIME RFCs and others ressources about S/MIME in general I've seen
2 versions of Content-Type for CMS Entity.  I was just wandering the difference
between the 2 Content-Type:

application/x-pkcs7-mime

and

application/pkcs7-mime

Is it the S/MIME version?  From an application stand point, when it's time to
recognize S/MIME message do we have to handle both Content-Type?

Thanks

|=========================================
| Simon Blanchet, B.Sc.Comp.Sc.
| Software Designer
| Matrox Electronic Systems Ltd.
|
| Email: [e-mail]
| Web: http://www.matrox.com
| Phone: [phone] x7421
| Fax: [phone]
|=========================================



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5K90li03629 for ietf-smime-bks; Wed, 20 Jun 2001 02:00:47 -0700 (PDT)
Received: from custos2.adm.arcor.net (custos2.arcor-ip.de [145.253.2.52]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5K90jk03616 for <[e-mail]>; Wed, 20 Jun 2001 02:00:45 -0700 (PDT)
Received: (from smap@localhost) by custos2.adm.arcor.net ( ARCOR.5.02) id LAA51756 for <[e-mail]>; Wed, 20 Jun 2001 11:00:28 +0200
From: [e-mail]
Received: from tlc-ffs012.tlc-ffdo01.db.de(172.24.113.20) via SMTP (2.0.002f) by custos2, id smtpd95JPia; Wed, 20 Jun 2001 11:00:27 +0100 (MET)
Received: by TLC-FFS012.TLC-FFDO01.DB.DE(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 41256A71.0036BCF6 ; Wed, 20 Jun 2001 10:57:53 +0100
X-Lotus-FromDomain: TLC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 20 Jun 2001 10:55:54 +0100
Subject: How to clearly recognize an S/MIME message
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Having read the two answers (thanks) to my question I get the following
impression:

   Section 3.2.1 should have a sentence added that says something like "Only if
the MIME type of a message is application/octet-stream the receiving agent
SHOULD use the file extension to determine if the message is an S/MIME message.

   I think, this would remedy the apparent contradiction.


   Regards,

   Frank Schwab




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5JJE5j23322 for ietf-smime-bks; Tue, 19 Jun 2001 12:14:05 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5JJE4J23318 for <[e-mail]>; Tue, 19 Jun 2001 12:14:04 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 19 Jun 2001 12:14:01 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BR1T5>; Tue, 19 Jun 2001 12:14:01 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: How to recognize an S/MIME message?
Date: Tue, 19 Jun 2001 12:13:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 17317BF315857-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Perhaps this can be clarified with an example in the new RFC2633:

1. If the Content-Type is application/pkcs7-mime, then the content should be
interpreted as a CMS object as specified in section 3.2

2. If the Content-Type is application/octet-stream, and the file extension
is P7M, then the content ahould be interpreted as a CMS object as specified
in section 3.2

3. If the Content-Type is application/pkcs7-signature then the content
should be interpreted per sction 3.4.3.1

4. If the Content-Type is application/octet-stream, and the file extension
is P7S, then the content should be interpreted per section 3.4.3.1

Personally, I think that Outlook is out-of-spec, but I can see how section
3.8 could be misunderstood.

Blake

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, June 19, 2001 4:14 AM
To: [e-mail]
Subject: How to recognize an S/MIME message?






My company is currently evaluating PKI and S/MIME components and we came
across
an apparent contradiction in the S/MIME v2 and v3 RFCs (RFC2311 and
RFC2633).

   Both documents have the following words in section 3.2.1:

   Including a file name serves two purposes. It facilitates easier use
   of S/MIME objects as files on disk. It also can convey type
   information across gateways. When a MIME entity of type
   application/pkcs7-mime (for example) arrives at a gateway that has no
   special knowledge of S/MIME, it will default the entity's MIME type
   to application/octet-stream and treat it as a generic attachment,
   thus losing the type information. However, the suggested filename for
   an attachment is often carried across a gateway. This often allows
   the receiving systems to determine the appropriate application to
   hand the attachment off to, in this case a stand-alone S/MIME
   processing application. Note that this mechanism is provided as a
   convenience for implementations in certain environments. A proper
   S/MIME implementation MUST use the MIME types and MUST NOT rely on
   the file extensions.

   This clearly states that an S/MIME-capable E-Mail client must only
recognize
S/MIME messages when they use the correct MIME types. However, section 3.8
of
both documents seem to contradict section 3.2.1:

3.8 Identifying an S/MIME Message

   Because S/MIME takes into account interoperation in non-MIME
   environments, several different mechanisms are employed to carry the
   type information, and it becomes a bit difficult to identify S/MIME
   messages. The following table lists criteria for determining whether
   or not a message is an S/MIME message. A message is considered an
   S/MIME message if it matches any below.

   The file suffix in the table below comes from the "name" parameter in
   the content-type header, or the "filename" parameter on the content-
   disposition header. These parameters that give the file suffix are
   not listed below as part of the parameter section.

   MIME type:   application/pkcs7-mime
   parameters:  any
   file suffix: any

   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any

   MIME type:   application/octet-stream
   parameters:  any
   file suffix: p7m, p7s, p7c

   This clearly states that a MIME type application/octet-stream with a file
suffix of e.g. p7m is a valid S/MIME message.

   It seems that not only we but also the vendors are confused by this
apparent
contradiction. Microsoft's Outlook adheres to section 3.2.1 and does not
recognize S/MIME messages with MIME type application/octet-stream and file
suffix p7m while Netscape's Messenger does.

   Can anybody shed some light on this? Maybe it would be a good idea to
clarify
the standard on this topic.


   Regards,

   Frank Schwab
   TLC GmbH





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5JE5uU11947 for ietf-smime-bks; Tue, 19 Jun 2001 07:05:56 -0700 (PDT)
Received: from aeposmail.aepos.com (aeposmail.aepos.com [209.112.11.5]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5JE5tJ11943 for <[e-mail]>; Tue, 19 Jun 2001 07:05:55 -0700 (PDT)
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256A70.004E48C5 ; Tue, 19 Jun 2001 10:15:04 -0400
X-Lotus-FromDomain: AEPOS
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 19 Jun 2001 10:15:00 -0400
Subject: RE: How to recognize an S/MIME message?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

My company is currently evaluating PKI and S/MIME components and we came across
an apparent contradiction in the S/MIME v2 and v3 RFCs (RFC2311 and RFC2633).

   Both documents have the following words in section 3.2.1:

   Including a file name serves two purposes. It facilitates easier use
   of S/MIME objects as files on disk. It also can convey type
   information across gateways. When a MIME entity of type
   application/pkcs7-mime (for example) arrives at a gateway that has no
   special knowledge of S/MIME, it will default the entity's MIME type
   to application/octet-stream and treat it as a generic attachment,
   thus losing the type information. However, the suggested filename for
   an attachment is often carried across a gateway. This often allows
   the receiving systems to determine the appropriate application to
   hand the attachment off to, in this case a stand-alone S/MIME
   processing application. Note that this mechanism is provided as a
   convenience for implementations in certain environments. A proper
   S/MIME implementation MUST use the MIME types and MUST NOT rely on
   the file extensions.

   This clearly states that an S/MIME-capable E-Mail client must only recognize
S/MIME messages when they use the correct MIME types. However, section 3.8 of
both documents seem to contradict section 3.2.1:

3.8 Identifying an S/MIME Message

   Because S/MIME takes into account interoperation in non-MIME
   environments, several different mechanisms are employed to carry the
   type information, and it becomes a bit difficult to identify S/MIME
   messages. The following table lists criteria for determining whether
   or not a message is an S/MIME message. A message is considered an
   S/MIME message if it matches any below.

   The file suffix in the table below comes from the "name" parameter in
   the content-type header, or the "filename" parameter on the content-
   disposition header. These parameters that give the file suffix are
   not listed below as part of the parameter section.

   MIME type:   application/pkcs7-mime
   parameters:  any
   file suffix: any

   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any

   MIME type:   application/octet-stream
   parameters:  any
   file suffix: p7m, p7s, p7c

   This clearly states that a MIME type application/octet-stream with a file
suffix of e.g. p7m is a valid S/MIME message.

   It seems that not only we but also the vendors are confused by this apparent
contradiction. Microsoft's Outlook adheres to section 3.2.1 and does not
recognize S/MIME messages with MIME type application/octet-stream and file
suffix p7m while Netscape's Messenger does.

   Can anybody shed some light on this? Maybe it would be a good idea to clarify
the standard on this topic.


   Regards,

   Frank Schwab
   TLC GmbH

-----

   The S/MIME Message Specification RFC's (2311 and 2633) state that your should
try to be "liberal in what you receive and conservative in what you send".  I've
always interpreted the above sections to mean that a sending agent should always
include the correct S/MIME header information (i.e. application/pkcs7-mime or
application/pkcs7-signature), and that as a minimum a receiving agent should
recognize these.  In addition, a receiving agent may recognize the p7m, p7s and
p7c file extensions as indicating S/MIME, in case the message has passed through
an environment (e.g. X.400 or MAPI) in which the MIME content types are dropped
(though in such a case, validation of the clear signature in the p7s file would
probably fail).  Some gateways keep a table of file extensions, and when they
convert a message to MIME, they assign the corresponding content type to any
attachments based on their extensions.  Other gateways treat all attachments as
generic, i.e. application/octet-stream.

   The main problem with relying on file extensions to determine the content
type is that there is no regulation on the use of extensions.  Anyone can create
a file with a .p7m extension regardless of its content (e.g. to them p7m might
stand for Payments in the 7th Month or Parking level 7 Map).  A receiving agent
can never be certain that such an attachment contains a PKCS#7 object until it
is processed, and to have a receiving agent constantly reporting errors while
processing attachments which were never meant to contain secure content would be
annoying.  Fortunately there are currently no major software products that use
the p7m extension for anything other than S/MIME.

   In short, if you want to guarantee that your receiving agent recognizes all
inbound S/MIME messages, have it use the file extensions.  If you want to be
certain that every processed attachment contains a PKCS#7 object, go by the MIME
content types only.

   As for Outlook and Netscape, the Outlook client is forced to rely on the
Exchange server to identify MIME content types, since all it recognizes is the
MAPI message format which does not preserve the MIME structure of a message.
How the Outlook client can verify an S/MIME clear signature is a mystery,
considering that it doesn't receive the signed content intact and the server
doesn't have the public key required to verify the signature (perhaps the
Exchange server appends the original MIME text to the MAPI message object for
such messages).  Netscape, on the other hand, has the entire original MIME
message to work with.  It seems to look up content types for generic attachments
with known extensions, and to process them accordingly.  I've noticed that
Netscape is extremely liberal in what it receives, and can even process messages
from Outlook that contain the annoying and otherwise unreadable winmail.dat
attachment that often plagues the acquaintances of Outlook users.  Not that I'm
partial to either one; I usually use Lotus Notes with an Entrust-Ready secure
messaging add-in.




Received: by above.proper.com (8.11.3/8.11.3) id f5JAHAW28319 for ietf-smime-bks; Tue, 19 Jun 2001 03:17:10 -0700 (PDT)
Received: from custos2.adm.arcor.net (custos2.arcor-ip.de [145.253.2.52]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JAH8J28311 for <[e-mail]>; Tue, 19 Jun 2001 03:17:08 -0700 (PDT)
Received: (from smap@localhost) by custos2.adm.arcor.net ( ARCOR.5.02) id MAA46928 for <[e-mail]>; Tue, 19 Jun 2001 12:17:03 +0200
From: [e-mail]
Received: from tlc-ffs012.tlc-ffdo01.db.de(172.24.113.20) via SMTP (2.0.002f) by custos2, id smtpdywyNqa; Tue, 19 Jun 2001 12:17:01 +0100 (MET)
Received: by TLC-FFS012.TLC-FFDO01.DB.DE(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 41256A70.003DC29A ; Tue, 19 Jun 2001 12:14:35 +0100
X-Lotus-FromDomain: TLC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 19 Jun 2001 12:13:53 +0100
Subject: How to recognize an S/MIME message?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My company is currently evaluating PKI and S/MIME components and we came across
an apparent contradiction in the S/MIME v2 and v3 RFCs (RFC2311 and RFC2633).

   Both documents have the following words in section 3.2.1:

   Including a file name serves two purposes. It facilitates easier use
   of S/MIME objects as files on disk. It also can convey type
   information across gateways. When a MIME entity of type
   application/pkcs7-mime (for example) arrives at a gateway that has no
   special knowledge of S/MIME, it will default the entity's MIME type
   to application/octet-stream and treat it as a generic attachment,
   thus losing the type information. However, the suggested filename for
   an attachment is often carried across a gateway. This often allows
   the receiving systems to determine the appropriate application to
   hand the attachment off to, in this case a stand-alone S/MIME
   processing application. Note that this mechanism is provided as a
   convenience for implementations in certain environments. A proper
   S/MIME implementation MUST use the MIME types and MUST NOT rely on
   the file extensions.

   This clearly states that an S/MIME-capable E-Mail client must only recognize
S/MIME messages when they use the correct MIME types. However, section 3.8 of
both documents seem to contradict section 3.2.1:

3.8 Identifying an S/MIME Message

   Because S/MIME takes into account interoperation in non-MIME
   environments, several different mechanisms are employed to carry the
   type information, and it becomes a bit difficult to identify S/MIME
   messages. The following table lists criteria for determining whether
   or not a message is an S/MIME message. A message is considered an
   S/MIME message if it matches any below.

   The file suffix in the table below comes from the "name" parameter in
   the content-type header, or the "filename" parameter on the content-
   disposition header. These parameters that give the file suffix are
   not listed below as part of the parameter section.

   MIME type:   application/pkcs7-mime
   parameters:  any
   file suffix: any

   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any

   MIME type:   application/octet-stream
   parameters:  any
   file suffix: p7m, p7s, p7c

   This clearly states that a MIME type application/octet-stream with a file
suffix of e.g. p7m is a valid S/MIME message.

   It seems that not only we but also the vendors are confused by this apparent
contradiction. Microsoft's Outlook adheres to section 3.2.1 and does not
recognize S/MIME messages with MIME type application/octet-stream and file
suffix p7m while Netscape's Messenger does.

   Can anybody shed some light on this? Maybe it would be a good idea to clarify
the standard on this topic.


   Regards,

   Frank Schwab
   TLC GmbH




Received: by above.proper.com (8.11.3/8.11.3) id f5CJOcP13192 for ietf-smime-bks; Tue, 12 Jun 2001 12:24:38 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CJOaJ13187 for <[e-mail]>; Tue, 12 Jun 2001 12:24:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22930; Tue, 12 Jun 2001 15:24:06 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Domain Security Services using S/MIME to Proposed Standard
Reply-to: [e-mail]
Date: Tue, 12 Jun 2001 15:24:06 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Domain Security Services using S/MIME
<draft-ietf-smime-domsec-08.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by June 26, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5A6Xe912140 for ietf-smime-bks; Sat, 9 Jun 2001 23:33:40 -0700 (PDT)
Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5A6XWJ12097 for <[e-mail]>; Sat, 9 Jun 2001 23:33:32 -0700 (PDT)
Received: from vishnu.vishnu (unknown [203.197.230.31]) by del2.vsnl.net.in (Postfix) with ESMTP id B696B3F9D7 for <[e-mail]>; Sun, 10 Jun 2001 12:04:27 +0530 (IST)
Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id M418DSQK; Sun, 10 Jun 2001 12:02:54 +0530
Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06102001-115214-4.MMD@vishnu; Sun, 10 Jun 2001 11:52:14 +0530
Delivered-To: [e-mail]
Received: (qmail 9161 invoked by uid 104); 9 Jun 2001 20:31:52 -0000
Delivered-To: [e-mail]
Received: (qmail 9150 invoked by alias); 9 Jun 2001 20:31:52 -0000
Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 9 Jun 2001 20:31:52 -0000
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03750 for [e-mail]; Sat, 9 Jun 2001 15:45:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id PAA03734 for <[e-mail]>; Sat, 9 Jun 2001 15:43:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17745; Sat, 9 Jun 2001 15:43:56 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Reuse of CMS Content Encryption Keys to Proposed Standard
Reply-To: [e-mail]
Date: Sat, 09 Jun 2001 15:43:55 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Reuse of CMS Content Encryption Keys
<draft-ietf-smime-rcek-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by June 23, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-rcek-04.txt





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5A6XdF12114 for ietf-smime-bks; Sat, 9 Jun 2001 23:33:39 -0700 (PDT)
Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5A6XWJ12096 for <[e-mail]>; Sat, 9 Jun 2001 23:33:32 -0700 (PDT)
Received: from vishnu.vishnu (unknown [203.197.230.31]) by del2.vsnl.net.in (Postfix) with ESMTP id 640123FA3B for <[e-mail]>; Sun, 10 Jun 2001 12:04:27 +0530 (IST)
Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id M418DSQ2; Sun, 10 Jun 2001 12:02:54 +0530
Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06102001-115212-3.MMD@vishnu; Sun, 10 Jun 2001 11:52:12 +0530
Delivered-To: [e-mail]
Received: (qmail 10903 invoked by uid 104); 9 Jun 2001 20:18:56 -0000
Delivered-To: [e-mail]
Received: (qmail 10899 invoked by alias); 9 Jun 2001 20:18:56 -0000
Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 9 Jun 2001 20:18:56 -0000
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03688 for [e-mail]; Sat, 9 Jun 2001 15:25:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id PAA03674 for <[e-mail]>; Sat, 9 Jun 2001 15:20:25 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17245; Sat, 9 Jun 2001 15:20:23 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Use of ECC Algorithms in CMS to Proposed Standard
Reply-To: [e-mail]
Date: Sat, 09 Jun 2001 15:20:23 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Use of ECC Algorithms in CMS
<draft-ietf-smime-ecc-06.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by June 23, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-06.txt





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f59KWuk04933 for ietf-smime-bks; Sat, 9 Jun 2001 13:32:56 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f59KWtJ04929 for <[e-mail]>; Sat, 9 Jun 2001 13:32:55 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17745; Sat, 9 Jun 2001 15:43:56 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Reuse of CMS Content Encryption Keys to Proposed Standard
Reply-to: [e-mail]
Date: Sat, 09 Jun 2001 15:43:55 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Reuse of CMS Content Encryption Keys
<draft-ietf-smime-rcek-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by June 23, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-rcek-04.txt




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f59K6Fi03353 for ietf-smime-bks; Sat, 9 Jun 2001 13:06:15 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f59K6CJ03348 for <[e-mail]>; Sat, 9 Jun 2001 13:06:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17245; Sat, 9 Jun 2001 15:20:23 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Use of ECC Algorithms in CMS to Proposed Standard
Reply-to: [e-mail]
Date: Sat, 09 Jun 2001 15:20:23 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security Working
Group to consider Use of ECC Algorithms in CMS
<draft-ietf-smime-ecc-06.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by June 23, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-06.txt




Received: by above.proper.com (8.9.3/8.9.3) id LAA19443 for ietf-smime-bks; Fri, 8 Jun 2001 11:35:47 -0700 (PDT)
Received: from mail1.itu.int (mail1.itu.ch [156.106.192.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19436 for <[e-mail]>; Fri, 8 Jun 2001 11:35:40 -0700 (PDT)
Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id <MRG8S6YQ>; Fri, 8 Jun 2001 20:35:01 +0200
Message-ID: <[e-mail]>
From: "Shaw, Robert" <[e-mail]>
To: Erdal YILDIZ <[e-mail]>
Cc: Ietf-Smime <[e-mail]>
Subject: RE: X.400 Docs
Date: Fri, 8 Jun 2001 20:33:45 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-9"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

http://www.itu.int/publications/bookshop/how-to-buy.html#free

describes how to download free a limited set of ITU-T
Recommendations per year.

See http://www.itu.int/itudoc/itu-t/rec/x/index.html for the X series.

Bob

> -----Original Message-----
> From: Erdal YILDIZ [mailto:[e-mail]]
> Sent: 06 June 2001 16:47
> To: Ietf-Smime
> Subject: X.400 Docs
> 
> 
> Hi All;
> 
> I need the "[X.400] ITU-T X.400 Series of Recommendations, Information
> technology - Message Handling Systems (MHS). X.400: System and Service
> Overview; X.402: Overall Architecture; X.411: Message Transfer System:
> Abstract Service Definition and Procedures; X.420: 
> Interpersonal Messaging
> System; 1996." documentations for my thesis work. I know that 
> final versions
> of those documents are not freely available, but if someone 
> final drafts or
> some detailled tutorial of them and send me, I will be really very
> appreciated.
> 
> Thanks in advance
> 
> Erdal YILDIZ
> 
> 


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA08971 for ietf-smime-bks; Thu, 7 Jun 2001 07:05:45 -0700 (PDT)
Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA08957 for <[e-mail]>; Thu, 7 Jun 2001 07:05:36 -0700 (PDT)
From: [e-mail]
Received: from vishnu.vishnu (unknown [203.197.193.57]) by del2.vsnl.net.in (Postfix) with ESMTP id A97F23EFA2 for <[e-mail]>; Thu,  7 Jun 2001 19:35:53 +0530 (IST)
Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MLZP8K21; Thu, 7 Jun 2001 19:34:23 +0530
Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06072001-193136-245.MMD@vishnu; Thu, 7 Jun 2001 19:31:36 +0530
Delivered-To: [e-mail]
Received: (qmail 19267 invoked by uid 104); 7 Jun 2001 13:12:21 -0000
Delivered-To: [e-mail]
Received: (qmail 19246 invoked by alias); 7 Jun 2001 13:12:21 -0000
Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 7 Jun 2001 13:12:21 -0000
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA29139 for [e-mail]; Thu, 7 Jun 2001 08:15:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA28773 for <[e-mail]>; Thu, 7 Jun 2001 07:07:56 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03420; Thu, 7 Jun 2001 07:07:53 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-01.txt
Date: Thu, 07 Jun 2001 07:07:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-01.txt
	Pages		: 53
	Date		: 06-Jun-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2630bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2630bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2630bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2630bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Received: by above.proper.com (8.9.3/8.9.3) id EAA18139 for ietf-smime-bks; Thu, 7 Jun 2001 04:08:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA18123 for <[e-mail]>; Thu, 7 Jun 2001 04:08:20 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03420; Thu, 7 Jun 2001 07:07:53 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-01.txt
Date: Thu, 07 Jun 2001 07:07:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-01.txt
	Pages		: 53
	Date		: 06-Jun-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2630bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2630bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2630bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2630bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA12458 for ietf-smime-bks; Thu, 7 Jun 2001 00:28:49 -0700 (PDT)
Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA12413 for <[e-mail]>; Thu, 7 Jun 2001 00:28:38 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010607072813.BFHE29059.femail4.sdc1.sfba.home.com@revelation>; Thu, 7 Jun 2001 00:28:13 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Russ Housley \(E-mail\)" <[e-mail]>
Cc: "Ietf-Smime \(E-mail\)" <[e-mail]>
Subject: Comments: draft-ietf-smime-cmsalg-00
Date: Thu, 7 Jun 2001 00:28:11 -0700
Message-ID: <005001c0ef23$69003910$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is the next set of comments:

1)  Table 1:  I hate to do it this way, but I don't think RSA is the correct
entry for Key Transport.  Given that we know that RSA-OAEP is coming down
the road, I think that this should be renamed as RSA v1.5 or something
similar. I see a similar problem for signature algorithms and the note.  See
comments 3 and 4 below.

2) Section 2.1:  I believe that the MUST and SHOULD statements in this
paragraph are in conflict.  ie. MUST encode as and SHOULD generate with.
These should be resolved as MUST in both locations.

3) Section 3:  RSA is not a signature algorithm.  RSA-SHA1 and RSA-MD5 are
signature algorithms.  RSA is a public key algorithm.

4) Section 3/Table 1:  From the requirements on digest algorithms I assume
that RSAwithSHA1 is a MUST and RSAwithMD5 is a SHOULD.

5) Section 3.1:  Change to "The algorithms parameter field MUST be encoded
as absent."

6) Section 3.2:  Boy we really messed this one up.  Section 3.2 should occur
as two different sections one for RSAwithMD5 and one for RSAwithSHA1.  I
will never understand how all of us missed this one.

The OIDs for this should be:
       sha1withRSAEncryption (1 2 840 113549 1 1 5)
or
#define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"

       md5withRSAEncryption (1 2 840 113549 1 1 4)

This is interesting.  the OIWSEC version is the one that I think I have
alwayed used (it's what I had for my own coding the the examples) but John
appears to be using the other one.  I note that there also appear to be
atleast two OIDS defined for MD5 but I am sure everyone is using the one
above.

7) Section 4.1, para 2:  There is a different in language here.
-   if ContentEncryptionAlg MUST KEK Alg.
-   SHOULD 3DES KEK
-   SHOULD RC2 KEK
-   MUST 3DES KEK on 3DES Content
-   MUST RC2 KEK on RC2 content.

Let me make a new stab at this:

Keep para 1 from section 4.1.

The following is the rest of section 4.1:

A key agreement algorithm consists of the following items:
1.  A shared secrect computation that takes the originator and receipient
keys and computes a shared secret.
2.  A symmetric key derivation algorithm that uses the shared secret to
compute a symmetric key.
3.  A key-wrap algorithm which uses the symmetric key generated by 2 to
encryption the CEK producing the value encded in the CMS kari structure.

   Key agreement algorithm identifiers are located in the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   keyEncryptionAlgorithm fields.

4.1.1  X9.42 Ephemeral-Static Diffie-Hellman

The shared-secret computation and symmetric key derivation algorithms for
Ephemeral-Static Diffie-Hellman key agreement are defined in RFC 2631
   [DH-X9.42].  E-S D-H uses the KEK algorithms defined in section 4.3 for
the key wrap algorithm.  ES DH MUST support the 3DES KEK for key wrapping.
ES DH SHOULD support RC2 KEK for key wrapping.  When using Ephemeral-Static
Diffie-Hellman, the
   EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
   used as follows:

...

      keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
<< Changed
      identifier.  The algorithm identifier parameter field for id-alg-
      ESDH is KeyWrapAlgorithm, and this parameter MUST be present.  The
<< Changed
      KeyWrapAlgorithm denotes the key wrap algorithm used
<< Changed
      to encrypt the content-encryption key with the pairwise key-
      encryption key generated using the X9.42 Ephemeral-Static Diffie-
      Hellman key agreement algorithm.  The document uses the KEK algorithms
defined in section 4.3 as the key wrap algorithms.  The KEK algorithm used
is defined in the KeyWrapAlgorithm parameter.  The id-alg-ESDH algorithm
      identifier and parameter syntax is:

         id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
             rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

         KeyWrapAlgorithm ::= AlgorithmIdentifier

New requirement: When deriving a Triple-DES key, a three key Triple-DES key
MUST be derived.  When deriving a Triple-DES key wrap key, the parity on
each of the three sub-keys MUST be correctly generated after the key
derivation process is complete.

8) Section 4.1, para 3:  The MAY in the sentence "For example" should be may
or "can be used"

9) Section 4.3:  The MAY in the sentence "For example,..." should be may or
"can be used".

10) Section 5: Type "MS implementations..." should be "CMS
implementations..."

11) Section 6.1: Should use MUST not must for the parameter encoding
statement.

12) Section 7:  I do not believe this section  needs any MUSTS for inclusion
of algorithms.  That is covered in section 4.

13) Security Considerations:  Change "The CMS" to either "CMS" or "The
Cryptographic Message Syntax (CMS)"

14) Security Considerations:  I recomend "This document identifies a set of
cryptographic algorithms for use with CMS."  - remove the word "the" as it
is not the entire set.

15) remove the paragraph on counter-signatures.

jim



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA03652 for ietf-smime-bks; Wed, 6 Jun 2001 15:28:33 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03631 for <[e-mail]>; Wed, 6 Jun 2001 15:28:26 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010606222822.VIYL14901.femail12.sdc1.sfba.home.com@revelation>; Wed, 6 Jun 2001 15:28:22 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
Date: Wed, 6 Jun 2001 15:28:19 -0700
Message-ID: <003e01c0eed7$fe076250$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, June 06, 2001 1:36 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Comments: draft-ietf-smime-rfc2630bis-00
>
>
> Jim:
>
> Thanks for spending so much time with the document.  You have
> performed a
> real service here.  I think that the bulk of your comments
> are handled
> here.  There are a few that need further dialogue.
>
> >1.  "The CMS ..." should be uniformly changed to "CMS ...".
>
> I think that "The Cryptographic Message Syntax (CMS) ..." is
> correct.  Are
> there places that I omitted "the"?

Actually I have no problems with "The Crryptographic Message Syntax (CMS)".
However as I look at the abstract for draft -00, the second paragraph starts
"The CMS is derived from PKCS#7 ..."  In doing searches of the draft the
phrase "the CMS" is quite common.  I count 5 that should be altered.

>
> >2.  I have a sever problem with the following text "However,
> implementations
> >of the CMS MUST support the mandatory to implement
> algorithms specified in
> >[CMSALG], or its successor."  It is my believe that this
> statement should be
> >removed for the following reasons:
> >
> >a)  This violates the letter and spirit of the IETF process rules for
> >pushing documents to standards.  In my opinion if this
> becomes a standard
> >then CMSALG must also be a standard.  Also if CMSALG is
> reset to draft, so
> >must this draft.  The words "MUST support" is extremely normative.
> >
> >b)  If I create a toolkit or other system and publish that I
> am STD [CMS]
> >conformant.  It does not make sense that by updating the set
> of required
> >algorithms I loose conformance to that standard.  I was
> compliant, I loose
> >compliance through no action of mine.  This argues that a
> new standard
> >number should be applied.
> >
> >c)  The reasoning behind not having a MUST for certificates
> is even more
> >strongly appliciable here.  While certificates and
> heirarchies can move
> >between different applications (thus making the arugment
> that application
> >spaces should mandate algorithms a somewhat odd argument),
> that is not the
> >case with CMS objects.  If S/MIME and CMS/SET were to specificy that
> >different content encryption algorithms be required, there is no
> >interactions between the spaces.  An S/MIME message would
> never be consumed
> >(successfully) by a CMS/SET application nor would one expect
> it to be used.
> >
> > From this standpoint I think that not requiring a MUST on
> algorithms from
> >CMS makes sense.
>
> I have asked Jeff and Marcus for guidance.  So far, I have
> not received input.

We will see what happens.

> >5) Section 2, para 3: Revert to original language on DER
> encoding of signed
> >and authenticated attributes. The correct location for the
> MUST statement is
> >in the description of the attribute fields in the
> appropriate structures.
>
> I thought that the rewording removed the "must."  We agree
> that the MUST
> statement belongs in the discussion of signed attributes and
> authenticated
> attributes.  How about this:
>
>     As a general design philosophy, each content type permits
> single pass
>     processing using indefinite-length Basic Encoding Rules (BER)
>     encoding.  Single-pass operation is especially helpful if
> content is
>     large, stored on tapes, or is "piped" from another
> process.  Single-
>     pass operation has one significant drawback: it is difficult to
>     perform encode operations using the Distinguished Encoding Rules
>     (DER) [X.509-88] encoding in a single pass since the
> lengths of the
>     various components may not be known in advance.  However, signed
>     attributes within the signed-data content type and authenticated
>     attributes within the authenticated-data content type need to be
>     transmitted in DER form to ensure that recipients can verify a
>     content that contains one or more unrecognized attributes.  Signed
>     attributes and authenticated attributes are the only CMS
> data types
>     that require DER encoding.

This is fine.

>
> >6) Section 5, para 8:  The MAY should be lower case.  This section is
> >descriptive in nature is not creating requirements on the
> implementor.
>
> Agree.  How about:
>
>     The signer's certificate can be included in the SignedData
>     certificates field.
>

This is fine.

> >7) Section 5.1, digestAlgorithms:  One of the following
> statements should be
> >added to this paragraph:
> >a) Each digest algorithm used in a signture computation MUST
> be included in
> >this set, although unused algorithms may also be included.  OR
> >b) Complient implementations MUST verify signatures for
> which the digest
> >algorithm is not in this set. OR
> >c) Complient implementations MAY fail signature verification
> if the digest
> >algorithm is not included in this set.
>
> How about:
>
>     Implementations MAY fail to validate signatures that use a
>     digest algorithm that is not included in this set.
>

I am more that happy with this this.  It was my perfered answer.

> >8) Section 5.1, certificates:  The following items are
> missing from this
> >paragraph.  1) If version 2 attribute certificates are
> present the version
> >MUST be 4.  2) The MAY from section 5, para 8 if it is considered of
> >importance.  I think it can be omitted.
>
> How about:
>
>     certificates is a collection of certificates.  It is intended that
>     the set of certificates be sufficient to contain chains from a
>     recognized "root" or "top-level certification authority" to all of
>     the signers in the signerInfos field.  There may be more
>     certificates than necessary, and there may be certificates
>     sufficient to contain chains from two or more independent top-
>     level certification authorities.  There may also be fewer
>     certificates than necessary, if it is expected that recipients
>     have an alternate means of obtaining necessary certificates (e.g.,
>     from a previous set of certificates).  The signer's certificate
>     MAY be included.  As discussed above, if version 2 attribute
>     certificates are present, then the value of version MUST be 4.
>     While the use of version 1 attribute certificates is discouraged,
>     if version 1 attribute certificates are present and no version 2
>     attribute certificates are present, then the value of version MUST
>     be 3.

Looks fine.

>
> >11) Section 5.3, para "digestAlgorithm"  See comment 7
> above.  Does the
> >should in the last sentence need to be SHOULD/MUST?
>
> How about:
>
>     digestAlgorithm identifies the message digest algorithm, and any
>     associated parameters, used by the signer.  The message digest is
>     computed on either the content being signed or the content
>     together with the signed attributes using the process described in
>     section 5.4.  The message digest algorithm SHOULD be among those
>     listed in the digestAlgorithms field of the associated SignerData.
>     Implementations MAY fail to validate signatures that use a digest
>     algorithm that is not included in the SignedData digestAlgorithms
>     set.

fine.

>
> >14) Section 5.3, para "signature":  I don't understand the
> MUST in this
> >paragraph.  The field is not optional how can it be omitted?
>  The MUST is
> >redundant.
>
> I agree that the ASN.1 definition and this must statement are
> redundant.  They are not contradictory.  What do you not
> understand?  What
> change are you requesting?

I am requesting the removal of the MUST as there is no option. (Just to be
irritating, the field could be present but of zero length under the current
text.)

> >16) Section 5.3, para "attrValues":  Append the following sentence.
> >"attrType may impose additional restrictions on the number
> of items in the
> >set."
>
> How about:
>
>     attrValues is a set of values that comprise the attribute.  The
>     type of each value in the set can be determined uniquely by
>     attrType.  The attrType MAY impose restrictions on the number of
>     items in the set.

I think this should be may not MAY as there is no protocol statement at this
point.  If you want one then it should be "Signatures MUST fail verification
if any restrictions on the number of items in the set, imposed by an
attrType definition, are not met."

>
> >18) Section 6.1, para "version":  What is the correct value
> if v2 attribute
> >cert and unprotected attributes are present?  Maybe should
> change this to an
> >if - then - else type of writing.
>
> It is pretty confusing.  How about:
>
>        [*** 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)
>              THEN version is 2
>              ELSE version is 0

This is fine.

>
> >20) Section 6.1, para "certs": ditto above for some.  What
> is the "optional"
> >feature being discussed on the MAY.
>
> How about:
>
>     certs is a collection of certificates.  certs may contain
>     originator certificates associated with several different key
>     management algorithms.  certs may also contain attribute
>     certificates associated with the originator.  The certificates
>     contained in certs are intended to be sufficient for all
>     recipients to build certification paths from a recognized
>     "root" or "top-level certification authority."  However, certs
>     may contain more certificates than necessary, and there may be
>     certificates sufficient to make certification paths from two or
>     more independent top-level certification authorities.
>     Alternatively, certs may contain fewer certificates than
>     necessary, if it is expected that recipients have an alternate
>     means of obtaining necessary certificates (e.g., from a
>     previous set of certificates).

Looks good.

>
> >21) Section 6.1, para "recipientInfos":  Should change the ASN to
> >"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to
> reflect the MUST
> >in the text?
>
> We use "SET OF" many places.  I do not think we want to add
> "SIZE (1..MAX)"
> to them all.  Therefore, I am not sure that there is any real
> value in
> adding it to this one.

This is the only one that I see where we have a requirement that the set
must not be empty and the element itself is not optional.  In most all of
the other locations either the element itself can be omitted or the SET can
consist of 0 items.

>
> >23) Section 6.1, para "contentEncryptionAlgorithm":  Please
> explain the
> >MUST.  How could you NOT use the same algorithm for each recipient?
>
> Agree.  How about:
>
>     The same content-encryption algorithm and content-encryption
>     key are used for all recipients.

fine.

>
> >25) Section 6.2.1, para "rid": Two items
> >a)  do we want to change to text to allow for SKI's to be
> non-certificate
> >based.
>
> I see no reason to do this.  Is there a constituency that needs it?

I was thinking of the PGP people, but don't have anything stronger.  I don't
think we need to do this.

>
> >b)  do we need a stronger definition of what a key transport
> public key is
> >if there is a MUST for it being in the certificate.
[ 
> Think about this
> >comment ]]]]]
> 
> I did think about your comment, and I do not think so.  [[ I am 
> anticipating an embarrassing reply. ]] This field is within the key 
> transport recipient information, therefore any recipien
t
> public key that is
> used with this syntax (and is interoperable) must be a key
> transport key.

The comment was for me, and I missed it in the review of the message.  I
think I must have been wandering when I wrote this and I don't remember why.
Omit.

>
> >c)  do we need to support both for specifying the
> certificate or just for
> >locating a certificate? (i.e. encode vs decode)
>
> We need both (for send and receive).  I prefer the subject
> key identifier;
> it is smaller.  However, S/MIME v2 requires issuer and serial
> number, which
> is bigger than a subject key identifier.  If you do not think
> that the MUST
> statement is complete, please propose an alternative.

Alternative:  "Implementations MUST support both alternatives for specifying
the recipient's certificate when decoding.  Implementations MUST support one
of these alternatives for encoding."

>
> >27) Section 6.2.2, para "ukm":  I believe this is a MUST not a SHOULD
> >statement.  I understand that we don't require it for the
> default algorithm
> >(ESDH), but it is premitted to occur.  If UKM is not
> supported then all that
> >could be done would be to ignore the recipient.  (Note:
> there is a MUST use
> >UKM in rfc2631 for one case.)
>
> UKM is required for Static-Static Diffie-Hellman.  I
> basically agree with
> your point, and it is not a big burden on an implementation.
> However, I
> would like to hear from more implementors before I make a change here.

John - please respond.

>
> >28) Section 6.3.  Lets seperate the discussion on how to pad from the
> >content encryption process.  I believe this should be moved
> to the algorithm
> >section or a seperate section in this document.  The CEK
> algorithm is what
> >determines the padding method not CMS.
>
> Not true.  CMS encryption always uses this padding.  CMS also
> supports
> algorithms that do not require any padding (for example, a
> stream cipher),
> but if padding is needed, this is the padding technique that
> MUST be used.

I beg to differ with you on this issue.  I believe that I could define a new
OID for RC5 with Ron's funky padding mode where the cipher text and plain
text are the same lengths.  More importantly, with some of the new chaining
modes for AES where there is interleaving between mutiple chains, I can see
the padding to be done over a multiple of n blocks of data rather than one.
I repeat, the padding alogorithm is a fucntion of the specified encryption
algorithm and is not fixed.

>
> >29) Section 6.3, para 2:  I don't like the section sentence in this
> >paragraph.  The content begin encrypted has little or
> nothing to do with the
> >value of the encrypted data octet string.  This is the post
> encryption
> >value.
>
> I understand your point.  These words have not changed in a very long
> time.  Perhaps you would like to propose some better ones.

Proposal:  "The input to the content-encryption process is the "value" of
the content being enveloped.  The resulting value of the encryption process
is then wrapped in an OCTET string for transporting."

>
> >33) Section 10.2.2: Why define another tag for v2 attribute
> certificates.
> >We have never bothered with this for v1/v2/v3 certificates.
>
> Long story.  The short version is that v2 ACs are not
> backward compatible
> with v1 ACs.  If you really want to hear the nasty, dirty details, I
> suggest you talk to Hoyt or Sharron.  This little jewel is
> the reason that
> the PKIX AC Profile requires the use of v2 ACs.
>

I can buy that. (Also it does justify uping the version number for me.)

>
> >36) Section 11.1: Content-type MUST be omitted when building counter
> >signatures.
>
> Elsewhere the document says: "The content-type attribute is
> not required
> when used as part of a countersignature unsigned attribute as
> defined in
> section 11.4."  This does not say MUST NOT to me.  It says MAY.  Eh?

I agree that that is what it presently says.  In practice I don't believe
that any has ever encoding in a content-type and I would like to codify that
practice.

>
> >37) Section 11.1: There MUST be exactly one instance of
> AttributeValue
> >present.  -- MUST NOT is not testable.
>
> It says: "A content-type attribute MUST have a single
> attribute value, even
> though the syntax is defined as a SET OF AttributeValue.
> There MUST NOT be
> zero or multiple instances of AttributeValue present."
>
> So, you agree with the first sentence.  I think the second
> sentence is a
> restatement of the first.  Does the second sentence help
> anyone understand?

I don't believe that the second statement helps.  I did miss the fact that
it is a restatement of the first.

>
> >43) Section 11.5: Item 1 in the values.  Change to "... but
> MUST NOT contain
> >a content-type attribute. (No content type has been defined for a
> >counter-signature.)"
>
> I assume that this is a comment about section 11.4, there is
> no section 11.5.
>
> See response to comment 36.  It seem to me that you are
> interpreting "need
> not" as "MUST NOT."  What have other implementors done?

see comment above on 36.

>
> Russ
>

jim



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA29476 for ietf-smime-bks; Wed, 6 Jun 2001 14:21:45 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29465 for <[e-mail]>; Wed, 6 Jun 2001 14:21:39 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010606212137.EWCE1531.femail3.sdc1.sfba.home.com@revelation> for <[e-mail]>; Wed, 6 Jun 2001 14:21:37 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime \(E-mail\)" <[e-mail]>
Subject: Comments: draft-ietf-smime-rfc2630bis-00
Date: Wed, 6 Jun 2001 14:21:36 -0700
Message-ID: <003801c0eece$aaec7230$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Sorry about taking so long.  Here is my first set of comments:

1.  "The CMS ..." should be uniformly changed to "CMS ...".

2.  I have a sever problem with the following text "However, implementations
of the CMS MUST support the mandatory to implement algorithms specified in
[CMSALG], or its successor."  It is my believe that this statement should be
removed for the following reasons:

a)  This violates the letter and spirit of the IETF process rules for
pushing documents to standards.  In my opinion if this becomes a standard
then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
must this draft.  The words "MUST support" is extremely normative.

b)  If I create a toolkit or other system and publish that I am STD [CMS]
conformant.  It does not make sense that by updating the set of required
algorithms I loose conformance to that standard.  I was compliant, I loose
compliance through no action of mine.  This argues that a new standard
number should be applied.

c)  The reasoning behind not having a MUST for certificates is even more
strongly appliciable here.  While certificates and heirarchies can move
between different applications (thus making the arugment that application
spaces should mandate algorithms a somewhat odd argument), that is not the
case with CMS objects.  If S/MIME and CMS/SET were to specificy that
different content encryption algorithms be required, there is no
interactions between the spaces.  An S/MIME message would never be consumed
(successfully) by a CMS/SET application nor would one expect it to be used.

>From this standpoint I think that not requiring a MUST on algorithms from
CMS makes sense.

3) Section 2, para 2:  Remove "if desired" from the last sentence.  That is
what MAY means.

4) Section 2, para 3: "within the authenticated-data content types require"
types should be singular.

5) Section 2, para 3: Revert to original language on DER encoding of signed
and authenticated attributes. The correct location for the MUST statement is
in the description of the attribute fields in the appropriate structures.

6) Section 5, para 8:  The MAY should be lower case.  This section is
descriptive in nature is not creating requirements on the implementor.

7) Section 5.1, digestAlgorithms:  One of the following statements should be
added to this paragraph:
a) Each digest algorithm used in a signture computation MUST be included in
this set, although unused algorithms may also be included.  OR
b) Complient implementations MUST verify signatures for which the digest
algorithm is not in this set. OR
c) Complient implementations MAY fail signature verification if the digest
algorithm is not included in this set.

8) Section 5.1, certificates:  The following items are missing from this
paragraph.  1) If version 2 attribute certificates are present the version
MUST be 4.  2) The MAY from section 5, para 8 if it is considered of
importance.  I think it can be omitted.

9) Section 5.2, para 7:  Change "the content type within ... should be
id-data" to "MUST be id-data"  and "content field ... MUST be omitted".

10) Section 5.3, para "sid":  What is the third alternative for specifying
the signer's public key?

11) Section 5.3, para "digestAlgorithm"  See comment 7 above.  Does the
should in the last sentence need to be SHOULD/MUST?

12) Section 5.3, para "signedAttributes":  Should be "signedAttrs".

13) Section 5.3, para "signedAttributes":  "Each SignedAttribute in the SET
MUST be DER encoded."

14) Section 5.3, para "signature":  I don't understand the MUST in this
paragraph.  The field is not optional how can it be omitted?  The MUST is
redundant.

15) Section 5.3, para "unsignedAttributes": should be "unsignedAttrs".

16) Section 5.3, para "attrValues":  Append the following sentence.
"attrType may impose additional restrictions on the number of items in the
set."

17) Section 5.6, para 1: Change "MAY" to "may".

18) Section 6.1, para "version":  What is the correct value if v2 attribute
cert and unprotected attributes are present?  Maybe should change this to an
if - then - else type of writing.

19) Section 6.1, para "originatorInfo":  Change MAY to may in last sentence.
No requirement is stated here.

20) Section 6.1, para "certs": ditto above for some.  What is the "optional"
feature being discussed on the MAY.

21) Section 6.1, para "recipientInfos":  Should change the ASN to
"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to reflect the MUST
in the text?

22) Section 6.1, para "encryptedContentInfo":  Remove the [*** NEW ***]
text.  The field is not optional.

23) Section 6.1, para "contentEncryptionAlgorithm":  Please explain the
MUST.  How could you NOT use the same algorithm for each recipient?

24) Section 6.1, para "encryptedContent":  Please explain how the MUST in
this paragraph would be tested.  I think this is a "must" not "MUST"

25) Section 6.2.1, para "rid": Two items
a)  do we want to change to text to allow for SKI's to be non-certificate
based.
b)  do we need a stronger definition of what a key transport public key is
if there is a MUST for it being in the certificate.  [[[[ Think about this
comment ]]]]]
c)  do we need to support both for specifying the certificate or just for
locating a certificate? (i.e. encode vs decode)

26) Section 6.2.2, para 1:  "...one or more recipients that use..."

27) Section 6.2.2, para "ukm":  I believe this is a MUST not a SHOULD
statement.  I understand that we don't require it for the default algorithm
(ESDH), but it is premitted to occur.  If UKM is not supported then all that
could be done would be to ignore the recipient.  (Note: there is a MUST use
UKM in rfc2631 for one case.)

28) Section 6.3.  Lets seperate the discussion on how to pad from the
content encryption process.  I believe this should be moved to the algorithm
section or a seperate section in this document.  The CEK algorithm is what
determines the padding method not CMS.

29) Section 6.3, para 2:  I don't like the section sentence in this
paragraph.  The content begin encrypted has little or nothing to do with the
value of the encrypted data octet string.  This is the post encryption
value.

30) Section 9.1:  Do we want to change the name of
unauthencticatedAttributes to unauthencticatedAttrs to be consistant with
the naming in signed and encrypted data?  (ditto with
autenticatedAttributes.)

31) Section 10.1.5: Should we change HMAC to HMAC-SHA1 as HMAC by itself is
not a MAC algorithm?

32) Section 10.2.1: Change MAY to may - not protocol requirement here.

33) Section 10.2.2: Why define another tag for v2 attribute certificates.
We have never bothered with this for v1/v2/v3 certificates.

34) Section 10.2.3: make MAY may, no protocol requirement imposed by CMS.

35) Section 11: Update RFC 2459 text reference to "Son of 2459".

36) Section 11.1: Content-type MUST be omitted when building counter
signatures.

37) Section 11.1: There MUST be exactly one instance of AttributeValue
present.  -- MUST NOT is not testable.

38) Section 11.2: See comment 37.

39) Section 11.3: I think we should loosen up the locations allows for
signing-time.  I would like to see it allowed as an autenticated attribute.

40) Section 11.3: See comment 37.

41) Section 11.4: should be "MUST NOT" not "MUST not" in the description of
generalizedTime.

42) Section 11.4: See comment 37.

43) Section 11.5: Item 1 in the values.  Change to "... but MUST NOT contain
a content-type attribute. (No content type has been defined for a
counter-signature.)"

44) Section 11.5, UnsignedAttribute syntax: I disagree with the MAY here.  I
believe this should be lower case.  If there is a procotol statement it
needs to be that implementations MUST be able to handle more than one
counter signature attribute.



OTHER:
1) should countersign say MUST omit content type?



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25414 for ietf-smime-bks; Wed, 6 Jun 2001 13:37:10 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA25400 for <[e-mail]>; Wed, 6 Jun 2001 13:36:58 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Jun 2001 20:36:10 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA29205 for <[e-mail]>; Wed, 6 Jun 2001 16:36:56 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8T1JXG>; Wed, 6 Jun 2001 16:36:55 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8T1JXD; Wed, 6 Jun 2001 16:36:44 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 06 Jun 2001 16:36:07 -0400
Subject: Re: Comments: draft-ietf-smime-rfc2630bis-00
In-Reply-To: <001d01c0ee3e$ee39ead0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

Thanks for spending so much time with the document.  You have performed a 
real service here.  I think that the bulk of your comments are handled 
here.  There are a few that need further dialogue.

>1.  "The CMS ..." should be uniformly changed to "CMS ...".

I think that "The Cryptographic Message Syntax (CMS) ..." is correct.  Are 
there places that I omitted "the"?

>2.  I have a sever problem with the following text "However, implementations
>of the CMS MUST support the mandatory to implement algorithms specified in
>[CMSALG], or its successor."  It is my believe that this statement should be
>removed for the following reasons:
>
>a)  This violates the letter and spirit of the IETF process rules for
>pushing documents to standards.  In my opinion if this becomes a standard
>then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
>must this draft.  The words "MUST support" is extremely normative.
>
>b)  If I create a toolkit or other system and publish that I am STD [CMS]
>conformant.  It does not make sense that by updating the set of required
>algorithms I loose conformance to that standard.  I was compliant, I loose
>compliance through no action of mine.  This argues that a new standard
>number should be applied.
>
>c)  The reasoning behind not having a MUST for certificates is even more
>strongly appliciable here.  While certificates and heirarchies can move
>between different applications (thus making the arugment that application
>spaces should mandate algorithms a somewhat odd argument), that is not the
>case with CMS objects.  If S/MIME and CMS/SET were to specificy that
>different content encryption algorithms be required, there is no
>interactions between the spaces.  An S/MIME message would never be consumed
>(successfully) by a CMS/SET application nor would one expect it to be used.
>
> From this standpoint I think that not requiring a MUST on algorithms from
>CMS makes sense.

I have asked Jeff and Marcus for guidance.  So far, I have not received input.

>3) Section 2, para 2:  Remove "if desired" from the last sentence.  That is
>what MAY means.

Done.

>4) Section 2, para 3: "within the authenticated-data content types require"
>types should be singular.

Done.

>5) Section 2, para 3: Revert to original language on DER encoding of signed
>and authenticated attributes. The correct location for the MUST statement is
>in the description of the attribute fields in the appropriate structures.

I thought that the rewording removed the "must."  We agree that the MUST 
statement belongs in the discussion of signed attributes and authenticated 
attributes.  How about this:

    As a general design philosophy, each content type permits single pass
    processing using indefinite-length Basic Encoding Rules (BER)
    encoding.  Single-pass operation is especially helpful if content is
    large, stored on tapes, or is "piped" from another process.  Single-
    pass operation has one significant drawback: it is difficult to
    perform encode operations using the Distinguished Encoding Rules
    (DER) [X.509-88] encoding in a single pass since the lengths of the
    various components may not be known in advance.  However, signed
    attributes within the signed-data content type and authenticated
    attributes within the authenticated-data content type need to be
    transmitted in DER form to ensure that recipients can verify a
    content that contains one or more unrecognized attributes.  Signed
    attributes and authenticated attributes are the only CMS data types
    that require DER encoding.

>6) Section 5, para 8:  The MAY should be lower case.  This section is
>descriptive in nature is not creating requirements on the implementor.

Agree.  How about:

    The signer's certificate can be included in the SignedData
    certificates field.

>7) Section 5.1, digestAlgorithms:  One of the following statements should be
>added to this paragraph:
>a) Each digest algorithm used in a signture computation MUST be included in
>this set, although unused algorithms may also be included.  OR
>b) Complient implementations MUST verify signatures for which the digest
>algorithm is not in this set. OR
>c) Complient implementations MAY fail signature verification if the digest
>algorithm is not included in this set.

How about:

    Implementations MAY fail to validate signatures that use a
    digest algorithm that is not included in this set.

>8) Section 5.1, certificates:  The following items are missing from this
>paragraph.  1) If version 2 attribute certificates are present the version
>MUST be 4.  2) The MAY from section 5, para 8 if it is considered of
>importance.  I think it can be omitted.

How about:

    certificates is a collection of certificates.  It is intended that
    the set of certificates be sufficient to contain chains from a
    recognized "root" or "top-level certification authority" to all of
    the signers in the signerInfos field.  There may be more
    certificates than necessary, and there may be certificates
    sufficient to contain chains from two or more independent top-
    level certification authorities.  There may also be fewer
    certificates than necessary, if it is expected that recipients
    have an alternate means of obtaining necessary certificates (e.g.,
    from a previous set of certificates).  The signer's certificate
    MAY be included.  As discussed above, if version 2 attribute
    certificates are present, then the value of version MUST be 4.
    While the use of version 1 attribute certificates is discouraged,
    if version 1 attribute certificates are present and no version 2
    attribute certificates are present, then the value of version MUST
    be 3.

>9) Section 5.2, para 7:  Change "the content type within ... should be
>id-data" to "MUST be id-data"  and "content field ... MUST be omitted".

Agree.  Done.  I changed "should" to "MUST" in two places.

>10) Section 5.3, para "sid":  What is the third alternative for specifying
>the signer's public key?

Ooops.  I changed "three" to "two".

>11) Section 5.3, para "digestAlgorithm"  See comment 7 above.  Does the
>should in the last sentence need to be SHOULD/MUST?

How about:

    digestAlgorithm identifies the message digest algorithm, and any
    associated parameters, used by the signer.  The message digest is
    computed on either the content being signed or the content
    together with the signed attributes using the process described in
    section 5.4.  The message digest algorithm SHOULD be among those
    listed in the digestAlgorithms field of the associated SignerData.
    Implementations MAY fail to validate signatures that use a digest
    algorithm that is not included in the SignedData digestAlgorithms
    set.

>12) Section 5.3, para "signedAttributes":  Should be "signedAttrs".

Agree.  Done.

>13) Section 5.3, para "signedAttributes":  "Each SignedAttribute in the SET
>MUST be DER encoded."

Agree.  Done.

>14) Section 5.3, para "signature":  I don't understand the MUST in this
>paragraph.  The field is not optional how can it be omitted?  The MUST is
>redundant.

I agree that the ASN.1 definition and this must statement are 
redundant.  They are not contradictory.  What do you not understand?  What 
change are you requesting?

>15) Section 5.3, para "unsignedAttributes": should be "unsignedAttrs".

Agree.  Done.

>16) Section 5.3, para "attrValues":  Append the following sentence.
>"attrType may impose additional restrictions on the number of items in the
>set."

How about:

    attrValues is a set of values that comprise the attribute.  The
    type of each value in the set can be determined uniquely by
    attrType.  The attrType MAY impose restrictions on the number of
    items in the set.

>17) Section 5.6, para 1: Change "MAY" to "may".

Agree.  Done.

>18) Section 6.1, para "version":  What is the correct value if v2 attribute
>cert and unprotected attributes are present?  Maybe should change this to an
>if - then - else type of writing.

It is pretty confusing.  How about:

       [*** 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)
             THEN version is 2
             ELSE version is 0

>19) Section 6.1, para "originatorInfo":  Change MAY to may in last sentence.
>No requirement is stated here.

Agree.  Done.

>20) Section 6.1, para "certs": ditto above for some.  What is the "optional"
>feature being discussed on the MAY.

How about:

    certs is a collection of certificates.  certs may contain
    originator certificates associated with several different key
    management algorithms.  certs may also contain attribute
    certificates associated with the originator.  The certificates
    contained in certs are intended to be sufficient for all
    recipients to build certification paths from a recognized
    "root" or "top-level certification authority."  However, certs
    may contain more certificates than necessary, and there may be
    certificates sufficient to make certification paths from two or
    more independent top-level certification authorities.
    Alternatively, certs may contain fewer certificates than
    necessary, if it is expected that recipients have an alternate
    means of obtaining necessary certificates (e.g., from a
    previous set of certificates).

>21) Section 6.1, para "recipientInfos":  Should change the ASN to
>"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to reflect the MUST
>in the text?

We use "SET OF" many places.  I do not think we want to add "SIZE (1..MAX)" 
to them all.  Therefore, I am not sure that there is any real value in 
adding it to this one.

>22) Section 6.1, para "encryptedContentInfo":  Remove the [*** NEW ***]
>text.  The field is not optional.

Agree. Done.

>23) Section 6.1, para "contentEncryptionAlgorithm":  Please explain the
>MUST.  How could you NOT use the same algorithm for each recipient?

Agree.  How about:

    The same content-encryption algorithm and content-encryption
    key are used for all recipients.

>24) Section 6.1, para "encryptedContent":  Please explain how the MUST in
>this paragraph would be tested.  I think this is a "must" not "MUST"

Agree.  Done.

>25) Section 6.2.1, para "rid": Two items
>a)  do we want to change to text to allow for SKI's to be non-certificate
>based.

I see no reason to do this.  Is there a constituency that needs it?

>b)  do we need a stronger definition of what a key transport public key is
>if there is a MUST for it being in the certificate.  [[[[ Think about this
>comment ]]]]]

I did think about your comment, and I do not think so.  [[ I am 
anticipating an embarrassing reply. ]] This field is within the key 
transport recipient information, therefore any recipient public key that is 
used with this syntax (and is interoperable) must be a key transport key.

>c)  do we need to support both for specifying the certificate or just for
>locating a certificate? (i.e. encode vs decode)

We need both (for send and receive).  I prefer the subject key identifier; 
it is smaller.  However, S/MIME v2 requires issuer and serial number, which 
is bigger than a subject key identifier.  If you do not think that the MUST 
statement is complete, please propose an alternative.

>26) Section 6.2.2, para 1:  "...one or more recipients that use..."

Agree.  Done.

>27) Section 6.2.2, para "ukm":  I believe this is a MUST not a SHOULD
>statement.  I understand that we don't require it for the default algorithm
>(ESDH), but it is premitted to occur.  If UKM is not supported then all that
>could be done would be to ignore the recipient.  (Note: there is a MUST use
>UKM in rfc2631 for one case.)

UKM is required for Static-Static Diffie-Hellman.  I basically agree with 
your point, and it is not a big burden on an implementation.  However, I 
would like to hear from more implementors before I make a change here.

>28) Section 6.3.  Lets seperate the discussion on how to pad from the
>content encryption process.  I believe this should be moved to the algorithm
>section or a seperate section in this document.  The CEK algorithm is what
>determines the padding method not CMS.

Not true.  CMS encryption always uses this padding.  CMS also supports 
algorithms that do not require any padding (for example, a stream cipher), 
but if padding is needed, this is the padding technique that MUST be used.

>29) Section 6.3, para 2:  I don't like the section sentence in this
>paragraph.  The content begin encrypted has little or nothing to do with the
>value of the encrypted data octet string.  This is the post encryption
>value.

I understand your point.  These words have not changed in a very long 
time.  Perhaps you would like to propose some better ones.

>30) Section 9.1:  Do we want to change the name of
>unauthencticatedAttributes to unauthencticatedAttrs to be consistant with
>the naming in signed and encrypted data?  (ditto with
>autenticatedAttributes.)

Good idea.  Done.

>31) Section 10.1.5: Should we change HMAC to HMAC-SHA1 as HMAC by itself is
>not a MAC algorithm?

Okay.  Done.  I called it "HMAC-SHA-1."

>32) Section 10.2.1: Change MAY to may - not protocol requirement here.

Agree. Done.

>33) Section 10.2.2: Why define another tag for v2 attribute certificates.
>We have never bothered with this for v1/v2/v3 certificates.

Long story.  The short version is that v2 ACs are not backward compatible 
with v1 ACs.  If you really want to hear the nasty, dirty details, I 
suggest you talk to Hoyt or Sharron.  This little jewel is the reason that 
the PKIX AC Profile requires the use of v2 ACs.

>34) Section 10.2.3: make MAY may, no protocol requirement imposed by CMS.

Agree.  I changed "MAY" to "may" in three places.

>35) Section 11: Update RFC 2459 text reference to "Son of 2459".

Agree.  This is a place holder.  I think I will know when son-of-RFC2459 
finally makes it through the PKIX WG, IESG, and RFC Editor....

>36) Section 11.1: Content-type MUST be omitted when building counter
>signatures.

Elsewhere the document says: "The content-type attribute is not required 
when used as part of a countersignature unsigned attribute as defined in 
section 11.4."  This does not say MUST NOT to me.  It says MAY.  Eh?

>37) Section 11.1: There MUST be exactly one instance of AttributeValue
>present.  -- MUST NOT is not testable.

It says: "A content-type attribute MUST have a single attribute value, even 
though the syntax is defined as a SET OF AttributeValue.  There MUST NOT be 
zero or multiple instances of AttributeValue present."

So, you agree with the first sentence.  I think the second sentence is a 
restatement of the first.  Does the second sentence help anyone understand?

>38) Section 11.2: See comment 37.

See response to comment 37. (I could not resist...)

>39) Section 11.3: I think we should loosen up the locations allows for
>signing-time.  I would like to see it allowed as an autenticated attribute.

Okay.  Done.

>40) Section 11.3: See comment 37.

See response to comment 37.

>41) Section 11.4: should be "MUST NOT" not "MUST not" in the description of
>generalizedTime.

Agree.  Done.

>42) Section 11.4: See comment 37.

See response to comment 37.

>43) Section 11.5: Item 1 in the values.  Change to "... but MUST NOT contain
>a content-type attribute. (No content type has been defined for a
>counter-signature.)"

I assume that this is a comment about section 11.4, there is no section 11.5.

See response to comment 36.  It seem to me that you are interpreting "need 
not" as "MUST NOT."  What have other implementors done?

>44) Section 11.5, UnsignedAttribute syntax: I disagree with the MAY here.  I
>believe this should be lower case.  If there is a procotol statement it
>needs to be that implementations MUST be able to handle more than one
>counter signature attribute.

I assume that this is a comment about section 11.4, there is no section 11.5.

Agree.  Done.

>OTHER:
>1) should countersign say MUST omit content type?

See response to comments 36 and 43.

Russ



Received: by above.proper.com (8.9.3/8.9.3) id LAA19829 for ietf-smime-bks; Wed, 6 Jun 2001 11:33:16 -0700 (PDT)
Received: from tube.net-tel.co.uk ([195.153.60.158]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19820 for <[e-mail]>; Wed, 6 Jun 2001 11:33:10 -0700 (PDT)
From: [e-mail]
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.net-tel.co.uk (3.05.5.2) with ESMTP id TAA02256; Wed, 06 Jun 2001 19:34:36 +0100
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Wed,  6 Jun 2001 19:31:01 +0100
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Wed,  6 Jun 2001 19:31:01 +0100
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed,  6 Jun 2001 19:31:01 +0100
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0057-010606193101-0ee3]
X400-Content-Type: P2-1988 (22)
X400-Originator: [e-mail]
Original-Encoded-Information-Types:  IA5-Text, (2)(6)(1)(12)(0), (1)(2)(840)(113556)(3)(10)(1)
X400-Recipients: non-disclosure:;
Date: Wed,  6 Jun 2001 19:31:01 +0100
X400-Content-Identifier: RE: X.400 Docs
Message-Id: <"JERSEY:00b4-010606192648-0004*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
To: Erdal YILDIZ <[e-mail]>
Cc: Ietf-Smime <[e-mail]>
Disposition-Notification-To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: RE: X.400 Docs
MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 3.5.5.2)
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi All;
> 
> I need the "[X.400] ITU-T X.400 Series of Recommendations, Information
> technology - Message Handling Systems (MHS). X.400: System and Service
> Overview; X.402: Overall Architecture; X.411: Message Transfer System:
> Abstract Service Definition and Procedures; X.420: Interpersonal Messaging
> System; 1996." documentations for my thesis work. I know that final 
> versions of those documents are not freely available, but if someone final 
> drafts or some detailled tutorial of them and send me, I will be really very
> appreciated.
> 
> Thanks in advance
> 
> Erdal YILDIZ
> 
> 

The Editor's version of the equivalent ISO/IEC documents are online at
http://standards.net-tel.co.uk/iso-iec-jtc1-sc33-wg1/1996-final-text

and if you are interested in s version which highlights the changes between the 1996 and 1999 versions see 10021-*-with-dams.pdf in:
http://standards.net-tel.co.uk/iso-iec-jtc1-sc33-wg1/drafts-in-preparation

Happy reading!

Jim




Received: by above.proper.com (8.9.3/8.9.3) id HAA04028 for ietf-smime-bks; Wed, 6 Jun 2001 07:46:15 -0700 (PDT)
Received: from tufan.tsk.mil.tr (tufan.tsk.mil.tr [212.50.38.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA04017 for <[e-mail]>; Wed, 6 Jun 2001 07:46:07 -0700 (PDT)
Received: from yengec (192.168.1.1 [192.168.1.1]) by tufan.tsk.mil.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LPXMD52K; Wed, 6 Jun 2001 17:46:22 +0300
From: "Erdal YILDIZ" <[e-mail]>
To: "Ietf-Smime" <[e-mail]>
Subject: X.400 Docs
Date: Wed, 6 Jun 2001 17:47:16 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-9"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi All;

I need the "[X.400] ITU-T X.400 Series of Recommendations, Information
technology - Message Handling Systems (MHS). X.400: System and Service
Overview; X.402: Overall Architecture; X.411: Message Transfer System:
Abstract Service Definition and Procedures; X.420: Interpersonal Messaging
System; 1996." documentations for my thesis work. I know that final versions
of those documents are not freely available, but if someone final drafts or
some detailled tutorial of them and send me, I will be really very
appreciated.

Thanks in advance

Erdal YILDIZ