NO RISK! YOUR $2400

["Kelli Crews" <[e-mail]>]

Your Winnings! Are waiting!

http://shudjjiic.net.cn/

Big Money PAYS You to Have FUN!




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3TIU6dB092287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2008 11:30:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3TIU6t7092286; Tue, 29 Apr 2008 11:30:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3TIU5Zt092269 for <[e-mail]>; Tue, 29 Apr 2008 11:30:05 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 782A93A6C08; Tue, 29 Apr 2008 11:30:01 -0700 (PDT)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-sha2-05.txt 
Message-Id: <[e-mail]>
Date: Tue, 29 Apr 2008 11:30:01 -0700 (PDT)
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		: Using SHA2 Algorithms with Cryptographic Message Syntax
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-sha2-05.txt
	Pages		: 10
	Date		: 2008-4-29
	
This document describes the conventions for using the Secure Hash 
   Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, 
   SHA-512) with the Cryptographic Message Syntax (CMS). It also 
   describes the conventions for using these algorithms with CMS and the 
   Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and 
   Elliptic Curve DSA (ECDSA) signature algorithms.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-smime-sha2-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3OGjA2G005621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2008 09:45:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3OGj9Eh005620; Thu, 24 Apr 2008 09:45:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m3OGj7qL005612 for <[e-mail]>; Thu, 24 Apr 2008 09:45:08 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 24748 invoked from network); 24 Apr 2008 16:44:57 -0000
Received: from unknown (HELO Wylie) ([e-mail]@71.191.11.170 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 24 Apr 2008 16:44:56 -0000
X-YMail-OSG: OtUfNDwVM1leX7CmDffPXw.JvY2WOi2y1l1um8sBO9VLfCXZkhWCjR66ehdG8fX6tPRDxn8JEN_Wi8Rv5GASnYpiMmewlAXLMOSAug--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" <[e-mail]>, "Daniel Brown" <[e-mail]>, "'Ietf-Smime'" <[e-mail]>
References: <[e-mail]>
Subject: RE: draft-ietf-smime-rfc3278-update-02
Date: Thu, 24 Apr 2008 12:41:47 -0400
Organization: IECA, Inc.
Message-ID: <012201c8a62a$16f76b50$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <[e-mail]>
Thread-Index: Acil+yEOq8jzoOllRiqOxdt145OA+gAInpZQ
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>

Alfred,

Thanks for your review.  All of you suggestions were incorporated. In
addition to you suggestion, I also added normative references to X.681,
RFC3370, RFC3565, RFC3852, and RFC5084 because we use/import ASN.1 from each
of these documents. I also added an introductory paragraph before the ASN.1
module.

All,

Does anybody think it would be clearer to resubmit this to be a bis draft
(i.e., obsolete 3278) instead of an update draft?  Originally, the draft
just updated the ECDSA 224-512 and SHA2 algorithms, but now it updates most
of the sections in RFC3278.  I think it might be clearer to just obsolete
RFC3278.

spt

>-----Original Message-----
>Hello,
>I also have reviewed your I-D, draft-ietf-smime-rfc3278-update-02.
>
>Here are my suggestions for further improvements of this memo.
>
>
>(1)   Section 1 -- structure and headlines
>
>I recommend amending the section title to:
>
>  1.  Introduction and Overview of Changes
>
>Below the first paragraph, I suggest to insert a subsection title:
>
>  1.1  Overview of Changes to RFC 3278
>
>(Note: The IESG very much likes to see a section title in the 
>ToC  linking the 'Updates' line in the front matter of the 
>document  to the body of the text.)
>
>And then move the unnumbered section now located between the 
>Abstract and 'Discussion' to the end of the original Section, 
>as a new subsection:
>
>  1.2  Conventions Used in this Document

Reshuffle and retitling done

>(2)  new Section 1.1 (now part of Section 1)
>
>I suggest to enhance the language in the bullets to improve 
>the readablitiy and precision of the text, as shown below.
>
>In particular, the repeated clause,
>  "... expands the options to the allowed algorithms to ..."
>seems to be potentially unclear.  I suggest to always use:
>  "... expands the set of allowed algorithms by adding ..."
>or simply:
>  "... expands the set of allowed algorithms by ..."
>
>Also, I recommend to make consistent use of present tense.

Agreed

>In the bullet related to Section 8.1, "algorithms for ..."
>should be changed to "algorithm identifiers for ...", and the 
>repeated use of "and" should be avoided to better represent 
>the logical grouping of the list given.

Agreed

>This leads to the following bullet-wise changes (using the log 
>form of above):
>
>    - Paragraph 3.1.1 used SHA1 in the KDF with ECDH std and cofactor
>      methods.  This document expands the options to the allowed
>      algorithms to SHA-224, SHA-256, SHA-384, and SHA-512.
>---
>    - Paragraph 3.1.1 used SHA1 in the KDF with ECDH std and cofactor
>|     methods.  This document expands the set of allowed algorithms by
>|     adding SHA-224, SHA-256, SHA-384, and SHA-512.

Fixed

>    - Paragraph 3.1.2 used SHA1 in the KDF with ECMQV. This document
>      expands the options to the allowed algorithms to SHA-224, SHA-
>      256, SHA-384, and SHA-512.
>---
>    - Paragraph 3.1.2 used SHA1 in the KDF with ECMQV. This document
>|     expands the set of allowed algorithms by adding SHA-224, SHA-256,
>      SHA-384, and SHA-512.

Fixed

>    - Paragraph 5 was update to include requirements for ...
>---               vvv      v
>    - Paragraph 5 is updated to include requirements for ...

Fixed

>    - Paragraph 7 was update to include S/MIME capabilities ...
>---               vvv      v
>    - Paragraph 7 is updated to include S/MIME capabilities ...

Fixed

>    - Paragraph 8.1 listed the algorithm identifiers for SHA-1 
>and SHA-1
>|     with ECDSA. This document adds algorithms for SHA-224, SHA-256,
>                           vvv       ^^^^^^^^^^
>|     SHA-384, and SHA-512 and SHA-224, SHA-256, SHA-384, and SHA-512
>      with ECDSA. This document also updates the list of algorithm
>      identifiers for ECDH std, ECDH cofactor, and ECMQV with SHA2
>      algorithms as the KDF.
>---
>    - Paragraph 8.1 listed the algorithm identifiers for SHA-1 
>and SHA-1
>|     with ECDSA.  This document adds algorithm identifiers 
>for SHA-224,
>|     SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA-256, SHA-
>      384, and SHA-512 with ECDSA.  This document also updates the list
>      of algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV
>      with SHA2 algorithms as the KDF.

Fixed

>(3)  Section 6
>
>The second 'New' part seems to be overly complex, hiding the 
>relatively simple orthogonal structure of its content.
>I suggest to remain more closely with the 'Old' style.
>
>Also, the clause "is not a complete list" is potentially 
>misleading and should better be rephrased.
>
>I suggest the following replacement text:
>
>   New:
>
>      The SMIMECapability value to indicate support for
>|        a)  the standard ECDH key agreement algorithm,
>|        b)  the cofactor ECDH key agreement algorithm, or
>|        c)  the 1-Pass ECMWV key agreement algorithm
>|     is a SEQUENCE with the capabilityID field containing the object
>      identifier
>|        a)  dhSingPass-stdDH-sha*kdf-scheme,
>|        b)  dhSingPass-cofactorDH-sha*kdf-scheme, or
>|        c)  mqvSinglePass-sha*kdf-scheme,
>|     respectively (where * is 1, 224, 256, 384, or 512) with the
>      parameters present.  The parameters indicate the supported
>      key-encryption algorithm with the KeyWrapAlgorithm algorithm
>|     identifier.
>|
>|     Example DER encodings that indicate some capabilities are as
>      follows (KA is key agreement, KDF is key derivation function,
>|     and Wrap is key wrap algorithm):
>
>... followed by the 3x3 = 9 examples already present in the 
>text, (without the two additional paragraphs of text).

Fixed

>(4)  Section 7
>
>(7a)  1st 'New': period missing at the end of the first paragraph.

Fixed

>(7b)  2nd 'New', last paragraph:   s/is/are/  ,  giving:
>      "When the object identifiers ... are used within ..."

Fixed

>(5)  Section 10
>
>(5a)
>Please give an indication of the ASN.1 version used, and add a 
>Reference to X.680.

Fixed. Also added reference to X.681.

>(5b)
>As a service to the reader, I suggest to amend all FROM 
>clauses in the IMPORTS ASN.1 statement by an ASN.1 comment 
>stating the document (RFC) where the named ASN.1 module is defined.

Added comments to indicate which document the imports come from. Since we
imported the ASN.1 from 4 RFCs that weren't reference I also added normative
references for RFC 3370, 3565, 3852, and 5084.

>(5c)
>In the first two extensible set definitions  s/::/::=/     :-)

Fixed



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3MHU92m059536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 10:30:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3MHU8Jc059535; Tue, 22 Apr 2008 10:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3MHU8MV059526 for <[e-mail]>; Tue, 22 Apr 2008 10:30:08 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 3B0203A68F1; Tue, 22 Apr 2008 10:30:01 -0700 (PDT)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-02.txt 
Message-Id: <[e-mail]>
Date: Tue, 22 Apr 2008 10:30:01 -0700 (PDT)
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		: Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-rfc3278-update-02.txt
	Pages		: 27
	Date		: 2008-4-22
	
RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 
   public-key algorithms in the Cryptographic Message Syntax (CMS).  
   This document updates RFC 3278 to add support for the SHA2 family of 
   hash algorithms.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-smime-rfc3278-update-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LGKd6Y090738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2008 09:20:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3LGKdbe090737; Mon, 21 Apr 2008 09:20:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m3LGKbep090721 for <[e-mail]>; Mon, 21 Apr 2008 09:20:38 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 65017 invoked from network); 21 Apr 2008 16:20:31 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.9.196 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 21 Apr 2008 16:20:30 -0000
X-YMail-OSG: sSR0R6cVM1k2iMwWdGgErnOsUN8gKxLwx2iziHHtWtyelANO2C8ZdHPy3TEJefL5HYJx2KjPHdFXAvRLPRtIVjRn78KzW_9Snz1oxkl_h0YJ87c2VgbWCHyi
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Ietf-Smime'" <[e-mail]>
Subject: New ASN.1 modules comments/questions
Date: Mon, 21 Apr 2008 12:17:39 -0400
Organization: IECA, Inc.
Message-ID: <018301c8a3cb$38074bf0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acijyzeq0RMiwCJnRHiuFMdEY7uJtQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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 and Paul,

Here are some comments/questions on the ASN.1 modules.

spt

-------------------

The definitions of AlgorithmIdentifier in the PKIX and SMIME modules are
different - is there a reason for the difference? Does it matter? In PKIX
it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 it's IOSet, in
ANSI X9 docs it's also IOSet, and in X.509 it's SupportedAlgorithms. If it
matters, then I guess I lean towards what's in RFC2976 since it's already in
an RFC.

-------------------

In the 3370 section,

 1. Shouldn't AlgorithmIdentifier be imported from the PKIX module?

 2. You used alg- as tag for hash algs, sig- for signature algs, kea- for
key agreement algs, alg- for symmetric key encryption algs.  I think it
might be easier to figure out which algs go where if the tag matches the
type of algorithm like mda- for MessageDigestAlgorithms, sa- for
SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms. 

 3. Could we change SymmetricKeyEncryptionAlgorithms to just
KeyWrapAlgorithms and use kwa- as the tag? There's also a KeyWrapAlgorithm
that I think is supposed to be the same as the
SymmetricKeyEncryptionAlgorithms so one or the other can get deleted (if you
delete the later change SupportKeyWrapAlgorithms to KeyWrapAlgorithms)?

 4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible?

 5. Do we need to add a MessageAuthenticationCodeAlgorithms for the hmac
alg? Then we could use maca- in front of the hMAC-SHA1.

 6. Some of the IOSets are {...} (like SignatureAlgorithms) while others
lists algorithms (like MessageDigestAlgorithms) - shouldn't all of them list
algorithms or none?

-------------------

In the 3565 section, I think the algorithms need to be defined using the new
syntax, import ALGORITHM, and define the algs as follows:

  ContentEncryptionAlgorithms ALGORITHM ::= { 
     cea-aes128-cbc   | 
     cea-aes192-cbc   | 
     cea-aes256-cbc, 
     ... -- Extensible 
     } 

   cea-aes128-cbc ALGORITHM ::= { 
     OID id-aes128-CBC PARMS AES-IV } 

   cea-aes192-cbc ALGORITHM ::= { 
     OID id-aes192-CBC PARMS AES-IV } 

   cea-aes256-cbc ALGORITHM ::= { 
     OID id-aes256-CBC PARMS AES-IV }

  KeyWrapAlgorithms ALGORITHM ::= { 
     kwa-aes128 | 
     kwa-aes192 | 
     kwa-aes256, 
     ... -- Extensible 
   } 

   kwa-aes128 ALGORITHM ::= { 
     OID id-aes128-wrap PARMS ABSENT } 

   kwa-aes192 ALGORITHM ::= { 
     OID id-aes192-wrap PARMS ABSENT } 

   kwa-aes256 ALGORITHM ::= { 
     OID id-aes256-wrap PARMS ABSENT } 

-------------------

In the 3851 section, shouldn't SMimeAttributeSet be extensible? r/{
attr-smimeCapabilities | attr-encrypKeyPref }/{ attr-smimeCapabilities |
attr-encrypKeyPref, ... }

-------------------

In the 3852 section,

 1. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I think it
should be id-pkix-explict(19) instead of (18).

 2. Are you going to remove the version notations [[3:, [[4:, etc?

 3. For consistency with 3370, can we change DigestAlgorithmList to
MessageDigestAlgorithms?

 4. For consistency, can we change UnsigedAttributes to
UnsignedAttributesSet and UnprotectedAttributes to UnprotectedAttribuesSet?

 5. In AuthenticatedData, SupportedAttributes is used in AuthAttributes and
UnauthAttributes. In AuthAttributes, can we change SupportAttributes to
AuthAttributesSet and in UnauthAttributes can we change SupportedAttributes
to UnauthAttributesSet?

 6. For consistency with the 3370 section, can we change
SignatureAlgorithmList to SignatureAlgorithms, DigestAlgorithmList to
MessageDigestAlgorithms, KeyAgreementAlgorithmList to
KeyAgreementAlgorithms, and ContentEncryptionAlgorithmLists to
ContentEncryptionAlgorithms?

 7. Can we change KeyDerivationAlgorithmIdentifier to use
KeyDerivationAlgorithms instead of AlgorithmList?

 8. Can we change MessageAuthenticationCodeAlgorithm to use
MessageAuthenticationCodeAlgorithms instead of AlgorithmList?

 9. Don't we want to define an OriginatorPKAlgorithms instead of using
AlgorithmList in OriginatorPublicKey:

       OriginatorPublicKey ::= SEQUENCE {
         algorithm AlgorithmIdentifier {{OriginatorPKAlgorithms}},
         publicKey BIT STRING
       }

       OriginatorPKAlgorithms ALGORITHM ::= {
         ... -- Extensible
       }

 10. For consistency, can we change KeyEncryptionAlgorithmList to be
KeyEncryptionAlgorithms?

-------------------

In the 4108 section, can we make FirwareContentTypes and FirmwareSignedAttrs
extensible?

-------------------

In the 4998 section,

 1. Shouldn't we constrain the digestAlgorithms and digestAlgorithm?

 2. Should the import for Attribute come from PKIX or RFC3852 update module?

 3. Why is Extensions and EXTENSION imported?

-------------------

In the 5035 section,

 1. Why is Extensions and EXTENSION imported?

 2. Should the import for Attribute come from PKIX or RFC3852 update module?

 3. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I think it
should be id-pkix-explict(19) instead of (18).

 4. Should EssSignedAttributes be SignedAttributes? Should it also be
extensible?

 5. Should EssContentTypes be just ContentSet?

 6. Is the note about the identical SecurityCategories encoding required
anymore?

 7. Shouldn't we say HashAlgorithms ::= MessageDigestAlgorithms instead of
HashAlgorithms ::= AlgorithmIdentifier {{...}}?

 8. Shouldn't we import the shaa256 alg?

-------------------

In the 5084 section, we should import ALGORITHM from PKIX and define the
algorithms as follows:

   ContentEncryptionAlgorithms ALGORITHM ::= { 
     cea-aes128-ccm   | 
     cea-aes192-ccm   | 
     cea-aes256-ccm   | 
     cea-aes128-gcm   | 
     cea-aes128-gcm   | 
     cea-aes128-gcm, 
     ... -- Extensible 
     } 

   cea-aes128-ccm ALGORITHM ::= { 
     OID id-aes128-CCM PARMS CCMParameters } 

   cea-aes192-ccm ALGORITHM ::= { 
     OID id-aes192-CCM PARMS CCMParameters } 

   cea-aes256-ccm ALGORITHM ::= { 
     OID id-aes256-CCM PARMS CCMParameters } 

   cea-aes128-gcm ALGORITHM ::= { 
     OID id-aes128-GCM PARMS GCMParameters } 

   cea-aes192-gcm ALGORITHM ::= { 
     OID id-aes192-GCM PARMS GCMParameters } 

   cea-aes256-gcm ALGORITHM ::= { 
     OID id-aes256-GCM PARMS GCMParameters } 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3BD9hh9086715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 06:09:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BD9h40086714; Fri, 11 Apr 2008 06:09:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [192.168.1.102] ([207.237.5.3]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3BD75qc086361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 06:07:06 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240824c42512427d1c@[192.168.1.102]>
In-Reply-To: <[e-mail]>
References: <016f01c89997$82122dc0$1b289386@jotop> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 11 Apr 2008 09:07:03 -0400
To: Russ Housley <[e-mail]>, Blake Ramsdell <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: AW: Content Type for XML Objects
Cc: [e-mail]
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 2:37 PM -0400 4/9/08, Russ Housley wrote:
>Blake:
>
>>  > The nice thing about S/MIME and PGP is that what's signed is 
>>"this string of
>>>  bits, exactly as is", without any need to perform impossible 
>>>manipulations on
>>>  it first like XMLdsig requires.
>>
>>One way to avoid this temptation is to just leave it as "throw a MIME
>>Content-Type at the beginning of it with application/(something)+xml, mark it
>>id-data and call it S/MIME". The overhead does not seem significant (just the
>>additional header), and I don't know the utility of being able to identify it
>>as XML at the outer CMS wrapper.
>
>I already proposed this before starting this thread.  This is the 
>response I got:
>
>>  Gah, please not MIME encoding.  We already have to have ASN.1 and XML
>>  libraries, I don't want to have to add a MIME library too.
>
>As you can see, there is a strong preference to carry the XML object 
>directly in CMS.

There are strong preferences all over on topics relating to XML. See 
the Apps Area mailing list, about once a year or so.

FWIW, I agree with Blake. Using the outer wrapper to say "the bits 
inside this are serialized as XML" doesn't seem useful to the S/MIME 
processor. Let's not reinvent MIME in our OIDs if we don't need to.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39KK8gX090249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 13:20:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m39KK8Gi090248; Wed, 9 Apr 2008 13:20:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39KK7BJ090241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 9 Apr 2008 13:20:08 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m39KMDTW017850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Apr 2008 13:22:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1207772533; bh=mL7xG9sP5d5tVtu5XukRZGDsYNxNa+kAMaoD zUUB75Q=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=gDuQMY 3jMMlY4gl5BDK+d4lKPz2GAXiPZOsNWnaQP1mj1/pSex2w+nqR0bQBobqXdzc9ez2SP ALV64/TgToW8OOdCWO8hXb4K+i3+CDkAFXgDvNqJ65jggparP6PSeIiUKYer4VOfEst qGWqqlSUrfdZ00b/jpKy3vq8xpdEiwg=
Received: from blake-ramsdells-macbook-pro.local (c-24-17-217-200.hsd1.wa.comcast.net [24.17.217.200]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m39KJxiS023040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 13:20:04 -0700
X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m39KJxiS023040
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1207772405; bh=mL7xG9sP5d5tVtu5XukRZGDsYNxNa+kAMaoD zUUB75Q=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=GRKV7kOLTaSeeVgTJbN0Ws7KEPNCQv6ynEaXc4 d5f1PuD0vndSno+RtVXiIDaTNXKT0G2a447+1f/M4Iqk2kymbwTBx7Mi48DWfqxj7Tq 9vXV0bIr78fh+GPMC5+pYoJqe7kA0HJDLJXbJrsssKAXH0OxZuHbv4lH+y+imAC1fM=
Date: Wed, 9 Apr 2008 13:17:51 -0700
From: Blake Ramsdell <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: AW: Content Type for XML Objects
Message-ID: <[e-mail]>
References: <016f01c89997$82122dc0$1b289386@jotop> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.15 (2007-04-06)
X-MM-Ex-RefId: 149371::080409132004-1AED8B90-63197609/0-0/0-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>

On Wed, Apr 09, 2008 at 02:37:31PM -0400, Russ Housley wrote:
>  I already proposed this before starting this thread.  This is the response I 
>  got:
> 
>  > Gah, please not MIME encoding.  We already have to have ASN.1 and XML
>  > libraries, I don't want to have to add a MIME library too.

I would be very surprised to find a CMS implementation that didn't have at
least a little bit of MIME in it. But the point is taken.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39J4EXq084923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 12:04:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m39J4Ea3084922; Wed, 9 Apr 2008 12:04:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m39J4Dj8084906 for <[e-mail]>; Wed, 9 Apr 2008 12:04:14 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 25723 invoked by uid 0); 9 Apr 2008 19:04:05 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 9 Apr 2008 19:04:05 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 09 Apr 2008 14:37:31 -0400
To: Blake Ramsdell <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: AW: Content Type for XML Objects
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <016f01c89997$82122dc0$1b289386@jotop> <[e-mail]> <[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>

Blake:

> > The nice thing about S/MIME and PGP is that what's signed is 
> "this string of
> > bits, exactly as is", without any need to perform impossible 
> manipulations on
> > it first like XMLdsig requires.
>
>One way to avoid this temptation is to just leave it as "throw a MIME
>Content-Type at the beginning of it with application/(something)+xml, mark it
>id-data and call it S/MIME". The overhead does not seem significant (just the
>additional header), and I don't know the utility of being able to identify it
>as XML at the outer CMS wrapper.

I already proposed this before starting this thread.  This is the 
response I got:

 > Gah, please not MIME encoding.  We already have to have ASN.1 and XML
 > libraries, I don't want to have to add a MIME library too.

As you can see, there is a strong preference to carry the XML object 
directly in CMS.

Russ





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m397igxQ027208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 00:44:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m397igYu027207; Wed, 9 Apr 2008 00:44:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m397iebr027193 for <[e-mail]>; Wed, 9 Apr 2008 00:44:41 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9F823187DD; Wed,  9 Apr 2008 19:44:39 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NxIPVbWGvJE; Wed,  9 Apr 2008 19:44:39 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2807E187DC; Wed,  9 Apr 2008 19:44:38 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0421119EC0B9; Wed,  9 Apr 2008 19:44:38 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1JjUyz-0005NA-S7; Wed, 09 Apr 2008 19:44:37 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: AW: Content Type for XML Objects
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 09 Apr 2008 19:44:37 +1200
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>

Blake Ramsdell <[e-mail]> writes:

>One way to avoid this temptation is to just leave it as "throw a MIME
>Content-Type at the beginning of it with application/(something)+xml, mark it
>id-data and call it S/MIME". The overhead does not seem significant (just the
>additional header), and I don't know the utility of being able to identify it
>as XML at the outer CMS wrapper.

Actually if the decision does end up being made to go with a non-id-data OID,
there's no reason why it has to be the same format as id-data.  So instead of
it being:

  Data ::= OCTET STRING

make it:

  XmlData ::= SEQUENCE {
  	version    INTEGER (0),
  	xmlInfo    UTF8String,
  	content    OCTET STRING
  	}

where 'xmlInfo' is whatever's needed to process the 'content'.  This does away
with the need to stick a MIME header around the XML data, which is a bit of an
artificial construct.  It also avoids a problem where what's being created
here is really a CMS type and not an S/MIME type, many CMS applications don't
do S/MIME so they couldn't do much with a Content-Type.

Or you could make the 'content' another UTF8String to make it explicit that
the content is supposed to be text, but I'm not sure how much variation XML
allows in its content, i.e. whether it would fall outside UTF8.  The 
advantage of 'OCTET STRING' is that it lets you take the XML content 
exactly as you see it and encapsulate it within a CMS blob without any need
for recoding.

(The other advantage with the 'xmlInfo' out-of-band data is that it's then
someone else's problem to standardise what goes in there, I'm not sure whether
CMS/SMIME should have to define formatting standards for XML content).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m397M9aq024854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 00:22:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m397M9Zf024853; Wed, 9 Apr 2008 00:22:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m397M9nu024845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 9 Apr 2008 00:22:09 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m397NuJq025021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Apr 2008 00:23:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1207725836; bh=ItFgC5ZZQLNR0/ow7gZxaDt2rwYtmxEXwDVE nqpfooI=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=udi9rJ gFo7kjGCTL1EVLVxIc4DS7SUTtl99mf3XoIB/BBJU6FR+BIwftsIuK365BCHajqr9WU whVXozGP/OORXFIE8PQtgqmDOAk0D+CSc1sPa57rjFpIDGqGV21m2QXKBEafn8U12sh /oTLRAy0Sh6nv7qPDExY/GSAQqERQ2E=
Received: from blake-ramsdells-macbook-pro.local (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m397Libe017788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 00:21:48 -0700
X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m397Libe017788
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1207725710; bh=ItFgC5ZZQLNR0/ow7gZxaDt2rwYtmxEXwDVE nqpfooI=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=jiY1XKEOyiVq7pxMPgmklG/tkEY9aRU0FC+PyG xmQ6IWdNZWJ9XjZzEiXJBvIirzTh5CK0rvE1DizKBidiDnRUn/L3KPDuRP0yhUR8S+e JnMFVV4+p/MMPrXqIEBWy3jpebAJlfsEmlZVUB2izgif4elwKk10m8dsSV2W4jDHHY=
Date: Wed, 9 Apr 2008 00:19:37 -0700
From: Blake Ramsdell <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: AW: Content Type for XML Objects
Message-ID: <[e-mail]>
References: <016f01c89997$82122dc0$1b289386@jotop> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.15 (2007-04-06)
X-MM-Ex-RefId: 149371::080409002149-1AED8B90-09C7CE54/0-0/0-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>

On Wed, Apr 09, 2008 at 06:31:03PM +1200, Peter Gutmann wrote:
> The nice thing about S/MIME and PGP is that what's signed is "this string of
> bits, exactly as is", without any need to perform impossible manipulations on
> it first like XMLdsig requires.

One way to avoid this temptation is to just leave it as "throw a MIME
Content-Type at the beginning of it with application/(something)+xml, mark it
id-data and call it S/MIME". The overhead does not seem significant (just the
additional header), and I don't know the utility of being able to identify it
as XML at the outer CMS wrapper.

It also, of course, neatly sidesteps any issues relating to "the C word" since
it is already steeped in current practice to just leave the poor guy's bits
alone, as Peter points out.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m397Cfxp023439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 00:12:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m397CfJu023438; Wed, 9 Apr 2008 00:12:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m397Ca5t023426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 9 Apr 2008 00:12:37 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 624476A955; Wed,  9 Apr 2008 00:12:35 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <016f01c89997$82122dc0$1b289386@jotop> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: AW: Content Type for XML Objects
Date: Wed, 9 Apr 2008 00:12:35 -0700
Message-ID: <01d201c89a11$163a2510$42ae6f30$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AciaC7MWOk3fsJQ2QrWNR4h+eSluQwAA+K1A
Content-Language: en-us
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>

I agree with at least part of what Peter said.

This is the path that I think should be followed:

1.  There should be one XML content type OID assigned.  There are not
multiple ways to encode XML at this point.

2.  It should be determined 
        a) We need an authenticated attribute to convey what the XML is and
        b) if the ContentHints attribute is 

	If the answers are yes and no, then a new authenticated attribute
should be created for this purpose.

3.  For those people who want to continue using C14N algorithms on XML
trees, they need to define one or more new hash algorithms that convert an
XML tree into a binary number.  These new hash algorithms would most likely
take as a parameter one of the existing string to binary number hash
algorithms we are familiar with today.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Peter Gutmann
> Sent: Tuesday, April 08, 2008 11:31 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: AW: Content Type for XML Objects
> 
> 
> =?iso-8859-1?Q?J=F6rg_Schwenk?= <[e-mail]> writes:
> 
> >- The problem now is that there are, up to my knowledge, at least two
> >different C14N algorithms specified. So one OID will not do, because
> it has
> >to tell the signature verification function how to process the XML
> data
> >before hashing it.
> 
> Argh, no, this is exactly the same mistake that XMLdsig makes, and (one
> of)
> the reasons why it's such a nightmare to implement (see
> http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt for the short
> form and
> http://seattle.toorcon.org/2007/talks/bradhill.ppt for the version with
> full
> orchestration and five part harmony).
> 
> The nice thing about S/MIME and PGP is that what's signed is "this
> string of
> bits, exactly as is", without any need to perform impossible
> manipulations on
> it first like XMLdsig requires.
> 
> >To sum up: I think we need a different OID for each C14N algorithm.
> 
> Only if we want to repeat XMLdsig's mistakes.  This is a chance to fix
> them,
> not to perpetuate them.
> 
> Peter.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m396VNH5019806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 23:31:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m396VNV7019805; Tue, 8 Apr 2008 23:31:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m396VHHN019783 for <[e-mail]>; Tue, 8 Apr 2008 23:31:21 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4F9CD18804; Wed,  9 Apr 2008 18:31:16 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DST5e5s5KDfV; Wed,  9 Apr 2008 18:31:16 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 50A5418629; Wed,  9 Apr 2008 18:31:15 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6BE0919EC0B9; Wed,  9 Apr 2008 18:31:03 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1JjTpn-00021q-8q; Wed, 09 Apr 2008 18:31:03 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: AW: Content Type for XML Objects
Cc: [e-mail]
In-Reply-To: <016f01c89997$82122dc0$1b289386@jotop>
Message-Id: <[e-mail]>
Date: Wed, 09 Apr 2008 18:31:03 +1200
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>

=?iso-8859-1?Q?J=F6rg_Schwenk?= <[e-mail]> writes:

>- The problem now is that there are, up to my knowledge, at least two
>different C14N algorithms specified. So one OID will not do, because it has
>to tell the signature verification function how to process the XML data
>before hashing it.

Argh, no, this is exactly the same mistake that XMLdsig makes, and (one of)
the reasons why it's such a nightmare to implement (see
http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt for the short form and
http://seattle.toorcon.org/2007/talks/bradhill.ppt for the version with full
orchestration and five part harmony).

The nice thing about S/MIME and PGP is that what's signed is "this string of
bits, exactly as is", without any need to perform impossible manipulations on
it first like XMLdsig requires.

>To sum up: I think we need a different OID for each C14N algorithm.

Only if we want to repeat XMLdsig's mistakes.  This is a chance to fix them,
not to perpetuate them.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38IKGa1058478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 11:20:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m38IKGEW058477; Tue, 8 Apr 2008 11:20:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m38IKF5H058470 for <[e-mail]>; Tue, 8 Apr 2008 11:20:16 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 4195 invoked by uid 0); 8 Apr 2008 18:20:09 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 8 Apr 2008 18:20:09 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 08 Apr 2008 14:10:56 -0400
To: Jörg Schwenk <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: AW: Content Type for XML Objects
Cc: <[e-mail]>
In-Reply-To: <016f01c89997$82122dc0$1b289386@jotop>
References: <[e-mail]> <[e-mail]> <[e-mail]> <016f01c89997$82122dc0$1b289386@jotop>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
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>

Jörg:

I agree with all of you observations, but I do not agree with your conclusion.

When CMS is used to encapsulate a content, the content is carried as 
an OCTET STRING, so it is not altered.  Canonicalization is not an 
issue.  When CMS is used for a detached content, all of the 
canonicalization issues come out, but it is not the job of the 
content type to provide encoding rules.  The detached content must be 
transferred in a manner that the same hash value can be 
computed.  That cannot fall on the assignment of a CMS content type 
object identifier.

Russ

At 12:42 PM 4/8/2008, Jörg Schwenk wrote:
>I think the problem is a little more complex:
>
>- If you have to (re-)compute a hash value, you need the bitwise identical
>representation of the signed data.
>
>- ASN.1, MIME and XML have different methods how to guarantee this; In XML,
>it is a process called canonicalization (C14N) that takes care e.g. of
>linebreaks, but also of more complicated stuff like namespaces.
>
>- The problem now is that there are, up to my knowledge, at least two
>different C14N algorithms specified. So one OID will not do, because it has
>to tell the signature verification function how to process the XML data
>before hashing it.
>
>- We also cannot rely on the XML data to carry this information: This is
>e.g. not part of a simple XHTML document.
>
>To sum up: I think we need a different OID for each C14N algorithm. To start
>with one is OK, but then the C14N variant must be fixed.
>
>Joerg
>
>-----Ursprüngliche Nachricht-----
>Von: [e-mail] [mailto:[e-mail]] Im
>Auftrag von Russ Housley
>Gesendet: Freitag, 4. April 2008 18:04
>An: Lisa Dusseault
>Cc: [e-mail]; [e-mail]
>Betreff: Re: Content Type for XML Objects
>
>
>Lisa:
>
>IN CMS OIDs are used for many different things.  OIDs are used to
>identify algorithms, but they are also used to identify content
>types.  We have assigned OIDs for varios "protecting" content types
>to allow layering of secuity envelopes, and we have assigned OIDs for
>various contents.
>
>In the most common case (id-data), then content type does not say
>anything.  In S/MIME, this content type is used, and it really means
>look inside for a MIME type.  The MIME type then tells the
>application how to handle the content.
>
>In the request that I have received, the XML object is being signed
>directly.  That is, there is no MIME encoding of the XML object prior
>to signature.
>
>Russ
>
>At 11:39 AM 4/4/2008, Lisa Dusseault wrote:
> >In apps, we've had the practice of defining different MIME types for
> >different kinds of XML-formatted data.  A custom MIME type can often
> >tell you much more than just what the formatting is, of course.  This
> >is most frequently seen in documents that might be sent over HTTP,
> >where filtering or dispatching (to a Web application, for example) can
> >possibly be done on the MIME type alone.  However there's always the
> >fallback to application/xml which may or may not be allowed depending
> >on the context.  E.g. the W3C says that XHTML documents SHOULD be
> >given the content type "application/html+xml" when returned to
> >clients, although of course a Web server could return other XML
> >documents as application/xml.
> >
> >The convention is to put "+xml" on the end of the MIME type -- I don't
> >know if it's very common for implementations to use that convention to
> >tell that the document is in XML even when the specific MIME type is
> >not known.
> >
> >Whether this approach would be worth it in CMS as well, I can't tell.
> >Looking at RFC2984, OIDs seem to be about cryptographic functions, not
> >content objects.  What am I missing?
> >
> >Lisa
> >
> >On Apr 4, 2008, at 6:54 AM, Russ Housley wrote:
> >
> >>I have received a request to assign an Object Identifier (OID) to be
> >>used as a content type for XML objects.  The idea is that one would
> >>look inside the XML object to determine  the type of XML object that
> >>is being carried inside CMS.
> >>
> >>Is this the right thing to do?
> >>
> >>Would it be better to have a different content type for each XML
> >>object?
> >>
> >>Would it be better to use id-data?
> >>
> >>Russ
> >



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38GhkxX049168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 09:43:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m38Ghkmg049167; Tue, 8 Apr 2008 09:43:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.rz.ruhr-uni-bochum.de (mx3.rz.ruhr-uni-bochum.de [134.147.64.33]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m38GhhQG049134 for <[e-mail]>; Tue, 8 Apr 2008 09:43:45 -0700 (MST) (envelope-from [e-mail])
X-Queued: (qmail 12844 invoked from network); 8 Apr 2008 16:43:36 -0000
Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx3.rz.ruhr-uni-bochum.de with SMTP; 8 Apr 2008 16:43:36 -0000
X-Queued: (qmail 10711 invoked by uid 281); 8 Apr 2008 16:43:36 -0000
X-Qmailscanner: from 217.225.188.63 (mNHiDSxtQuVJ3Mxa9yfinw==@217.225.188.63) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.71/4.27.   Clear:RC:1(217.225.188.63):.  Processed in 0.040385 secs); 08 Apr 2008 16:43:36 -0000
Received: from pd9e1bc3f.dip.t-dialin.net (HELO jotop) (mNHiDSxtQuVJ3Mxa9yfinw==@217.225.188.63) by c2-3-4.rz.ruhr-uni-bochum.de with (RC4-MD5 encrypted) SMTP; 8 Apr 2008 16:43:36 -0000
From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: AW: Content Type for XML Objects
Date: Tue, 8 Apr 2008 18:42:17 +0200
Message-ID: <016f01c89997$82122dc0$1b289386@jotop>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; boundary="----=_NextPart_000_016B_01C899A8.45288CE0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
Thread-Index: AciWceD5T+bUUue6TIOOIwcRnT/mcQDGwOHw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>

This is a multi-part message in MIME format.

------=_NextPart_000_016B_01C899A8.45288CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think the problem is a little more complex:

- If you have to (re-)compute a hash value, you need the bitwise =
identical
representation of the signed data.

- ASN.1, MIME and XML have different methods how to guarantee this; In =
XML,
it is a process called canonicalization (C14N) that takes care e.g. of
linebreaks, but also of more complicated stuff like namespaces.

- The problem now is that there are, up to my knowledge, at least two
different C14N algorithms specified. So one OID will not do, because it =
has
to tell the signature verification function how to process the XML data
before hashing it.

- We also cannot rely on the XML data to carry this information: This is
e.g. not part of a simple XHTML document.

To sum up: I think we need a different OID for each C14N algorithm. To =
start
with one is OK, but then the C14N variant must be fixed.

Joerg

-----Urspr=FCngliche Nachricht-----
Von: [e-mail] =
[mailto:[e-mail]] Im
Auftrag von Russ Housley
Gesendet: Freitag, 4. April 2008 18:04
An: Lisa Dusseault
Cc: [e-mail]; [e-mail]
Betreff: Re: Content Type for XML Objects


Lisa:

IN CMS OIDs are used for many different things.  OIDs are used to=20
identify algorithms, but they are also used to identify content=20
types.  We have assigned OIDs for varios "protecting" content types=20
to allow layering of secuity envelopes, and we have assigned OIDs for=20
various contents.

In the most common case (id-data), then content type does not say=20
anything.  In S/MIME, this content type is used, and it really means=20
look inside for a MIME type.  The MIME type then tells the=20
application how to handle the content.

In the request that I have received, the XML object is being signed=20
directly.  That is, there is no MIME encoding of the XML object prior=20
to signature.

Russ

At 11:39 AM 4/4/2008, Lisa Dusseault wrote:
>In apps, we've had the practice of defining different MIME types for
>different kinds of XML-formatted data.  A custom MIME type can often
>tell you much more than just what the formatting is, of course.  This
>is most frequently seen in documents that might be sent over HTTP,
>where filtering or dispatching (to a Web application, for example) can
>possibly be done on the MIME type alone.  However there's always the
>fallback to application/xml which may or may not be allowed depending
>on the context.  E.g. the W3C says that XHTML documents SHOULD be
>given the content type "application/html+xml" when returned to
>clients, although of course a Web server could return other XML
>documents as application/xml.
>
>The convention is to put "+xml" on the end of the MIME type -- I don't
>know if it's very common for implementations to use that convention to
>tell that the document is in XML even when the specific MIME type is
>not known.
>
>Whether this approach would be worth it in CMS as well, I can't tell.
>Looking at RFC2984, OIDs seem to be about cryptographic functions, not
>content objects.  What am I missing?
>
>Lisa
>
>On Apr 4, 2008, at 6:54 AM, Russ Housley wrote:
>
>>I have received a request to assign an Object Identifier (OID) to be
>>used as a content type for XML objects.  The idea is that one would
>>look inside the XML object to determine  the type of XML object that
>>is being carried inside CMS.
>>
>>Is this the right thing to do?
>>
>>Would it be better to have a different content type for each XML
>>object?
>>
>>Would it be better to use id-data?
>>
>>Russ
>


------=_NextPart_000_016B_01C899A8.45288CE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGtzCCA1Mw
ggK8oAMCAQICDgPYAAEAAuYuTmNUEqhuMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ
MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50
ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu
ZGUwHhcNMDcwNzAyMTA1MzUyWhcNMDgwODIxMTA1MzUyWjBKMQswCQYDVQQGEwJERTEWMBQGA1UE
AxMNSm9lcmcgU2Nod2VuazEjMCEGCSqGSIb3DQEJARYUam9lcmcuc2Nod2Vua0BydWIuZGUwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL87hBfH2WpWbqzzSHa01D/EXd+mumSJaTjgMAq3Jzte
NBcMZ0/0P9TSjc/CAXkFsaxrEHd+2ddr8rVMjgyL1ACJ8yYsSL0Xl2bYKPjxPBL1Hhj7Npn+Gx1I
BRH23trbSlXYyyf23zBK9/zSaJCX1lrYOh9uABAh4lUayTWBLowTAgMBAAGjgcgwgcUwDAYDVR0T
AQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cudHJ1c3Rj
ZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgEDBFAWTmh0
dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS8wM0Q4MDAwMTAw
MDJFNjJFNEU2MzU0MTJBODZFPzANBgkqhkiG9w0BAQQFAAOBgQAX7f7Uf+07c7YnZjsJAk8Vokbp
RPyQmtjmuTjBGhmI3Bebt+KHiEc1IK0HsoXIygouWghdUf4wiz3rWPWPsHNhzUCpiL4R7tYr3BDI
ntjOj91o67QETMR+zp840S7H4UyUiBYw3eZKMsUISOA7xV51knhlegxjUx/zmjLOsAMxXzCCA1ww
ggLFoAMCAQICAgPpMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFt
YnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3Vy
aXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg
MSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNOTgwMzA5
MTE1OTU5WhcNMTEwMTAxMTE1OTU5WjCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcx
EDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBp
biBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0Ex
KTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVyLmRlMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCwKeu0drOu17ZbtF7nveOxnEkEV1uhq9l/Exv9umGr2Odx3y0AlF1RSH0j
73VihJA8Ch9ZEXQvjoCl/TACPSlSzXIaSSGcvMtSjkihY5bIEIUwaVd0RcBahsbVPeBoV30xaiSN
RZc+MX5oZjJuJG3sMjbJQcrwMUTIo2HKG6A2HwIDAQABo2swaTAPBgNVHRMBAf8EBTADAQH/MA4G
A1UdDwEB/wQEAwIBhjAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n
dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQQFAAOBgQBPmVmFyGRWgsVv
PdhGCS88UcGncFiBkhLq9NQWAJZecijn1jZfGpyvH8KDGrQFVZmmWFw3KPJXHutdv7HTRQ9yHAPS
AMcsVdr+X4l2i+LUd/VNCRevxLqrMCtPuB3q2f9Z8FB0Rrpe6jaw65J7D1jaMuFSvSM3D/XzAEqu
sF7ebjGCBAgwggQEAgEBMIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G
A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERh
dGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcG
CSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDgPYAAEAAuYuTmNUEqhuMAkG
BSsOAwIaBQCgggKOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4
MDQwODE2NDIxN1owIwYJKoZIhvcNAQkEMRYEFP2bEfxhwAXGl3+B448ik5E5nwtZMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHgBgkrBgEEAYI3EAQxgdIw
gc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTow
OAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJI
MSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0
aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOA9gAAQAC5i5OY1QSqG4wgeIGCyqGSIb3DQEJEAILMYHS
oIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6
MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i
SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy
dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDgPYAAEAAuYuTmNUEqhuMA0GCSqGSIb3DQEBAQUABIGA
FPYWsxCRLz3iFdxrC4xJRhCNccH8KElysw9u0rUM24gUNV4AWUuLP8FUwnGhB+jIIlYPYpLF2ELj
S+ZODsNgJ53Rzivs+e9RrOOYeDlAxdt46AQ2BXy0WmgUmrG2cyf0se+Nl9Moe2ICf11YP/SwNZGM
dPyEh3VGnX8UrQnFm0gAAAAAAAA=

------=_NextPart_000_016B_01C899A8.45288CE0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m358QWCV077997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Apr 2008 01:26:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m358QWj3077996; Sat, 5 Apr 2008 01:26:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m358QJc4077967; Sat, 5 Apr 2008 01:26:20 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B78CB185BF; Sat,  5 Apr 2008 21:26:16 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcXwd7i8YiR4; Sat,  5 Apr 2008 21:26:16 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6758A185BB; Sat,  5 Apr 2008 21:26:13 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 048BC19EC0B9; Sat,  5 Apr 2008 21:26:03 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Ji3is-0000rg-SN; Sat, 05 Apr 2008 21:26:02 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 05 Apr 2008 21:26:02 +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>

Simon Josefsson <[e-mail]> writes:

>What are the "stupid parameters" boundaries that you use?  I'd like to
>consider adopting something similar.  Using values that someone else has
>already tried appear less likely to introduce new problems.

Hmm, I wound down the limits a bit more for the latest release (e.g. the
maximum size of e has gone from 64 to 40 bits) so they haven't been as heavily
tested as the previous version, but anyway here are some of them:

For RSA:

	nLen >= MIN_PKCSIZE, nLen <= CRYPT_MAX_PKCSIZE

	e >= MIN_PUBLIC_EXPONENT, eLen < 40 bits.  The latter check is to preclude
	DoS attacks due to ridiculously large e values.

	|p-q| > 128 bits

Also for the key parameters in general:

	p, q < d
	( d * e ) mod p-1 == 1
	( d * e ) mod q-1 == 1
	( q * u ) mod p == 1
	gcd( ( p - 1 )( q - 1), e ) == 1
	e1 < p, e2 < q

For DLP-based PKCs:

	pLen >= MIN_PKCSIZE, pLen <= CRYPT_MAX_PKCSIZE.

	2 <= g <= p - 2.
	PKCS #3 keys: g < 256.  This isn't strictly necessary but use of g
		in DH typically sets g = 2, the only reason for setting it to a
		larger value is either stupidity or a deliberate DoS, neither of
		which we want to encourage.
	Non-PKCS #3 keys: g a generator of order q when the q parameter is
		present.  FIPS 186/X9.42 use a g the same size as p so we can't
		limit the size.

	y < p

If I've missed any checks, please let me know.

(Ahh, sorry the constants in the above are various configurable values, I
think the names make their function obvious).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m356kw4U072749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 23:46:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m356kwWo072748; Fri, 4 Apr 2008 23:46:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m356kpGU072732; Fri, 4 Apr 2008 23:46:56 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A61E818608; Sat,  5 Apr 2008 19:46:48 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkJvJ9o2aBfA; Sat,  5 Apr 2008 19:46:48 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 634F118605; Sat,  5 Apr 2008 19:46:47 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 34FFC19EC0B9; Sat,  5 Apr 2008 19:46:45 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Ji2An-0004SS-2n; Sat, 05 Apr 2008 19:46:45 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 05 Apr 2008 19:46:45 +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>

Dr Stephen Henson <[e-mail]> writes:

>Some implementations (by accident or design) restrict e to 32 bits in size.

This is actually quite useful, although the limitation in the most widespread
implementation that does this is more or less arbitrary (when they designed
their key blob format they only left 32 bits for e) it's conveniently
discouraged anyone from using large e values (well, almost anyone anyway, I
once ran into an implementation from Germany that used a 32-bit e, but also
encoded it incorrectly so anything over INT_MAX ended up negative), so it's
fairly safe to require |e| to be < 32 bits for DoS-protection purposes.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34G4Dgw018326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 09:04:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m34G4DMw018325; Fri, 4 Apr 2008 09:04:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m34G4Brb018319 for <[e-mail]>; Fri, 4 Apr 2008 09:04:12 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 20531 invoked by uid 0); 4 Apr 2008 16:04:07 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 4 Apr 2008 16:04:07 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Apr 2008 12:04:09 -0400
To: Lisa Dusseault <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Content Type for XML Objects
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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>

Lisa:

IN CMS OIDs are used for many different things.  OIDs are used to 
identify algorithms, but they are also used to identify content 
types.  We have assigned OIDs for varios "protecting" content types 
to allow layering of secuity envelopes, and we have assigned OIDs for 
various contents.

In the most common case (id-data), then content type does not say 
anything.  In S/MIME, this content type is used, and it really means 
look inside for a MIME type.  The MIME type then tells the 
application how to handle the content.

In the request that I have received, the XML object is being signed 
directly.  That is, there is no MIME encoding of the XML object prior 
to signature.

Russ

At 11:39 AM 4/4/2008, Lisa Dusseault wrote:
>In apps, we've had the practice of defining different MIME types for
>different kinds of XML-formatted data.  A custom MIME type can often
>tell you much more than just what the formatting is, of course.  This
>is most frequently seen in documents that might be sent over HTTP,
>where filtering or dispatching (to a Web application, for example) can
>possibly be done on the MIME type alone.  However there's always the
>fallback to application/xml which may or may not be allowed depending
>on the context.  E.g. the W3C says that XHTML documents SHOULD be
>given the content type "application/html+xml" when returned to
>clients, although of course a Web server could return other XML
>documents as application/xml.
>
>The convention is to put "+xml" on the end of the MIME type -- I don't
>know if it's very common for implementations to use that convention to
>tell that the document is in XML even when the specific MIME type is
>not known.
>
>Whether this approach would be worth it in CMS as well, I can't tell.
>Looking at RFC2984, OIDs seem to be about cryptographic functions, not
>content objects.  What am I missing?
>
>Lisa
>
>On Apr 4, 2008, at 6:54 AM, Russ Housley wrote:
>
>>I have received a request to assign an Object Identifier (OID) to be
>>used as a content type for XML objects.  The idea is that one would
>>look inside the XML object to determine  the type of XML object that
>>is being carried inside CMS.
>>
>>Is this the right thing to do?
>>
>>Would it be better to have a different content type for each XML
>>object?
>>
>>Would it be better to use id-data?
>>
>>Russ
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34Fdsf8016788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 08:39:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m34FdskU016787; Fri, 4 Apr 2008 08:39:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34Fdpha016778 for <[e-mail]>; Fri, 4 Apr 2008 08:39:53 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8ADC314220E; Fri,  4 Apr 2008 08:39:53 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiqLNovmQL8u; Fri,  4 Apr 2008 08:39:47 -0700 (PDT)
Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1833514220D; Fri,  4 Apr 2008 08:39:47 -0700 (PDT)
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Russ Housley <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Content Type for XML Objects
Date: Fri, 4 Apr 2008 08:39:43 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.919.2)
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>

In apps, we've had the practice of defining different MIME types for  
different kinds of XML-formatted data.  A custom MIME type can often  
tell you much more than just what the formatting is, of course.  This  
is most frequently seen in documents that might be sent over HTTP,  
where filtering or dispatching (to a Web application, for example) can  
possibly be done on the MIME type alone.  However there's always the  
fallback to application/xml which may or may not be allowed depending  
on the context.  E.g. the W3C says that XHTML documents SHOULD be  
given the content type "application/html+xml" when returned to  
clients, although of course a Web server could return other XML  
documents as application/xml.

The convention is to put "+xml" on the end of the MIME type -- I don't  
know if it's very common for implementations to use that convention to  
tell that the document is in XML even when the specific MIME type is  
not known.

Whether this approach would be worth it in CMS as well, I can't tell.  
Looking at RFC2984, OIDs seem to be about cryptographic functions, not  
content objects.  What am I missing?

Lisa

On Apr 4, 2008, at 6:54 AM, Russ Housley wrote:

> I have received a request to assign an Object Identifier (OID) to be  
> used as a content type for XML objects.  The idea is that one would  
> look inside the XML object to determine  the type of XML object that  
> is being carried inside CMS.
>
> Is this the right thing to do?
>
> Would it be better to have a different content type for each XML  
> object?
>
> Would it be better to use id-data?
>
> Russ
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34Ef7hX010669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 07:41:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m34Ef7Dk010667; Fri, 4 Apr 2008 07:41:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34Ef5r2010655 for <[e-mail]>; Fri, 4 Apr 2008 07:41:06 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F0DD44808D8; Sat,  5 Apr 2008 03:41:04 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ7WqG-9m8iP; Sat,  5 Apr 2008 03:41:04 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8DD1148085F; Sat,  5 Apr 2008 03:41:04 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id ECE6419EC0B9; Sat,  5 Apr 2008 03:41:02 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Jhn6E-00080i-QW; Sat, 05 Apr 2008 03:41:02 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Content Type for XML Objects
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 05 Apr 2008 03:41:02 +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>

Russ Housley <[e-mail]> writes:

>I have received a request to assign an Object Identifier (OID) to be used as
>a content type for XML objects.  The idea is that one would look inside the
>XML object to determine  the type of XML object that is being carried inside
>CMS.
>
>Is this the right thing to do?

One part of me wants to say "What makes XML so special that it should get its
own content-type?".  However if this is an attempt to clean up the XMLdsig
mess then I'm all for it.

>Would it be better to have a different content type for each XML object?
>
>Would it be better to use id-data?

Redde Caesari quae sunt Caesaris.  Have one overall XML content-type and then
let the XML layer sort out what's actually in there.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34DsYN4005960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 06:54:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m34DsYWW005959; Fri, 4 Apr 2008 06:54:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m34DsXIJ005953 for <[e-mail]>; Fri, 4 Apr 2008 06:54:34 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 25644 invoked by uid 0); 4 Apr 2008 13:54:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 4 Apr 2008 13:54:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Apr 2008 09:54:26 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Content Type for XML Objects
Cc: [e-mail], [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>

I have received a request to assign an Object Identifier (OID) to be 
used as a content type for XML objects.  The idea is that one would 
look inside the XML object to determine  the type of XML object that 
is being carried inside CMS.

Is this the right thing to do?

Would it be better to have a different content type for each XML object?

Would it be better to use id-data?

Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31NIE4Y093229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2008 16:18:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m31NIEI9093228; Tue, 1 Apr 2008 16:18:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31NIDTE093222 for <[e-mail]>; Tue, 1 Apr 2008 16:18:14 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 5A6923A6A94; Tue,  1 Apr 2008 16:15:01 -0700 (PDT)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-01.txt 
Message-Id: <[e-mail]>
Date: Tue,  1 Apr 2008 16:15:01 -0700 (PDT)
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		: Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-rfc3278-update-01.txt
	Pages		: 9
	Date		: 2008-4-1
	
RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 
   public-key algorithms in the Cryptographic Message Syntax (CMS).  
   This document updates RFC 3278 to add support for the SHA2 family of 
   hash algorithms.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-smime-rfc3278-update-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--