i very want to find my love

["Marinka" <[e-mail]>]

Greetings to you!

I can't remove my eyes from you. You are so handsome and so interesting man,
I have never met before into my life.
If you are not against, I would be glad to get acquainted with you. As usual
men got acquainted with me, but everything is different today.
I want to get acquainted with you and it will be very sad if you don't want
to know me.
Maybe I am very ordinary person from one look, and you won't fall in love
from the first sight. But don't be very   precipitate at coming to your
decision. It may be fatal, because I can be a woman whom you are waiting
for, whom you need every morning and every night, who will be your support
and your love for the rest of life.
Let me come into your life, and I will light your life with love
http://rudateonline.info/?idAff=101


Looking forward to get a note from you

Marishka






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9UDcigp042697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 06:38:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9UDciEP042696; Tue, 30 Oct 2007 06:38:44 -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.13.5/8.13.5) with SMTP id l9UDcgKH042689 for <[e-mail]>; Tue, 30 Oct 2007 06:38:43 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 20920 invoked by uid 0); 30 Oct 2007 13:38:39 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 30 Oct 2007 13:38:39 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Oct 2007 09:31:47 -0400
To: Alice Hagens <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC 3217 Errata
Cc: [e-mail], Henrick Hellstrцm <[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>

Looks fine to me.

At 08:11 PM 10/29/2007, Alice Hagens wrote:
>Russ,
>
>Please check the errata as it appears here:
>
>  http://www.rfc-editor.org/errata_search.php?rfc=3217
>
>Some of the notes can be moved to appear before the examples, if that
>is more clear.
>
>Assumed it should be marked "Verified", or did you want it marked
>"Reported" and a notification sent to the IESG requesting that they
>verify it?
>
>Thank you.
>
>RFC Editor/ah
>
>On Oct 28, 2007, at 12:13 PM, Russ Housley wrote:
>
>>Dear RFC Editor:
>>
>>Section 4.4 of RFC 3217 is ambiguous.  The text is silent about the
>>RC2
>>parameter that indicates the effective key size.  This errata
>>resolves the
>>ambiguity.
>>
>>The first paragraph of section 4.4 says:
>>
>>    This section contains a RC2 Key Wrap example. Intermediate values
>>    corresponding to the named items in section 4.1 are given in
>>hexadecimal.
>>
>>New:
>>
>>    This section contains a RC2 Key Wrap example. Intermediate values
>>    corresponding to the named items in section 4.1 are given in
>>hexadecimal. In
>>    this example, the effective key length parameter for the RC2
>>algorithm should
>>    be 40 bits.
>>
>>To aid implementors, this errata includes two examples.  The first
>>one matches
>>section 4.4 and uses a 40-bit effective key size.  The second one
>>uses a
>>128-bit effective key size.  Many thanks to Peter Yee for
>>generating the
>>examples and Blake Ramsdell for checking them.
>>
>>Thanks,
>>   Russ
>>
>>==========================================
>>
>>RC2 Effective Key Bits: 40
>>
>>CEK is (16 bytes):
>>  b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9
>>
>>LENGTH is: 16
>>
>>LCEK is (17 bytes):
>>  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
>>  d9
>>
>>PAD is (7 bytes):
>>  48 45 cc e7 fd 12 50
>>
>>LCEKPAD is (24 bytes):
>>  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
>>  d9 48 45 cc e7 fd 12 50
>>
>>SHA-1 Digest is (20 bytes):
>>  0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
>>  7e ca 48 06
>>
>>ICV is (8 bytes):
>>  0a 6f f1 9f db 40 49 88
>>
>>LCEKPADICV is (32 bytes):
>>  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
>>  d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88
>>
>>IV is (8 bytes):
>>  c7 d9 00 59 b2 9e 97 f7
>>
>>KEK (16 bytes):
>>  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05
>>
>>TEMP1 (32 bytes):
>>  a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8
>>  ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7
>>
>>TEMP2 (40 bytes):
>>  c7 d9 00 59 b2 9e 97 f7 a0 1d a2 59 37 93 12 60
>>  e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32
>>  9f a9 8a 07 a3 1f f7 a7
>>
>>TEMP3 (40 bytes):
>>  a7 f7 1f a3 07 8a a9 9f 32 99 8e ff 9e d7 8c ac
>>  b8 70 ce 04 f5 55 8c e4 60 12 93 37 59 a2 1d a0
>>  f7 97 9e b2 59 00 d9 c7
>>
>>FinalIV (8 bytes):
>>  4a dd a2 2c 79 e8 21 05
>>
>>KEK (16 bytes):
>>  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05
>>
>>RESULT (40 bytes):
>>  70 e6 99 fb 57 01 f7 83 33 30 fb 71 e8 7c 85 a4
>>  20 bd c9 9a f0 5d 22 af 5a 0e 48 d3 5f 31 38 98
>>  6c ba af b4 b2 8d 4f 35
>>
>>==========================================
>>
>>RC2 Effective Key Bits: 128
>>
>>CEK is (16 bytes):
>>  b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9
>>
>>LENGTH is: 16
>>
>>LCEK is (17 bytes):
>>  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
>>  d9
>>
>>PAD is (7 bytes):
>>  48 45 cc e7 fd 12 50
>>
>>LCEKPAD is (24 bytes):
>>  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
>>  d9 48 45 cc e7 fd 12 50
>>
>>SHA-1 Digest is (20 bytes):
>>  0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
>>  7e ca 48 06
>>
>>ICV is (8 bytes):
>>  0a 6f f1 9f db 40 49 88
>>
>>LCEKPADICV is (32 bytes):
>>  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
>>  d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88
>>
>>IV is (8 bytes):
>>  c7 d9 00 59 b2 9e 97 f7
>>
>>KEK (16 bytes):
>>  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05
>>
>>TEMP1 (32 bytes):
>>  03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66
>>  67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29
>>
>>TEMP2 (40 bytes):
>>  c7 d9 00 59 b2 9e 97 f7 03 5e 97 2a b1 5c c4 c9
>>  c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae
>>  86 08 db c8 9e 64 ca 29
>>
>>TEMP3 (40 bytes):
>>  29 ca 64 9e c8 db 08 86 ae 46 67 a2 bc 3e e4 67
>>  66 21 5a a3 ba 3d a0 c4 c9 c4 5c b1 2a 97 5e 03
>>  f7 97 9e b2 59 00 d9 c7
>>
>>FinalIV (8 bytes):
>>  4a dd a2 2c 79 e8 21 05
>>
>>KEK (16 bytes):
>>  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05
>>
>>RESULT (40 bytes):
>>  f4 d8 02 1c 1e a4 63 d2 17 a9 eb 69 29 ff a5 77
>>  36 d3 e2 03 86 c9 09 93 83 5b 4b e4 ad 8d 8a 1b
>>  c6 3b 25 de 2b f7 79 93
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9TDsnWP018732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2007 06:54:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9TDsn8W018731; Mon, 29 Oct 2007 06:54:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9TDskws018720 for <[e-mail]>; Mon, 29 Oct 2007 06:54:48 -0700 (MST) (envelope-from [e-mail])
Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id <V1C33G25>; Mon, 29 Oct 2007 13:54:38 -0000
Message-ID: <[e-mail]>
From: "Pope, Nick" <[e-mail]>
To: "'Turner, Sean P.'" <[e-mail]>, "'Julien Stern'" <[e-mail]>, [e-mail]
Subject: RE: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic Si gnatures (CAdES)) to Informational RFC
Date: Mon, 29 Oct 2007 13:54:31 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I can confirm this (apologies for the slow response - I have been away).

Nick

> -----Original Message-----
> From: Turner, Sean P. [mailto:[e-mail]]
> Sent: 19 October 2007 21:00
> To: 'Julien Stern'; [e-mail]
> Subject: RE: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic
> Signatures (CAdES)) to Informational RFC
> 
> 
> My understanding is that this ID is technically equivalent to ETSI TS 101
> 733 V.1.7.3 (according to the abstract).
> 
> spt
> 
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Julien Stern
> >Sent: Friday, October 19, 2007 3:54 AM
> >To: [e-mail]
> >Subject: Re: Last Call: draft-ietf-smime-cades (CMS Advanced
> >Electronic Signatures (CAdES)) to Informational RFC
> >
> >
> >Hi,
> >
> >the RFC contains the same issues as the corresponding ETSI standard.
> >These issue will most likely by fixed in a revision of the
> >standard, but they are currently present.
> >
> >If the RFC is supposed to be strictly aligned with version
> >1.7.3 of ETSI 101 733, and if a new version revision of the
> >RFC is planned when the new revision of the ETSI standard
> >occurs, then dismiss these comments.
> >
> >Regards,
> >
> >--
> >Julien
> >
> >----------------------
> >In section 6.2.1:
> >
> >QUOTE:
> >| The complete-certificate-references attribute is an unsigned
> >attribute.
> >| It references the full set of CA certificates ...
> >
> >There can (and SHOULD in fact) be some other certificates (CRL
> >Issuers, OCSP responders, ...)
> >
> >
> >----------------------
> >In section 6.2.2:
> >
> >This section calls for a one-to-one mapping from the
> >revocation information on the certificates and talks about
> >certificate path.
> >
> >QUOTE:
> >| CompleteRevocationRefs shall contain one CrlOcspRef for the signing-
> >| certificate, followed by one for each OtherCertID in the
> >| CompleteCertificateRefs attribute.  The second and subsequent
> >| CrlOcspRef fields shall be in the same order as the OtherCertID to
> >| which they relate.
> >| At least one of CRLListID or OcspListID or OtherRevRefs should be
> >| present for all but the "trusted" CA of the certificate path.
> >
> >The certificate "path" is not a "path". It is a "tree" in the
> >general case. This makes the one-to-one mapping more complex
> >to implement. This may force the duplication of references.
> >And finally, it is not possible to always respect the latest
> >rules (e.g. for an OCSP responder with the no-check extension).
> >
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on [phone] or email [e-mail].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9SK0NBW037139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Oct 2007 13:00:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9SK0NjP037138; Sun, 28 Oct 2007 13:00:23 -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.13.5/8.13.5) with SMTP id l9SK0LBD037128 for <[e-mail]>; Sun, 28 Oct 2007 13:00:22 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 12199 invoked by uid 0); 28 Oct 2007 20:00:14 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 28 Oct 2007 20:00:14 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 28 Oct 2007 15:13:45 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RFC 3217 Errata
Cc: Henrick Hellstrцm <[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>

Dear RFC Editor:

Section 4.4 of RFC 3217 is ambiguous.  The text is silent about the RC2
parameter that indicates the effective key size.  This errata resolves the
ambiguity.

The first paragraph of section 4.4 says:

    This section contains a RC2 Key Wrap example. Intermediate values
    corresponding to the named items in section 4.1 are given in hexadecimal.

New:

    This section contains a RC2 Key Wrap example. Intermediate values
    corresponding to the named items in section 4.1 are given in 
hexadecimal. In
    this example, the effective key length parameter for the RC2 
algorithm should
    be 40 bits.

To aid implementors, this errata includes two examples.  The first one matches
section 4.4 and uses a 40-bit effective key size.  The second one uses a
128-bit effective key size.  Many thanks to Peter Yee for generating the
examples and Blake Ramsdell for checking them.

Thanks,
   Russ

==========================================

RC2 Effective Key Bits: 40

CEK is (16 bytes):
  b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9

LENGTH is: 16

LCEK is (17 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9

PAD is (7 bytes):
  48 45 cc e7 fd 12 50

LCEKPAD is (24 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50

SHA-1 Digest is (20 bytes):
  0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
  7e ca 48 06

ICV is (8 bytes):
  0a 6f f1 9f db 40 49 88

LCEKPADICV is (32 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88

IV is (8 bytes):
  c7 d9 00 59 b2 9e 97 f7

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

TEMP1 (32 bytes):
  a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8
  ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7

TEMP2 (40 bytes):
  c7 d9 00 59 b2 9e 97 f7 a0 1d a2 59 37 93 12 60
  e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32
  9f a9 8a 07 a3 1f f7 a7

TEMP3 (40 bytes):
  a7 f7 1f a3 07 8a a9 9f 32 99 8e ff 9e d7 8c ac
  b8 70 ce 04 f5 55 8c e4 60 12 93 37 59 a2 1d a0
  f7 97 9e b2 59 00 d9 c7

FinalIV (8 bytes):
  4a dd a2 2c 79 e8 21 05

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

RESULT (40 bytes):
  70 e6 99 fb 57 01 f7 83 33 30 fb 71 e8 7c 85 a4
  20 bd c9 9a f0 5d 22 af 5a 0e 48 d3 5f 31 38 98
  6c ba af b4 b2 8d 4f 35

==========================================

RC2 Effective Key Bits: 128

CEK is (16 bytes):
  b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9

LENGTH is: 16

LCEK is (17 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9

PAD is (7 bytes):
  48 45 cc e7 fd 12 50

LCEKPAD is (24 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50

SHA-1 Digest is (20 bytes):
  0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
  7e ca 48 06

ICV is (8 bytes):
  0a 6f f1 9f db 40 49 88

LCEKPADICV is (32 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88

IV is (8 bytes):
  c7 d9 00 59 b2 9e 97 f7

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

TEMP1 (32 bytes):
  03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66
  67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29

TEMP2 (40 bytes):
  c7 d9 00 59 b2 9e 97 f7 03 5e 97 2a b1 5c c4 c9
  c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae
  86 08 db c8 9e 64 ca 29

TEMP3 (40 bytes):
  29 ca 64 9e c8 db 08 86 ae 46 67 a2 bc 3e e4 67
  66 21 5a a3 ba 3d a0 c4 c9 c4 5c b1 2a 97 5e 03
  f7 97 9e b2 59 00 d9 c7

FinalIV (8 bytes):
  4a dd a2 2c 79 e8 21 05

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

RESULT (40 bytes):
  f4 d8 02 1c 1e a4 63 d2 17 a9 eb 69 29 ff a5 77
  36 d3 e2 03 86 c9 09 93 83 5b 4b e4 ad 8d 8a 1b
  c6 3b 25 de 2b f7 79 93




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9PCupGQ001406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 05:56:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9PCupbU001405; Thu, 25 Oct 2007 05:56:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9PCumZ4001395 for <[e-mail]>; Thu, 25 Oct 2007 05:56:50 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA57398 for <[e-mail]>; Thu, 25 Oct 2007 15:04:16 +0200
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102514563496:77897 ; Thu, 25 Oct 2007 14:56:34 +0200 
Date: Thu, 25 Oct 2007 14:56:32 +0200
From: "Denis Pinkas" <[e-mail]>
To: "ietf-smime" <[e-mail]>
Subject: Comments on draft-ietf-smime-ibearch-05.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/10/2007 14:56:34, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/10/2007 14:56:47, Serialize complete at 25/10/2007 14:56:47
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are preliminary comments on this draft:

1 - Both the title of the document and the abstract are misleading.

     Identity-based Encryption Architecture

     This document describes the security architecture required 
     to implement identity-based encryption, a public-key 
     encryption technology that uses a user's identity to 
     generate their public key. 

The content of the document mandates the use of on-line trusted 
server by the recipient.  This major constraint neither appears in 
the title, nor in the abstract.

A "real" Identity-based Encryption would mimic what is known today 
as an "Identity-based signature system".

If it existed algorithms allowing to support a "real" Identity-based 
Encryption system, it would have the following properties :

An off-line trusted authority would have a master private key and 
a master public key.

The trusted authority would deliver to each of its registered users 
a personal private key derived from the private key and their identity. 
That trusted authority would then deliver to each registered user :
a personal private key, an identifier and the master public key.

When a registered user would like to receive an encrypted message, it would 
provide to the sender both his identifier and the master public key. 
The sender would use them to encrypt the message.

The recipient would decrypt the message using his personal private key.

I have no idea if someone has already invented an algorithm to support that 
scheme, but in any case the wording "Identity-based Encryption" alone 
should not be used to avoid confusion later.

Note: the identifier is that case is not simply the name of a user, 
but at least his name, a validity period and a public "magic number".

2 - Since the abstract is unclear, by not mentioning the mandatory use 
of an on-line trusted server, it is amazing to read in the overview 
the following sentence:

        Identity-based encryption (IBE) is a public-key 
        encryption technology that allows a public key to be 
        calculated from an identity and the corresponding private 
        key to be calculated from the public key. 

Readers might think that anybody can compute the corresponding 
private key from the public key.   :-(


3 - The next question is whether the use of new algorithms is really necessary 
to support an architecture where an on-line trusted server is called by the recipients, 
and where the sender uses both a public key and the recipient's identity.

It seems that a system where senders would encrypt both a random key 
and the recipient's identity under the public key of an on-line trusted 
authority would exhibit the same advantages / disadvantages. The sender 
would encrypt the message under the random key.  The recipient would need 
to authenticate to the on-line server and pass the encrypted block to 
the on-line server to recover the value of the random key.
Then it will be able to decrypt the encrypted message.


4 - It is questionable whether this draft should continued on the standard 
track within the S-MIME working group. BTW, this draft is not written 
in accordance wit the IETF template since the target category is not indicated.

Denis






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9NLnpeB096492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 14:49:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9NLnphP096491; Tue, 23 Oct 2007 14:49:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9NLnlO4096480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 14:49:48 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080ec3441c80fda0@[10.20.30.108]>
In-Reply-To: <01b901c8156f$7e87a0b0$1402a8c0@jotop>
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <000701c81211$4b5959b0$e20c0d10$@com> <01b901c8156f$7e87a0b0$1402a8c0@jotop>
Date: Tue, 23 Oct 2007 14:49:43 -0700
To: =?iso-8859-1?Q?J=F6rg_Schwenk?=  <[e-mail]>, <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: AW: Header Protection for S/MIME
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>

Everyone: please read RFC 4871 before suggesting headers and 
canonicalization. The DKIM WG spend a long time thrashing on these 
issues, and the result came from being worn down, not clean crisp 
design. This is a minefield.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9NCMwPA041499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 05:22:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9NCMwMR041498; Tue, 23 Oct 2007 05:22:58 -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.13.5/8.13.5) with SMTP id l9NCMubD041491 for <[e-mail]>; Tue, 23 Oct 2007 05:22:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10364 invoked by uid 271); 23 Oct 2007 12:22:56 -0000
Received: from 134.147.64.5 by mx3.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.64.5):.  Processed in 0.054885 secs); 23 Oct 2007 12:22:56 -0000
Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx3.rz.ruhr-uni-bochum.de with SMTP; 23 Oct 2007 12:22:56 -0000
Received: (qmail 27556 invoked by uid 281); 23 Oct 2007 12:22:55 -0000
Received: from 134.147.40.27 (mNHiDSxtQuXceNKd/NAiPg==@134.147.40.27) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.40.27):.  Processed in 0.033422 secs); 23 Oct 2007 12:22:55 -0000
Received: from jotop.nds.ruhr-uni-bochum.de (HELO jotop) (mNHiDSxtQuXceNKd/NAiPg==@134.147.40.27) by c2-3-4.rz.ruhr-uni-bochum.de with (RC4-MD5 encrypted) SMTP; 23 Oct 2007 12:22:55 -0000
From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[e-mail]>
To: <[e-mail]>
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <000701c81211$4b5959b0$e20c0d10$@com>
Subject: AW: Header Protection for S/MIME
Date: Tue, 23 Oct 2007 14:23:18 +0200
Message-ID: <01b901c8156f$7e87a0b0$1402a8c0@jotop>
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <000701c81211$4b5959b0$e20c0d10$@com>
MIME-Version: 1.0
Thread-Index: AcgPnKZVJ9dcnn/IR4qJxvcvQYH1PgCc2jZwAMo7MYA=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01B5_01C81580.41CB5160"; micalg=SHA1
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_01B5_01C81580.41CB5160
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some ideas to the problems mentioned below:

- I think the final version of this draft should give clear =
recommendations
about how to group headers to be hashed, e.g. TO and CC should be =
grouped
together because both can be used to send signed SPAM, and DATE and =
SUBJECT
should be grouped together because they contain metainformation about =
the
message. Using more than one hashed subpaket can make things clearer, =
e.g. a
change in the FROM field can be handled differently by the client if =
this
change comes from a mailing list agent.

1.- 3. We could make comparisons more robust by strengthening the
canonicalization algorithms. E.g. we could only select the RFC 822 mail
address, without the nicknames. (However, the behavior of mail clients =
when
displaying the header lines must be taken into account.)

If we have found a good, robust canonicalization algorithm, from a =
practical
point of view it shouldn't be important if we embed the result of the
canonicalization directly in the attribute, or if we hash it before.=20

Joerg=20

-----Urspr=FCngliche Nachricht-----
Von: [e-mail] =
[mailto:[e-mail]] Im
Auftrag von Jim Schaad
Gesendet: Freitag, 19. Oktober 2007 07:31
An: 'Blake Ramsdell'
Cc: [e-mail]
Betreff: RE: Header Protection for S/MIME

...

I think that there is a shortage here as with the current embedded =
message
draft in terms of guidance about what to do for changed headers.  A
statement to the user that "one or more of the following headers was
changed" is more confusing to the user than displaying two sets of =
headers
which might be the default behavior with the current documents.

...

I do have some other issues with this document as it currently stands.

1.  As you pointed out this document does not really meet the stated
criteria of finding out what header was changed.  As in the DKIM world =
all
you know is that someone changed the headers in such as way that the
canonicalization algorithm did not ignore what the change was.

2.  It is not clear to me that just placing the data of the headers into =
the
attribute and providing some ways of canonicalizing the comparisons =
between
the actual header and the attribute header is a better approach.

3.  It is not clear to me that this approach is actually smaller than
placing the headers to be protected into the attribute directly.

All that being said, my preferred solution to this problem has always =
been
to place the headers to be protected into an attribute.  I have never =
been a
fan of the embedded message approach.

Jim



------=_NextPart_000_01B5_01C81580.41CB5160
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
BSsOAwIaBQCgggKOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3
MTAyMzEyMjMxOFowIwYJKoZIhvcNAQkEMRYEFFXPGUMB4AfqMCpA2fy5sgnAOooPMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHgBgkrBgEEAYI3EAQxgdIw
gc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTow
OAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJI
MSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0
aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOA9gAAQAC5i5OY1QSqG4wgeIGCyqGSIb3DQEJEAILMYHS
oIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6
MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i
SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy
dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDgPYAAEAAuYuTmNUEqhuMA0GCSqGSIb3DQEBAQUABIGA
Prwm9irHSsHtEKCGcmxHnXt6Mf72pHOynunPVz5qe+j0+DAj3vyVEny9sx4xhrt4UoZVYPDrbE0U
wpXzR3fKZwE/z0N9TM6cRtxhe/66TfcBK2DqK9Z/aC46hei7y9T5Kj6gAO2T+xSL/7QjhG9hbpPD
sSe05TKYHAOH1GWtJtYAAAAAAAA=

------=_NextPart_000_01B5_01C81580.41CB5160--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9NCA25T039879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 05:10:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9NCA2Me039878; Tue, 23 Oct 2007 05:10:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l9NC9xBM039856 for <[e-mail]>; Tue, 23 Oct 2007 05:10:01 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4471e362b; Tue, 23 Oct 2007 20:22:43 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm9c471908b8; Sat, 20 Oct 2007 02:21:53 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 20 Oct 2007 02:21:53 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivwR-0001wL-Gj; Fri, 19 Oct 2007 13:47:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivwK-0001qo-Uq for [e-mail]; Fri, 19 Oct 2007 13:47:16 -0400
Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IivwJ-000244-Qs for [e-mail]; Fri, 19 Oct 2007 13:47:16 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EA7BF32990; Fri, 19 Oct 2007 17:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IivR7-0002iQ-Pn; Fri, 19 Oct 2007 13:15:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 19 Oct 2007 13:15:01 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-05.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Use of the RSA-KEM Key Transport Algorithm in CMS
	Author(s)	: J. Randall, B. Kaliski
	Filename	: draft-ietf-smime-cms-rsa-kem-05.txt
	Pages		: 23
	Date		: 2007-10-19
	
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 
   mechanism for transporting keying data to a recipient using the 
   recipient's RSA public key. This document specifies the conventions 
   for using the RSA-KEM Key Transport Algorithm with the Cryptographic 
   Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and 
   ISO/IEC 18033-2.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-05.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MGI3bw037858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 09:18:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9MGI3lW037857; Mon, 22 Oct 2007 09:18:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l9MGI1GU037849 for <[e-mail]>; Mon, 22 Oct 2007 09:18:02 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jme6471d1bd1; Tue, 23 Oct 2007 00:30:44 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2447182c7e; Fri, 19 Oct 2007 06:30:19 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 19 Oct 2007 06:30:19 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicoU-0003la-UF; Thu, 18 Oct 2007 17:21:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicoO-0003dH-96 for [e-mail]; Thu, 18 Oct 2007 17:21:48 -0400
Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iicns-0001HR-Cn for [e-mail]; Thu, 18 Oct 2007 17:21:48 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5D40A32981; Thu, 18 Oct 2007 21:20:46 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IicnO-0000ew-9O; Thu, 18 Oct 2007 17:20:46 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 18 Oct 2007 17:20:46 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: [e-mail]
Subject: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic  Signatures (CAdES)) to Informational RFC 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security WG (smime)
to consider the following document:

- 'CMS Advanced Electronic Signatures (CAdES) '
   <draft-ietf-smime-cades-06.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2007-11-01. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-06.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14070&rfc_flag=0


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9ME1PC5020796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 07:01:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9ME1POX020795; Mon, 22 Oct 2007 07:01:25 -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.13.5/8.13.5) with SMTP id l9ME1N7v020787 for <[e-mail]>; Mon, 22 Oct 2007 07:01:24 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30157 invoked by uid 271); 22 Oct 2007 14:01:23 -0000
Received: from 134.147.64.5 by mx3.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.64.5):.  Processed in 0.044772 secs); 22 Oct 2007 14:01:23 -0000
Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx3.rz.ruhr-uni-bochum.de with SMTP; 22 Oct 2007 14:01:23 -0000
Received: (qmail 21659 invoked by uid 281); 22 Oct 2007 14:01:22 -0000
Received: from 134.147.40.26 (ZB/UoYRplUIeCKm2fHsdQQ==@134.147.40.26) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.40.26):.  Processed in 0.016028 secs); 22 Oct 2007 14:01:22 -0000
Received: from nds28.nds.ruhr-uni-bochum.de (HELO ?134.147.40.26?) (ZB/UoYRplUIeCKm2fHsdQQ==@134.147.40.26) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Oct 2007 14:01:22 -0000
Message-ID: <[e-mail]>
Date: Mon, 22 Oct 2007 16:01:19 +0200
From: Lijun Liao <[e-mail]>
Reply-To: [e-mail]
Organization: Chair for Network and Data Security, Ruhr University Bochum
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: [e-mail]
Subject: RE: Header Protection for S/MIME
X-Enigmail-Version: 0.95.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>"The main
>security goal of mail message header protection is not to protect the whole
>RFC 2822 header against manipulation, but to make it possible for the
>receiving client to detect which headers have been changed." isn't exactly true,
>you can't figure out which headers have been changed, only that "something in
>the list of headers that were protected with the digest has changed".

That is what we mean. Perhaps we need to reorganize the sentences.

>I think that there is a shortage here as with the current embedded message
>draft in terms of guidance about what to do for changed headers.  A
>statement to the user that "one or more of the following headers was
>changed" is more confusing to the user than displaying two sets of headers
>which might be the default behavior with the current documents.

First, the most clients show only one set of headers. Second, if two sets of
headers are supported, there are some fields which are in both sets. This is 
more confusing to the end user than the proposed approach.

>I do have some other issues with this document as it currently stands.
>
>1.  As you pointed out this document does not really meet the stated
>criteria of finding out what header was changed.  As in the DKIM world all
>you know is that someone changed the headers in such as way that the
>canonicalization algorithm did not ignore what the change was.
Right. The goal is to detect whether there is any modification to the protected
headers. To find out what header was changed, surely one can put a list of 
entry (header field name and the hash value). However this is trivial. The
embedded message approach also does not provide any mechanism to find out it.

>2.  It is not clear to me that just placing the data of the headers into the
>attribute and providing some ways of canonicalizing the comparisons between
>the actual header and the attribute header is a better approach.
Surely you can define a data format to specify the headers to protected. However
it has the following disadvantages:
 2.1. It enlarges the message size;
 2.2. The header fields must be presented twice in a message
 2.3. The comparison of the header fields is complex, especially for the fields
      with multiple instances.
Hence putting the header fields in the CMS attribute needs more complexity and 
message size, but does not provide any more security.

>3.  It is not clear to me that this approach is actually smaller than
>placing the headers to be protected into the attribute directly.
See the comment to 2.

Regards,

Lijun





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MDXdlg017408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 06:33:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9MDXdVQ017407; Mon, 22 Oct 2007 06:33:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l9MDXbSV017396 for <[e-mail]>; Mon, 22 Oct 2007 06:33:38 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm13c471caf93; Mon, 22 Oct 2007 21:46:17 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb04717bf13; Fri, 19 Oct 2007 03:45:35 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 19 Oct 2007 03:45:35 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiapo-0005md-LV; Thu, 18 Oct 2007 15:15:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiapi-0005jl-VC for [e-mail]; Thu, 18 Oct 2007 15:15:02 -0400
Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiaph-0005cz-R4 for [e-mail]; Thu, 18 Oct 2007 15:15:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BDCBF32981; Thu, 18 Oct 2007 19:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iiaph-0003P2-Lk; Thu, 18 Oct 2007 15:15:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 18 Oct 2007 15:15:01 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cades-06.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: CMS Advanced Electronic Signatures (CAdES)
	Author(s)	: J. Ross, et al.
	Filename	: draft-ietf-smime-cades-06.txt
	Pages		: 132
	Date		: 2007-10-18
	
This document defines the format of an electronic signature that can
   remain valid over long periods.  This includes evidence as to its
   validity even if the signer or verifying party later attempts to deny
   (i.e., repudiates the validity of the signature). 

   The format can be considered as an extension to RFC 3852 [4] and 
   RFC 2634 [5], where, when appropriate additional signed and 
   unsigned attributes have been defined.  

   The contents of this Informational RFC amounts to a 
   transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cades-06.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JK2jax020636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 13:02:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9JK2jHJ020635; Fri, 19 Oct 2007 13:02:45 -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.13.5/8.13.5) with SMTP id l9JK2h0b020628 for <[e-mail]>; Fri, 19 Oct 2007 13:02:44 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 78999 invoked from network); 19 Oct 2007 20:02:33 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.4.14 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 19 Oct 2007 20:02:33 -0000
X-YMail-OSG: 0bzQxVsVM1n_rRFZ3THKAT6yaViomgbg1XFfYwe4TSs4gMeTlpZArshSUFWKmjCWnHFUajOH4Q--
From: "Turner, Sean P." <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: RE: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic Signatures (CAdES)) to Informational RFC
Date: Fri, 19 Oct 2007 15:59:52 -0400
Organization: IECA, Inc.
Message-ID: <001c01c8128a$9d269f40$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: AcgSJ5Q7u1UeWcpUQxWn1DDzK73RDwAYRVKA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My understanding is that this ID is technically equivalent to ETSI TS 101
733 V.1.7.3 (according to the abstract).

spt 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Julien Stern
>Sent: Friday, October 19, 2007 3:54 AM
>To: [e-mail]
>Subject: Re: Last Call: draft-ietf-smime-cades (CMS Advanced 
>Electronic Signatures (CAdES)) to Informational RFC
>
>
>Hi,
>
>the RFC contains the same issues as the corresponding ETSI standard.
>These issue will most likely by fixed in a revision of the 
>standard, but they are currently present.
>
>If the RFC is supposed to be strictly aligned with version 
>1.7.3 of ETSI 101 733, and if a new version revision of the 
>RFC is planned when the new revision of the ETSI standard 
>occurs, then dismiss these comments.
>
>Regards,
>
>--
>Julien
>
>----------------------
>In section 6.2.1:
>
>QUOTE:
>| The complete-certificate-references attribute is an unsigned 
>attribute.
>| It references the full set of CA certificates ...
>
>There can (and SHOULD in fact) be some other certificates (CRL 
>Issuers, OCSP responders, ...)
>
>
>----------------------
>In section 6.2.2:
>
>This section calls for a one-to-one mapping from the 
>revocation information on the certificates and talks about 
>certificate path.
>
>QUOTE:
>| CompleteRevocationRefs shall contain one CrlOcspRef for the signing- 
>| certificate, followed by one for each OtherCertID in the 
>| CompleteCertificateRefs attribute.  The second and subsequent 
>| CrlOcspRef fields shall be in the same order as the OtherCertID to 
>| which they relate.
>| At least one of CRLListID or OcspListID or OtherRevRefs should be 
>| present for all but the "trusted" CA of the certificate path.
>
>The certificate "path" is not a "path". It is a "tree" in the 
>general case. This makes the one-to-one mapping more complex 
>to implement. This may force the duplication of references. 
>And finally, it is not possible to always respect the latest 
>rules (e.g. for an OCSP responder with the no-check extension).
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JHF3Hv005371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 10:15:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9JHF3NM005370; Fri, 19 Oct 2007 10:15:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JHF2eG005363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 19 Oct 2007 10:15:03 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EA7BF32990; Fri, 19 Oct 2007 17:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IivR7-0002iQ-Pn; Fri, 19 Oct 2007 13:15:01 -0400
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-cms-rsa-kem-05.txt 
Message-Id: <[e-mail]>
Date: Fri, 19 Oct 2007 13:15:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the RSA-KEM Key Transport Algorithm in CMS
	Author(s)	: J. Randall, B. Kaliski
	Filename	: draft-ietf-smime-cms-rsa-kem-05.txt
	Pages		: 23
	Date		: 2007-10-19
	
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 
   mechanism for transporting keying data to a recipient using the 
   recipient's RSA public key. This document specifies the conventions 
   for using the RSA-KEM Key Transport Algorithm with the Cryptographic 
   Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and 
   ISO/IEC 18033-2.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-05.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JE97wk086088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 07:09:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9JE9742086087; Fri, 19 Oct 2007 07:09:07 -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.13.5/8.13.5) with SMTP id l9JE951K086071 for <[e-mail]>; Fri, 19 Oct 2007 07:09:06 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 7079 invoked by uid 0); 19 Oct 2007 14:09:02 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 19 Oct 2007 14:09:02 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 19 Oct 2007 10:09:01 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: Henrick Hellstrцm <[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 propose the following errata to RFC 3217:

Section 4.4 of RFC 3217 is ambiguous.  The text is silent about the RC2
parameter that indicates the effective key size.  This errata resolves the
ambiguity.

The first paragraph of section 4.4 says:

    This section contains a RC2 Key Wrap example. Intermediate values
    corresponding to the named items in section 4.1 are given in hexadecimal.

New:

    This section contains a RC2 Key Wrap example. Intermediate values
    corresponding to the named items in section 4.1 are given in 
hexadecimal. In
    this example, the effective key length parameter for the RC2 
algorithm should
    be 40 bits.

To aid implementors, this errata includes two examples.  The first one matches
section 4.4 and uses a 40-bit effective key size.  The second one uses a
128-bit effective key size.  Many thanks to Peter Yee for generating the
examples and Blake Ramsdell for checking them.

==========================================

RC2 Effective Key Bits: 40

CEK is (16 bytes):
  b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9

LENGTH is: 16

LCEK is (17 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9

PAD is (7 bytes):
  48 45 cc e7 fd 12 50

LCEKPAD is (24 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50

SHA-1 Digest is (20 bytes):
  0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
  7e ca 48 06

ICV is (8 bytes):
  0a 6f f1 9f db 40 49 88

LCEKPADICV is (32 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88

IV is (8 bytes):
  c7 d9 00 59 b2 9e 97 f7

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

TEMP1 (32 bytes):
  a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8
  ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7

TEMP2 (40 bytes):
  c7 d9 00 59 b2 9e 97 f7 a0 1d a2 59 37 93 12 60
  e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32
  9f a9 8a 07 a3 1f f7 a7

TEMP3 (40 bytes):
  a7 f7 1f a3 07 8a a9 9f 32 99 8e ff 9e d7 8c ac
  b8 70 ce 04 f5 55 8c e4 60 12 93 37 59 a2 1d a0
  f7 97 9e b2 59 00 d9 c7

FinalIV (8 bytes):
  4a dd a2 2c 79 e8 21 05

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

RESULT (40 bytes):
  70 e6 99 fb 57 01 f7 83 33 30 fb 71 e8 7c 85 a4
  20 bd c9 9a f0 5d 22 af 5a 0e 48 d3 5f 31 38 98
  6c ba af b4 b2 8d 4f 35

==========================================

RC2 Effective Key Bits: 128

CEK is (16 bytes):
  b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9

LENGTH is: 16

LCEK is (17 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9

PAD is (7 bytes):
  48 45 cc e7 fd 12 50

LCEKPAD is (24 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50

SHA-1 Digest is (20 bytes):
  0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
  7e ca 48 06

ICV is (8 bytes):
  0a 6f f1 9f db 40 49 88

LCEKPADICV is (32 bytes):
  10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
  d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88

IV is (8 bytes):
  c7 d9 00 59 b2 9e 97 f7

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

TEMP1 (32 bytes):
  03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66
  67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29

TEMP2 (40 bytes):
  c7 d9 00 59 b2 9e 97 f7 03 5e 97 2a b1 5c c4 c9
  c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae
  86 08 db c8 9e 64 ca 29

TEMP3 (40 bytes):
  29 ca 64 9e c8 db 08 86 ae 46 67 a2 bc 3e e4 67
  66 21 5a a3 ba 3d a0 c4 c9 c4 5c b1 2a 97 5e 03
  f7 97 9e b2 59 00 d9 c7

FinalIV (8 bytes):
  4a dd a2 2c 79 e8 21 05

KEK (16 bytes):
  fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

RESULT (40 bytes):
  f4 d8 02 1c 1e a4 63 d2 17 a9 eb 69 29 ff a5 77
  36 d3 e2 03 86 c9 09 93 83 5b 4b e4 ad 8d 8a 1b
  c6 3b 25 de 2b f7 79 93



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JDSIjJ082017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 06:28:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9JDSIXJ082016; Fri, 19 Oct 2007 06:28:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JDSGo9082008 for <[e-mail]>; Fri, 19 Oct 2007 06:28:17 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l9JDSECN009070 for <[e-mail]>; Fri, 19 Oct 2007 09:28:14 -0400 (EDT)
Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Fri, 19 Oct 2007 09:28:14 -0400
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 09:28:13 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Header Protection for S/MIME
Date: Fri, 19 Oct 2007 09:28:13 -0400
Message-ID: <[e-mail]>
In-Reply-To: <000701c81211$4b5959b0$e20c0d10$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Header Protection for S/MIME
Thread-Index: AcgPnKZVJ9dcnn/IR4qJxvcvQYH1PgCc2jZwABAy/yA=
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <000701c81211$4b5959b0$e20c0d10$@com>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 19 Oct 2007 13:28:13.0454 (UTC) FILETIME=[E63F1AE0:01C81253]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15480001
X-TM-AS-Result: : Yes--9.302500-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTEzOTAwNi03MDQy?= =?us-ascii?B?ODctNzAzODI5LTEzOTAxMC03MDQwNDktNzAxODU0LTcwMzc0Ny03?= =?us-ascii?B?MDI3MjYtNzAxNjE4LTcwMzU0My03MDA4MTctNzAwNDc2LTcwNDAz?= =?us-ascii?B?NC03MDA4MzktNzEwMzc1LTcwMjM1OC03MDI4MDctNzAzMjgzLTcw?= =?us-ascii?B?NDQzMC03MDIwNTAtNzAwMzk4LTE0ODAzOS0xNDgwNTAtMjAwNDA=?=
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9JDSHo9082011
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Jim Schaad
>
> All that being said, my preferred solution to this problem has
> always been to place the headers to be protected into an attribute.
> I have never been a fan of the embedded message approach.
>

Well now that 3 alternatives are on the table, I prefer Jim's
approach because a header-protection-aware receiver can use
the correct header values rather than just generating a
"something is wrong" error.

Was this ever written up in an I-D that could be resurrected,
or if not, is anyone going to write one?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9J7sNh0052210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 00:54:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9J7sN1N052209; Fri, 19 Oct 2007 00:54:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9J7sL6N052202 for <[e-mail]>; Fri, 19 Oct 2007 00:54:22 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id 73DFE4F439 for <[e-mail]>; Fri, 19 Oct 2007 09:54:15 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 562A84428C for <[e-mail]>; Fri, 19 Oct 2007 09:54:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 107O0frDPbSl for <[e-mail]>; Fri, 19 Oct 2007 09:54:16 +0200 (CEST)
Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 5CD374400C for <[e-mail]>; Fri, 19 Oct 2007 09:54:15 +0200 (CEST)
Received: by mars.cry.pto (sSMTP sendmail emulation); Fri, 19 Oct 2007 09:54:15 +0200
From: "Julien Stern" <[e-mail]>
Date: Fri, 19 Oct 2007 09:54:15 +0200
To: [e-mail]
Subject: Re: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic Signatures (CAdES)) to Informational RFC
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[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.13 (2006-08-11)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

the RFC contains the same issues as the corresponding ETSI standard.
These issue will most likely by fixed in a revision of the standard,
but they are currently present.

If the RFC is supposed to be strictly aligned with version 1.7.3
of ETSI 101 733, and if a new version revision of the RFC is planned
when the new revision of the ETSI standard occurs, then dismiss these
comments.

Regards,

--
Julien

----------------------
In section 6.2.1:

QUOTE:
| The complete-certificate-references attribute is an unsigned attribute.
| It references the full set of CA certificates ...

There can (and SHOULD in fact) be some other certificates
(CRL Issuers, OCSP responders, ...)


----------------------
In section 6.2.2:

This section calls for a one-to-one mapping from the revocation
information on the certificates and talks about certificate path.

QUOTE:
| CompleteRevocationRefs shall contain one CrlOcspRef for the signing-
| certificate, followed by one for each OtherCertID in the 
| CompleteCertificateRefs attribute.  The second and subsequent 
| CrlOcspRef fields shall be in the same order as the OtherCertID to 
| which they relate.  
| At least one of CRLListID or OcspListID or OtherRevRefs should be present
| for all but the "trusted" CA of the certificate path.

The certificate "path" is not a "path". It is a "tree" in the
general case. This makes the one-to-one mapping more complex to
implement. This may force the duplication of references. And finally,
it is not possible to always respect the latest rules (e.g. for an
OCSP responder with the no-check extension).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9J5WuP4042097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 22:32:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9J5WuQo042096; Thu, 18 Oct 2007 22:32:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9J5Wt8u042087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 18 Oct 2007 22:32:56 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (pool-71-111-65-176.ptldor.dsl-w.verizon.net [71.111.65.176]) by smtp1.pacifier.net (Postfix) with ESMTP id 318276F31C; Thu, 18 Oct 2007 22:31:27 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Header Protection for S/MIME
Date: Thu, 18 Oct 2007 22:31:24 -0700
Message-ID: <000701c81211$4b5959b0$e20c0d10$@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: AcgPnKZVJ9dcnn/IR4qJxvcvQYH1PgCc2jZw
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>

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Blake Ramsdell
> Sent: Monday, October 15, 2007 7:28 PM
> To: Kemp, David P.
> Cc: [e-mail]
> Subject: Re: Header Protection for S/MIME
> 
> 
> On Mon, Oct 15, 2007 at 12:44:37PM -0400, Kemp, David P. wrote:
> > Perhaps there has been no discussion because there is nothing to
> > complain about.  Controversy, or "clash" in media terms, is what
> sells.
> > The document appears to be a well-thought-out approach to providing
> > header integrity protection (but not confidentiality, for which
> > encapsulation is required).  Unlike the current encapsulation
> approach,
> > it is compatible with header-protection-unaware applications, and it
> > avoids the issue of how to represent inner and outer headers to users
> by
> > not using an outer header in the first place.
> 
> Silence can also indicate apathy. So let's start diving into whether
> it's so
> cool that there's nothing to say, or we don't care so much that there's
> nothing to say.
> 
> I read this draft over, and indeed, it documents a new approach to
> header
> protection, and it appears to be heavily influenced by the DKIM
> approach to
> header processing. To hit the high points:
> 
> * A new signed attribute is introduced, which contains
> 
>   * An algorithm identifier to indicate a canonicalization algorithm to
> be
>     used when presenting the headers to the digesting algorithm
> 
>   * A digesting algorithm identifier
> 
>   * An ordered list of headers, multiple instances of a header are
> indicated
>     by listing the header name more than once
> 
>   * A digest of the canonical values of those headers
> 
> * Uh, that's pretty much it

I think that there is a shortage here as with the current embedded message
draft in terms of guidance about what to do for changed headers.  A
statement to the user that "one or more of the following headers was
changed" is more confusing to the user than displaying two sets of headers
which might be the default behavior with the current documents.

> 
> Now, there's some things in here that need fixing. I'm sure there's
> some ASN.1
> fun, especially debating NULL vs. absent parameters for
> CanonAlgorithmIdentifier. I'm sure there might be some opinions about
> whether
> the digest algorithm should be specified in the outer SignedData
> digestAlgorithms list. And the security goals need some work -- "The
> main
> security goal of mail message header protection is not to protect the
> whole
> RFC 2822 header against manipulation, but to make it possible for the
> receiving client to detect which headers have been changed." isn't
> exactly true,
> you can't figure out which headers have been changed, only that
> "something in
> the list of headers that were protected with the digest has changed".
> 
> One appealing aspect is that it is compatible with current practice --
> it is
> incremental functionality that oblivious clients will simply skip. And
> the
> cost of this approach is fairly little -- slightly increased message
> size.
> 
> OK, so I'll start. Is there some goal that we can achieve with this
> mechanism
> that is better than the "just wrap a whole message/rfc822 and lord
> knows how
> you merge the resulting headers" approach that is the current practice?
> 
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

I do have some other issues with this document as it currently stands.

1.  As you pointed out this document does not really meet the stated
criteria of finding out what header was changed.  As in the DKIM world all
you know is that someone changed the headers in such as way that the
canonicalization algorithm did not ignore what the change was.

2.  It is not clear to me that just placing the data of the headers into the
attribute and providing some ways of canonicalizing the comparisons between
the actual header and the attribute header is a better approach.

3.  It is not clear to me that this approach is actually smaller than
placing the headers to be protected into the attribute directly.

All that being said, my preferred solution to this problem has always been
to place the headers to be protected into an attribute.  I have never been a
fan of the embedded message approach.

Jim




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9ILxTeB006321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 14:59:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9ILxTx8006320; Thu, 18 Oct 2007 14:59:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sjpexch1.corp.ad.entrust.com (dmz09.entrust.jp [218.44.241.219]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9ILxSh5006312 for <[e-mail]>; Thu, 18 Oct 2007 14:59:28 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Erratum of draft-ietf-smime-cades-06.txt
Date: Fri, 19 Oct 2007 06:58:41 +0900
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Erratum of draft-ietf-smime-cades-06.txt
Thread-Index: AcgRztPkUyh9YhOuTMWV1pz95G1P4AAAvbZQ
From: "Kenji Urushima" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9ILxTh5006314
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

There is an erratum in the I-D.

=== [Page52]
=== 6.3.6 Time-stamped certificates and crls references attribute 
=== definition 

****
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) memberus(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26}
****

This should be following.

****
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26}
****

Regards,

- Kenji

============
Kenji URUSHIMA | Entrust Japan | http://japan.entrust.com/



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9ILKmac003630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 14:20:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9ILKmf2003629; Thu, 18 Oct 2007 14:20:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9ILKkqU003622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 18 Oct 2007 14:20:47 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5D40A32981; Thu, 18 Oct 2007 21:20:46 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IicnO-0000ew-9O; Thu, 18 Oct 2007 17:20:46 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic  Signatures (CAdES)) to Informational RFC 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 18 Oct 2007 17:20:46 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security WG (smime)
to consider the following document:

- 'CMS Advanced Electronic Signatures (CAdES) '
   <draft-ietf-smime-cades-06.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2007-11-01. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-06.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14070&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9IJF3k8092176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 12:15:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9IJF3m4092175; Thu, 18 Oct 2007 12:15:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9IJF20K092167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 18 Oct 2007 12:15:03 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BDCBF32981; Thu, 18 Oct 2007 19:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iiaph-0003P2-Lk; Thu, 18 Oct 2007 15:15:01 -0400
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-cades-06.txt 
Message-Id: <[e-mail]>
Date: Thu, 18 Oct 2007 15:15:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: CMS Advanced Electronic Signatures (CAdES)
	Author(s)	: J. Ross, et al.
	Filename	: draft-ietf-smime-cades-06.txt
	Pages		: 132
	Date		: 2007-10-18
	
This document defines the format of an electronic signature that can
   remain valid over long periods.  This includes evidence as to its
   validity even if the signer or verifying party later attempts to deny
   (i.e., repudiates the validity of the signature). 

   The format can be considered as an extension to RFC 3852 [4] and 
   RFC 2634 [5], where, when appropriate additional signed and 
   unsigned attributes have been defined.  

   The contents of this Informational RFC amounts to a 
   transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cades-06.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9IEpXMc066712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 07:51:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9IEpXDg066711; Thu, 18 Oct 2007 07:51:33 -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.13.5/8.13.5) with SMTP id l9IEpVHM066695 for <[e-mail]>; Thu, 18 Oct 2007 07:51:32 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6670 invoked by uid 271); 18 Oct 2007 14:51:22 -0000
Received: from 134.147.64.5 by mx3.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.64.5):.  Processed in 0.044054 secs); 18 Oct 2007 14:51:22 -0000
Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx3.rz.ruhr-uni-bochum.de with SMTP; 18 Oct 2007 14:51:22 -0000
Received: (qmail 24608 invoked by uid 281); 18 Oct 2007 14:51:22 -0000
Received: from 134.147.40.27 (mNHiDSxtQuUqhe27fWa1Ng==@134.147.40.27) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.40.27):.  Processed in 0.025712 secs); 18 Oct 2007 14:51:22 -0000
Received: from jotop.nds.ruhr-uni-bochum.de (HELO jotop) (mNHiDSxtQuUqhe27fWa1Ng==@134.147.40.27) by c2-3-4.rz.ruhr-uni-bochum.de with (RC4-MD5 encrypted) SMTP; 18 Oct 2007 14:51:21 -0000
From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Russ Housley'" <[e-mail]>
References: <001101c8042f$20b70b20$0301a8c0@Wylie> 
Subject: AW: Header Protection for S/MIME
Date: Thu, 18 Oct 2007 16:51:17 +0200
Message-ID: <02bd01c81196$56dab700$1b289386@jotop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: AcgMIZ+Hy6sUi0tPSC6AX/3QPCi4JAFRGhtg
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9IEpXHM066705
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

to start the discussion on our draft [1], I'd like to explain the idea and
the advantages it has (in our opinion) over the solution proposed in RFC
3851.

Idea

The idea is to put Information about the header in a CMS hashed subpacket.
Legacy mail clients may simply ignore this subpacket (i.e. they don't
recompute the hash value contained in this packet). Conforming mail clients
compute an additional hash value over some normalized header fields, and
include this hash value in CMS signature verification.

Advantages

1. Backward compatibility: Legacy mail clients are not affected by the
introduction of an additional signed subpacket. (This is in contrast to RFC
3851, where legacy clients will display only the outer header lines, without
check.)

2. Flexibility: Any combination of header lines can be protected. This may
range from introducing a single hashed subpacket for the most important
header lines (e.g. From, Sender, To, CC, Date, Subject) to separate hashed
subpackets for each line. Conforming clients may thus detect changes in sets
of lines, or single lines.

3. Easy implementation: If a header line has been changed, a warning can be
displayed (e.g. display the line in red).

4. Support for mailing lists: If a mail list agent changes the To header,
and if To was protected by its own hashed subpacket, the mail client will
display that this field has been changed.

I think our draft still needs a lot of refinement, and we will be grateful
for comments from this list.

We have implemented a Java client as a proof-of-concept, and a thunderbird
implementation is underway.

[1] http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt

Greeting

Joerg
www.nds.rub.de

________________________________________
Von: Russ Housley [mailto:[e-mail]] 
Gesendet: Donnerstag, 11. Oktober 2007 18:13
An: [e-mail]
Cc: [e-mail]; [e-mail]
Betreff: Re: Header Protection for S/MIME

I have not seen any discussion of this document on this list.  It is
proposing a very different approach to a problem that was discussed on this
mail list.  The current MSG specification includes a very different solution
to this problem.

We should be talking about this proposal ....

Russ

At 09:29 AM 10/1/2007, Turner, Sean P. wrote:


The authors of the following draft wanted me to bring their draft to your
attention: 

http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt 

spt 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9GEqomg019425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 07:52:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9GEqo13019424; Tue, 16 Oct 2007 07:52:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9GEqntE019418 for <[e-mail]>; Tue, 16 Oct 2007 07:52:49 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l9GEqmFm021867; Tue, 16 Oct 2007 10:52:48 -0400 (EDT)
Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Tue, 16 Oct 2007 10:52:48 -0400
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 10:52:48 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Header Protection for S/MIME
Date: Tue, 16 Oct 2007 10:52:47 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Header Protection for S/MIME
Thread-Index: AcgPnFEPp7g3QZDwQF2pR0Kf6iS3zgAYq8Lg
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Oct 2007 14:52:48.0414 (UTC) FILETIME=[37EB4BE0:01C81004]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15480001
X-TM-AS-Result: : Yes--8.016000-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMzM2Ni03MTE0?= =?us-ascii?B?MDItNzAxNTc2LTcwMjA0NC03MDA2MTgtNzA3ODAwLTcwMjE5MS03?= =?us-ascii?B?MDIzNTgtNzAyMjE0LTcwMTY0Ny03MDA3NjUtNzAxMjk0LTcwNDA1?= =?us-ascii?B?NS03MDk4MjMtNzAwODQ2LTcwNzE2My03MDE4MzctNzAzNjI5LTcw?= =?us-ascii?B?MjY0My03MDMyODMtMzAwMDE1LTEzOTAwNi0xMzkwMTAtMTIxNjIw?= =?us-ascii?B?LTcwMDA3My03MDUxNjctNzA5NTg0LTcwMDk5NC03MDA0NzYtNzAx?= =?us-ascii?B?NTM5LTcwODE3OS03MDE0NTUtNzA0NzEyLTE0ODAzOS0xNDgwNTAt?= =?us-ascii?B?MjAwNDA=?=
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9GEqotE019419
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>

Security is not an end in itself, it supports and facilitates
"mission applications" that do something meaningful for end
users.  End users want email (at least the older ones do, younger
folks use instant messaging), and I would think if the
goal is to have email that "just works" in terms of spam
resistance, the integrity attribute approach is much more
natural than S/MIME's confidentiality-oriented encapsulation.

I have not followed DKIM at all and am not in a position
to comment on what the spambuster community wants.  But if
they want security and ask S/MIME for help (in the form of
an already-written I-D, not just a vague request), it seems
that apathy from us is an inappropriate response.  We should
1) tell them why what they want is wrong from a security perspective,
2) accommodate their request by adopting the I-D, or
3) let them do their own security outside the S/MIME WG.

I don't think (1) applies, so do we want to help them (2) or
tell them we can't be bothered (3)?

Dave


-----Original Message-----
> From: Blake Ramsdell [mailto:[e-mail]]
>
> OK, so I'll start. Is there some goal that we can achieve with
> this mechanism that is better than the "just wrap a whole
> message/rfc822 and lord knows how you merge the resulting
> headers" approach that is the current practice?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9GEHhBB016335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 07:17:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9GEHhQu016334; Tue, 16 Oct 2007 07:17:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9GEHTb6016298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 07:17:30 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240802c33a785320c2@[10.20.30.249]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0624080dc3287b38eda4@[10.20.30.108]> <[e-mail]> <911C71EDB2C439B63590@public> <BE10533CC3E50C4F3595@public> <6A0DB8E11F1A1B403605@public> <[e-mail]> <[e-mail]>
Date: Tue, 16 Oct 2007 07:17:23 -0700
To: Blake Ramsdell <[e-mail]>, Henrick =?iso-8859-1?Q?Hellstr=F6m?=  <[e-mail]>, Russ Housley <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: [e-mail]
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>

At 8:07 PM -0700 10/15/07, Blake Ramsdell wrote:
>On Thu, Oct 04, 2007 at 07:54:29AM +0200, Henrick Hellstrцm wrote:
>>  I agree; my observations don't concern the algorithm itself, but only
>>  the effect the "example" in RFC 3217 might have on implementations of
>>  the algorithm.
>
>I propose the following errata to RFC 3217:
>
>Current first paragraph of section 4.4:
>
>This section contains a RC2 Key Wrap example. Intermediate values
>corresponding to the named items in section 4.1 are given in hexadecimal.
>
>New:
>
>This section contains a RC2 Key Wrap example. Intermediate values
>corresponding to the named items in section 4.1 are given in hexadecimal. In
>this example, the effective key length parameter for the RC2 algorithm should
>be 40 bits.

It is not "should be", it is "is".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9G388an058353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 20:08:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9G3883P058352; Mon, 15 Oct 2007 20:08:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9G3845W058321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Oct 2007 20:08:06 -0700 (MST) (envelope-from [e-mail])
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.0/Switch-3.3.0) with ESMTP id l9G38lrN002874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 20:08:53 -0700
X-DKIM: Sendmail DKIM Filter v1.0.0 spork.sendmail.com l9G38lrN002874
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1192504135; bh=1aMrIfKflGzZYuBzzfFWVyh7gAKVYg0HUCdw g4fUP1o=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=GPUAyYoLUot61fECJrJs8/5H8hkBMGfKrryU6Wj+hPEObAh3WBPJe13BYkQ6aXMpd 3So0odg2YJ6WTs2QHklHIAJw1W3VCRjC5M2R3iMY9jKn1phDkgDUgKQeLJkBLIByiXb MCg5M0nj0O5Briscs9hHvpWUbBbAI0vX7JkHMcI=
Date: Mon, 15 Oct 2007 20:07:21 -0700
From: Blake Ramsdell <[e-mail]>
To: Henrick =?iso-8859-1?Q?Hellstr=F6m?= <[e-mail]>, Russ Housley <[e-mail]>
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0624080dc3287b38eda4@[10.20.30.108]> <[e-mail]> <911C71EDB2C439B63590@public> <BE10533CC3E50C4F3595@public> <6A0DB8E11F1A1B403605@public> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.15 (2007-04-06)
X-MM-Ex-RefId: 149371::071015200854-7AD95B90-7CFF5055/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 Thu, Oct 04, 2007 at 07:54:29AM +0200, Henrick Hellstrцm wrote:
> I agree; my observations don't concern the algorithm itself, but only 
> the effect the "example" in RFC 3217 might have on implementations of 
> the algorithm.

I propose the following errata to RFC 3217:

Current first paragraph of section 4.4:

This section contains a RC2 Key Wrap example. Intermediate values
corresponding to the named items in section 4.1 are given in hexadecimal.

New:

This section contains a RC2 Key Wrap example. Intermediate values
corresponding to the named items in section 4.1 are given in hexadecimal. In
this example, the effective key length parameter for the RC2 algorithm should
be 40 bits.

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.13.5/8.13.5) with ESMTP id l9G2T33b056037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 19:29:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9G2T3Lr056036; Mon, 15 Oct 2007 19:29:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9G2T0Ow056027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 15 Oct 2007 19:29:00 -0700 (MST) (envelope-from [e-mail])
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.0/Switch-3.3.0) with ESMTP id l9G2TjLw018980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 19:29:50 -0700
X-DKIM: Sendmail DKIM Filter v1.0.0 spork.sendmail.com l9G2TjLw018980
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1192501791; bh=7xz9tX7wtslu9QhNc0UML3O64QRuraCLwFmV GbfxRYc=; 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=eJ9YM3F8Xnvm3gkg+X7+aLH6NevcPdCBaBub39 +3WVS9XoD6BIcmFu/M8aUKzny1Iu3/l9xoYDf30tKo0w9hRKDqQvG9Pnt2Jmw8V2JXb eJqopGtjSkyP97R1gwvXleXKUvzVHNeLeQbOYg6EyOZnY2ns/PxniDIUPIWfBchYVQ=
Date: Mon, 15 Oct 2007 19:28:19 -0700
From: Blake Ramsdell <[e-mail]>
To: "Kemp, David P." <[e-mail]>
Cc: [e-mail]
Subject: Re: Header Protection for S/MIME
Message-ID: <[e-mail]>
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[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::071015192950-7AD96B90-42DC1376/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 Mon, Oct 15, 2007 at 12:44:37PM -0400, Kemp, David P. wrote:
> Perhaps there has been no discussion because there is nothing to
> complain about.  Controversy, or "clash" in media terms, is what sells.
> The document appears to be a well-thought-out approach to providing
> header integrity protection (but not confidentiality, for which
> encapsulation is required).  Unlike the current encapsulation approach,
> it is compatible with header-protection-unaware applications, and it
> avoids the issue of how to represent inner and outer headers to users by
> not using an outer header in the first place.

Silence can also indicate apathy. So let's start diving into whether it's so
cool that there's nothing to say, or we don't care so much that there's
nothing to say.

I read this draft over, and indeed, it documents a new approach to header
protection, and it appears to be heavily influenced by the DKIM approach to
header processing. To hit the high points:

* A new signed attribute is introduced, which contains

  * An algorithm identifier to indicate a canonicalization algorithm to be
    used when presenting the headers to the digesting algorithm

  * A digesting algorithm identifier

  * An ordered list of headers, multiple instances of a header are indicated
    by listing the header name more than once

  * A digest of the canonical values of those headers

* Uh, that's pretty much it

Now, there's some things in here that need fixing. I'm sure there's some ASN.1
fun, especially debating NULL vs. absent parameters for
CanonAlgorithmIdentifier. I'm sure there might be some opinions about whether
the digest algorithm should be specified in the outer SignedData
digestAlgorithms list. And the security goals need some work -- "The main
security goal of mail message header protection is not to protect the whole
RFC 2822 header against manipulation, but to make it possible for the
receiving client to detect which headers have been changed." isn't exactly true,
you can't figure out which headers have been changed, only that "something in
the list of headers that were protected with the digest has changed".

One appealing aspect is that it is compatible with current practice -- it is
incremental functionality that oblivious clients will simply skip. And the
cost of this approach is fairly little -- slightly increased message size.

OK, so I'll start. Is there some goal that we can achieve with this mechanism
that is better than the "just wrap a whole message/rfc822 and lord knows how
you merge the resulting headers" approach that is the current practice?

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.13.5/8.13.5) with ESMTP id l9FGihS0096625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 09:44:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9FGihIP096624; Mon, 15 Oct 2007 09:44:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9FGigTl096605 for <[e-mail]>; Mon, 15 Oct 2007 09:44:42 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l9FGid1i027514 for <[e-mail]>; Mon, 15 Oct 2007 12:44:39 -0400 (EDT)
Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 15 Oct 2007 12:44:39 -0400
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Oct 2007 12:44:38 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-fd66a291-b2d4-40b5-95d4-44ccf2d064cd"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Header Protection for S/MIME
Date: Mon, 15 Oct 2007 12:44:37 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Header Protection for S/MIME
Thread-Index: AcgMJZX+gLsTXLaJQLGYQfGUvqzoaADIpBvw
References: <001101c8042f$20b70b20$0301a8c0@Wylie> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 15 Oct 2007 16:44:38.0987 (UTC) FILETIME=[AD51B9B0:01C80F4A]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15480001
X-TM-AS-Result: : Yes--18.215000-0-3-1
X-TM-AS-Category-Info: : 3:0.000000
X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE1LTE1MDU2Ny03MDk1?= =?us-ascii?B?ODQtNzAyNzI2LTcwMTYxOC03MTA5NzAtNzA5MTM3LTcxMDgzOS03?= =?us-ascii?B?MDU0NDEtNzAwODM5LTcxMDM3NS03MDQwNTUtNzAyNzYyLTcwNDcx?= =?us-ascii?B?Mi03MDE1NzYtNzA1ODYxLTcwODE3OS03MDI2MjYtNzAxMzM3LTcw?= =?us-ascii?B?Mzc4OC03MDM1NjYtNzA5NDE1LTcwNTM4OC03MDQyODctNzAzODI5?= =?us-ascii?B?LTcwMDQ3My03MDEyOTQtNzAzNzQ3LTcwNDQzMC0xMjE2NDgtMTg4?= =?us-ascii?B?MDE5LTMwMDAxNS03MDA3NDktNzAwMjk4LTcwMDA3My0xMzk3MDQt?= =?us-ascii?B?NzA4MTk2LTcwMDM0Mi0xMTE2MDQtMTg4MTE5LTcwNjExMC03MDAw?= =?us-ascii?B?MTgtNzAwMDA3LTcwMDAxNS03MDAwMTctNzAwMzYyLTE4ODExOC0x?= =?us-ascii?B?ODgxNDYtNzAwNzgyLTcwNjgxNy03MDI2MDktNzAzMzIxLTE4ODEx?= =?us-ascii?B?NC0xODgwMzgtNzAwMzQ1LTcwNTcxOC03MDE4MjctNzAwMjY0LTcw?= =?us-ascii?B?MjQ5Ny03MDQ0MjUtNzA0MTQxLTcwMDczMi03MDEwMTItNzAwOTA3?= =?us-ascii?B?LTcwMTMwNi03MDA2MjItNzAwMTYwLTcwMTU5NC03MDI3OTEtMTA2?= =?us-ascii?B?NjQwLTcwMDc1OC03MDM3MDctNzAwMDc4LTE4ODEyNS0xMTE2MDUt?= =?us-ascii?B?NzAwMDc0LTcwMDE0Mi03MDAwNzktMTg4MTI0LTE4ODA3OC0xMTE2?= =?us-ascii?B?MDgtNzAwNTI5LTcwMDA3Ny03MDA4MDItNzAxNjY5LTE4ODA1Ny03?= =?us-ascii?B?MDU0OTQtMTg4MTA1LTE4ODAzNS0xMTE2MDMtMTQ4MDM5LTE0ODA1?= =?us-ascii?B?MC0xNTkyMw==?=
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.

------=_NextPartTM-000-fd66a291-b2d4-40b5-95d4-44ccf2d064cd
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C80F4A.AD94B632"

------_=_NextPart_001_01C80F4A.AD94B632
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Perhaps there has been no discussion because there is nothing to
complain about.  Controversy, or "clash" in media terms, is what sells.
The document appears to be a well-thought-out approach to providing
header integrity protection (but not confidentiality, for which
encapsulation is required).  Unlike the current encapsulation approach,
it is compatible with header-protection-unaware applications, and it
avoids the issue of how to represent inner and outer headers to users by
not using an outer header in the first place.

=20

In short, what's not to like, and when can we buy it?  Seriously, if
this is a straw poll for accepting this proposal as a work item and
progressing it toward RFC, I vote yes.

=20

And if we need to spice things up with a little clash, "fielname" is
misspelled in section 2.1.

=20

=20

  _____ =20

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Thursday, October 11, 2007 12:13 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: Header Protection for S/MIME

=20

I have not seen any discussion of this document on this list.  It is
proposing a very different approach to a problem that was discussed on
this mail list.  The current MSG specification includes a very different
solution to this problem.

We should be talking about this proposal ....

Russ





------_=_NextPart_001_01C80F4A.AD94B632
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:210968756;
	mso-list-template-ids:1876587966;
	mso-list-style-name:"Style Bulleted 10 pt";}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ascii-font-family:Wingdings;
	mso-hansi-font-family:Wingdings;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Perhaps there has been no =
discussion
because there is nothing to complain about. &nbsp;Controversy, or =
&#8220;clash&#8221;
in media terms, is what sells. The document appears to be a =
well-thought-out
approach to providing header integrity protection (but not =
confidentiality, for
which encapsulation is required).&nbsp; Unlike the current encapsulation =
approach,
it is compatible with header-protection-unaware applications, and it =
avoids the
issue of how to represent inner and outer headers to users by not using =
an
outer header in the first place.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In short, what&#8217;s not to like, =
and
when can we buy it?&nbsp; Seriously, if this is a straw poll for =
accepting this
proposal as a work item and progressing it toward RFC, I vote =
yes.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>And if we need to spice things up =
with a
little clash, &#8220;fielname&#8221; is misspelled in section =
2.1.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, October =
11, 2007
12:13 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail];
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Header =
Protection for
S/MIME</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I have not seen any discussion of this document on this =
list.&nbsp; It
is proposing a very different approach to a problem that was discussed =
on this
mail list.&nbsp; The current MSG specification includes a very different
solution to this problem.<br>
<br>
We should be talking about this proposal ....<br>
<br>
Russ<br>
<br>
<br>
<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C80F4A.AD94B632--

------=_NextPartTM-000-fd66a291-b2d4-40b5-95d4-44ccf2d064cd--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9BGDANU038762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 09:13:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9BGDAIn038761; Thu, 11 Oct 2007 09:13:10 -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.13.5/8.13.5) with SMTP id l9BGD9jC038754 for <[e-mail]>; Thu, 11 Oct 2007 09:13:09 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 13794 invoked by uid 0); 11 Oct 2007 16:13:04 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (209.183.196.229) by woodstock.binhost.com with SMTP; 11 Oct 2007 16:13:04 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 11 Oct 2007 12:12:49 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Header Protection for S/MIME
Cc: [e-mail], [e-mail]
In-Reply-To: <001101c8042f$20b70b20$0301a8c0@Wylie>
References: <001101c8042f$20b70b20$0301a8c0@Wylie>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
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>

<html>
<body>
I have not seen any discussion of this document on this list.&nbsp; It is
proposing a very different approach to a problem that was discussed on
this mail list.&nbsp; The current MSG specification includes a very
different solution to this problem.<br><br>
We should be talking about this proposal ....<br><br>
Russ<br><br>
At 09:29 AM 10/1/2007, Turner, Sean P. wrote:<br><br>
<blockquote type=cite class=cite cite=""><font size=2>The authors of the
following draft wanted me to bring their draft to your attention:</font>
<br><br>
<font size=2 color="#0000FF"><u>
<a href="http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt">
http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt</a>
</u></font> <br><br>
<font size=2>spt</font> <br>
</blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9BFcos2035850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 08:38:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9BFcox1035848; Thu, 11 Oct 2007 08:38:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9BFcn66035840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 11 Oct 2007 08:38:50 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6F7DC32894; Thu, 11 Oct 2007 15:38:49 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ig07d-0007uZ-Bi; Thu, 11 Oct 2007 11:38:49 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-smime-ibearch (Identity-based Encryption  Architecture) to Proposed Standard 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 11 Oct 2007 11:38:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security WG (smime)
to consider the following document:

- 'Identity-based Encryption Architecture '
   <draft-ietf-smime-ibearch-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2007-10-25. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14987&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9BFMf61034808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 08:22:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9BFMfab034807; Thu, 11 Oct 2007 08:22:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9BFMe94034800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 11 Oct 2007 08:22:40 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B287632894; Thu, 11 Oct 2007 15:22:39 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ifzrz-0007iz-Km; Thu, 11 Oct 2007 11:22:39 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-smime-bfibecms (Using the Boneh-Franklin  and Boneh-Boyen identity-based encryption algorithms with the  Cryptographic Message Syntax (CMS)) to Proposed Standard 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 11 Oct 2007 11:22:39 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the S/MIME Mail Security WG (smime)
to consider the following document:

- 'Using the Boneh-Franklin and Boneh-Boyen identity-based encryption 
   algorithms with the Cryptographic Message Syntax (CMS) '
   <draft-ietf-smime-bfibecms-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2007-10-25. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-07.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14992&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9ADPxSE000116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 06:25:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9ADPxJ7000115; Wed, 10 Oct 2007 06:25:59 -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.13.5/8.13.5) with SMTP id l9ADPwvq099997 for <[e-mail]>; Wed, 10 Oct 2007 06:25:59 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 1747 invoked by uid 0); 10 Oct 2007 13:25:55 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 10 Oct 2007 13:25:55 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 10 Oct 2007 09:17:04 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Error in RFC 4134 Sample 4.4
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
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>

<html>
<body>
<tt>In RFC 4134 sample 4.4, there is a problem with the text as the
countersignature is not produced by Diane but by Alice.<br><br>
The first sentence of Section 4.4 says:<br><br>
&nbsp;&nbsp; Same as 4.1, but includes Carl's root cert, Carl's CRL, some
signed<br>
&nbsp;&nbsp; and unsigned attributes (Countersignature by
Diane).<br><br>
Is should say:<br><br>
&nbsp;&nbsp; Same as 4.1, but includes Carl's root cert, Carl's CRL, some
signed<br>
&nbsp;&nbsp; and unsigned attributes (Countersignature by Alice).<br>
</body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9A8AoMv070060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 01:10:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9A8AoRj070059; Wed, 10 Oct 2007 01:10:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cryptomathic.com (mail.cryptomathic.com [194.239.238.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9A8An8n070043 for <[e-mail]>; Wed, 10 Oct 2007 01:10:49 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Re: About countersignature in RFC 4134
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: <[e-mail]>
From: =?ISO-8859-1?Q?Jan_Ulrik_Kj=E6rsgaard?= <[e-mail]>
Date: Wed, 10 Oct 2007 10:20:14 +0200
X-MIMETrack: Serialize by Router on domino01/CRYPTOMAThIC(Release 7.0.2|September 26, 2006) at 2007/10/10 10:20:16, Serialize complete at 2007/10/10 10:20:16
Content-Type: multipart/alternative; boundary="=_alternative 002CF027C1257370_="
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 multipart message in MIME format.
--=_alternative 002CF027C1257370_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

In RFC 4134 sample 4.4 there is a problem with the text as the=20
countersignature is not produced by Diane but by Alice.

Jan
---
On Jan 26, 2006, at 1:17 PM, Russ Housley wrote:

Has anyone confirmed this issue. If it is confirmed, the WG should submit=20
an errata to the RFC Editor.=20

It looks like there is a discrepancy here -- the text says:

(Countersignature by Diane)

and the signature is indeed the serial number for Alice.


Jo=EBl, in your testing did the countersignature verify with Alice's=20
certificate?=20


I'm trying to figure out if the error here is the text "(Countersignature=20
by Diane)" or the serial number of the certificate needs to be changed to=20
Diane's. I'm presuming that it's just the text.=20

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




--=_alternative 002CF027C1257370_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><tt><font size=3D3>In RFC 4134 sample 4.4 there is a problem with the
text as the countersignature is not produced by Diane but by Alice.</font><=
/tt>
<br>
<br><tt><font size=3D3>Jan</font></tt>
<br><tt><font size=3D3>---<br>
On Jan 26, 2006, at 1:17 PM, Russ Housley wrote:<br>
</font></tt>
<br><tt><font size=3D3>Has anyone confirmed this issue. If it is confirmed,
the WG should submit an errata to the RFC Editor. </font></tt>
<br><tt><font size=3D3><br>
It looks like there is a discrepancy here -- the text says:<br>
<br>
(Countersignature by Diane)<br>
<br>
and the signature is indeed the serial number for Alice.<br>
<br>
</font></tt>
<br><tt><font size=3D3>Jo=EBl, in your testing did the countersignature ver=
ify
with Alice's certificate? </font></tt>
<br><tt><font size=3D3><br>
</font></tt>
<br><tt><font size=3D3>I'm trying to figure out if the error here is the
text &quot;(Countersignature by Diane)&quot; or the serial number of the
certificate needs to be changed to Diane's. I'm presuming that it's just
the text. </font></tt>
<br><tt><font size=3D3><br>
Blake<br>
--<br>
Blake Ramsdell | Sendmail, Inc. | </font></tt><a href=3Dhttp://www.sendmail=
.com/><tt><font size=3D3 color=3Dblue><u>http://www.sendmail.com</u></font>=
</tt></a><tt><font size=3D3><br>
<br>
<br>
<br>
</font></tt>
--=_alternative 002CF027C1257370_=--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l945sXb7064090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 22:54:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l945sXGw064089; Wed, 3 Oct 2007 22:54:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.streamsec.net ([81.27.0.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l945sVPY064072 for <[e-mail]>; Wed, 3 Oct 2007 22:54:32 -0700 (MST) (envelope-from [e-mail])
X-Snugfrom: [e-mail]
X-Snugip: 81.27.13.220
Received: from [e-mail] ([81.27.13.220]) by public([81.27.0.72]) with SMTP ID: Snug for [e-mail] to, 04 okt 07 07:54:03 (+0200)
Message-ID: <261D7CFC7B9797943624@public>
X-Snugserver-Info: UIDL=261D7CFC7B9797943624
X-Snugserver-Info: STAMP=20071004075403
Message-ID: <[e-mail]>
Date: Thu, 04 Oct 2007 07:54:29 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Mime-Version: 1.0
To: Paul Hoffman <[e-mail]>, [e-mail], Blake Ramsdell <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
References: <[e-mail]>	<[e-mail]>	<p0624080dc3287b38eda4@[10.20.30.108]> <[e-mail]>	<911C71EDB2C439B63590@public> <BE10533CC3E50C4F3595@public> <6A0DB8E11F1A1B403605@public>
In-Reply-To: <6A0DB8E11F1A1B403605@public>
X-Mailer: SnugMail
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Reply-To: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman wrote:
>> The test vectors increased the ambiguity because they didn't
>> say that they would only work with implementations that used 40
>> effective key bits by default. In fact, the only ones who have
>> successfully implemented RC Key Wrap so far are likely to be developers
>> who were programming against older versions of MS CryptoAPI and were
>> blissfully oblivious about the EKBParameter of RC2.
>
> It is likely that some made this mistake, sure, but it is also likely 
> that others figured it out by hand. None of us know what the 
> percentage on each side is, so "are likely" seems to be a stretch.
>
Perhaps, and yes you are right it was an intentional hyperbole, but I 
have actually made an effort to download a number of open source 
implementations of S/MIME, as everyone else here can. Not even Mozilla 
implements RC2 Key Wrap. It isn't *completely* unreasonable to assume 
that the absence of well specified test vectors have made a number of 
independent implementors skip or postpone this feature, as well as made 
a number of other implementors simply use MS CryptoAPI for RC2 without 
setting the EKBParameter. I found examples of both.

> The problem you have found is not a weakness in the RC2 key wrap 
> algorithm: it is (likely) a mistake by the person who generated the 
> example, and (likely) the person who tested them.
>
> This is worthy of an errata to RFC 3217 warning RC2 implementers about 
> the problem, pointing to this example as how easy it is to miss it. 
I agree; my observations don't concern the algorithm itself, but only 
the effect the "example" in RFC 3217 might have on implementations of 
the algorithm.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l940pGkD039986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 17:51:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l940pGCg039985; Wed, 3 Oct 2007 17:51:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [165.227.249.200] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l940pAPa039977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 17:51:11 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240805c329e638fe40@[165.227.249.200]>
In-Reply-To: <BE10533CC3E50C4F3595@public>
References: <[e-mail]> <[e-mail]> <p0624080dc3287b38eda4@[10.20.30.108]> <[e-mail]> <911C71EDB2C439B63590@public> <BE10533CC3E50C4F3595@public>
Date: Wed, 3 Oct 2007 17:51:07 -0700
To: "[e-mail]" <[e-mail]>, Blake Ramsdell <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: [e-mail]
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>

At 1:42 AM +0200 10/4/07, Henrick Hellstrцm wrote:
>Blake Ramsdell wrote:
>  > The good news is that the test vector caught the ambiguity.
>>  
>I strongly disagree. The test vectors did absolutely not catch the
>ambiguity.

The term "test vectors" is incorrect here. That term is not used in 
the document. The section in question very clearly is labelled 
"example".

>The test vectors increased the ambiguity because they didn't
>say that they would only work with implementations that used 40
>effective key bits by default. In fact, the only ones who have
>successfully implemented RC Key Wrap so far are likely to be developers
>who were programming against older versions of MS CryptoAPI and were
>blissfully oblivious about the EKBParameter of RC2.

It is likely that some made this mistake, sure, but it is also likely 
that others figured it out by hand. None of us know what the 
percentage on each side is, so "are likely" seems to be a stretch.

>Programmers like me and a bunch of others who were aware of all details
>of the RC2 algorithm, as well as the necessity of testing
>implementations against test vectors and reading RFCs to the letter,
>have not caught the ambiguity but simply left the RC2 Key Wrap algorithm
>unimplemented. You can't find it in our library. You can't find it in
>Crypto++. You can't find it in OpenSSL. You can however find it in some
>libraries that link to the MS CryptoAPI.

The problem you have found is not a weakness in the RC2 key wrap 
algorithm: it is (likely) a mistake by the person who generated the 
example, and (likely) the person who tested them.

This is worthy of an errata to RFC 3217 warning RC2 implementers 
about the problem, pointing to this example as how easy it is to miss 
it.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93Ng8PC035760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 16:42:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l93Ng8vm035759; Wed, 3 Oct 2007 16:42: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.streamsec.net ([81.27.0.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93Ng6aI035751 for <[e-mail]>; Wed, 3 Oct 2007 16:42:07 -0700 (MST) (envelope-from [e-mail])
X-Snugfrom: [e-mail]
X-Snugip: 81.27.13.220
Received: from [e-mail] ([81.27.13.220]) by public([81.27.0.72]) with SMTP ID: Snug for [e-mail] to, 04 okt 07 01:41:38 (+0200)
Message-ID: <BE10533CC3E50C4F3595@public>
X-Snugserver-Info: UIDL=BE10533CC3E50C4F3595
X-Snugserver-Info: STAMP=20071004014138
Message-ID: <[e-mail]>
Date: Thu, 04 Oct 2007 01:42:04 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Mime-Version: 1.0
To: Blake Ramsdell <[e-mail]>
Cc: [e-mail]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
References: <[e-mail]>	<[e-mail]>	<p0624080dc3287b38eda4@[10.20.30.108]> <[e-mail]> <911C71EDB2C439B63590@public>
In-Reply-To: <911C71EDB2C439B63590@public>
X-Mailer: SnugMail
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Reply-To: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake Ramsdell wrote:
> This observation is correct, based on my own testing here. In order to get the
> example in section 4.4 of RFC 3217 to work correctly, you need to use an
> effective key length parameter of 40 bits. The effective key length parameter
> is not discussed, and it is an important input to the RC2 algorithm.
>   
Thanks for confirming this.

> I do not see this -- I see that the input key length must be 128 bits, but
> there is no indication about any particular value for the effective key
> length. The language I see in RFC 3370, section 4.1:
>
> <snip>
> For key agreement of RC2 key-encryption keys, 128 bits MUST be
> generated as input to the key expansion process used to compute the
> RC2 effective key [RC2].
> </snip>
>
> This language appears to be compatible with the language in RFC 3217. If you
> have another concern in mind, let me know.
>
>   
Wrong section. You should be looking at RFC 3370, section 4.3.2:

<snip>
 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be 
used with the RC2ParameterVersion parameter set to 58.
</snip>

The RC2ParameterVersion parameter value of 58 is the encoding of 128 
Effective Key Bits. Hence, this is mandatory.

> I'm not sure, but I'd say "be careful of default parameters". Like I'm not
> sure what the default IV is also, for instance.
>
> The good news is that the test vector caught the ambiguity.
>   
I strongly disagree. The test vectors did absolutely not catch the 
ambiguity. The test vectors increased the ambiguity because they didn't 
say that they would only work with implementations that used 40 
effective key bits by default. In fact, the only ones who have 
successfully implemented RC Key Wrap so far are likely to be developers 
who were programming against older versions of MS CryptoAPI and were 
blissfully oblivious about the EKBParameter of RC2.

Programmers like me and a bunch of others who were aware of all details 
of the RC2 algorithm, as well as the necessity of testing 
implementations against test vectors and reading RFCs to the letter, 
have not caught the ambiguity but simply left the RC2 Key Wrap algorithm 
unimplemented. You can't find it in our library. You can't find it in 
Crypto++. You can't find it in OpenSSL. You can however find it in some 
libraries that link to the MS CryptoAPI.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93NHDCi034107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 16:17:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l93NHDEw034106; Wed, 3 Oct 2007 16:17:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93NHCl4034099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 3 Oct 2007 16:17:13 -0700 (MST) (envelope-from [e-mail])
Received: from blake-ramsdells-macbook-pro.local (c-24-17-217-200.hsd1.mn.comcast.net [24.17.217.200]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id l93NHCo9015455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 16:17:24 -0700
X-DKIM: Sendmail DKIM Filter v1.0.0 fife.sendmail.com l93NHCo9015455
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1191453445; bh=DJTrxhi8SSj/zUDMBk5y31ggmhjqbrK7CsZLq KjmfxY=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=r+9Pz2SbuwcDkrNPHv335YYIoAitqq3lKgowtDnGO0j+fC3Ptfmbo31MikKWAqCjt qaX4yksCo6wAiVYmDZHfEyH5z+rG7sIsz0zUpHRhiGZNMoFXoFQXmCP8TCITqGZG5Nx m8uHklueD5J6gymzmCewVrW/wXtbSMkOu+8/JCU=
Date: Wed, 3 Oct 2007 16:15:53 -0700
From: Blake Ramsdell <[e-mail]>
To: Henrick =?iso-8859-1?Q?Hellstr=F6m?= <[e-mail]>
Cc: [e-mail]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0624080dc3287b38eda4@[10.20.30.108]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.15 (2007-04-06)
X-MM-Ex-RefId: 149371::071003161725-0FD19B90-13460A1A/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, Oct 03, 2007 at 10:46:01AM +0200, Henrick Hellstrцm wrote:
> Firstly, RFC 3217 doesn't explicitly say that the test vectors are
> generated using 40 effective key bits. Without that information the test
> vectors are not unequivocally specified. You need that piece of
> information in order to reproduce the values.

This observation is correct, based on my own testing here. In order to get the
example in section 4.4 of RFC 3217 to work correctly, you need to use an
effective key length parameter of 40 bits. The effective key length parameter
is not discussed, and it is an important input to the RC2 algorithm.

> Secondly, RFC 3217 is now part of S/MIME Charter. This charter also
> includes RFC 3370 (CMS algorithms) which refers to RFC 3217, but states
> that RC2 Key Wrap keys MUST be used with 128 effective key bits
> (parameter value 58).

I do not see this -- I see that the input key length must be 128 bits, but
there is no indication about any particular value for the effective key
length. The language I see in RFC 3370, section 4.1:

<snip>
For key agreement of RC2 key-encryption keys, 128 bits MUST be
generated as input to the key expansion process used to compute the
RC2 effective key [RC2].
</snip>

This language appears to be compatible with the language in RFC 3217. If you
have another concern in mind, let me know.

> This is a potentially serious documentation bug. Say, for instance, that
> you are programming against MS CryptoAPI in Windows 2000 or earlier,
> which had 40 effective key bits as the default for RC2. In such case the
> test vectors in RFC 3217 *will* check out OK with default settings, and
> you might be mislead to believe you have implemented RFC 3370 correctly
> even though you haven't. If the test vectors in RFC 3217 had been
> generated using 128 effective key bits, or if RFC 3217 had explicitly
> specified the use of 40 effective key bits, such errors would be a lot
> more easy to spot during testing and code review.

I'm not sure, but I'd say "be careful of default parameters". Like I'm not
sure what the default IV is also, for instance.

The good news is that the test vector caught the ambiguity.

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.13.5/8.13.5) with ESMTP id l93IhLLk010049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 11:43:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l93IhLQB010048; Wed, 3 Oct 2007 11:43:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.streamsec.net ([81.27.0.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93IhJc6010041 for <[e-mail]>; Wed, 3 Oct 2007 11:43:20 -0700 (MST) (envelope-from [e-mail])
X-Snugfrom: [e-mail]
X-Snugip: 81.27.13.220
Received: from [e-mail] ([81.27.13.220]) by public([81.27.0.72]) with SMTP ID: Snug for [e-mail] on, 03 okt 07 20:42:50 (+0200)
Message-ID: <AEA74E03E9F0B0823528@public>
X-Snugserver-Info: UIDL=AEA74E03E9F0B0823528
X-Snugserver-Info: STAMP=20071003204250
Message-ID: <[e-mail]>
Date: Wed, 03 Oct 2007 20:43:16 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Mime-Version: 1.0
To: [e-mail]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
References: <[e-mail]>	<[e-mail]>	<p0624080dc3287b38eda4@[10.20.30.108]> <8795D8BBBA42CF093315@public> <FF4F25BD79BE70933499@public>
In-Reply-To: <FF4F25BD79BE70933499@public>
X-Mailer: SnugMail
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Reply-To: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman wrote:
>
> At 10:46 AM +0200 10/3/07, Henrick Hellstrцm wrote:
>> Firstly, RFC 3217 doesn't explicitly say that the test vectors are
>> generated using 40 effective key bits. Without that information the test
>> vectors are not unequivocally specified. You need that piece of
>> information in order to reproduce the values.
>
> After reading and re-reading, I do not see how you can say that the 
> test vectors are generated using 40 effective key bits. Where does 
> that show up in the RFC?

It *doesn't* say that in the RFC, which is *exactly* what I am
complaining about.

I discovered it myself by trial-and-error, and to be honest, it took me
a couple of days, because there were a lot of other variables I checked
first (such as endianess etc)




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93HbkOj004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 10:37:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l93HbkVV004561; Wed, 3 Oct 2007 10:37:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l93HbbTq004547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 10:37:40 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240820c329838074eb@[10.20.30.108]>
In-Reply-To: <8795D8BBBA42CF093315@public>
References: <[e-mail]> <[e-mail]> <p0624080dc3287b38eda4@[10.20.30.108]> <8795D8BBBA42CF093315@public>
Date: Wed, 3 Oct 2007 10:37:33 -0700
To: "[e-mail]" <[e-mail]>, [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
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>

At 10:46 AM +0200 10/3/07, Henrick Hellstrцm wrote:
>Firstly, RFC 3217 doesn't explicitly say that the test vectors are
>generated using 40 effective key bits. Without that information the test
>vectors are not unequivocally specified. You need that piece of
>information in order to reproduce the values.

After reading and re-reading, I do not see how you can say that the 
test vectors are generated using 40 effective key bits. Where does 
that show up in the RFC?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l938k7v8051882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 01:46:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l938k7OA051881; Wed, 3 Oct 2007 01:46:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.streamsec.net ([81.27.0.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l938k5o1051875 for <[e-mail]>; Wed, 3 Oct 2007 01:46:06 -0700 (MST) (envelope-from [e-mail])
X-Snugfrom: [e-mail]
X-Snugip: 81.27.13.220
Received: from [e-mail] ([81.27.13.220]) by public([81.27.0.72]) with SMTP ID: Snug for [e-mail] on, 03 okt 07 10:45:37 (+0200)
Message-ID: <8795D8BBBA42CF093315@public>
X-Snugserver-Info: UIDL=8795D8BBBA42CF093315
X-Snugserver-Info: STAMP=20071003104537
Message-ID: <[e-mail]>
Date: Wed, 03 Oct 2007 10:46:01 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Mime-Version: 1.0
To: [e-mail]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
References: <[e-mail]> <[e-mail]> <p0624080dc3287b38eda4@[10.20.30.108]>
In-Reply-To: <p0624080dc3287b38eda4@[10.20.30.108]>
X-Mailer: SnugMail
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Reply-To: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

The problem has two sides.

Firstly, RFC 3217 doesn't explicitly say that the test vectors are
generated using 40 effective key bits. Without that information the test
vectors are not unequivocally specified. You need that piece of
information in order to reproduce the values.

Secondly, RFC 3217 is now part of S/MIME Charter. This charter also
includes RFC 3370 (CMS algorithms) which refers to RFC 3217, but states
that RC2 Key Wrap keys MUST be used with 128 effective key bits
(parameter value 58).

This is a potentially serious documentation bug. Say, for instance, that
you are programming against MS CryptoAPI in Windows 2000 or earlier,
which had 40 effective key bits as the default for RC2. In such case the
test vectors in RFC 3217 *will* check out OK with default settings, and
you might be mislead to believe you have implemented RFC 3370 correctly
even though you haven't. If the test vectors in RFC 3217 had been
generated using 128 effective key bits, or if RFC 3217 had explicitly
specified the use of 40 effective key bits, such errors would be a lot
more easy to spot during testing and code review.

Hope that makes my case clear.

P.S. Why doesn't *this* list accept S/MIME signed email? ;) D.S.

Paul Hoffman wrote:
> [[ Never hurts to ask the original poster ... ]]
>
> At 4:37 PM -0400 10/2/07, Russ Housley wrote:
>> I asked a developer to take a look, and they are unable to figure out 
>> what the problem.  More information is needed to confirm.
>>
>> Russ
>>
>> At 11:21 PM 9/25/2007, Peter Gutmann wrote:
>>
>>> -- Snip --
>>>
>>> From:  [e-mail]
>>> Newsgroups: sci.crypt
>>> Subject: Error in RFC 3217
>>> Date: Wed, 01 Aug 2007 11:54:13 -0700
>>>
>>> There is an error in the test vectors for RC2 Key Wrap given in RFC
>>> 3217. The specification states that RC2 should be used with a 128 bit
>>> key and 128 effective key bits. The test vectors are however generated
>>> using RC2 with a 128 bit key but only 40 effective key bits (which BTW
>>> was the default for MS CryptoAPI prior to Windows XP).
>>>
>>> I don't know if R. Housley is reading these groups, but clearly this
>>> is an error that should be corrected.
>>>
>>> The algorithms specified in RFC 3217 are primarily used for S/MIME. If
>>> you have ever used S/MIME for encrypting email using a certificate
>>> with a DH public key and the RC2-CBC encryption algorithm, chances are
>>> you only got 40 bits of security even if you opted for 128 bit
>>> encryption.
>
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l92MnAv3009547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 15:49:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l92MnAQQ009546; Tue, 2 Oct 2007 15:49:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l92Mn5Wm009537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 15:49:06 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080dc3287b38eda4@[10.20.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 2 Oct 2007 15:49:02 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
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>

[[ Never hurts to ask the original poster ... ]]

At 4:37 PM -0400 10/2/07, Russ Housley wrote:
>I asked a developer to take a look, and they are unable to figure 
>out what the problem.  More information is needed to confirm.
>
>Russ
>
>At 11:21 PM 9/25/2007, Peter Gutmann wrote:
>
>>-- Snip --
>>
>>From:  [e-mail]
>>Newsgroups: sci.crypt
>>Subject: Error in RFC 3217
>>Date: Wed, 01 Aug 2007 11:54:13 -0700
>>
>>There is an error in the test vectors for RC2 Key Wrap given in RFC
>>3217. The specification states that RC2 should be used with a 128 bit
>>key and 128 effective key bits. The test vectors are however generated
>>using RC2 with a 128 bit key but only 40 effective key bits (which BTW
>>was the default for MS CryptoAPI prior to Windows XP).
>>
>>I don't know if R. Housley is reading these groups, but clearly this
>>is an error that should be corrected.
>>
>>The algorithms specified in RFC 3217 are primarily used for S/MIME. If
>>you have ever used S/MIME for encrypting email using a certificate
>>with a DH public key and the RC2-CBC encryption algorithm, chances are
>>you only got 40 bits of security even if you opted for 128 bit
>>encryption.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l92Kbqgk099027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 13:37:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l92Kbq5a099026; Tue, 2 Oct 2007 13:37:52 -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.13.5/8.13.5) with SMTP id l92Kbo3b099018 for <[e-mail]>; Tue, 2 Oct 2007 13:37:51 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 16550 invoked by uid 0); 2 Oct 2007 20:37:43 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 2 Oct 2007 20:37:43 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 02 Oct 2007 16:37:48 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I asked a developer to take a look, and they are unable to figure out 
what the problem.  More information is needed to confirm.

Russ

At 11:21 PM 9/25/2007, Peter Gutmann wrote:

>-- Snip --
>
>From:  [e-mail]
>Newsgroups: sci.crypt
>Subject: Error in RFC 3217
>Date: Wed, 01 Aug 2007 11:54:13 -0700
>
>There is an error in the test vectors for RC2 Key Wrap given in RFC
>3217. The specification states that RC2 should be used with a 128 bit
>key and 128 effective key bits. The test vectors are however generated
>using RC2 with a 128 bit key but only 40 effective key bits (which BTW
>was the default for MS CryptoAPI prior to Windows XP).
>
>I don't know if R. Housley is reading these groups, but clearly this
>is an error that should be corrected.
>
>The algorithms specified in RFC 3217 are primarily used for S/MIME. If
>you have ever used S/MIME for encrypting email using a certificate
>with a DH public key and the RC2-CBC encryption algorithm, chances are
>you only got 40 bits of security even if you opted for 128 bit
>encryption.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l91LhZHO060969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 14:43:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l91LhZFm060968; Mon, 1 Oct 2007 14:43:35 -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.13.5/8.13.5) with SMTP id l91LhYrO060960 for <[e-mail]>; Mon, 1 Oct 2007 14:43:34 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 19669 invoked by uid 0); 1 Oct 2007 21:43:26 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 1 Oct 2007 21:43:26 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 01 Oct 2007 17:43:31 -0400
To: [e-mail], [e-mail], [e-mail]
From: The IESG <[e-mail]> (by way of Russ Housley <[e-mail]>)
Subject: Last Call: draft-lepinski-dh-groups (Additional Diffie-Hellman Groups for use with IETF Standards) to Informational RFC 
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>

The IESG has received a request from an individual submitter to consider
the following document:

- 'Additional Diffie-Hellman Groups for use with IETF Standards '
    <draft-lepinski-dh-groups-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2007-10-23. Exceptionally,
comments may be sent to [e-mail] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l91Gvil6022124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 09:57:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l91Gvikj022123; Mon, 1 Oct 2007 09:57:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l91GveHj022115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 1 Oct 2007 09:57:41 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 79313328FA; Mon,  1 Oct 2007 16:57:40 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IcOaS-0002yR-Cq; Mon, 01 Oct 2007 12:57:40 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, smime mailing list <[e-mail]>, smime chair <[e-mail]>
Subject: Protocol Action: 'Cryptographic Message Syntax (CMS)  Authenticated-Enveloped-Data Content Type' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 01 Oct 2007 12:57:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data 
   Content Type '
   <draft-ietf-smime-cms-auth-enveloped-06.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-06.txt

Technical Summary

This document describes an additional content type for the 
Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data 
content type is intended for use with authenticated encryption modes.  
All of the various key management techniques that are supported in the 
CMS enveloped-data content type are also supported by the CMS 
authenticated-enveloped- data content type.
 
Working Group Summary

This document is a product of the smime working group.  The
document follows the style of RFC 3852 (CMS) in describing a content 
type and it's fields.  It is heavily based on an existing content type
(authenticated-data) therefore it is straightforward to understand 
the fields and their use.  The only discussion point on the list was 
the number and location of the authenticated attributes (authAttrs) 
field.  It was argued that the current document, which has one 
authAttrs field after the content, is optimized for the aes-gcm/ccm 
algorithms (see aes-gcm/ ccm draft) and that it would be better to 
have two locations for the authAttr field.

With two fields, efficiencies are afforded to both the current 
algorithms and yet-to-be-defined algorithms that work "faster/better" 
with the authAttrs before the content.  The counter argument against 
two fields was complexity.  The working group determined one field
after the data could adequately support the full range of algorithms
based on tests performed by Peter Gutmann.

Protocol Quality

Tim Polk reviewed this document for the IESG.  There are no current
implementations, although WG members have expressed interest in
implementing this specification.

Note to RFC Editor

Please make the following changes.

In section 3:

OLD:
  accept unsolicited encrypted messages, they become even more
  vulnerable to unwanted traffic since the present mitigation
                                       ^^^
NEW:
  accept unsolicited encrypted messages, they become even more
  vulnerable to unwanted traffic since many present mitigation
                                       ^^^^

In section 2.2:

OLD:
 the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for
                                  ^^^
NEW:
 the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for
                                  ^^^



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l91DVgJE099185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 06:31:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l91DVgHl099184; Mon, 1 Oct 2007 06:31:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l91DVeQV099171 for <[e-mail]>; Mon, 1 Oct 2007 06:31:41 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 51071 invoked from network); 1 Oct 2007 13:31:40 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.38.202 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 1 Oct 2007 13:31:39 -0000
X-YMail-OSG: xphwuHoVM1k_ao6TMrnh6vbrcBrfs8gIzCsUTfn6okMfIrSa7TT1q2lfKLFZ.aOv0tEH5EatBFJNEFZ8QwWHw9Z0IbL0ltmHSzTSA3As2lfKwvMAASdlDhUhAa3TXxONaSF5MllOdl8KWg--
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Header Protection for S/MIME
Date: Mon, 1 Oct 2007 09:29:43 -0400
Organization: IECA, Inc.
Message-ID: <001101c8042f$20b70b20$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C8040D.99A56B20"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcgELyA99Ll6Qe9jQVKXcNG0cRhulQ==
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_0012_01C8040D.99A56B20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The authors of the following draft wanted me to bring their draft to your
attention:

http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt

spt



------=_NextPart_000_0012_01C8040D.99A56B20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Header Protection for S/MIME</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">The authors of the following draft =
wanted me to bring their draft to your attention:</FONT>
</P>

<P><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect=
-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-liao-smimeheader=
protect-00.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0012_01C8040D.99A56B20--