Subject: i very want to find my love

From: "Marinka" <[email-masked]>
Date: Thu, 01 Nov 2007 05:54:00 +0200

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

Date: Tue, 30 Oct 2007 09:31:47 -0400
To: Alice Hagens <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RFC 3217 Errata
Cc: [email-masked], Henrick Hellstrцm <[email-masked]>, [email-masked]
Sender: [email-masked]

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
>

From: "Pope, Nick" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, "'Julien Stern'" <[email-masked]>, [email-masked]
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
Sender: [email-masked]

All,

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

Nick

> -----Original Message-----
> From: Turner, Sean P. [mailto:[email-masked]]
> Sent: 19 October 2007 21:00
> To: 'Julien Stern'; [email-masked]
> 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: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Julien Stern
> >Sent: Friday, October 19, 2007 3:54 AM
> >To: [email-masked]
> >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 +44 (0)1844 201800 or email [email-masked].
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". 

Date: Sun, 28 Oct 2007 15:13:45 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RFC 3217 Errata
Cc: Henrick Hellstrцm <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Thu, 25 Oct 2007 14:56:32 +0200
From: "Denis Pinkas" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Comments on draft-ietf-smime-ibearch-05.txt
Sender: [email-masked]

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

Date: Tue, 23 Oct 2007 14:49:43 -0700
To: =?iso-8859-1?Q?J=F6rg_Schwenk?=  <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: AW: Header Protection for S/MIME
Sender: [email-masked]

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.

From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[email-masked]>
To: <[email-masked]>
Subject: AW: Header Protection for S/MIME
Date: Tue, 23 Oct 2007 14:23:18 +0200
Sender: [email-masked]

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: [email-masked] =
[mailto:[email-masked]] Im
Auftrag von Jim Schaad
Gesendet: Freitag, 19. Oktober 2007 07:31
An: 'Blake Ramsdell'
Cc: [email-masked]
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"

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

To: [email-masked]
From: [email-masked]
Date: Fri, 19 Oct 2007 13:15:01 -0400
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-05.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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

--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
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Date: Thu, 18 Oct 2007 17:20:46 -0400
Cc: [email-masked]
Subject: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic  Signatures (CAdES)) to Informational RFC 
Reply-To: [email-masked]
Sender: [email-masked]

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
[email-masked] mailing lists by 2007-11-01. Exceptionally, 
comments may be sent to [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Date: Mon, 22 Oct 2007 16:01:19 +0200
From: Lijun Liao <[email-masked]>
Reply-To: [email-masked]
Organization: Chair for Network and Data Security, Ruhr University Bochum
To: [email-masked]
Subject: RE: Header Protection for S/MIME
Sender: [email-masked]

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

To: [email-masked]
From: [email-masked]
Date: Thu, 18 Oct 2007 15:15:01 -0400
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cades-06.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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

--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
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>
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.
Sender: [email-masked]

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Julien Stern
>Sent: Friday, October 19, 2007 3:54 AM
>To: [email-masked]
>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).
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-05.txt 
Date: Fri, 19 Oct 2007 13:15:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

--OtherAccess--

--NextPart--

Date: Fri, 19 Oct 2007 10:09:01 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: Henrick Hellstrцm <[email-masked]>
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Header Protection for S/MIME
Date: Fri, 19 Oct 2007 09:28:13 -0400
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 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?

From: "Julien Stern" <[email-masked]>
Date: Fri, 19 Oct 2007 09:54:15 +0200
To: [email-masked]
Subject: Re: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic Signatures (CAdES)) to Informational RFC
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "Jim Schaad" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Header Protection for S/MIME
Date: Thu, 18 Oct 2007 22:31:24 -0700
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Blake Ramsdell
> Sent: Monday, October 15, 2007 7:28 PM
> To: Kemp, David P.
> Cc: [email-masked]
> 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

Content-class: urn:content-classes:message
Subject: Erratum of draft-ietf-smime-cades-06.txt
Date: Fri, 19 Oct 2007 06:58:41 +0900
From: "Kenji Urushima" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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/

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic  Signatures (CAdES)) to Informational RFC 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Thu, 18 Oct 2007 17:20:46 -0400
Sender: [email-masked]

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
[email-masked] mailing lists by 2007-11-01. Exceptionally, 
comments may be sent to [email-masked] 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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cades-06.txt 
Date: Thu, 18 Oct 2007 15:15:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

--OtherAccess--

--NextPart--

From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Russ Housley'" <[email-masked]>
Subject: AW: Header Protection for S/MIME
Date: Thu, 18 Oct 2007 16:51:17 +0200
Sender: [email-masked]

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:[email-masked]] 
Gesendet: Donnerstag, 11. Oktober 2007 18:13
An: [email-masked]
Cc: [email-masked]; [email-masked]
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 

Content-class: urn:content-classes:message
Subject: RE: Header Protection for S/MIME
Date: Tue, 16 Oct 2007 10:52:47 -0400
From: "Kemp, David P." <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 16 Oct 2007 07:17:23 -0700
To: Blake Ramsdell <[email-masked]>, Henrick =?iso-8859-1?Q?Hellstr=F6m?=  <[email-masked]>, Russ Housley <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 15 Oct 2007 20:07:21 -0700
From: Blake Ramsdell <[email-masked]>
To: Henrick =?iso-8859-1?Q?Hellstr=F6m?= <[email-masked]>, Russ Housley <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Sender: [email-masked]

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

Date: Mon, 15 Oct 2007 19:28:19 -0700
From: Blake Ramsdell <[email-masked]>
To: "Kemp, David P." <[email-masked]>
Cc: [email-masked]
Subject: Re: Header Protection for S/MIME
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Header Protection for S/MIME
Date: Mon, 15 Oct 2007 12:44:37 -0400
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, October 11, 2007 12:13 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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'>
[email-masked] [mailto:[email-masked]] =
<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> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked];
[email-masked]<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--

Date: Thu, 11 Oct 2007 12:12:49 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Header Protection for S/MIME
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-smime-ibearch (Identity-based Encryption  Architecture) to Proposed Standard 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Thu, 11 Oct 2007 11:38:49 -0400
Sender: [email-masked]

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
[email-masked] mailing lists by 2007-10-25. Exceptionally, 
comments may be sent to [email-masked] 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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
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: [email-masked]
Cc: <[email-masked]>
Date: Thu, 11 Oct 2007 11:22:39 -0400
Sender: [email-masked]

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
[email-masked] mailing lists by 2007-10-25. Exceptionally, 
comments may be sent to [email-masked] 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

Date: Wed, 10 Oct 2007 09:17:04 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Error in RFC 4134 Sample 4.4
Cc: [email-masked]
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: About countersignature in RFC 4134
From: =?ISO-8859-1?Q?Jan_Ulrik_Kj=E6rsgaard?= <[email-masked]>
Date: Wed, 10 Oct 2007 10:20:14 +0200
Sender: [email-masked]

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_=--

Date: Thu, 04 Oct 2007 07:54:29 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked], Blake Ramsdell <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Reply-To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 3 Oct 2007 17:51:07 -0700
To: "[email-masked]" <[email-masked]>, Blake Ramsdell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Thu, 04 Oct 2007 01:42:04 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Reply-To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 3 Oct 2007 16:15:53 -0700
From: Blake Ramsdell <[email-masked]>
To: Henrick =?iso-8859-1?Q?Hellstr=F6m?= <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Sender: [email-masked]

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

Date: Wed, 03 Oct 2007 20:43:16 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[email-masked]>
To: [email-masked]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Reply-To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

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)

Date: Wed, 3 Oct 2007 10:37:33 -0700
To: "[email-masked]" <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Sender: [email-masked]

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?

Date: Wed, 03 Oct 2007 10:46:01 +0200
From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[email-masked]>
To: [email-masked]
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Reply-To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 2 Oct 2007 15:49:02 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 02 Oct 2007 16:37:48 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Fwd from sci.crypt: Error in RFC 3217
Sender: [email-masked]

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

Date: Mon, 01 Oct 2007 17:43:31 -0400
To: [email-masked], [email-masked], [email-masked]
From: The IESG <[email-masked]> (by way of Russ Housley <[email-masked]>)
Subject: Last Call: draft-lepinski-dh-groups (Additional Diffie-Hellman Groups for use with IETF Standards) to Informational RFC 
Sender: [email-masked]

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
[email-masked] mailing lists by 2007-10-23. Exceptionally,
comments may be sent to [email-masked] 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

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>
Subject: Protocol Action: 'Cryptographic Message Syntax (CMS)  Authenticated-Enveloped-Data Content Type' to Proposed Standard 
Date: Mon, 01 Oct 2007 12:57:40 -0400
Sender: [email-masked]

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

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Header Protection for S/MIME
Date: Mon, 1 Oct 2007 09:29:43 -0400
Organization: IECA, Inc.
Sender: [email-masked]

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