Subject: NO RISK! YOUR $2400

From: "Kelli Crews" <[email-masked]>
Date: Wed, 30 Apr 2008 04:03:06 -0100

Your Winnings! Are waiting!

http://shudjjiic.net.cn/

Big Money PAYS You to Have FUN!

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-sha2-05.txt 
Date: Tue, 29 Apr 2008 11:30:01 -0700 (PDT)
Sender: [email-masked]

--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:	<[email-masked]>

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" <[email-masked]>, "Daniel Brown" <[email-masked]>, "'Ietf-Smime'" <[email-masked]>
Subject: RE: draft-ietf-smime-rfc3278-update-02
Date: Thu, 24 Apr 2008 12:41:47 -0400
Organization: IECA, Inc.
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-02.txt 
Date: Tue, 22 Apr 2008 10:30:01 -0700 (PDT)
Sender: [email-masked]

--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:	<[email-masked]>

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: "'Ietf-Smime'" <[email-masked]>
Subject: New ASN.1 modules comments/questions
Date: Mon, 21 Apr 2008 12:17:39 -0400
Organization: IECA, Inc.
Sender: [email-masked]

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 } 

Date: Fri, 11 Apr 2008 09:07:03 -0400
To: Russ Housley <[email-masked]>, Blake Ramsdell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: AW: Content Type for XML Objects
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Wed, 9 Apr 2008 13:17:51 -0700
From: Blake Ramsdell <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: AW: Content Type for XML Objects
Sender: [email-masked]

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

Date: Wed, 09 Apr 2008 14:37:31 -0400
To: Blake Ramsdell <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: AW: Content Type for XML Objects
Cc: [email-masked]
Sender: [email-masked]

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: AW: Content Type for XML Objects
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 09 Apr 2008 19:44:37 +1200
Sender: [email-masked]

Blake Ramsdell <[email-masked]> 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.

Date: Wed, 9 Apr 2008 00:19:37 -0700
From: Blake Ramsdell <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AW: Content Type for XML Objects
Sender: [email-masked]

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

From: "Jim Schaad" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AW: Content Type for XML Objects
Date: Wed, 9 Apr 2008 00:12:35 -0700
Sender: [email-masked]

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: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Gutmann
> Sent: Tuesday, April 08, 2008 11:31 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: AW: Content Type for XML Objects
> 
> 
> =?iso-8859-1?Q?J=F6rg_Schwenk?= <[email-masked]> 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.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: AW: Content Type for XML Objects
Cc: [email-masked]
Date: Wed, 09 Apr 2008 18:31:03 +1200
Sender: [email-masked]

=?iso-8859-1?Q?J=F6rg_Schwenk?= <[email-masked]> 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.

Date: Tue, 08 Apr 2008 14:10:56 -0400
To: Jörg Schwenk <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: AW: Content Type for XML Objects
Cc: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] Im
>Auftrag von Russ Housley
>Gesendet: Freitag, 4. April 2008 18:04
>An: Lisa Dusseault
>Cc: [email-masked]; [email-masked]
>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
> >

From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: AW: Content Type for XML Objects
Date: Tue, 8 Apr 2008 18:42:17 +0200
Sender: [email-masked]

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: [email-masked] =
[mailto:[email-masked]] Im
Auftrag von Russ Housley
Gesendet: Freitag, 4. April 2008 18:04
An: Lisa Dusseault
Cc: [email-masked]; [email-masked]
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"

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 05 Apr 2008 21:26:02 +1300
Sender: [email-masked]

Simon Josefsson <[email-masked]> 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.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 05 Apr 2008 19:46:45 +1300
Sender: [email-masked]

Dr Stephen Henson <[email-masked]> 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.

Date: Fri, 04 Apr 2008 12:04:09 -0400
To: Lisa Dusseault <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Content Type for XML Objects
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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
>

Cc: [email-masked], [email-masked]
From: Lisa Dusseault <[email-masked]>
To: Russ Housley <[email-masked]>
Subject: Re: Content Type for XML Objects
Date: Fri, 4 Apr 2008 08:39:43 -0700
Sender: [email-masked]

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
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Content Type for XML Objects
Cc: [email-masked], [email-masked]
Date: Sat, 05 Apr 2008 03:41:02 +1300
Sender: [email-masked]

Russ Housley <[email-masked]> 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.

Date: Fri, 04 Apr 2008 09:54:26 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Content Type for XML Objects
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-01.txt 
Date: Tue,  1 Apr 2008 16:15:01 -0700 (PDT)
Sender: [email-masked]

--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:	<[email-masked]>

--NextPart--